AndroidStudio + MAT 内存泄漏分析

一概要：

内存泄漏是一些已经不使用的对象，依然占有内存且垃圾回收机制不法回收它们。最终导致常驻内存越来越大

，影响到程序的性能。

在Android 虚拟机中，采用Mark-Sweep方式实现垃圾回收。Mark标记，Sweep检测。虚拟机会从GC Roots开始

遍历，如果某个节点无法找到一条到达GC Roots的路径，则表示该引用无效，可以被回收。内存泄漏就是存在一些

不好的调用，导致一些无效的引用于GC Roots相连，无法被回收。

知道了原因，我们理应在开发中尽量避免这些。但是万一发生了（代码又不是一个人写的），我们要准确找出它们。

所以我们就要用到检测内存泄漏的工具。

转载：http://blog.csdn.net/u012760183/article/details/52068490

二使用：

实例代码（我们进入主页面后，点击启动TestSecondActivity，然后按返回退出）：

Intent intent2 = new Intent(MainActivity.this, TestSecondActivity.class);
startActivity(intent2);

public class TestSecondActivity extends AppCompatActivity{

@Override
protected void onCreate(@Nullable Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_testsecond);
Runnable runnable = new Runnable() {
@Override
public void run() {
LogUtil.i("TestSE", "thread:" + Thread.currentThread() + "start");
try{
Thread.sleep(80000l);
}catch (Exception e){

}
LogUtil.i("TestSE", "thread:" + Thread.currentThread() + " end");
}
};
new Thread(runnable).start();
}
}

我们会通过两种方式，来检测内存泄漏：

#使用MAT用具查找

1，首先打开Android Studio中的Android Device Monitor如下图。



2，打开后会出现下面界面，选中你要检测应用的包名，然后点击下图画圈的地方（Update Heap），会在程序包

名后标记一个图标



3，接下就是我们的操作，,重复启动回退TestSecondActivity 两次，然后再点下图画圈地方（Dump HPROF file）

生成hprof文件。



生成的hprof文件。



4，因为MAT是用于分析java hprof的工具，我们生成的是Android属性的hprof文件，所以我们要转化一下（我将刚刚

生成的文件重名android.hprof）。

Android Sdk中为我们提供了工具：hprof-conv.exe。



转化成了java属性的文件java.hprof。

5，使用MAT打开hprof文件，（如果还没有安装MAT的，先下载安装：https://www.eclipse.org/mat/）。



打开后如图：



6，之后我们查看内存中的对象，由于我们的内存泄漏一般都发生在Activity中所以我们之查找Activity即可。

点击下图中的QQL图标，输入select * from instanceof android.app.Activity,类似于SQL语句。红色感叹号为执行按钮。



#内存中有两个TestSecondActivity，但是我们已经退出了TestSecondActivity，说明发生了内存泄漏。

#上面有两个属性。Shallow Size对象自身占用大小，不包括引用。Retained Size对象自身大小+ 直接或间接引用对象

的大小。

7，右击TestSecondActivity，—— Path to GC Roots——All Reference。



看到this$0引用了这个Activity，this$0表示内部类意思。Activity被一个内部类引用，而这个内部类又被target（Thread）引用。

从上面的代码可知：

TestSecondActivity中有内部类runnable，而runnable被Thread使用。工作线程Thread需要sleep 80秒。所以导致

TestSecondActivity无法释放。

解决方法。我们在Activity onDestroy中shutdown 线程Thread就可以了（当然先把Thread变成全局变量）

#直接使用Android Studio上的Monitor Memory查找

1，依然是利用上面的代码，运行程序，打开Android Studio的Monitor界面，查看Memory图像。



2，点击下卡车图标（图中1），可以执行一次GC；点击图中2的位置，可以查看hprof文件。（依次点击1,2）

3，查看结果



#同样监听到了TestSecondActivity的内存泄漏。

三注意

Android中内存引起内存泄漏的常见使用。

1，static变量引起的内存泄漏。

因为static生命周期是类加载时开始，类卸载结束。也就是说static变量在程序死亡时才结束。而如果static变量引用

Activity，那么Activity的资源将一直得不到释放。造成内存泄漏。

解决方法，如果需要Context对象，尽量使用getApplicationContext。假如必须使用Activity那么最好在onDestroy方

法中，将Activity引用设置为null。

2，线程造成的内存泄漏。

类似于上面的例子，线程执行时间长，即使Activity结束了任然在执行。因为new Thread生成一个匿名内部类（内部

类的创建必须依靠外部类），因此握有Activity实例，Activity无法释放。AsyncTask更为严重，因为AsyncTask维持一

个生命周期。

解决方法：合理安排线程，控制线程在Activity结束时结束。

3，Bitmap占用过多的内存。

Bitmap解析需要占用内存，但是Android只提供了8M内存给Bitmap，如果Bitmap过多且不能及时的回收。则会造成内

存溢出。

解决方法：及时recycle，加载图片前先适当的压缩图片。

4，资源未被及时关闭造成内存泄漏

例如Cursor，没有及时关闭，会因持有Activity引用，造成内存泄漏。

解决方法：在onDestroy中及时的关闭。

5，Handler的使用

Handler对象会发送Message到MessageQueue，Looper对象会轮询MessageQueue对象去除Message执行。如果

Message对象长时间未被取出执行。则Message对象持有Handler对象，Handler对象持有Activity（可能）。造成泄漏。

解决方法，在onDestroy中，Handler removeMessage。

欢迎指正！