Android 性能优化之使用MAT分析内存泄露

转载请注明本文出自xiaanming的博客（http://blog.csdn.net/xiaanming/article/details/42396507），请尊重他人的辛勤劳动成果，谢谢！

我们平常在开发Android应用程序的时候，稍有不慎就有可能产生OOM，虽然JAVA有垃圾回收机，但也不能杜绝内存泄露，内存溢出等问题，随着科技的进步，移动设备的内存也越来越大了，但由于Android设备的参差不齐，可能运行在这台设备好好的，运行在那台设备就报OOM，这些适配问题也是比较蛋疼的，比如我们平常运行着一个应用程序，运行的好好的，突然到某个Activity就给你爆出一个OOM的错误，你可能会以为是这个Activity导致的内存泄露，你会想到也有可能是内存有泄露吗？内存泄露就像一个定时炸弹，随时都有可能使我们的应用程序崩溃掉，所以作为一名Android开发人员，还是需要有分析内存泄露的能力，说道这里我们还是要说下什么是内存泄露，内存泄露是指有个引用指向一个不再被使用的对象，导致该对象不会被垃圾回收器回收。因此，垃圾回收器是无法回收内存泄露的对象。本文就使用DDMS(Dalvik Debug Monitor Server)和MAT(Memory Analyzer Tool)工具带大家来分析内存泄露问题。

工具的准备

DDMS是ADT自带的调试工具,有关DDMS的使用请参考http://developer.android.com/tools/debugging/ddms.html，而MAT的就需要我们自行安装Eclipse插件，安装方法我就不多说了，下面给出一个在线安装的地址：http://download.eclipse.org/mat/1.3/update-site/，MAT可以检测到内存泄露，降低内存消耗，它有着非常强大的解析堆内存空间dump能力。

如何检测内存泄露

1.使用DDMS检测内存泄露

打开Devices视图,选择我们需要分析的应用程序进程，点击Updata Heap按钮

然后在打开DDMS, 选择Heap标签，然后点击Cause GC按钮，点击Cause GC是手动触发JAVA垃圾回收器，如下图

如果我们要测试某个Activity是否发生内存泄露，我们可以反复进入和退出这个Activity, 再手动触发几次垃圾回收，观察上图中 data object这一栏中的 Total Size的大小是保持稳定还是有明显的变大趋势，如果有明显的变大趋势就说明这个Activity存在内存泄露的问题，我们就需要在具体分析。

2.使用Logcat检测内存泄露

当垃圾回收机在进行垃圾回收之后，会在Logcat中作相对于的输出，所以我们也可以通过这些信息来判断是否存在内存泄露问题

一，上面消息的第一个部分产生GC的原因，一共有四种类型
GC_CONCURRENT   当你的堆内存快被用完的时候，就会触发这个GC回收
GC_FOR_MALLOC  堆内存已经满了，同时又要试图分配新的内存，所以系统要回收内存
GC_EXTERNAL_ALLOC   在Android3.0 (Honeycomb)以前，释放通过外部内存（比如在2.3以前，产生的Bitmap对象存储在Native Memory中）时产生。Android3.0和更高版本中不再有这种类型的内存分配了。
GC_EXPLICIT  调用System.gc时产生，上图中就是点击Cause GC按钮手动触发垃圾回收器产生的log信息

二，freed 1413K表示GC释放了1434K的内存

三，20% free 9349K/11644K， 20%表示目前可分配内存占的比例，9349K表示当前活动对象所占内存，11644K表示Heap的大小

四，paused 8ms + 3ms， total 71ms,则表示触发GC应用暂停的时间和GC总共消耗的时间

有了这些log信息，我们就可以知道GC运行几次以后有没有成功释放出一些内存，如果分配出去的内存在持续增加，那么很明显存在内存泄露，如下存在内存泄露的Log信息

很明显Heap中空闲内存占总Heap的比例在缩小，Heap中活动对象所占的内存在增加。

内存泄露分析实战

下面是一个存在内存泄露的例子代码，这也是比较常见的一种内存泄露的方式，就是在Activity中写一些内部类，并且这些内部类具有生命周期过长的现象

1. package com.example.memoryleak;
2. import java.util.ArrayList;
3. import java.util.List;
4. import android.app.Activity;
5. import android.os.Bundle;
6. public class LeakActivity extends Activity {
7. private List<String> list = new ArrayList<String>();
8. @Override
9. protected void onCreate(Bundle savedInstanceState) {
10. super.onCreate(savedInstanceState);
11. //模拟Activity一些其他的对象
12. for(int i=0; i<10000;i++){
13. list.add("Memory Leak!");
14. }
15. //开启线程
16. new MyThread().start();
17. }
18. public class MyThread extends Thread{
19. @Override
20. public void run() {
21. super.run();
22. //模拟耗时操作
23. try {
24. Thread.sleep(10 * 60 * 1000);
25. } catch (InterruptedException e) {
26. e.printStackTrace();
27. }
28. }
29. }
30. }

