基于eclipse的MAT使用

MAT：memory analyze tool
这是一个android的内存分析工具。如果使用的是ADT开发工具，是需要下载的
在help里面的install new software里面输入
org.eclipse.mat.updatesite http://download.eclipse.org/mat/1.5/update-site/ 这个是当前的最新版本
集成之后重启。

如果你是从http://www.eclipse.org/mat/downloads.php下载相应的操作系统的客户端。

使用：

1.在eclipse上面点击DDMS，确认Devices、Heap和logat视图（在Window里面Show View里面）已经打开。

2.将手机设备连接到电脑，并确保使用“USB调试“模式链接，链接成功后在Devices视图中就会看到设备的序列号，和设备正在运行的部分进程。 

3.选中想要分析的应用进程，在Devices视图上方的一行图标按钮中，选中“Update Heap”按钮。

4.在Devices视图上方的一行图标按钮中，点击Cause GC。比如我想检查A界面是否有内存泄漏，我在进入A界面前点击Cause GC，然后进入A界面，退出A界面，再点击Cause GC，重复几次，查看heap窗口的data Object是否有明显增加。如果有就说明很有可能在A界面有内存泄漏了。

5.导出分析文件。

这里如果你是下载的客户端，生产的.hprof文件是不能直接用客户端打开的。会提示：

Error opening heap dump 'system_process.hprof'. Check the error log for further details.
Error opening heap dump 'system_process.hprof'. Check the error log for further details.
Unknown HPROF Version (JAVA PROFILE 1.0.3) (java.io.IOException)
Unknown HPROF Version (JAVA PROFILE 1.0.3)

这个时候需要进行文件转换：找到你的sdk---> platform-tools 把你保存的保存的.hprof

使用hprof-conv转化hprof文件, 

例如 hprof-conv input.hprof     out.hprof

6.查看分析文件：直接使用默认选项。进入界面，点击这个

然后点击这个（名字都很长，我就不写了）

选择group by package，然后找到你的包，右键，选择list object 字目录下，income是按进入时间排序，outgoing相反。

前面有小红点的就是可能有内存溢出的了。然后就可以定位到相关的泄漏了。

为什么说是可能？因为比如这个，就不是泄漏了，demo是A页面打开了SecondAty，然后返回A界面，然后CauseGC，B界面是空的。

具体原因还不是很理解。群里小伙伴说是SDK泄漏，但是用另一个工具LeakCanary来检测相同的demo却没有报内存泄漏。所以说这个只是可能。（蛋疼）

Tips：
一些对象有着有限的生命周期。当这些对象所要做的事情完成了，我们希望他们会被回收掉。但是如果有一系列对这个对象的引用，那么在我们期待这个对象生命周期结束的时候被收回的时候，它是不会被回收的。它还会占用内存，这就造成了内存泄露。持续累加，内存很快被耗尽。
比如，当 Activity.onDestroy 被调用之后，activity 以及它涉及到的 view 和相关的 bitmap 都应该被回收。但是，如果有一个后台线程持有这个 activity 的引用，那么 activity 对应的内存就不能被回收。这最终将会导致内存耗尽，然后因为 OOM 而 crash。

优化
检查static方法是否持有context，如果该context来自activity，考虑将其换为getApplicationContext
是否在activity里面声明了static方法
就目前使用的结果来看，绝大部分泄漏是由于使用单例模式hold住了Activity的引用，比如传入了context或者将Activity作为listener设置了进去，所以在使用单例模式的时候要特别注意，还有在Activity生命周期结束的时候将一些自定义监听器的Activity引用置空。
注册了的监听器没有反注册的问题，这也是引起内存泄露的原因中最常见的。

参考

http://blog.csdn.net/p106786860/article/details/9268613