“坑”描述：

在對(duì)我們自己研發(fā)的一款android終端進(jìn)行camera拍照壓力測(cè)試時(shí)，發(fā)現(xiàn)當(dāng)拍照張數(shù)達(dá)到幾萬張時(shí)，查看內(nèi)存占用情況，發(fā)現(xiàn)內(nèi)存泄露。

填“坑”：

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; }

坑就在上面這個(gè)接口函數(shù)中：
熟悉libjpeg的同學(xué)會(huì)注意到，上面的接口在調(diào)用完jpeg_finish_compress（）后，沒有調(diào)用jpeg_destroy_compress（），這個(gè)接口是釋放壓縮工作過程中所申請(qǐng)的資源，主要就是jpeg壓縮對(duì)象。
由于android原生接口中，沒有調(diào)用jpeg_destroy_compress（）導(dǎo)致每次泄露幾十個(gè)字節(jié)，當(dāng)拍照數(shù)量達(dá)到萬級(jí)時(shí)，才會(huì)有所察覺。

怎么找到這個(gè)坑的：

這個(gè)過程后面有時(shí)間會(huì)詳細(xì)寫下，目前心得就是模塊的架構(gòu)十分重要，對(duì)這種數(shù)據(jù)流的控制，pipeline方式是比較好的方案，因?yàn)榭梢悦鞔_輸入輸出，然后通過偽造輸入輸出對(duì)各個(gè)模塊進(jìn)行單獨(dú)的壓力測(cè)試。最難控制的就是“洋蔥”式的包裹調(diào)用，要像“剝洋蔥”一樣一層層的剝離十分麻煩。

你的android機(jī)上有這個(gè)問題嗎：

9成的概率下你的手機(jī)應(yīng)該不會(huì)有這個(gè)問題，因?yàn)樯厦嫖抑v到是在我們做的一款終端上發(fā)現(xiàn)的問題，我們的終端芯片方案比較挫，沒有硬編碼模塊，導(dǎo)致使用了android的軟編碼方案，也就用到libjpeg這個(gè)模塊，也就觸發(fā)了上面問題函數(shù)接口的調(diào)用。

牢騷：

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

總結(jié)

以上是生活随笔為你收集整理的修过的一个android framework原生系统代码bug的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。