LeakCanary详解（源码分析）
LeakCanary目前已经成为我们在开发阶段查找内存泄漏的一个关键手段了，主要是因为LeakCanary的便捷性，我们不用再经常费劲的去看mat了。
LeakCanary在检测内存泄漏方面的一个重要原理其实就是（ReferenceQueue），下面我们来介绍一下ReferenceQueue。
ReferenceQueue
当系统检测到与ReferenceQueue有关联的对象被回收后，会把对象的引用加入到ReferenceQueue队列中。举个例子：
当我们想检测一个对象是否被回收了，那么我们就可以采用 Reference + ReferenceQueue，需要几个步骤：
1、创建一个引用队列 ReferenceQueue。
2、创建 refrence 对象，并关联引用队列 ReferenceQueue。
3、在 reference 被回收的时候，refrence 会被添加到 ReferenceQueue中。
ReferenceQueue<Object> queue = new ReferenceQueue<Object>() ;
Object o = new Object() ;
WeakReference<Object> refrence = new WeakReference<>(o , queue);
o = null ;
System.gc() ;
Thread.sleep(5000) ;
System.out.println(queue.poll()) ;在了解了ReferenceQueue后，我们来看一下LeakCanary检测内存泄漏的流程。
现在我们结合具体代码来分析一下上面的流程：
1、App.install()
LeakCanary.java
//这里的install主要是调用了refWatcher这个静态函数
public static @NonNull RefWatcher install(@NonNull Application application) {
return refWatcher(application).listenerServiceClass(DisplayLeakService.class)
.excludedRefs(AndroidExcludedRefs.createAppDefaults().build())
.buildAndInstall();
}
//这里返回一个AndroidRefWatcherBuilder
public static @NonNull AndroidRefWatcherBuilder refWatcher(@NonNull Context context) {
return new AndroidRefWatcherBuilder(context);
}
AndroidRefWatchBuilder.java
//ok，其实refWatcher这个静态函数最终要返回的就是一个RefWatcher
public @NonNull RefWatcher buildAndInstall() {
if (LeakCanaryInternals.installedRefWatcher != null) {
throw new UnsupportedOperationException("buildAndInstall() should only be called once.");
}
RefWatcher refWatcher = build();
if (refWatcher != DISABLED) {
if (enableDisplayLeakActivity) {
LeakCanaryInternals.setEnabledAsync(context, DisplayLeakActivity.class, true);
}
if (watchActivities) {
//为Activity注册生命周期监听
ActivityRefWatcher.install(context, refWatcher);
}
if (watchFragments) {
//为Fragment注册生命周几监听
FragmentRefWatcher.Helper.install(context, refWatcher);
}
}
LeakCanaryInternals.installedRefWatcher = refWatcher;
return refWatcher;
}LeakCanary这个类相当于一个工厂类，对外封装了RefWatcher的构造方法。其中在buildAnInstall()里，我们会注册activity和fragment的生命周期监听（watchActivitys和watchFragments默认都是true，可以根据自己需要自行修改），下面我们来分析下activity的生命周期监听。
ActivityRefWatcher.java
public static void install(@NonNull Context context, @NonNull RefWatcher refWatcher) {
Application application = (Application) context.getApplicationContext();
ActivityRefWatcher activityRefWatcher = new ActivityRefWatcher(application, refWatcher);
//通过Application的registerActivityLifecycleCallbacks
application.registerActivityLifecycleCallbacks(activityRefWatcher.lifecycleCallbacks);
}监控activity的生命周期是通过Application的registerActivityLifecycleCallbacks来实现的，registerActivityLifecycleCallbacks可以监控到activity的所有生命周期函数。
当activity的调用了onDestroy生命结束的时候，会出发onActivityDestroyed这个回调函数，这里我们看到了refWatcher.watch(activity)
ActivityRefWatch.java
private final Application.ActivityLifecycleCallbacks lifecycleCallbacks =
new ActivityLifecycleCallbacksAdapter() {
@Override public void onActivityDestroyed(Activity activity) {
refWatcher.watch(activity);
}
};refWatcher.watch()从这里开始，我们进入了真正的内存泄漏检测工作。前面所介绍的是对象的生命周期检测工作。当有对象的寿命周期结束的时候，我们就要检测它是否存在内存泄漏喽！
在watch中我们主要做三件事情：
1、生成一个UUID（唯一）
2、把UUID放到retainKeys中，retainKeys作为RefWatcher的成员变量，用来辅助检测对象是否存在泄漏，如果对象被回收会把对象的UUID从retainedKeys中移除（Set<String> retainedKeys）
3、创建一个弱引用，指向被监测的对象，并把弱引用和queue(ReferenceQueue)关联。关于ReferenceQueue请看文章前部有详细介绍。
4、判断reference是否被正确回收
RefWatcher.java
//watchedReference就是我们要监测的activity或者fragment了
public void watch(Object watchedReference, String referenceName) {
.....
//1、生命一个UUID
String key = UUID.randomUUID().toString();
//2、把UUID放到retainedKeys中
retainedKeys.add(key);
//3、创建弱引用，指向检测的对象
final KeyedWeakReference reference =
new KeyedWeakReference(watchedReference, key, referenceName, queue);
//4、判断reference是否被正确回收
ensureGoneAsync(watchStartNanoTime, reference);
}好了，到这里正如我们前面介绍的ReferenceQueue时候讲的，我们已经把一个弱引用和一个ReferenceQueue关联起来了。前面我们讲过，当引用对应的对象被回收后，这个引用会加入到对应的ReferenceQueue中。对应到我们这里就是这里如果reference指向的activity被回收后，refernce就会加入到queue中。
我们来继续分析上面的第4步（判断reference是否被正确回收）
Retryable.Result ensureGone(final KeyedWeakReference reference, final long watchStartNanoTime) {
long gcStartNanoTime = System.nanoTime();
long watchDurationMs = NANOSECONDS.toMillis(gcStartNanoTime - watchStartNanoTime);
removeWeaklyReachableReferences();//下面分析
if (debuggerControl.isDebuggerAttached()) {
//排除debug的状况
// The debugger can create false leaks.
return RETRY;
}
if (gone(reference)) {
//如果reference已经不在retainedKeys中了，说明被正确回收了
return DONE;
}
gcTrigger.runGc(); //执行垃圾回收
removeWeaklyReachableReferences();
if (!gone(reference)) {
//如果reference在retainKeys中，没被回收啊！兄嘚
long startDumpHeap = System.nanoTime();
long gcDurationMs = NANOSECONDS.toMillis(startDumpHeap - gcStartNanoTime); //本次gc时间？
File heapDumpFile = heapDumper.dumpHeap();
if (heapDumpFile == RETRY_LATER) {
// Could not dump the heap.
return RETRY;
}
long heapDumpDurationMs = NANOSECONDS.toMillis(System.nanoTime() - startDumpHeap);
HeapDump heapDump = heapDumpBuilder.heapDumpFile(heapDumpFile).referenceKey(reference.key)
.referenceName(reference.name)
.watchDurationMs(watchDurationMs)
.gcDurationMs(gcDurationMs)
.heapDumpDurationMs(heapDumpDurationMs)
.build();
heapdumpListener.analyze(heapDump);
}
return DONE;
}
private void removeWeaklyReachableReferences() {
// WeakReferences are enqueued as soon as the object to which they point to becomes weakly
// reachable. This is before finalization or garbage collection has actually happened.
//当弱引用指向的对象被回收后，相应的弱引用会加入到queue中，这里把被回收的对象从retainedKeys中移除
KeyedWeakReference ref;
while ((ref = (KeyedWeakReference) queue.poll()) != null) {
retainedKeys.remove(ref.key);
}
}
private boolean gone(KeyedWeakReference reference) {
return !retainedKeys.contains(reference.key);
}这里我们先分析两个辅助方法：
1、boolean gone(KeyedWeakReference reference)，这个方法比较简单，就是判断引用是否还在retainedKeys中。如果不在retainedKeys则返回true。
2、void removeWeaklyReachableReferences()，这个方法也比较简单，就是移除了queue队头的一个引用，然后把这个引用对应在retainedKey中的UUID移除。
有了上面的两个辅助函数，下面我们来继续分析ensureGone。
1、先进行了一些时间上的计算，这个可以自己分析下源码。
2、调用了一次removeWeaklyReachableReferences()，移除了queue队头的一个引用（如果队列不为空的情况）
3、调用gone(reference)，判断reference是否还在retainedKey中，上面我们分析过retainedKey，这里可以看出如果调用了一次removeWeaklyReachableReferences后reference还在retainedKey中，说明对象没有被回收可能出现泄漏，如果已经不在retainedKey中，直接返回DONE。
4、gcTrigger.runGc(); //执行垃圾回收
5、重复（步骤2、3），执行了垃圾回收后再看看reference是否被回收。如果没被回收，对不起，可能泄漏了。
根据开始时候的流程介绍，现在我们要走入了heapdump的地盘。
6、File heapDumpFile = heapDumper.dumpHeap();这里开始，我们要去dump现在的内存情况了，其实就是生成一个hropf，使用过mat的同学肯定了解这个后缀的文件是可以查看内存中对象的引用链的。
7、内存dump结束后就是分析refrence的引用链了。heapdumpListener.analyze(heapDump)。
第6、7步这里没有具体的代码引用，喜欢的童鞋可以自己看下，代码在AndroidHeapDumper和HeapAnalyzerService中
其中dump内存使用的是Debug.dumpHprofData(heapDumpFile.getAbsolutePath());这个方法，二分析hropf的代码主要在analyzer这个moduler下面，分析的代码我并没有看，因为没有找到hropf的具体文件结构。以后找到了再继续分析下！
总结：
本文主要是分析了下LeakCanary的工作流程，其工作流程简单的抽象出来就是。
1、注册对象生命周期监听
2、利用ReferenceQueue检测对象是否正确回收（二次确认）
3、dump内存生成hropf文件
4、分析hropf文件，查找泄漏对象到gcroot的最短引用路径
最后附上一张LeakCanary的uml草图：