Android 内存检测工具

所谓内存泄漏，是指本该被回收的内存由于某种原因绕开了GC回收算法，从而导致该内存无法被有效数据使用而使得总内存减小的情况。

内存泄漏会导致内存消耗的增加，大量的消耗会使得APP OOM，特别是在一些内存比较小的机器上。下面我们看看有哪些工具可以用来分析内存泄漏。

Heap Dump

Heap Dump的主要功能就是查看不同的数据类型在内存中的使用情况。它可以帮助你找到大对象，也可以通过数据的变化发现内存泄漏。

使用Heap Dump

打开Android Device Monitor工具，在左边Devices列表中选择要查看的应用程序进程，点击Update Heap按钮，在右边选择Heap选项，并点击Cause GC按钮，就会开始显示数据。我们每次点击Cause GC按钮都会强制应用程序进行垃圾回收，并将清理后的数据显示在Heap工具中。如下图所示。

从上图可以看出，Heap工具共有三个区域，分别是总览视图(上部)、详情视图(中部)和内存分配柱状图(下部)。

总览视图

其中总览视图可以查看整体的内存情况，表中的显示信息如下所示：

• Heap Size 堆栈分配给该应用程序的内存大小
• Allocated 已使用的内存大小
• Free 空闲的内存大小
• %Used 当前Heap的使用率（Allocated/Heap Size）
• #Objects 对象的数量

详情视图

详细视图展示了所有的数据类型的内存情况，表中列的信息如下所示：

• Total Size 总共占用的内存大小
• Smallest 将该数据类型的对象从小到大排列，排在第一个的对象所占用的内存
• Largest 将该数据类型的对象从小到大排列，排在最后一个的对象所占用的内存
• Median 将该数据类型的对象从小到大排列，排在中间的对象所占用的内存
• Average 该数据类型的对象所占用内存的平均值

除了列的信息，还有行信息：

• data object 对象
• class object 类
• 1-byte array (byte[],boolean[]) 1字节的数组对象
• 2-byte array (short[],char[]) 2字节的数组对象
• 4-byte array (object[],int[],float[]) 4字节的数组对象
• 6-byte array (long[],double[]) 8字节的数组对象
• non-Java object 非Java对象

行信息中两个比较重要的参数：
free—它与总览视图中的free的含义不同，它代表内存碎片。当新创建一个对象时，如果碎片内存能容下该对象，则复用碎片内存，否则就会从free空间（总览视图中的free）重新划分内存给这个新对象。free是判断内存碎片化程度的一个重要的指标。
1-byte array—图片是以byte[]的形式存储在内存中的，如果1-byte array一行的数据过大，则需要检查图片的内存管理了。

检测内存泄漏

我们先写一个内存泄漏的例子：
MainActivity：

public class MainActivity extends AppCompatActivity {    private Button button;    @Override    protected void onCreate(Bundle savedInstanceState) {        super.onCreate(savedInstanceState);        setContentView(R.layout.activity_main);        button =(Button)findViewById(R.id.bt_next);        button.setText("SecondActivity");        button.setOnClickListener(new View.OnClickListener() {            @Override            public void onClick(View v) {                startActivity(new Intent(MainActivity.this,SecondActivity.class));            }        });    }}

SecondActivity：

public class SecondActivity extends AppCompatActivity {    private static Object inner;    private Button button;    @Override    protected void onCreate(Bundle savedInstanceState) {        super.onCreate(savedInstanceState);        setContentView(R.layout.activity_main);        button = (Button) findViewById(R.id.bt_next);        button.setText("MainActivity");        button.setOnClickListener(new View.OnClickListener() {            @Override            public void onClick(View v) {                createInnerClass();                finish();            }        });    }    class InnerClass {    }    private void createInnerClass() {        inner = new InnerClass();    }}

内存泄漏的原因很简单，SecondActivity的内部类InnerClass Hold住了外部类实例的引用，而InnerClass的实例是静态的，就会间接的长期维持着外部类实例的引用，阻止被系统回收，导致SecondActivity实例不能被释放。

Heap Dump检测内存泄漏：通常做法是使用Update Heap进行内存监听，然后操作可能发生泄漏的APP功能、界面，并点击Cause GC进行手动GC，经过多次操作后查看data object的Total Size大小是否有很大的变化，如果有则可能发生了内存泄漏，导致内存使用不断增大。

步骤：
（1）在左边Devices列表中选择要查看的应用程序进程，点击Update Heap按钮，在右边选择Heap选项，并点击Cause GC按钮，就会开始显示数据，如下图所示。

