最近有客户反馈,使用平台的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 可用相关参数。我这边没有使用。
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。