无论怎么小心,想完全避免bad code 是不可能的,此时就需要一些 工具来帮助我们检查代码中是否存在会造成内存泄漏的地方。 Android tools 中的 DDMS 就带有一个很不错的内存监测工具 Heap( 这里我使用 eclipse 的 ADT 插件,并以真机为例,在模拟器中的情 况类似 ) 。用 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 。
总之 ,使用DDMS 的 Heap 视图工具可以很方便的确认我们的程序 是否存在内存泄漏的可能 性。
四、内 存分析工具 MAT(Memory Analyzer Tool)
如果使用DDMS 确实发现了我们的程序中存在内存泄 漏,那又如何定位到具体出现问题的代码片段,最终找到问题所在呢?如果从头到尾的分析代码逻辑,那肯定会把人逼疯,特别是在维护别人写的代码的时候。这里 介绍一个极好的内存分析工具 -- Memory Analyzer Tool(MAT) 。
MAT是一个 Eclipse 插件,同时也有单独的 RCP 客户端。官方下载地址、 MAT 介绍和详细的使用教程请参见: www.eclipse.org/mat , 在此不进行说明了。另外在 MAT 安 装后的帮助文档里也有完备的使用教程。在此仅举例说明其使用方法。我自己使用的是 MAT 的 eclipse 插件,使用插件要比 RCP 稍微方便一些。
使用MAT 进行内存分析需要几个步骤,包括:生成 .hprof 文件、打开 MAT 并导入 .hprof 文件、使用 MAT 的视图工具分析内存。以下详细介绍。
(一 ) 生成 .hprof 文件
生成.hprof 文件的方法有很多,而且 Android 的不同版本中生成 .hprof 的方式也稍有差别,我使用的版 本的是 2.1 ,各 个版本中生成 .prof 文 件的方法请参考:
http://android.git.kernel.org/?p=platform/dalvik.git;a=blob_plain;f=docs/heap-profiling.html;hb=HEAD。
1. 打开 eclipse 并切换到 DDMS 透视图,同时确认 Devices 、 Heap 和 logcat 视图已经打开了;
2. 将手机设备链接到电脑,并确保使用“ USB 调试”模式链接,而不是“ Mass Storage “模式;
3. 链接成功后在 Devices 视图中就会看到设备的序列 号,和设备中正在运行的部分进程;
4. 点击选中想要分析的应用的进程,在 Devices 视图上方的一行图标按钮中, 同时选中“ Update Heap ” 和“ Dump HPROF file ” 两个按钮;
5. 这是 DDMS 工具将会自动生成当前选中进程的 .hprof 文件,并将其进行转换后存放在 sdcard 当中,如果你已经安装了 MAT 插件,那么此时 MAT 将会自动被启用,并开始对 .hprof 文件进行分析;
注意:第4 步和第 5 步能够正常使用前提是我们需要有 sdcard ,并且当前进程有向 sdcard 中写入的权限 (WRITE_EXTERNAL_STORAGE) , 否则 .hprof 文 件不会被生成,在 logcat 中 会显示诸如
ERROR/dalvikvm(8574): hprof: can't open /sdcard/com.xxx.hprof-hptemp: Permission denied.
的信息。
如果我们没有sdcard ,或者当前进程没有向 sdcard 写入的权限(如 system_process ),那我们可 以这样做:
6. 在当前程序中,例如 framework 中某些代码中,可以使用 android.os.Debug 中的
public static void dumpHprofData(String fileName) throws IOException
方法,手动的指定.hprof 文件的生成位置。例如:
xxxButton.setOnClickListener(new View.OnClickListener() {
public void onClick(View view) {
android.os.Debug.dumpHprofData("/data/temp/myapp.hprof");
... ...
}
}
上述代码意图是希望在xxxButton 被点击的时候开始抓取内存 使用信息,并保存在我们指定的位置: /data/temp/myapp.hprof , 这样就没有权限的限制了,而且也无须用 sdcard 。 但要保证 /data/temp 目 录是存在的。这个路径可以自己定义,当然也可以写成 sdcard 当中的某个路径。
(二 ) 使用 MAT 导入 .hprof 文件
1. 如果是 eclipse 自动生成的 .hprof 文件,可以使用 MAT 插件直接打开(可能是比较新的 ADT 才支持);
2. 如果 eclipse 自动生成的 .hprof 文件不能被 MAT 直接打开,或者是使用 android.os.Debug.dumpHprofData() 方 法手动生成的 .hprof 文 件,则需要将 .hprof 文 件进行转换,转换的方法:
例如我将.hprof 文件拷贝到 PC 上的 /ANDROID_SDK/tools 目录 下,并输入命令 hprof-conv xxx.hprof yyy.hprof , 其中 xxx.hprof 为 原始文件, yyy.hprof 为 转换过后的文件。转换过后的文件自动放在 /ANDROID_SDK/tools 目 录下。 OK ,到此 为止, .hprof 文 件处理完毕,可以用来分析内存泄露情况了。
3. 在 Eclipse 中点击 Windows->Open Perspective->Other->Memory Analyzer , 或者打 Memory Analyzer Tool 的 RCP 。在 MAT 中点击 File->Open File ,浏览 并导入刚刚转换而得到的 .hprof 文 件。
(三 ) 使用 MAT 的视图工具分析内存
导入.hprof 文件以后, MAT 会自动解析并生成报告,点击 Dominator Tree ,并按 Package 分组,选择自己所定义的 Package 类点右键,在弹出菜单中选择 List objects->With incoming references 。 这时会列出所有可疑类,右键点击某一项,并选择 Path to GC Roots -> exclude weak/soft references , 会进一步筛选出跟程序相关的所有有内存泄露的类。据此,可以追踪到代码中的某一个产生泄露的类。
MAT的界面如下图所示。
具体的分析方法在此不做说明了,因为在MAT 的官方网站和客户端的帮助文档中有十分 详尽的介绍。
了解MAT 中各个视图的作用很重要,例如 www.eclipse.org/mat/about/screenshots.php 中 介绍的。
总之使用MAT 分析内存查找内存泄漏的根本思路,就是 找到哪个类的对象的引用没有被释放,找到没有被释放的原因,也就可以很容易定位代码中的哪些片段的逻辑有问题了。
至此请各位自己动手,丰衣足食吧