2014年在做一个Android终端设备开发过程中，发现了一个Android Framework层的Bug，给Google提交了issue和解决方案，和外界传言一致Google一般不太在意个人开发者提交的issue，直到2017年12月，再次提交了issue，在几轮沟通无果下，忍不住喷了Google几句后，终于该issue被转交给了Android development team处理，又经过快三个月的时间收到了下面的答复：
google issues：https://issuetracker.google.com/issues/70016687
issue背景：
在对我们自己研发的一款Android终端设备进行Camera拍照压力测试时，发现当拍照张数达到数万张时，出现OOM，导致系统崩溃。
issue分析解决过程：
该项目为开发一款Android工业终端设备，采用TI芯片方案，由于芯片方案商支持不够完善（主要TI被高通打的放弃了移动端芯片市场），Camera的HAL层需要我们自己移植适配。
分析思路：
首先看下Android系统架构图中中Camera功能模块的分布情况，从App层->Framework->HAL->Kernel一路下来：
（图片取自https://blog.csdn.net/asd1031/article/details/53699867）
- 首先怀疑测试app自身存在内存问题。
- Android application Framework，libraries层和jni相关模块是经过Google大量验证的模块，出现问题的概率比较小，暂时排除。
- 怀疑HAL层移植问题。
怀疑1：测试app问题
压力测试app由测试同学开发提供的，该app每隔3s触发一次拍照操作，并对拍摄的照片进行清理，以达到拍摄10万张照片的测试目的。基于以上分析，为了排除测试app问题，采用Android原生Camera app进行压力测试，编写monkey测试脚本，触发原生Camera app拍照，进行压力测试。（此处遇到的问题是：如何实现对照片的清理工作，直接触发shell环境下rm操作，并不会清除Android内部文件缓存索引，拍摄几千张照片后仍然会导致存储空间用尽，解决此问题也耗费了点时间，不过不是本文的重点，此处不做展开）
结果：通过原生Camera app进行测试后，仍然出现内存泄漏，此处基本排除测试app的问题。
怀疑2：HAl层
基于之前的分析，我们把怀疑对象聚集在我们自己集成的Android HAL层，在分析之前，简单描述下Android Camera拍照的流程：Linux Kernel提供标准的v4l2接口，供上层（此处即为HAL）获取图像原始数据，HAL层拿到图像数据进行编码（一般为jpeg），回调给Camera service。其中Linux Kernel下Camera驱动和HAL适配层一般由芯片厂商提供，其余部分由Linux Kernel和Android系统官方维护，开发。
这样对HAL的测试分为三步：
- 验证芯片厂商的Camera驱动是否存在问题。
- 验证HAL层图像数据捕获流程是否存在问题。
- 验证图像编码流程是否存在问题。
Camera驱动
Android系统是基于Linux Kernel开发，支持标准的v4l2接口，只需要编写一个简单的基于v4l2的视频捕获程序就可以验证camera驱动的问题，此处测试验证没有内存泄漏，排查驱动问题。
HAL层视频捕获流程
测试思路非常明确，难点在于要把芯片提供商的HAL层源码中进行视频捕获功能的模块剥离出来，单独进行压力测试。（由于原厂提供的HAL层代码，耦合比较严重，在不影响内部流程，结构的情况下，要找到适合的切面mock一些数据接口，才好进行有效的测试。）
经过以上的工作，进行了压力测试，系统未出现内存泄漏，基本排除HAL层捕获流程。
HAL层图像编码流程
继续对图像编码部分剥离，进行压力测试，发现内存泄漏，基本定位大概的泄漏位置，不过由于Android整个编码过程也进行层层的封装，泄漏位置还需要继续细致的定位，这样经过层层的细化，像剥洋葱一样一层层mock输入数据，最终定位在Android系统层的jpeg编码处理中：（frameworks/base/core/jni/android/graphics/YuvToJpegEncoder.cpp）
关于Android的jpeg编码：Android系统jpeg编码支持硬编码和软编码，如果芯片集成了jpeg硬件编码模块，会优先选择硬编码，而如果没有该模块，会采用软件的jpeg编码进行处理。
Android采用的软件编码库是业内知名的libjpeg库，而正是对这个库的使用出了问题：
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（），这个接口是释放压缩工作过程中所申请的资源，就是代码中的cinfo结构，该结构只占十几个字节的内存， 这样就导致了每拍摄一张照片，就泄漏一个cinfo的内存，当拍照数量达到万级时，才会有所察觉。
对这种数据流的控制，pipeline方式是比较好的方案，因为可以明确输入输出，这样非常方便通过伪造输入数据对各个模块进行单独的压力测试，最难控制的就是“洋葱”式的包裹调用，要像“剥洋葱”一样一层层的剥离，找准切面十分麻烦。
这个bug是否影响到你的Android手机
七成的概率下你的手机应该不会有这个问题，即时有这个问题你也很难发现这个问题，因为上面讲到android系统有两种编码方式选择，优先使用硬件编码模块，如果没有硬件编码模块，才会使用软编码的方式，而目前大部分中高端的芯片方案都集成了硬件模块，只有在少数低端芯片上才会使用软编码的方式，并且即使你的手机没有硬编码模块，用的软编码，也很难遇见这个问题，因为对于普通用户，持续拍摄上万张照片是不太可能的，第一受限于手机的存储空间（一万张照片，至少要30G的空间），第二即使能拍摄上万张照片，但要保持手机一直工作不重启也还是比较苦难的（总会死个机啥的）。
哈哈，这么一说发现这个bug其实是一个不会发生的bug了！！！不过我们之前的产品，定位于工业级别，对图像采集有比较高的要求，所以制定了10万张照片的测试标准，也就让我发现了这个不会影响到大部分人的bug。
最后再吐槽下Google
该bug在2014年就已经提交了issue，不过没持续关注，过了几个月被莫名其妙的关闭了，当时没有在意，不过当Android 6.0，7.0版本出来时，我都看了下这个bug，一直存在，所以在去年（2017年）12月份又提了一个issue，Google方面的处理人仍然各种推诿扯皮，最后我没忍住喷了几句，这次Google方面回复会转给开发团队处理，终于在今年（2018年）给出了fixed的结论。
