From http://blog.chinaunix.net/uid-13614124-id-4054242.html
From http://blog.csdn.net/bd_zengxinxin/article/details/47432223?ref=myread
上一篇讲述了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的内存增长减少了,但其实这也很有用,把握好下一步的方向不也很关键吗?
![](https://i-blog.csdnimg.cn/blog_migrate/603ffb65412613cdb24cfc8b622470b6.png)
参考:http://bricolsoftconsulting.com/how-to-enable-native-heap-tracking-in-ddms/
二、PC设置
在C:\Documents and Settings\Administrator\.android\ ddms.cfg 文件末尾添加
native=true
三、检查泄露
从SDK\tools 中启动独立的 DDMS ( ddms.bat )可以看见 native heap 选项卡
点击snapshot current... 按钮就可以了,如果按下±按钮,在点击 snapshot current 可以比较两次之间新分配了哪些空间。
有人说使用自己用源码编译出来DDMS 和模拟器,下面的 stacktrace 中的 File 和 Line 列就有值了。我们用的是真机啊。。。没有关系 ~~
找到自己的库函数***.so 后面的 Method 列中的地址。使用 NDK 中的 addr2line 工具,
用法:在命令行中addr2line.exe -e ***\obj\local\armeabi\***.so 地址
注意,一定要是obj 底下的 .so , lib 里面的是不含有符号表的。另外 Method 中的地址一般要将高 3 位置 0 ,80cc6e22 变为 000c6e22 。 80dxxxxx 的怎么变自己领悟吧。。。