欢迎使用CSDN-markdown编辑器

Android native heap memory leak 实战（二） — DDMS 2013-12-26 16:29:44
分类： Android平台
上一篇讲述了Valgrind，后续发现还有memory leak，但是Valgrind没有给出详细的调用信息，所以只能作罢，寻找其他工具。
从网上了解到DDMS有个隐藏的页面，Native Heap。于是抱着试试看的态度，找来了一台Android设备，刷了CM，这么做的目的是为了得到userdebug/eng版本的ROM(查看命令：adb shell getprop ro.build.type)，一般的官方ROM都是user的，没有厉害的debug能力。于是开工！
第一步：setprop libc.debug.malloc 1。这里有四种prop可以设置，1是mem leak，5和10是内存越界，20是虚拟机。可悲的是5和10并没有被libc_malloc_debug库完美地支持，所以只有1好用。

第二步，stop, start。这些操作都是在device shell里面做的。设备会快速重启。

第三步，验证prop。getprop看看结果，然后ls一下，去logcat里看一下结果。如果结果都能对的上，那就可以继续了。

第四步，在ddms.cfg文件最后增加一行native=true并save。ddms.cfg位于c:\Users\xxx.android目录下。

第五步，打开单独的ddms（确保eclipse没有在跑），选择Native Heap页面，点击snapshot按钮。snapshot的过程有点慢。最后能看到每个so占用了多少内存以及百分比。过一段时间snapshot一次就能看到每个so的趋势了。

第六步，分析。snapshot显示了分配内存的地址（记做addressA），这个地址是RAM地址，不是so的相对地址。为了得到相对地址，需要ps一下，找到你的pid，然后cat /proc/pid/maps,找到so的起始地址(记做addressB)。然后拿addressA - addressB，得到相对地址，用addr2line定位到哪一处调用。这里我还用过objdump -dS libXXX.so > XXX.dump，把so反编译出来，分析XXX.dump，找到相对地址的调用位置，一看是_Znwj，这个就是new。其实，搞来搞去最终定位到new，等于浪费表情了。

这个工具远没有Mac Instrument强大，它不能定位到哪个函数占用了多少内存。它能做的就是告诉你哪个so的内存增长减少了，但其实这也很有用，把握好下一步的方向不也很关键吗？

参考：http://bricolsoftconsulting.com/how-to-enable-native-heap-tracking-in-ddms/