运行例子代码，选择Devices视图，点击上面Updata Heap标签，然后再旋转屏幕，多重复几次，然后点击Dump HPROF file, 之后Eclipse的MAT插件会自动帮我们打开，如下图

我们看到下面有Histogram（直方图）他列举了每个对象的统计，Dominator Tree(支配树）提供了程序中最占内存的对象的排列，这两个是我在排查内存泄露的时候用的最多的

Histogram（直方图)

我们先来看Histogram, MAT最有用的工具之一，它可以列出任意一个类的实例数。它支持使用正则表达式来查找某个特定的类，还可以计算出该类所有对象的保留堆最小值或者精确值, 我们可以通过正则表达式输入LeakActivity, 看到Histogram列出了与LeakActivity相关的类

我们可以看到LeakActivity,和MyThread内部类都存在16个对象，虽然LeakActivity和MyThread存在那么多对象，但是到这里并不能让我们准确的判断这两个对象是否存在内存泄露问题， 选中com.example.memoryleak.LeakActivity，点击右键，如下图

Merge Shortest Paths to GC Roots 可以查看一个对象到RC  Roots是否存在引用链相连接, 在JAVA中是通过可达性（Reachability Analysis)来判断对象是否存活，这个算法的基本思想是通过一系列的称谓"GC Roots"的对象作为起始点，从这些节点开始向下搜索，搜索所走得路径称为引用链，当一个对象到GC Roots没有任何引用链相连则该对象被判定为可以被回收的对象，反之不能被回收，我们可以选择 exclude all phantom/weak/soft etc.references(排查虚引用/弱引用/软引用等）因为被虚引用/弱引用/软引用的对象可以直接被GC给回收.

可以看到LeakActivity存在GC Roots链，即存在内存泄露问题，可以看到LeakActivity被MyThread的this$0持有。

除了使用Merge Shortest Paths to GC Roots 我们还可以使用

List object - With outgoing References   显示选中对象持有那些对象

List object - With incoming References  显示选中对象被那些外部对象所持有

Show object by class - With outgoing References  显示选中对象持有哪些对象, 这些对象按类合并在一起排序

Show object by class - With incoming References  显示选中对象被哪些外部对象持有, 这些对象按类合并在一起排序

Dominator Tree(支配树）

它可以将所有对象按照Heap大小排序显示, 使用方法跟Histogram（直方图)差不多，在这里我就不做过多的介绍了

我们知道上面的例子代码中我们知道内部类会持有外部类的引用，如果内部类的生命周期过长，会导致外部类内存泄露，那么你会问，我们应该怎么写那不会出现内存泄露的问题呢？既然内部类不行，我们就外部类或者static的内部类，如果我们需要用到外部类里面的一些东西，我们可以将外部类Weak Reference传递进去

1. package com.example.memoryleak;
2. import java.lang.ref.WeakReference;
3. import java.util.ArrayList;
4. import java.util.List;
5. import android.app.Activity;
6. import android.os.Bundle;
7. public class LeakActivity extends Activity {
8. private List<String> list = new ArrayList<String>();
9. @Override
10. protected void onCreate(Bundle savedInstanceState) {
11. super.onCreate(savedInstanceState);
12. //模拟Activity一些其他的对象
13. for(int i=0; i<10000;i++){
14. list.add("Memory Leak!");
15. }
16. //开启线程
17. new MyThread(this).start();
18. }
19. public static class MyThread extends Thread{
20. private WeakReference<LeakActivity> mLeakActivityRef;
21. public MyThread(LeakActivity activity){
22. mLeakActivityRef = new WeakReference<LeakActivity>(activity);
23. }
24. @Override
25. public void run() {
26. super.run();
27. //模拟耗时操作
28. try {
29. Thread.sleep(10 * 60 * 1000);
30. } catch (InterruptedException e) {
31. e.printStackTrace();
32. }
33. //如果需要使用LeakActivity，我们需要添加一个判断
34. LeakActivity activity = mLeakActivityRef.get();
35. if(activity != null){
36. //do something
37. }
38. }
39. }
40. }

同理，Handler也存在同样的问题，比如下面的代码

1. package com.example.memoryleak;
2. import android.app.Activity;
3. import android.os.Bundle;
4. import android.os.Handler;
5. import android.os.Message;
6. public class LeakActivity extends Activity {
7. @Override
8. protected void onCreate(Bundle savedInstanceState) {
9. super.onCreate(savedInstanceState);
10. MyHandler handler = new MyHandler();
11. handler.sendMessageDelayed(Message.obtain(), 10 * 60 * 1000);
12. }
13. public class MyHandler extends Handler{
14. @Override
15. public void handleMessage(Message msg) {
16. super.handleMessage(msg);
17. }
18. }
19. }

我们知道使用MyHandler发送消息的时候，Message会被加入到主线程的MessageQueue里面，而每条Message的target会持有MyHandler对象，而MyHandler的this$0又会持有LeakActivity对象， 所以我们在旋转屏幕的时候，由于每条Message被延迟了 10分钟，所以必然会导致LeakActivity泄露,所以我们需要将代码进行修改下

1. package com.example.memoryleak;
2. import java.lang.ref.WeakReference;
3. import android.app.Activity;
4. import android.os.Bundle;
5. import android.os.Handler;
6. import android.os.Message;
7. public class LeakActivity extends Activity {
8. MyHandler handler;
9. @Override
10. protected void onCreate(Bundle savedInstanceState) {
11. super.onCreate(savedInstanceState);
12. handler = new MyHandler(this);
13. handler.sendMessageDelayed(Message.obtain(), 10 * 60 * 1000);
14. }
15. public static class MyHandler extends Handler{
16. public WeakReference<LeakActivity> mLeakActivityRef;
17. public MyHandler(LeakActivity leakActivity) {
18. mLeakActivityRef = new WeakReference<LeakActivity>(leakActivity);
19. }
20. @Override
21. public void handleMessage(Message msg) {
22. super.handleMessage(msg);
23. if(mLeakActivityRef.get() != null){
24. //do something
25. }
26. }
27. }
28. @Override
29. protected void onDestroy() {
30. handler.removeCallbacksAndMessages(null);
31. super.onDestroy();
32. }
33. }

上面的代码就能保证LeakActivity不会被泄露，注意我们在Activity的onDestory方法中使用了handler.removeCallbacksAndMessages(null)，这样子能保证LeakActivity退出的时候，每条Message的target  MyHandler也会被释放， 所以我们在使用非static的内部类的时候，要注意该内部类的生命周期是否比外部类要长，如果是的话我们可以使用上面的解决方法。

常见的内存泄露问题

1.上面两种情形

2.资源对象没有关闭，比如数据库操作中得Cursor,IO操作的对象

3.调用了registerReceiver注册广播后未调用unregisterReceiver()来取消

4.调用了View.getViewTreeObserver().addOnXXXListener ,而没有调用View.getViewTreeObserver().removeXXXListener

5.Android 3.0以前，没有对不在使用的Bitmap调用recycle(),当然在Android 3.0以后就不需要了，更详细的请查看http://blog.csdn.net/xiaanming/article/details/41084843

6.Context的泄露，比如我们在单例类中使用Context对象，如下

1. import android.content.Context;
2. public class Singleton {
3. private Context context;
4. private static Singleton mSingleton;
5. private Singleton(Context context){
6. this.context = context;
7. }
8. public static Singleton getInstance(Context context){
9. if(mSingleton == null){
10. synchronized (Singleton.class) {
11. if(mSingleton == null){
12. mSingleton = new Singleton(context);
13. }
14. }
15. }
16. return mSingleton;
17. }
18. }

假如我们在某个Activity中使用Singleton.getInstance(this)或者该实例，那么会造成该Activity一直被Singleton对象引用着，所以这时候我们应该使用getApplicationContext()来代替Activity的Context，getApplicationContext()获取的Context是一个全局的对象，所以这样就避免了内存泄露。相同的还有将Context成员设置为static也会导致内存泄露问题。

7.不要重写finalize()方法，我们有时候可能会在某个对象被回收前去释放一些资源，可能会在finalize()方法中去做，但是实现了finalize的对象，创建和回收的过程都更耗时。创建时，会新建一个额外的Finalizer 对象指向新创建的对象。 而回收时，至少需要经过两次GC，第一次GC检测到对象只有被Finalizer引用，将这个对象放入 Finalizer.ReferenceQueue 此时，因为Finalizer的引用，对象还无法被GC，
Finalizer$FinalizerThread 会不停的清理Queue的对象，remove掉当前元素，并执行对象的finalize方法，清理后对象没有任何引用，在下一次GC被回收，所以说该对象存活时间更久，导致内存泄露。

如果大家还有一些内存泄露的情形欢迎提出来，我好更新下！