一． 概述：
流程分为三块：
１．监听
２．检测泄露
３．分析
监听
在Android中，当一个Activity走完onDestroy生命周期后，说明该页面已经被销毁了，应该被系统GC回收。通过Application.registerActivityLifecycleCallbacks()方法注册Activity生命周期的监听，每当一个Activity页面销毁时候，获取到这个Activity去检测这个Activity是否真的被系统GC。
检测
当获取了待分析的对象后，需要确定这个对象是否产生了内存泄漏。
通过WeakReference + ReferenceQueue来判断对象是否被系统GC回收，WeakReference 创建时，可以传入一个 ReferenceQueue 对象。当被 WeakReference 引用的对象的生命周期结束，一旦被 GC 检查到，GC 将会把该对象添加到 ReferenceQueue 中，待ReferenceQueue处理。当 GC 过后对象一直不被加入 ReferenceQueue，它可能存在内存泄漏。
当我们初步确定待分析对象未被GC回收时候，手动触发GC，二次确认。
分析
分析这块使用了Square的另一个开源库haha，https://github.com/square/haha，利用它获取当前内存中的heap堆信息的快照snapshot，然后通过待分析对象去snapshot里面去查找强引用关系。
二． 源码流程
１．监听：
在Application里加入代码：
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(getApplication());
然后， install里调用的是：
if (refWatcher != DISABLED) {
if (watchActivities) {
ActivityRefWatcher.install(context, refWatcher);
}
if (watchFragments) {
FragmentRefWatcher.Helper.install(context, refWatcher);
}
}
所以， Application里默认会放对Activity和Fragment的监控。
放的过程比较有意思：
先： application.registerActivityLifecycleCallbacks(activityRefWatcher.lifecycleCallbacks);
在这里lifecycleCallbacks的定义是：
private final Application.ActivityLifecycleCallbacks lifecycleCallbacks =
new ActivityLifecycleCallbacksAdapter() {
@Override public void onActivityDestroyed(Activity activity) {
refWatcher.watch(activity);
}
};
Application里这个Callback的调用时机是：
在Activity.java里， 每个方法比如onCreate里，会有调用：
getApplication().dispatchActivityCreated(this, savedInstanceState);
而dispatchActivityCreated里就会调用自己的callback相应的代码
2 检测
在onActivityDestroy里调用的是：refWatcher.watch(activity);
watch的主要工作就是这个：
final long watchStartNanoTime = System.nanoTime();
String key = UUID.randomUUID().toString();
retainedKeys.add(key);
final KeyedWeakReference reference =
new KeyedWeakReference(watchedReference, key, referenceName, queue);
ensureGoneAsync(watchStartNanoTime, reference);
对每一个监控的对象， 随机生成一个key，放在retainedKeys（private final Set
这里的关键点在创建KeyedWeakReference的时候， 传入了queue。这个是WeakReference的一个特有功能，如果创建一个弱引用， 并且传入一个queue的话， 那么当gc回收这个弱引用的时候， 会将相应的弱引用放在传入的queue中。这个很重要！
接下来， 看ensureGoneAsync的实现：
Retryable.Result ensureGone(final KeyedWeakReference reference, final long watchStartNanoTime) {
long gcStartNanoTime = System.nanoTime();
long watchDurationMs = NANOSECONDS.toMillis(gcStartNanoTime - watchStartNanoTime);
removeWeaklyReachableReferences();
if (debuggerControl.isDebuggerAttached()) {
// The debugger can create false leaks.
return RETRY;
}
if (gone(reference)) {
return DONE;
}
gcTrigger.runGc();
removeWeaklyReachableReferences();
if (!gone(reference)) {
long startDumpHeap = System.nanoTime();
long gcDurationMs = NANOSECONDS.toMillis(startDumpHeap - gcStartNanoTime);
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;
}
其中的removeWeaklyReachableReferences就是
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.
KeyedWeakReference ref;
while ((ref = (KeyedWeakReference) queue.poll()) != null) {
retainedKeys.remove(ref.key);
}
}
根据gc回收时放入queue里的弱引用，将刚才生成key时放入的retainKeys里的被回收的对象的key去掉。
而怎么根据queue来找到key呢？就是在创建弱引用的时候， 将key作为参数传给了弱引用并且存下来当做一个属性。
下面继续看ensureGone的步骤：
remove后retainkeys依然包含我们监控的key的话， 就继续执行gc（gc这里也有一点值得注意的， 放在gc篇里了）。然后看reference是否依然包含key：
private boolean gone(KeyedWeakReference reference) {
return !retainedKeys.contains(reference.key);
}
然后，就检测到有内存泄露了。下面是分析的步骤
- 分析
File heapDumpFile = heapDumper.dumpHeap(); 先拿到dump文件。
AndroidHeapDumper.java中的dumpHeap:
@Override
public File dumpHeap() {
File heapDumpFile = leakDirectoryProvider.newHeapDumpFile();
if (heapDumpFile == RETRY_LATER) {
return RETRY_LATER;
}
FutureResult waitingForToast = new FutureResult<>();
showToast(waitingForToast);
if (!waitingForToast.wait(5, SECONDS)) {
CanaryLog.d("Did not dump heap, too much time waiting for Toast.");
return RETRY_LATER;
}
Notification.Builder builder = new Notification.Builder(context)
.setContentTitle(context.getString(R.string.leak_canary_notification_dumping));
Notification notification = LeakCanaryInternals.buildNotification(context, builder);
NotificationManager notificationManager =
(NotificationManager) context.getSystemService(Context.NOTIFICATION_SERVICE);
int notificationId = (int) SystemClock.uptimeMillis();
notificationManager.notify(notificationId, notification);
Toast toast = waitingForToast.get();
try {
Debug.dumpHprofData(heapDumpFile.getAbsolutePath());
cancelToast(toast);
notificationManager.cancel(notificationId);
return heapDumpFile;
} catch (Exception e) {
CanaryLog.d(e, "Could not dump heap");
// Abort heap dump
return RETRY_LATER;
}
}
dump生成hprof文件是调用：Debug.dumpHprofData(heapDumpFile.getAbsolutePath());
这是集成在vm中的一个功能，不做详细讨论，大致就是把当前的内存状态（对象引用关系）放到一个hprof文件中。生成文件后，弹窗消失。
然后就是生成一个HeapDump的对象， 用heapdumpListner：heapdumpListener.analyze(heapDump);
ServiceHeapDumpListener.java:
@Override public void analyze(HeapDump heapDump) {
checkNotNull(heapDump, "heapDump");
HeapAnalyzerService.runAnalysis(context, heapDump, listenerServiceClass);
}
而这里的HeapAnalyzerService是一个IntentService。在这个新启动的service中执行对hprof文件的分析查找， 最后打印出泄露栈。具体HeapAnalyzerService的工作流程， 会在HeapAnalyzerService篇讲。
参考文章：
https://allenwu.itscoder.com/leakcanary-source
https://blog.csdn.net/xiaohanluo/article/details/78196755
https://allenwu.itscoder.com/leakcanary-source
https://ivanljt.github.io/blog/2017/12/15/%E6%8B%86%E8%BD%AE%E5%AD%90%E7%B3%BB%E5%88%97%E2%80%94%E2%80%94LeakCanary%E5%B7%A5%E4%BD%9C%E5%8E%9F%E7%90%86/
https://cloud.tencent.com/developer/article/1327724