native heap调试方法
原理：
纯C/C++ 编写的natvie进程，不容易查找内存泄露Google的bionic库为我们查找内存泄露提供了一个很好的API get_malloc_leak_info。利用它，我们很容易通过得到backtrace的方式找到涉嫌内存泄露的地方。
我们可以使用adb shell setprop libc.debug.malloc 1来设置内存的调试等级（debug_level）.对于不同的调试等级，内存分配管理函数操作句柄将指向不同的内存分配管理函数。
函数get_malloc_leak_info用于获取内存泄露信息。在分配内存时，记录下调用堆栈，在释放时清除它们。这样，剩下的就很有可能是产生内存泄露的根源
内存泄漏的判断：
判断内存泄漏的时候，先要区分是VM heap泄漏还是Native heap泄漏，区分的方式如下，在泄漏的平台上敲下
“dumpsys meminfo com.yunos.tv.yingshi.boutique”
shell下会打印出当前进程的内存使用和分配情况，如下：
如何得到native heap文件：
首先要确认debug 的code 是运行在native 进程，还是java进程.如果是在native进程，如下操作：
- 准备一个D版本的系统软件
2．setprop libc.debug.malloc 1 - 杀掉要分析的native进程
- 通过Kill -60 pid 发送一个信号给一个进程，产生一个native heap信息文件到/data/system/nativeheap目录,eng版本有这个目录，user版本需要用root权限创建一个 目录权限为777的nativeheapheap目录。
如果是java进程，需要在先确认SDK的本:
getprop ro.build.version.sdk
如果SDK=22线烧一个usr版本的img，再烧一个eng版本的boot.img
然后手动push一个libc_malloc_debug_leak.so=>/system/lib
(从D版本盒子获取/system/lib下)
如果是android4.4的盒子 可以直接用eng版本调试
setprop sys.systemserver.firstboot 0
setprop persist.sys.backup_log 1
reboot
setprop sys.systemserver.firstboot 0
setprop libc.debug.malloc 1
stop
start
如何分析
两种分析方式，比较通常用的是ddms图形化显示.
- 在C:\Documents and Settings\Administrator.android\ ddms.cfg 文件末尾添加 native=true,
- 从SDK\tools 中启动独立的 DDMS （ ddms.bat ）可以看见 native heap 选项卡
成功运行后的界面如下：
Native Heap页面，先点击boutique这个进程，在点击Native heap点击
snapshot Current Native heap Usage按钮,最后能看到每个so占用了多少内存以及百分比。过一段时间就能看见每个so的趋势了。
把怀疑的so 可以导出数据。
Snapshot显示了分配内存的地址（记做addressA），
这个地址是RAM地址，不是so的相对地址。为了得到相对地址，需要ps一下，找到你的pid，然后cat /proc/pid/maps,找到so的起始地址(记做addressB)。然后拿addressA - addressB，得到相对地址，用addr2line定位到哪一处调用。
VM heap 的泄漏，和native 相识，不过要切换到上图中的VM heap 这个page，
然后在点击你感兴趣的进程，然后在点击左上角绿色圆柱的那个图标（show heap update），就会出现下面的例子截图：
查看data object那一行的Total Size值，这个值代表的意思就是当前进程中Java对象所占用的内存总量，通过这个值来判断是否内存泄露。
但是我目前感觉该检测过程只是提供了一个方向来验证被怀疑的功能模块可能存在内存泄露，但具体哪里出现内存泄露，还需要log进行查看解决问题.