什么是内存泄露

一些对象有着有限的生命周期。当这些对象所要做的事情完成了，我们希望他们会被回收掉。但是如果有一系列对这个对象的引用，那么在我们期待这个对象生命周期结束的时候被收回的时候，它是不会被回收的。它还会占用内存，这就造成了内存泄露。持续累加，内存很快被耗尽。

比如，当 Activity.onDestroy 被调用之后，activity 以及它涉及到的 view 和相关的 bitmap 都应该被回收。但是，如果有一个后台线程持有这个 activity 的引用，那么 activity 对应的内存就不能被回收。这最终将会导致内存耗尽，然后因为 OOM 而 crash。

LeakCanary 是一个检测内存泄露的开源类库。你可以在 debug 包种轻松检测内存泄露。

工程的github网址:https://github.com/square/leakcanary  是square公司搞的。

使用：

在 build.gradle 中加入引用，不同的编译使用不同的引用：

 dependencies {

   debugCompile 'com.squareup.leakcanary:leakcanary-android:1.3'

   releaseCompile 'com.squareup.leakcanary:leakcanary-android-no-op:1.3'

 }

在 Application 中：

public class ExampleApplication extends Application {

    @Override

    public void onCreate() {

        super.onCreate();

        if (LeakCanary.isInAnalyzerProcess(this)) {

            // This process is dedicated to LeakCanary for heap analysis.

            // You should not init your app in this process.

            return;

        }

        LeakCanary.install(this);

    }

}

在AndroidManifest中<application>标签下添加

工作机制

1. RefWatcher.watch() 创建一个 KeyedWeakReference 到要被监控的对象。

2. 然后在后台线程检查引用是否被清除，如果没有，调用GC。

3. 如果引用还是未被清除，把 heap 内存 dump 到 APP 对应的文件系统中的一个 .hprof 文件中。

4. 在另外一个进程中的 HeapAnalyzerService 有一个 HeapAnalyzer 使用HAHA 解析这个文件。

5. 得益于唯一的 reference key, HeapAnalyzer 找到 KeyedWeakReference，定位内存泄露。

6. HeapAnalyzer 计算 到 GC roots 的最短强引用路径，并确定是否是泄露。如果是的话，建立导致泄露的引用链。

7. 引用链传递到 APP 进程中的 DisplayLeakService， 并以通知的形式展示出来。

写一个内存泄漏的案例运行

手机生成了两个APK文件，原APP和  Leaks（检测内存泄漏）

检测内存泄漏

运行案例，进入内存泄漏界面，Leak就会分析那些地方存在内存泄漏（时间可能有点久），可以看到服务提示和消息

打开LeaksApp查看详细信息