Android 性能优化之MAT分析内存泄漏

我的博客原文地址

MAT 是 Memory Analyzer Tool 的简称，它是一款强大的内存分析工具，使用它能帮助开发者快速分析内存泄漏以及优化内存的使用。
内存泄漏也是我们开发过程中经常碰到的问题，掌握了MAT工具，那么你就不会惧怕内存泄漏，使用它可以让内存泄漏无所遁形。

MAT下载

进入网址下载MAT工具，如果你使用 Eclipse 开发工具而且已经集成了插件，可以不用下载了。

场景准备

我们用下面的代码产生一个内存泄漏的场景：
MainActivity.java

    @Override    protected void onCreate(Bundle savedInstanceState) {        super.onCreate(savedInstanceState);        if(mInnerClassInstance == null){            mInnerClassInstance = new InnerClass();        }        mInnerClassInstance.testFunc();    }    public static InnerClass mInnerClassInstance;    class InnerClass{        public void testFunc(){            Log.e("InnerClass", "InnerClass.testFunc()");        }    }

我们知道，在 Java 中，非静态内部类会默认隐性引用外部类对象。而上面的例子中的静态变量mInnerClassInstance在第一个MainActivity实例创建后便会一直存在，那么它就会一直持有MainActivity的一个引用，在MainActivity实例销毁后它是无法被回收的，因此便造成了内存泄漏。

内存泄漏的初步分析

首先可以用adb shell dumpsys meminfo <包名>先进行初步的分析。
我们按下手机的后退键回到桌面，这时会调用MainActivity的onDestroy()，正常情况下MainActivity实例会被回收。

$ adb shell dumpsys meminfo com.example.hq.testsomethingApplications Memory Usage (kB):Uptime: 23692543 Realtime: 23692543** MEMINFO in pid 29474 [com.example.hq.testsomething] **                   Pss  Private  Private  Swapped     Heap     Heap     Heap                 Total    Dirty    Clean    Dirty     Size    Alloc     Free                ------   ------   ------   ------   ------   ------   ------  Native Heap     5252     4568        0     9400    32768    30309     2458  Dalvik Heap     1761     1692        0      320    11829     7872     3957 Dalvik Other      467      396        0     2848        Stack      200      200        0        0                                  Ashmem        2        0        0        0    Other dev        4        0        4        0     .so mmap     1047      156       12     2184    .apk mmap      160        0       72        0    .ttf mmap       33        0       16        0    .dex mmap      268        4      264        0    .oat mmap     1172        0      388        4    .art mmap     1434      492      424       80   Other mmap      131        8       28        4      Unknown      188      188        0       96        TOTAL    12119     7704     1208    14936    44597    38181     6415 App Summary                       Pss(KB)                        ------           Java Heap:     2608         Native Heap:     4568                Code:      912               Stack:      200            Graphics:        0       Private Other:      624              System:     3207               TOTAL:    12119      TOTAL SWAP (KB):    14936 Objects               Views:       26         ViewRootImpl:        0         AppContexts:        2           Activities:        1              Assets:        3        AssetManagers:        2       Local Binders:       11        Proxy Binders:       15       Parcel memory:        3         Parcel count:       12    Death Recipients:        1      OpenSSL Sockets:        0 Dalvik         isLargeHeap:    false SQL         MEMORY_USED:        0  PAGECACHE_OVERFLOW:        0          MALLOC_SIZE:        0

我们通过这个结果查看发现Objects这一项里面的Activities为1,证明还是有个Activity的实例存在的，没有被正常回收。下面我们来借助于MAT工具来分析一下。

使用Android Monitor分析内存泄漏

Android Studio 中的 Android Monitor 里面有个 Memory 控制台，它提供了一个内存监视器，我们可以通过它方便地查看应用程序的性能和内存使用情况，从而也就可以找到需要释放对象，查找内存泄漏等。

点击图中的按钮可以触发一次GC

点击图中的按钮可以生成hprof文件来进行分析。

这里我们不再详细介绍。

生成HPROF文件

使用Android Studio

