“坑”描述：

在對我們自己研發的一款android終端進行camera拍照壓力測試時，發現當拍照張數達到幾萬張時，查看內存占用情況，發現內存泄露。

填“坑”：

frameworks/base/core/jni/android/graphics/YuvToJpegEncoder.cpp

bool YuvToJpegEncoder::encode(SkWStream* stream, void* inYuv, int width,int height, int* offsets, int jpegQuality) {jpeg_compress_struct    cinfo;skjpeg_error_mgr        sk_err;skjpeg_destination_mgr  sk_wstream(stream);cinfo.err = jpeg_std_error(&sk_err);sk_err.error_exit = skjpeg_error_exit;if (setjmp(sk_err.fJmpBuf)) {return false;}jpeg_create_compress(&cinfo);cinfo.dest = &sk_wstream;setJpegCompressStruct(&cinfo, width, height, jpegQuality);jpeg_start_compress(&cinfo, TRUE);compress(&cinfo, (uint8_t*) inYuv, offsets);jpeg_finish_compress(&cinfo);return true;
}

坑就在上面這個接口函數中：
熟悉libjpeg的同學會注意到，上面的接口在調用完jpeg_finish_compress（）后，沒有調用jpeg_destroy_compress（），這個接口是釋放壓縮工作過程中所申請的資源，主要就是jpeg壓縮對象。
由于android原生接口中，沒有調用jpeg_destroy_compress（）導致每次泄露幾十個字節，當拍照數量達到萬級時，才會有所察覺。

怎么找到這個坑的：

這個過程后面有時間會詳細寫下，目前心得就是模塊的架構十分重要，對這種數據流的控制，pipeline方式是比較好的方案，因為可以明確輸入輸出，然后通過偽造輸入輸出對各個模塊進行單獨的壓力測試。最難控制的就是“洋蔥”式的包裹調用，要像“剝洋蔥”一樣一層層的剝離十分麻煩。

你的android機上有這個問題嗎：

9成的概率下你的手機應該不會有這個問題，因為上面我講到是在我們做的一款終端上發現的問題，我們的終端芯片方案比較挫，沒有硬編碼模塊，導致使用了android的軟編碼方案，也就用到libjpeg這個模塊，也就觸發了上面問題函數接口的調用。

牢騷：

做底層系統開發就是這樣，一個bug耗費了很久的時間去測試，查找，驗證。一層層剝離模塊，逐步定位問題的大概位置，到最后精確定位問題，并解決，bug的解決可能就是一行代碼的事（上面就加上destroy接口即可），但著實耗費了不少時間，如果按照代碼行數計算kpi，這個performance應該是差的可以了。