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对内存泄露是无能为力的。