首先我们借助Android Studio生成hprof文件，Tools -> Android -> Android Device Monitor 打开 DDMS：

点击一下我们需要调试的进程，此时进程上访的一排工具处于可点击状态，点击一下 Update Heap 按钮可以在Heap视图里面现实当前堆内存的使用情况，点击 Cause GC 按钮可以触发一次GC操作。

按回退键回到桌面，然后点击 Dump HPROF file 按钮，如图：

会生成 hprof 文件，会弹框提示我们保存下来。
然后打开MAT工具，File –> Open Heap Dump…，选择刚刚生成的文件，如果出现下面的错误，用 hprof-conv 命令转换一下就可以了。这是因为MAT是用来分析java程序的hprof文件的，与Android导出的hprof有一定的格式区别，因此我们需要把导出的hprof文件转换一下。hprof-conv 是 Android SDK 提供的工具，它位于 Android SDK 的platform-tools目录下。

android-sdk-linux/platform-tools/hprof-conv com.example.hq.testsomething.hprof test.hprof

使用Eclipse

如果你的 Eclipse 安装了MAT插件，那么安装上面使用Android Studio生成hprof文件的步骤，点击 Dump HPROF file 按钮后，就直接打开了该hprof文件。

使用代码

android.os.Debug.dumpHprofData(hprofName);

生成的hprof文件也需要用hprof-conv转换一下才能用MAT工具打开。

通过MAT工具分析内存泄漏

介绍

打开hprof文件后首先进入主视图，下来看一下这个主视图：

MAT 提供了很多功能，但是最常用的只有 Histogram 和 Domintor Tree：

• Histogram：通过 Histogram 可以直观地看出内存中不同类型的 buffer 的数量和占用内存的大小。
• Domintor Tree：把内存中的对象按照从大到小的顺序进行排序，并且可以分析对象之间的引用关系

我们看到在这两个视图中还会发现有 Shallow size 和 Retained Size 两个属性：

• Shallow size：对象自身占用的内存大小，不包括它引用的对象。针对非数组类型的对象，它的大小就是对象与它所有的成员变量大小的总和。
  当然这里面还会包括一些java语言特性的数据存储单元。针对数组类型的对象，它的大小是数组元素对象的大小总和。
• Retained Size：当前对象大小+当前对象可直接或间接引用到的对象的大小总和。(间接引用的含义：A->B->C, C就是间接引用)

一个对象到GC Roots的引用链被称为Path to GC Roots，通过分析Path to GC Roots可以找出JAVA的内存泄露问题。

内存泄漏分析

我们在主视图中选择Actions–>Domintor Tree或者Histogram也可以。
因为在前面我们已经初步分析了MainActivity是存在内存泄漏的，这里我们可以使用界面中的搜索功能，在输入框中输入MainActivity进行过滤，查看当前存在的MainActivity对象，我们发现当前有两个MainActivity对象，这是因为我们按back键退出应用再进来，系统都会重新创建一个新的MainActivity，但是第一次创建的老的对象却无法回收，所以就出现了两个MainActivity对象。

我们在进一步分析一下是什么导致了内存泄漏，单击选中MainActivity，然后单击鼠标右键->Path To GC Roots->exclude all phontom/weak/soft etc. references，如图所示。

这里在 Path To GC Roots 之所以选择排除所有的虚引用、弱引用和软引用，是因为它们都有很大的几率被GC回收掉的，它们并不会构成内存泄漏。
可以看到是 mInnerClassInstance 引用了 MainActivity 导致了无法释放。

Domintor Tree 视图分析

一般分析内存泄漏我们需要分析 Domintor Tree 视图，但是在视图中内存泄漏一般不会直接显示出来，这个时候我们一般要需要按照内存的从大到小去排查一遍。

在图中我们就发现第2列中就有个BitmapDrawable对象，同样我们选择BitmapDrawable对象，然后单击鼠标右键->Path To GC Roots->exclude all phontom/weak/soft etc. references，如图所示。

可以看到同样是 mInnerClassInstance 引用了 MainActivity 导致了BitmapDrawable对象无法释放。