LeakCanary背景

java.lang.OutOfMemoryError
        at android.graphics.Bitmap.nativeCreate(Bitmap.java:-2)
        at android.graphics.Bitmap.createBitmap(Bitmap.java:689)
        at com.squareup.ui.SignView.createSignatureBitmap(SignView.java:121)

大名鼎鼎的OOM，就是内存泄漏，那什么是内存泄漏呢？

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

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

所以，我们在写程序的时候，要捕捉到我们写的存在内存泄漏的代码修复掉，LeakCanary就应运而生！

LeakCanary简介

LeakCanary 是啥？它的说明是这样的：
A memory leak detection library for Android and Java./一个Android和java内存泄漏检测库。
很简单，就是捕获内存泄漏的

LeakCanary好处

它可以在我们的应用发生内存泄漏的时候发出提醒，提醒包括通知和Log。并且集成起来特别简单方便

LeakCanary缺点

有好处就会有缺点，LeakCanary也不是万能的。
它是在相应的问题页面回退之后才会分析是否存在内存泄漏，如果存在内存泄漏，将进行相应的分析并处理，若没有则不会。它不能做到MAT或者studio中相应的实时查看内存状态，并且检测具有很大的延时，最少10s。

LeakCanary使用

①在你的build.gradle中添加依赖：

dependencies {
  debugCompile 'com.squareup.leakcanary:leakcanary-android:1.5.4'
  releaseCompile 'com.squareup.leakcanary:leakcanary-android-no-op:1.5.4'
}

②在你的Application中初始化

public class MyApplication 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);
    // Normal app init code...
  }
}

这样就可以了。
然后测试一下怎么样，我们自己弄出一个内存泄露看看它怎么工作的吧

public class ErrorTestActivity extends AppCompatActivity {

    private static ErrorTest mErrorTest;

    @Override
    protected void onCreate(@Nullable Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        if (mErrorTest == null) {
            mErrorTest = new ErrorTest();
        }
        finish();
    }

    class ErrorTest {
    }
}

我们首先再来分析一下这个程序：
这个Activity中，存在一个静态的ErrorTest实例，并且这个实例在Activity初始化的时候也进行了初始化，接着我们在初始化完毕后finish掉这个Activity。
因为mErrorTest是一个静态的变量并且不为null，所以GC不会将其清理，而Activity因为持有这个静态变量，生命周期也不能正常执行，不能进行onDestroy()。这样这个Activity内存泄漏了！

安装我们的应用后，手机上会出现如下两个图标：
左侧的是自己应用的图标，右侧是自动给安装的LeakCanary的图标。

安装样式

打开我们的APP，跳转到我们的问题页面ErrorTestActivity，人为制造内存泄漏，之后Back出去，等一段时间，看情况，一般会大于10s，有些会更长（不清楚具体的触发条件，什么时候开始检测，作者也没具体说明）因为ErrorTestActivity存在内存泄漏，LeakCanary就会检测出来，Toast提示：

检测样式

OK，出现这样的Toast，你的代码就存在内存泄漏了，然后打开自动给你安装的LeakCanary小程序（这里需要点小耐心，因为需要一会才会更新到LeakCanary上面）

展示错误信息

OK，根据展示信息，ErrorTestActivity里面的的实例对象被泄漏了

LeakCanary进阶 - RefWatcher

RefWatcher的作用是监控那些本该被回收的对象
看上面我们在Application我们初始化LeakCanary的代码有这么一行：

LeakCanary.install(this);

它会返回一个预定义的RefWatcher，同时也会启用一个 ActivityRefWatcher，用于自动监控
调用了Activity.onDestroy()之后存在泄露的activity。我们也可以使用RefWatcher来监测我们关心的对象。
那这样我们可以这么写我们的Application

public class MyApplication extends Application {

  private static RefWatcher refWatcher;

  @Override 
  public void onCreate() {
    super.onCreate();
    if (LeakCanary.isInAnalyzerProcess(this)) {
      return;
    }
    //LEAK_ENABLE就是个开关，我是用来标识发包版本关闭LeakCanary工具的
    ifBuildConfig.LEAK_ENABLE){
      refWatcher = LeakCanary.install(this);
    }
  }

  public static RefWatcher getRefWatcher() {
      return refWatcher;
  }
}

这样我们就可以使用RefWatcher监控一些本该关掉（调用onDestroy了）的对象，比如使用RefWatcher监控自定义的Fragment：

public abstract class TLifeBaseFragment extends Fragment {

    ····

    @Override 
    public void onDestroy() {
        super.onDestroy();
        RefWatcher refWatcher = MyApplication.getRefWatcher();
        refWatcher.watch(this);
    }
}

最后附上GitHub的链接地址：GitHub

感谢成长过程中的大神们：
LeakCanary: 让内存泄露无所遁形
LeakCanary 中文使用说明