（2）在MainActivity和SecondActivity间跳转多次。这样会生成多个SecondActivity实例且不能释放。重新点击Update Heap和Cause GC按钮，显示新的数据。

可以看到data object由610.500KB增长到1.158MB

（3）这时我点击Cause GC按钮，数据显示为：

经过Cause GC的操作，Total Size的值从1.158MB变为了667.109KB，这是一个比较大的变化，说明在Cause GC操作之前有518.683KB(1.158MB-667.109KB)的内存没有被回收，可能发生了内存泄漏。你多GC几次，甚至会释放更多的内存。

Allocation Tracker

使用Heap Dump可以让你对APP的内存整体使用情况进行掌控，但缺点是无法了解每块内存具体分配给哪个对象了，这时就需要使用Allocation Tracker工具来进行内存跟踪。它允许你在执行某些操作的同时监视在何处分配对象，了解这些分配使你能够调整与这些操作相关的方法调用，以优化应用程序性能和内存使用。

Allocation Tracker能够做到如下的事情：

• 显示代码分配对象类型、大小、分配线程和堆栈跟踪的时间和位置。
• 通过重复的分配/释放模式帮助识别内存变化。
• 当与 HPROF Viewer结合使用时，可以帮助你跟踪内存泄漏。例如，如果你在堆上看到一个bitmap对象，你可以使用Allocation Tracker来找到其分配的位置。

使用Allocation Tracker

AS和DDMS中都有Allocation Tracker，这里会介绍AS中的Allocation Tracke如何使用。
使用的步骤为：

• 运行需要监控的应用程序。
• 点击AS面板下面的Android Monitors选项，查看
• 点击Start Allocation Tracking按钮
• 操作应用程序。

• 点击Stop Allocation Tracking按钮 ，结束快照。这时Memory Monitor会显示出捕获快照的期间，如下图所示。
  

• 过几秒后就会自动打开一个窗口，显示当前生成的alloc文件的内存数据。

alloc文件分析

该alloc文件显示以下信息：

• Method—负责分配的Java方法
• Count—分配的实例总数
• Total Size—分配内存的总字节数

目前的菜单选项是Group by Method我们也可以选择 Group By Allocator，如下图所示

同样是上面的demo，我们在MainActivity和SecondActivity间跳转了5次。
可以看到SecondActivity生成了5个匿名内部类OnClickListener实例（SecondActivity$1 表示它的第一个匿名内部类）和5个内部类InnerClass的实例，每个实例16个字节，且都没有被释放内存。

我们可以选择列表中的一项，单击鼠标右键，在弹出的菜单中选择jump to the source就可以跳转到对应的源文件中。
除此之外，还可以点击Show/Hide Chart按钮来显示数据的图形化，如下图所示。

MAT

如果想要深入的进行分析并确定内存泄漏，就要分析疑似发生内存泄漏时所生成堆存储文件。堆存储文件可以使用DDMS或者Memory Monitor来生成，输出的文件格式为hprof，而MAT就是来分析堆存储文件的。

MAT，全称为Memory Analysis Tool，是对内存进行详细分析的工具，它是Eclipse的插件，如果用Android Studio进行开发则需要单独下载它，下载地址为：http://eclipse.org/mat/。

生成hprof文件

我们这里分析一下用AS的Memory Monitor来生成hprof文件。

我们还是先写一个内存泄漏的例子：

public class MainActivity extends AppCompatActivity {    private Button button;    @Override    protected void onCreate(Bundle savedInstanceState) {        super.onCreate(savedInstanceState);        setContentView(R.layout.activity_main);        button =(Button)findViewById(R.id.bt_next);        button.setText("SecondActivity");        button.setOnClickListener(new View.OnClickListener() {            @Override            public void onClick(View v) {                startActivity(new Intent(MainActivity.this,SecondActivity.class));            }        });    }}

public class SecondActivity extends AppCompatActivity {    private Button button;    @Override    protected void onCreate(Bundle savedInstanceState) {        super.onCreate(savedInstanceState);        setContentView(R.layout.activity_main);        button = (Button) findViewById(R.id.bt_next);        button.setText("MainActivity");        button.setOnClickListener(new View.OnClickListener() {            @Override            public void onClick(View v) {                LeakThread leakThread = new LeakThread();                leakThread.start();                finish();            }        });    }    class LeakThread extends Thread {        @Override        public void run() {            try {                Thread.sleep(60 * 60 * 1000);            } catch (InterruptedException e) {                e.printStackTrace();            }        }    }}

