LeakCanary简介

leakCanary是square公司推出的一个用于检测内存泄漏的工具，在一个activity完全ondestroy方法执行时，我们都会希望它的内存空间能够完全被回收。但是实际上并非是这样的，往往可能会出现内存泄漏，比如说这个activity被其他没有回收的类所持有引用。那么就会造成ondestory方法执行完之后，这个activity没有被回收，造成内存泄漏。所以，为了让我们在开发测试时更容易的发现内存泄漏的情况，square公司推出了这个开源库。

LeakCanary流程

LeakCanary的使用

对于一个app引入leakCanary这个库是非常的简单的，只需要在gradle文件中引入下面几个依赖,这几个依赖会针对不同的编译版本引入不同的包：

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

然后在代码中，我们只需要在我们项目中的application类去调用install方法建立LeakCanary监测就行了。

  if (LeakCanary.isInAnalyzerProcess(this)) {
        //这个是在分析heap的进程中，监测进程不能和分析进程在同一个。
    return;
    }
    LeakCanary.install(this);

LeakCanary的简单实现流程

在我们在Application类中调用了LeakCanary的install方法之后，就开始整个activity的监测流程。

对application注册了一个关于activity生命周期的回调callBack，在这个回调里面，LeakCanary只关注onDestroy方法，毕竟我们需要监测内存泄漏，肯定是从onDestroy方法开始的。
一旦一个activity执行了ondestroy方法，也就是这个activity需要被销毁时，此时就开始了LeakCanary的工作，会在callBack里面执行watch方法，也就是开始监测了这个activity被销毁的过程。
在watch方法里面，会生成一个带有自定义key值的弱引用，LeakCanary通过这个弱引用来监测是否被完全回收，对于android里面的弱引用的回收，当弱引用指向的对象被gc回收时，此时会将这个弱引用添加到一个对应的队列里面。
假如watch监测出来可能出现内存溢出，此时就会利用一个叫做haha的库，这个库是回来解析heapDump文件的，然后通过这个文件分析是否真正的出现了内存溢出。出现溢出，生成溢出堆栈信息。

LeakCanary的代码实现：

RefWatcher的内部实现

public static RefWatcher install(Application application) {
    return refWatcher(application).listenerServiceClass(DisplayLeakService.class)
        .excludedRefs(AndroidExcludedRefs.createAppDefaults().build())
        .buildAndInstall();
  }

在我们在application调用了install方法时，将会通过builder方法创建RefWatcher。

DisplayLeakService是一个服务类，主要是用来分析泄漏的结果
AndroidExcludedRefs排除android系统的bug 我们先看buildAndInstall的实现

 public RefWatcher buildAndInstall() {
    ...
    //创建RefWatcher实例
    RefWatcher refWatcher = build();
    if (refWatcher != DISABLED) {
      if (watchActivities) {
        //开启Activity监听
        ActivityRefWatcher.install(context, refWatcher);
      }
      if (watchFragments) {
        //开启Fragment监听
        FragmentRefWatcher.Helper.install(context, refWatcher);
      }
    }
    LeakCanaryInternals.installedRefWatcher = refWatcher;
    return refWatcher;
  }

在这个方法中，会创建出RefWatcher，同时开启Activity和Fragment的泄漏的监听。
首先，我们先看看如何开启Activity的监听。

public static void install(Context context, RefWatcher refWatcher) {
    Application application = (Application) context.getApplicationContext();
    ActivityRefWatcher activityRefWatcher = new ActivityRefWatcher(application, refWatcher);

    application.registerActivityLifecycleCallbacks(activityRefWatcher.lifecycleCallbacks);
  }

其中，activityRefWatcher.lifecycleCallbacks为

  private final Application.ActivityLifecycleCallbacks lifecycleCallbacks =
      new ActivityLifecycleCallbacksAdapter() {
        @Override public void onActivityDestroyed(Activity activity) {
          refWatcher.watch(activity);
        }
      };

所以，对于Activity的监听，其实就是对application注册了LifeCycleCallback，在每一个watcheActivity的时候，都会移除上一次的注册。

 public void watchActivities() {
    // Make sure you don't get installed twice.
    stopWatchingActivities();
    application.registerActivityLifecycleCallbacks(lifecycleCallbacks);
  }

  public void stopWatchingActivities() {
    application.unregisterActivityLifecycleCallbacks(lifecycleCallbacks);
  }

最后在onActivityDestroyed的回调，执行watch操作，进行内存泄漏的检测。
其实fragment和activity的监听其实是非常类似的，只不过在onDestory回调到时，调用了RefWatcher的watchFragments方法

 private final Application.ActivityLifecycleCallbacks activityLifecycleCallbacks =
        new ActivityLifecycleCallbacksAdapter() {
          @Override public void onActivityCreated(Activity activity, Bundle savedInstanceState) {
            for (FragmentRefWatcher watcher : fragmentRefWatchers) {
              watcher.watchFragments(activity);
            }
          }
        };

在这个watchFragments中，注册了fragment的监听。

@Override public void watchFragments(Activity activity) {
    if (activity instanceof FragmentActivity) {
      FragmentManager supportFragmentManager =
          ((FragmentActivity) activity).getSupportFragmentManager();
      supportFragmentManager.registerFragmentLifecycleCallbacks(fragmentLifecycleCallbacks, true);
    }
  }

这个fragmentLifecycleCallbacks是fragment的lifeCycleCallback

private final FragmentManager.FragmentLifecycleCallbacks fragmentLifecycleCallbacks =
      new FragmentManager.FragmentLifecycleCallbacks() {
        @Override public void onFragmentDestroyed(FragmentManager fm, Fragment fragment) {
          refWatcher.watch(fragment);
        }
      };

这样，也就是完成了对于fragment的监听，在onFragmentDestroyed调用时，也会调用watch方法进行检测内存泄漏，只不过和activity不一样的是，在这里传入的fragment实例。

对于RefWatcher，这个类是LeakCanary的核心。我们可以先看看其中的一些成员变量

  //执行内存泄漏的检测
  private final WatchExecutor watchExecutor;
  //用于查询是否在查询中
  private final DebuggerControl debuggerControl;
  //处理Gc，执行gc操作
  private final GcTrigger gcTrigger;
  //Dump内存泄漏的堆文件
  private final HeapDumper heapDumper;
  private final HeapDump.Listener heapdumpListener;
  private final HeapDump.Builder heapDumpBuilder;
  //产生内存泄漏的key
  private final Set retainedKeys;
  //引用队列
  private final ReferenceQueue

LeakCanary详解