Android Studio和 MAT 内存泄漏分析

（2）非静态内部类创建静态实例造成的内存泄漏

public class MainActivity extends AppCompatActivity {

private static TestResource mResource = null;

@Override

protected void onCreate(Bundle savedInstanceState) {

super.onCreate(savedInstanceState);

setContentView(R.layout.activity_main);

if(mManager == null){

mManager = new TestResource();

}//…

}

class TestResource {//…

}

}

非静态内部类默认会持有外部类的引用，而该非静态内部类又创建了一个静态的实例，该实例的生命周期和应用的一样长，这就导致了该静态实例一直会持有该Activity的引用，导致Activity的内存资源不能正常回收。

（3）匿名内部类造成的内存泄漏

匿名内部类默认也会持有外部类的引用。如果在Activity/Fragment中使用了匿名类，并被异步线程持有,如果没有任何措施这样一定会导致泄漏。

程序员Android 转于网络

ref1和ref2的区别是，ref2使用了匿名内部类。我们来看看运行时这两个引用的内存：

程序员Android 转于网络

可以看到，ref1没什么特别的。但ref2这个匿名类的实现对象里面多了一个引用：

this$0这个引用指向MainActivity.this，也就是说当前的MainActivity实例会被ref2持有，如果将这个引用再传入一个异步线程，此线程和此Acitivity生命周期不一致的时候，就会造成Activity的泄漏。

例子：Handler造成的内存泄漏

程序员Android 转于网络

在该 MainActivity 中声明了一个延迟10分钟执行的消息 Message，mHandler 将其 push 进了消息队列 MessageQueue 里。当该 Activity 被 finish() 掉时，延迟执行任务的 Message 还会继续存在于主线程中，它持有该 Activity 的 Handler 引用，然后又因 为 Handler 为匿名内部类，它会持有外部类的引用（在这里就是指 MainActivity），所以此时 finish() 掉的 Activity 就不会被回收了，从而造成内存泄漏。

修复方法：在 Activity 中避免使用非静态内部类或匿名内部类，比如将 Handler 声明为静态的，则其存活期跟 Activity 的生命周期就无关了。如果需要用到Activity，就通过弱引用的方式引入 Activity，避免直接将 Activity 作为 context 传进去。另外， Looper 线程的消息队列中还是可能会有待处理的消息，所以我们在 Activity 的 Destroy 时或者 Stop 时应该移除消息队列 MessageQueue 中的消息。见下面代码：

程序员Android 转于网络

（4）资源未关闭造成的内存泄漏

对于使用了BraodcastReceiver，ContentObserver，File， Cursor，Stream，Bitmap等资源的使用，应该在Activity销毁时及时关闭或者注销，否则这些资源将不会被回收，造成内存泄漏。

（5）一些不良代码造成的内存压力

有些代码并不造成内