1. 内容
本文档包含如下内容:
l 如何确定App存在内存泄露
l 如何定位App的内存泄露位置
l 怎样避免内存泄露
2. 名词解释
App:Application
VSS - Virtual Set Size 虚拟耗用内存(包含共享库占用的内存)
RSS - Resident Set Size 实际使用物理内存(包含共享库占用的内存)
PSS - Proportional Set Size 实际使用的物理内存(比例分配共享库占用的内存)
USS - Unique Set Size 进程独自占用的物理内存(不包含共享库占用的内存)
3. 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跟踪内存变化(Linux 环境下面跑的内容)
使用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的插件,下载地址是http://www.eclipse.org/mat/downloads.php 。
Mat的解析文件是hprof文件。 这个文件存放了某Process的内存快照
如何从手机或者模拟器获得hprof文件呢?
adb shell
#ps (找一下要Kill的进程号)
# chmod 777 /data/misc
# kill -10 进程号
这样会在/data/misc目录下生成一个带当前时间的hprof文件,比如
heap-dump-tm1291023618-pid1059.hprof
但是这个文件不能直接被mat读取,我们需要借助android提供的工具hprof-conv 来把上面的hprof转化为mat可以读取的格式。
首先将文件pull到当前目录
adb pull /data/misc/heap-dump-tm1291023618-pid1059.hprof ./
然后借助hprof-conv转换一下格式,此工具在sdk/android-sdk_eng._linux-x86/tools下面.
./hprof-conv heap-dump-tm1291023618-pid1059.hprof readershot.hprof
用mat或eclipse打开(如果装mat插件的话) ,选择[Leak Suspects Report],如图 :
这样就Mat就会为我们自动生成一个泄露推测报告,如下图,
从报告中报告的三个问题,我们大约可以断定这些地方存在一些问题,
从上图中Suspect1中,可以看到由class loader加载的HashMap有内存聚集,大概分配了1.6M的内存,所以对照代码中的HashMapEntry,就可以准确定位到有可能存在内存泄露的地方,通过逻辑判断这部分是否有优化的可能。
这里顺便介绍一下dalvik.system.PahtClassLoader,这个是Android中Dalvik的系统类和程序类的装载器,所有的.dex都需要通过它的装载之后生成我们所需要的对象。
另外Mat还提供了其他的视图,比如上图可以通过类名/Class loadeer来展示各类所占用的堆空间大小,所占内存的比例,对象的数目,通过这些参数我们也可以判断哪些对象可能是不太正常的。
简单介绍一下ShallowHeap和RetainedHeap。
Shallow size就是对象本身占用内存的大小,不包含对其他对象的引用,也就是对象头加成员变量(不是成员变量的值)的总和。在32位系统上,对象头占用8字节,int占用4字节,不管成员变量(对象或数组)是否引用了其他对象(实例)或者赋值为null它始终占用4字节。
Retained size是该对象自己的shallow size,加上从该对象能直接或间接访问到对象的shallow size之和。换句话说,retained size是该对象被GC之后所能回收到内存的总和。
借助于Mat堆内存快照的分析,我们基本可以定位Java层的内存泄露的问题,Mat是个很强悍的工具,更多的用法请参考http://dev.eclipse.org/blogs/memoryanalyzer/。
而还有一些内存泄露通过Mat是查不出来的,比如native的代码,对C/C++是无能为力的,对于这些问题是本文无法涵盖的,相关可以参考valgrind(http://valgrind.org/)
如何避免内存泄露
AndroidSDK中有一篇文章专门写了怎样避免内存泄露,这篇文章的中文翻译我贴在了下面。除了下文中提到的Context和View的强引用,还有一些需要注意点:
1:BraodcastReceiver,ContentObserver,FileObserver在Activity onDeatory或者某类声明周期结束之后一定要unregister掉,否则这个Activity/类会被system强引用,不会被内存回收。
2:不要直接对Activity进行直接引用作为成员变量,如果不得不这么做,请用private WeakReference<Activity> mActivity来做,相同的,对于Service等其他有自己声明周期的对象来说,直接引用都需要谨慎考虑是否会存在内存泄露的可能;
3:很多内存泄露是由于循环引用造成的,比如a中包含了b,b包含了c,c又包含a,这样只要一个对象存在其他肯定会一直常驻内存,这要从逻辑上来分析是否需要这样的设计。
下文来自http://androidappdocs.appspot.com/resources/articles/avoiding-memory-leaks.html
Avoiding Memory Leaks
避免内存泄露
Android应用程序,至少是在 T-Mobile G1上,是被分配了16M的Heap。对于手机来说,这已经是很多内存了,但是对开发者而言,却显的很少。尽管你没有打算用光所有的内存,也应该尽量少用内存以至于其他应用程序不被杀掉。越多的应用程序被Android保存在内存里,用户在切换程序的时候就越快。作为我工作的一部分,我遇到的大部分 Android应用程序中的内存泄露问题都是因为相同的原因:对 Context保持一个长生命周期的引用。
在Android里,一个Context被用于很多操作,但是大部分是用于加载和访问资源。这就是为什么所有的widget在他们的构造里都接收一个Context的参数。在一个典型的Android应用程序里,你经常用到两种Context,Activity 和Application。开发者经常把前者传到需要Context的类和方法里。
@Override
protected void onCreate(Bundle state) {
super.onCreate(state);
TextView label = new TextView(this);
label.setText("Leaks are bad");
setContentView(label);
}
这就意味views有一个对这个activity的引用,也就是保持了该Activity里的所有引用,经常是整个view体系和它所有的资源。因此如果你"泄露"了Context("泄露"意思是你保存了一个引用,因此阻止了GC收集它),你就泄露了很多内存。如果你不注意的话,泄露整个Activity真的很容易。
当屏幕的orientation变化时,默认情况下系统会销毁当前的activity再创建一个保存原来状态的新activity,这时Android会从资源中重新加载这个application的UI。现在假设你写的一个application里有一个很大的bitmap,你又不想每次转屏都重新加载。最简单的方式就是把它保存为一个static变量:
private static Drawable sBackground;
@Override
protected void onCreate(Bundle state) {
super.onCreate(state);
TextView label = new TextView(this);
label.setText("Leaks are bad");
if (sBackground == null) {
sBackground = getDrawable(R.drawable.large_bitmap);
}
label.setBackgroundDrawable(sBackground);
setContentView(label);
}
这个代码非常快,但是也是非常错误的,它泄露了屏幕旋转前的activity。当一个 Drawable附到一个view上时,view就被作为一个callback设置到drawable上。在上面一小断代码里,就意味着该drawable有一个对textview的引用,而这个textview又有对这个activity(就是这个context)的引用,而这个activity里有很多对其他对象的引用(取决你的代码)。
这个例子是一个泄露Context的最简单的情况,你可以在 Home screen's source code(方法unbindDrawables())看到当一个activity被销毁时我们是怎么工作的,我们会设置保存drawable的callback为null。有很多情况可以造成一系列context泄漏,它们会很快地耗光你的内存,这些非常不好。
有两个简单的方法来避免context相关的内存泄露。最明显的方法是避免context超过自己的使用范围。上面的例子表明对外部静态变量的引用同样危险。第二种解决方法是用Application context。这个context会存活在整个application生命周期中,它不依靠activity的生命周期。如果你想保存一个需要context的长生命周期的对象,记住使用Application context。你可以通过调用 Context.getApplicationContext() 或者Activity.getApplication()来获得它。
总之,为了避免context相关的内存泄露,记得下面的步骤:
不要在context-activity里保存长生命周期的引用 (对于activity的引用,应该有和这个activiy相同的生命周期)
试着使用Application context来代替context-activity
如果你不想控制非静态内部类的生命周期,就要避免在一个activity里使用它,而要用一个静态的内部类,对外部的这个activity有一个弱引用。这种解决方法有一个实例: ViewRoot和它的内部类中有一个对外部类的WeakReference。
GC对内存泄露是无能为力的。
参考资料
How to use Eclipse Memory Analyzer to analyze JVM Memeory