[高级]Android 内存分析工具MAT

前提条件：

1，电脑安装了java 运行环境  

2，手机端开启了 USB 调试开关 

3，获取 root 权限

基本步骤：

1，使用eclipse 自带的 DDMS 工具分析各线程的内存使用状况，以下图所示

 

Heap视图界面会定时刷新，在对应用的不断的操做过程当中就能够看到内存使用的变化。

怎样判断当前进程是否有内存泄漏呢？

这里须要注意一个值：VM Heap页面中部有一个data object选项，即数据对象，也就是咱们的程序中大量存在的类类型的对象。

在data object一行中有一列是“Total Size”，其值就是当前进程中全部Java数据对象的内存总量，通常状况下，这个值的大小决定了是否会有内存泄漏。如上图中选中行所示。

能够据此判断内存有泄漏：
1) 不断的操做当前应用，或者重复某一动做，注意观察data object的Total Size值。

2) 正常状况下Total Size值都会稳定在一个有限的范围内，也就是说若是程序中的的代码逻辑良好，

没有建立的对象不被GC机制正常回收的状况，即使 咱们不断的操做生成不少对象，而在虚拟机不断的进行垃圾回收的过程当中，这些对象都被正常回收了，内存使用量会保持在一个比较稳定的水平。

3) 若是代码中存在对象引用没有释放的状况，则data object的Total Size值在每次GC后不会有明显的回落，随着操做次数的增多Total Size的值会愈来愈大。
正常状况下，一个虚拟机的进程的内存在64M, 若是内存泄漏会发现 Heap Size 在不断的逼近 64M, 一旦达到这个值时，就会出现退出应用等状况。


发生内存泄露，Total Size的值愈来愈大时，按下“Dump HPROF file”按钮，这个时候会提示设置hprof文件的保存路径。保存后，能够对比log来分析是哪些操做形成了内存泄漏。

2，点击 按钮，导出 hprof 文件，使用MAT 工具进行分析。具体分析步骤和过程详见下面连接

http://www.ibm.com/developerworks/cn/opensource/os-cn-ecl-ma/index.html

3，打开 MAT 工具，File-->Open Heap Dump... 选择你刚刚保存的 hprof 文件打开

此时，会弹出一个错误，以下图所示：

提示：  Unknown HPROF Version (JAVA PROFILE 1.0.3) (java.io.IOException)

哦，不要觉得是 MAT 工具版本不对，实际上是 android 的 hprof 文件在这里须要进行转换一下格式才可使用 MAT 打开，不知道 谷歌在这里

捣了什么鬼，难道是优化？

使用 android sdk 目录下的 tools 中一个工具进行转化一下

 

4，使用AndrodiSDK/tools/hprof-conv转化hprof文件, 

首先，要经过控制台进入到你的 android sdk tools 目录下

例如 hprof-conv input.hprof     out.hprof

再使用MAT工具打开转换后的 hprof 文件，就能看到完整的内存使用分析报告了。

以下所示是 MAT 分析内存使用的主界面：

点击上图中的 Reports -->Leak Suspects 则能够进一步看到更详细的内存泄漏疑点。

在其中怀疑的地方，点击 Details 就能够看到具体的内存使用状况了。

tip1:

有一种比较好的方法是，在内存泄漏开始时抓取一个 hprof 文件，在内存泄漏很厉害时，app 濒临崩溃时再抓取一个hprof 文件。

对比看这两个图，就很容易看出来上面的饼图中哪一块存在内存泄漏。

有的时候能直接看出来多了一块。那么咱们就从那一块入手进行分析。比较快能获得结果。

tip2:

看 dominator_tree，能够从列表中 data_object 最多的几项数据入手分析，以下文件所示（136，80对应的两项）

 

我这边曾经就由于在 onStart 中添加了一个 PhoneStateListener 的监听，而在 onStop 中未设置为空，致使内存泄漏。

这里引用一点别人总结的实例：

 

缘由1：

          BraodcastReceiver，ContentObserver，FileObserver，Cursor在Activity onDeatory或者某类声明周期结束以后必定要unregister或者close掉，不然这个Activity类会被system强引用，不会被内存回收。

缘由2：

        不要直接对Activity进行直接引用做为成员变量，若是不得不这么作，请用private WeakReference mActivity来作，相同的，对于Service等其余有本身声明周期的对象来讲，直接引用都须要谨慎考虑是否会存在内存泄露的可能。（）

 

private static class MyHandler extends Handler {
        private WeakReference<GeneralSettings> mStatus;

        public MyHandler(GeneralSettings activity) {
            mStatus = new WeakReference<GeneralSettings>(activity);
        }

        @Override
        public void handleMessage(Message msg) {
            GeneralSettings status = mStatus.get();
            if (status == null) {
                return;
            }

            switch (msg.what) {
                case EVENT_UPDATE_STATS:
                    status.updateTimes();
                    sendEmptyMessageDelayed(EVENT_UPDATE_STATS, 1000);
                    break;
            }
        }
}

 

缘由3：

对 Context 保持了一个长生命周期的引用。

 

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);
}

sBackground的生命周期比Activity要长，label引用到context，sBackground又把label设为内部成员变量，因此sBackground引用到了context，致使activity结束的时候context仍是不能释放，从而引起内存泄露。（不甚理解，还要仔细研究一下）

 

最后，做者给了一点总结（有些地方仍是不太懂……）

总结：

 

1.      对activity的引用应该控制在activity的生命周期以内；

2.      若是不能就考虑使用getApplicationContext或者getApplication；

3.      尽可能不要在静态变量或者静态内部类中使用非静态外部成员变量（包括context），即便要使用，也要考虑适时把外部成员变量置空（如上例能够经过把sBackground的callback置空来解决内存泄露的问题）；也能够在内部类中使用弱引用来引用外部类的变量；

4.      作到在onDestroy中释放资源，如清空对图片等资源有直接引用或者间接引用的数组（使用array.clear();array = null）；