内存泄漏的原因是非静态内部类LeakThread Hold住了外部类的引用，而LeakThread中做了耗时操作，导致外部类SecondActivity无法被释放。

生成hprof文件主要分为一下几个步骤：

• 运行需要监控的应用程序。
• 点击AS面板下面的Android Monitors选项，查看
• 操作应用程序（本文的例子就是不断切换Activity）。
• 点击Dump Java Heap按钮 ，生成hprof文件。

Memory Monitor生成的hprof文件不是标准的，AS提供了便捷的转换方式：Memory Monitor生成的hprof文件都会显示在AS左侧的Captures标签中，在Captures标签中选择要转换的hprof文件，并点击鼠标右键，在弹出的菜单中选择Export to standard.hprof选项，即可导出标准的hprof文件，如下图所示。

MAT分析hpof文件

用MAT打开标准的hprof文件，选择Leak Suspects Report选项。这时MAT就会生成报告，这个报告分为两个标签页，一个是Overview，一个是Leak Suspects，如下图所示。

Leak Suspects中会给出了MAT认为可能出现内存泄漏问题的地方，本例共给出了4个内存泄漏猜想，通过点击每个内存泄漏猜想的Details可以看到更深入的分析清理情况。如果内存泄漏不是特别的明显，通过Leak Suspects是很难发现内存泄漏的位置。

打开Overview标签页，首先看到的是一个饼状图，它主要用来显示内存的消耗，饼状图的彩色区域代表被分配的内存，灰色区域的则是空闲内存，点击每个彩色区域可以看到这块区域的详细信息，如下图所示。

再往下看，Actions一栏的下面列出了MAT提供的四种Action，其中分析内存泄漏最常用的就是Histogram和Dominator Tree。Histogram可以统计内存中对象的名称、种类、实例数和大小，而Dominator Tree则是建立这些内存对象之间的关系。
我们点击Actions中给出的链接或者在MAT工具栏中就可以打开Histogram和Dorminator Tree。

Histogram

图中可以看出Dorminator Tree有四列数据。

• Class Name：类名
• Objects：对象实例的个数
• Shallow Heap：对象自身占用的内存大小，不包括它引用的对象。如果是数组类型的对象，它的大小是数组元素的类型和数组长度决定。如果是非数组类型的对象，它的大小由其成员变量的数量和类型决定。
• Retained Heap：一个对象的Retained Set所包含对象所占内存的总大小。换句话说，Retained Heap就是当前对象被GC后，从Heap上总共能释放掉的内存。

在列表顶部的Regex区域，可以输入过滤条件（支持正则表达式），通常Activity的内存泄漏，可以直接通过输入Activity名获取与之相关的的实例。

可以看到，SecondActivity实例创建了11次，基本可以判断内存泄漏了。具体是如何泄漏的呢？可以通过查看GC对象的引用链来分析。在SecondActivity上右键，选择Merge Shortest Paths to GC Root，并通过弹出的列表选择相关类型的引用（强、软、弱、虚），分析不同引用类型下的GC情况，这里我们选择exclude all phantom/weak/soft etc. references，因为这个选项排除了虚引用、弱引用和软引用，这些引用一般是可以被回收的。这时MAT就会给出SecondActivity的GC引用链。

到这里整个内存泄漏一目了然了，引用SecondActivity的是内部类LeakThread，this$0的含义就是内部类自动保留的一个指向所在外部类的引用，而这个外部类就是SecondActivity，导致SecondActivity无法被GC。

同时，在Histogram中还可以查看一个对象包含了哪些对象的引用。例如查看SecondActivity包含的引用，在SecondActivity上右键，选择List objects—with incoming references（显示选中对象被哪些外部对象引用，而with outcoming references表示选中对象持有哪些对象的引用）

Dominator Tree

Dorminator Tree意味支配树，从名称就可以看出Dorminator Tree更善于去分析对象的引用关系。而Histogram更侧重于量的分析。

Shallow Heap和Retained Heap的含义和上面Histogram中的一样。

同样过滤SecondActivity：

发现有些图标带有小圆点，表示它们可以被GC系统访问到，是内存泄漏的重点怀疑对象。那么SecondActivity没有原点，是不是代表不能被GC访问，可以回收呢？当然不是，如果可以回收，又怎么会存在这么多的实例呢。那怎么找到它的GC Root呢？在SecondActivity上右键，选择Path To GC Roots，同样选择exclude all phantom/weak/soft etc. references

