记一次android native 内存泄漏分析

最近有客户反馈，使用平台的SDK，进行扫码时，使用几个小时后，内存就变占满了，然后呢，系统就重启了。

于是，给客户脚本，ps之类拷机，定位，发现是system_server出现内存泄漏。这个大家伙，有java,有native.

通过的抓取2分钟时间内dumpsys meminfo差异 ：

主要在Native Heap增加。

好吧，确认是Native Heap出现内存泄漏无疑。

Native Heap的泄漏，主要还是通过开启 libc debug 来分析。

1.设置属性：

setprop libc.debug.malloc 1

setprop libc.debug.malloc.options backtrace

stop;start

注意不是重启，不然这些属性就失效了。另外，开启这个属性后，系统的运行速度会严重变慢。所以不同的测试场景，需要考虑系统负载。

2.抓取操作前后dumpheap 差异：

ps 获取下system_server的进程号，比如 520

am dumpheap -n 520 /sdcard/0.txt

am dumpheap -n 520 /sdcard/1.txt

可以多个。

3.解析上述dumpheap:

放在android工程根目录执行：

python native_heapdump_viewer.py 0.txt > 00.txt
python native_heapdump_viewer.py 1.txt > 11.txt

注意native_heapdump_viewer.py 可用相关参数。我这边没有使用。

native_heapdump_viewer.py下载

4.然后对比00.txt,11.txt,重点关注排前面的数据:

 

这边列出的，是按调用流程，从上到下。比如下面的代码，可以方便在工程中找到。

88432  25.39% 100.00%    20808     e8c29312 /system/lib/libc.so __pthread_start(void*) /proc/self/cwd/bionic/libc/bionic/pthread_create.cpp:198 (discriminator 1)
  4436088  23.52%  92.64%    17960       e71c5f28 /system/lib/libandroid_runtime.so android::AndroidRuntime::javaThreadShell(void*) frameworks/base/core/jni/AndroidRuntime.cpp:1174
  3736560  19.81%  84.23%    15327         e8cc53a2 /system/lib/libutils.so android::Thread::_threadLoop(void*) /proc/self/cwd/system/core/libutils/Threads.cpp:754
  2922464  15.50%  78.21%    15159           e89a880c /system/lib/libinputflinger.so android::InputReaderThread::threadLoop() /proc/self/cwd/frameworks/native/services/inputflinger/InputReader.cpp:949 (discriminator 1)
  2912784  15.45%  99.67%    15029             e89a6d38 /system/lib/libinputflinger.so android::InputReader::loopOnce() /proc/self/cwd/frameworks/native/services/inputflinger/InputReader.cpp:314

这样，一行行跟进去，终于发现在

InputReader.cpp:2277 ，每进来一个操作事件，被修改的代码，就new一个字符数组来获取某个属性，但并没有释放，醉了。

知道原因后，就改了这个属性的获取方式。然后测试，OK。