内存泄露分析手段

来源：互联网发布：中国网络的发展史编辑：程序博客网时间：2024/06/05 02:43

1.内存溢出后的Log是比较随机的报错，直接通过Log找错不可靠。
2.通过ddms 查看音乐进程内存情况，反复操作，找到复现的可能（类似黑盒测试，当然会有一些更专业的工具如MAT帮助）
3.找到复现路径，即点击进入播放界面很容易内存泄露，无法释放。
4.音乐更改的UI比较大，替换的图片也比较多，之前有些背景图片可能达到几百KB（后面图片已经优化），首先怀疑是否是图片的处理不当，导致内存泄露。
5.经过反复review代码，排除上述可能，如果早点分析hprof文件，不用在这块浪费太多时间。
6.分析hprof文件，发现viewpaper反复申请了大量的相同大小内存，地址却不同。可能是这块的问题，再查看代码，
发现viewpaper的确每次startActivity后，强转为子View paper，但是当退出view的时候，忘记去destroy activity。
7.锁定问题，与修辉讨论修改方案，monkeyrunner测试，内存水平正常。

8.内存泄露的可能性相当多，除了常见的Bitmap，Cursor释放，静态常量的不确定生命周期，还存在其他可能，分析时不要先入为主，最终还要仔细review出问题的代码。

Heap监测应用进程-内存使用情况

1. 启动eclipse后，切换到DDMS透视图，并确认Devices视图、Heap视图都是打开的；

2. 将手机通过USB链接至电脑，链接时需要确认手机是处于“USB调试”模式，而不是作为“Mass Storage”；

3. 链接成功后，在DDMS的Devices视图中将会显示手机设备的序列号，以及设备中正在运行的部分进程信息；

4. 点击选中想要监测的进程，比如system_process进程；

5. 点击选中Devices视图界面中最上方一排图标中的“Update Heap”图标；

6. 点击Heap视图中的“Cause GC”按钮（清理内存）；

7. 此时在Heap视图中就会看到当前选中的进程的内存使用量的详细情况。
说明：
a) 点击“Cause GC”按钮相当于向虚拟机请求了一次gc操作；
b) 当内存使用信息第一次显示以后，无须再不断的点击“Cause GC”，Heap视图界面会定时刷新，在对应用的不断的操作过程中就可以看到内存使用的变化；
c) 内存使用信息的各项参数根据名称即可知道其意思，在此不再赘述。
如何才能知道我们的程序是否有内存泄漏的可能性呢？

这里需要注意一个值：Heap视图中部有一个Type叫做data object，即数据对象，也就是我们的程序中大量存在的类，类型的对象。

在data object一行中有一列是“Total Size”，其值就是当前进程中所有Java数据对象的内存总量，一般情况下，这个值的大小决定了是否会有内存泄漏。

可以这样判断：
a) 不断的反复操作当前应用，同时注意观察data object的Total Size值；
b) 正常情况下Total Size值都会稳定在一个有限的范围内，也就是说由于程序中的的代码良好，没有造成对象不被垃圾回收的情况，所以说虽然我们不断的操作会不断的生成很多对象，而在虚拟机不断的进行GC的过程中，这些对象都被回收了，内存占用量会会落到一个稳定的水平；
c) 反之如果代码中存在没有释放对象引用的情况，则data object的Total Size值在每次GC后不会有明显的回落，随着操作次数的增多Total Size的值会越来越大，
直到到达一个上限后导致进程被kill掉。
d) 此处已system_process进程为例，在我的测试环境中system_process进程，所占用的内存的data object的Total Size，正常情况下会稳定在2.2~2.8之间，而当其值超过3.55后进程就会被kill。

1.生成heap dump

在DDMS左边的面板选择进程com.android.phone

然后在工具条上边点击 updates heap 按钮。这个时候切换到DDMS的VM Heap分页。