得出的结果和上面是一样的，引用SecondActivity的是LeakThread，这导致了SecondActivity无法被GC。

OQL

OQL全称为Object Query Language，类似于SQL语句的查询语言，能够用来查询当前内存中满足指定条件的所有的对象。它的查询语句的基本格式为：

SELECT * FROM [ INSTANCEOF ]    <class_name> [ WHERE <filter-expression>]

当我们点击OQL按钮，输入条件select * from instanceof android.app.Activity并按下F5时（或者按下工具栏的红色叹号），会将当前内存中所有Activity都显示出来，如下图所示。

更过用法详见官方文档。

LeakCanary

LeakCanary 是一个开源的在debug版本中检测内存泄漏的java库。

使用LeakCanary

在APP的build.gradle文件添加：

dependencies {  debugCompile 'com.squareup.leakcanary:leakcanary-android:1.5.2'  releaseCompile 'com.squareup.leakcanary:leakcanary-android-no-op:1.5.2'}

接下来在Application加入如下代码

public class BaseApplication extends Application {    @Override public void onCreate() {    super.onCreate();    //如果当前的进程是用来给LeakCanary进行堆分析的则return    if (LeakCanary.isInAnalyzerProcess(this)) {      return;    }    LeakCanary.install(this);  }}

上面代码只能够检测Activity的内存泄漏，当然还存在其他类的内存泄漏，这时我们就需要使用RefWatcher来进行监控。改写Application，如下所示

public class BaseApplication extends Application {        private RefWatcher refWatcher;        @Override public void onCreate() {        super.onCreate();        refWatcher= setupLeakCanary();    }    private RefWatcher setupLeakCanary() {        //如果当前的进程是用来给LeakCanary进行堆分析的则return        if (LeakCanary.isInAnalyzerProcess(this)) {            return RefWatcher.DISABLED;        }        return LeakCanary.install(this);    }    public static RefWatcher getRefWatcher(Context context) {        BaseApplication baseApplication = (BaseApplication) context.getApplicationContext();        return baseApplication.refWatcher;    }}

这里我们仍然使用上一节的demo，只是在SecondActivity中实现onDestroy方法，其中得到RefWatcher，并调用它的watch方法，watch方法的参数就是要监控的对象。

public class SecondActivity extends AppCompatActivity {    private Button button;    @Override    protected void onCreate(Bundle savedInstanceState) {        super.onCreate(savedInstanceState);        setContentView(R.layout.activity_main);        button = (Button) findViewById(R.id.bt_next);        button.setText("MainActivity");        button.setOnClickListener(new View.OnClickListener() {            @Override            public void onClick(View v) {                LeakThread leakThread = new LeakThread();                leakThread.start();                finish();            }        });    }    class LeakThread extends Thread {        @Override        public void run() {            try {                Thread.sleep(60 * 60 * 1000);            } catch (InterruptedException e) {                e.printStackTrace();            }        }    }    @Override    protected void onDestroy() {        super.onDestroy();        RefWatcher refWatcher = BaseApplication.getRefWatcher(this);        refWatcher.watch(this);    }}

其实这个例子中onDestroy方法是多余的，因为LeakCanary在调用install方法时会启动一个ActivityRefWatcher类，它用于自动监控Activity执行onDestroy方法之后是否发生内存泄露。这里只是为了方便举例，如果想要监控Fragment，在Fragment中添加如上的onDestroy方法是有用的。

操作

运行程序，这时会在界面生成一个名为Leaks的应用图标。接下来不断的切换Activity，这时会闪出一个提示框，提示内容为：“Dumping memory app will freeze.Brrrr.”。再稍等片刻，内存泄漏信息就会通过Notification展示出来

Notification中提示了MainActivity发生了内存泄漏， 泄漏的内存为4.3KB。点击Notification就可以进入内存泄漏详细页，除此之外也可以通过Leaks应用的列表界面进入，列表界面如下图所示

点击加号就可以查看具体类所在的包名称。整个详情就是一个引用链：SecondActiviy的内部类LeakThread引用了LeakThread的this0，this0的含义就是内部类自动保留的一个指向所在外部类的引用，而这个外部类就是详情最后一行所给出的SecondActiviy的实例，这将会导致SecondActiviy无法被GC，从而产生内存泄漏。

除此之外，我们还可以将 heap dump（hprof文件）和info信息分享出去，如下图所示。

需要注意的是分享出去的hprof文件并不是标准的hprof文件，还需要将它转换为标准的hprof文件，这样才会被MAT识别从而进行分析。