AndroidApp定位和規避内存泄露方法研究.docVIP

Android App定位和规避内存泄露方法研究 内容 本文档包含如下内容: 如何确定App存在内存泄露 如何定位App的内存泄露位置 怎样避免内存泄露 名词解释 App：Application VSS - Virtual Set Size 虚拟耗用内存（包含共享库占用的内存） RSS - Resident Set Size 实际使用物理内存（包含共享库占用的内存） PSS - Proportional Set Size 实际使用的物理内存（比例分配共享库占用的内存） USS - Unique Set Size 进程独自占用的物理内存（不包含共享库占用的内存） Android查看内存的工具 DDMS查看系统内存 在sdk/ android-sdk_eng._linux-x86/tools下，启动ddms， ./ddms 通过ddms的sysInfo，如下图，我们可以看到系统内存目前的分布情况，这是一个饼状图， 从图中看BaiduReader大概占用了12%，10M左右的内存。 使用procrank查看进程内存 procrank 命令可以获得当前系统中各进程的内存使用快照，这里有PSS，USS，VSS，RSS。我们一般观察Uss来反映一个Process的内存使用情况，Uss 的大小代表了只属于本进程正在使用的内存大小，这些内存在此Process被杀掉之后，会被完整的回收掉， Vss和Rss对查看某一Process自身内存状况没有什么价值，因为他们包含了共享库的内存使用，而往往共享库的资源占用比重是很大的，这样就稀释了对Process自身创建内存波动。 而Pss是按照比例将共享内存分割，某一Process对共享内存的占用情况。 procrank 的代码在 /system/extras/procrank,,在模拟器或者设备上的运行文件位/system/xbin 在adb shell之后，我们运行procrank下图是Help 下图是BaiduReader运行下的所有进程的内存使用列表 从上图我们可以看到，所有的后台守护进程都比基于dalvik的虚拟机进程要小的多，zygote是虚拟机收个进程，由它来负责folk生成其他的虚拟机进程，而刚才PSS中谈到的共享库，其实就是由Zygote加载的，而其他虚拟机进程与Zygote共享这些内存。 使用脚本配合procrank跟踪内存变化 使用procrank来跟踪某进程的使用哪个情况我们常常借助与脚本。这样就可以查看某一段时间的内存变化。 如创建一个文件：trackmem.sh chmod 775 trackmem.sh 内容如下： #!/bin/bash while true; do adb shell procrank | grep com.baidu.BaiduReader sleep 1 done 运行该脚本： ./trackmem.sh 这个脚本的用途是每1秒钟让系统输出一次BaiduReader的内存使用状况，如下图： 观察USS的变化，从7M多提高到了9M多，这是由于打开了一个比较消耗资源的阅读界面，之后的操作时，不断的重复打开关闭这个界面（Activity），会发现内存只会偶尔的下降一点，而不会跟随GC的回收策略，当Acitivity被关闭之后，相关的资源会一并回收，所以我们判断这个Activity很可能存在内存泄露。 怎样判断是否存在内存泄露 AndroidApp是基于虚拟机的，其内存管理都是由Dalvik代为管理的，GC的回收不是及时的，比如一个Activity被Finish掉之后，其内存的引用对象会在下次GC回收的时候，通过回收算法计算，如果这部分内存已经属于可回收的对象，那么这些垃圾对象会被一并回收，所以内存的趋势图大概如下： 如果我们怀疑某一次操作或者某个界面存在内存泄露，一般的查找方法是重复这个操作，或者重复打开关闭这个界面，理论上，每次关闭都会对应一次大的内存释放，而如果存在内存泄露的情况，举例如下图，在重复打开关闭Reader的阅读界面的时候，内存一直在向上爬升，也就是说每次关闭这个Activity的时候，有些应该释放的内存没有被释放掉 如何定位内存泄露的位置 查找内存泄露一种比较土但比较彻底的方法就是代码走查，我们可以一行行的分析对象的创建去留等等，但会很耗时间，也比较迷茫 这里给出一种通过工具来查找的方法，但此方法只适用于Java层的查找，C/C++是没用的，也就是说只针对与被虚拟机来管理的进程和内存。 现在向大家引荐Eclipse Memory Analyzer tool(MAT)，，可以直接使用RCP版本或者安装其eclipse的插件，下载地址是/mat/download