LeakCanary代码量比较多，阅读源码容易把人绕晕，提取主干代码，精简后的代码只有200行，看完这200行代码，LeakCanary检测内存泄露原理应该就清楚了,回头再看LeakCanary完整源码就不再神秘。
精简后的源代码已发布在Github上:https://github.com/andev009/LearnLeakCanary
LeakCanary是安卓开发中分析内存泄露的工具。源代码内容很多，总结起来主要分三个部分：1.检测泄露，2，分析泄露，3，通知泄露。分析泄露用到了HAHA这个工具，有兴趣的可以单独分析，通知泄露，利用安卓自身消息机制，Service, Notification, Activity这些，按流程走就行了。本文分析内存泄露检测这块，这块才是LeakCanary原理的核心。
LeakCanary检测内存泄露分两个部分：
1.监听Activity生命周期，在Activity销毁的时候通知LeakCanary。
2.内存泄露检测.
监听Activity生命周期
public class LearnLeakCanaryApplication extends Application {
@Override
public void onCreate() {
super.onCreate();
ActivityRefWatcher.install(this, new RefWatcher());
}
}
首先看入口，在Application完成注册工作，和LeakCanary源码注册不一样，用的ActivityRefWatcher完成注册，其实LeakCanary也差不多，不过多了各种配置。
注册主要做两件事，一是Application绑定Activity生命周期,Activity销毁的时候都能监听到。二是new了个RefWatcher对象，RefWatcher就做了一件事，检测泄露，如果泄露就捕捉给HAHA处理。这样看，这一句代码就完成了两件重要的工作。
ActivityRefWatcher注册时最后的调用watchActivities，在这个函数里完成Application和生命周期的监听注册。
public static void install(Application application, RefWatcher refWatcher) {
new ActivityRefWatcher(application, refWatcher).watchActivities();
}
public void watchActivities() {
// Make sure you don't get installed twice.
stopWatchingActivities();
application.registerActivityLifecycleCallbacks(lifecycleCallbacks);
}
lifecycleCallbacks就是生命周期回调，Activity销毁时，会被Application监听，然后走onActivityDestroyed回调。在onActivityDestroyed里，把自己交给RefWatcher，让RefWatcher去检测自己是否真的被回收。
private final Application.ActivityLifecycleCallbacks lifecycleCallbacks =
new Application.ActivityLifecycleCallbacks() {
@Override public void onActivityCreated(Activity activity, Bundle savedInstanceState) {
}
@Override public void onActivityStarted(Activity activity) {
}
@Override public void onActivityResumed(Activity activity) {
}
@Override public void onActivityPaused(Activity activity) {
}
@Override public void onActivityStopped(Activity activity) {
}
@Override public void onActivitySaveInstanceState(Activity activity, Bundle outState) {
}
@Override public void onActivityDestroyed(Activity activity) {
Log.d(TAG, activity.getLocalClassName() + " onActivityDestroyed");
ActivityRefWatcher.this.onActivityDestroyed(activity);
}
};
内存泄露判断
内存泄露判断主要是用到了WeakReference和ReferenceQueue，他们俩的关系很简单，弱引用对象回收了，弱引用对象就会在ReferenceQueue里，如果ReferenceQueue里没有，就说明可能泄露。至于为什么会这样，看Reference源码这里入队列这段注释。
/**
* Adds this reference object to the queue with which it is registered,
* if any.
*
* This method is invoked only by Java code; when the garbage collector
* enqueues references it does so directly, without invoking this method.
*
* @return true if this reference object was successfully
* enqueued; false if it was already enqueued or if
* it was not registered with a queue when it was created
*/
public boolean enqueue() {
return queue != null && queue.enqueue(this);
}
上面说可能泄露是因为GC不一定及时，所以LeakCanary会再调一次GC，然后再检测ReferenceQueue是否存在回收的对象。如果这次还没有就是泄露了，后面的逻辑就是给HAHA分析，Notification通知。
void ensureGone(final KeyedWeakReference reference, String referenceName, final long watchStartNanoTime) {
long gcStartNanoTime = System.nanoTime();
long watchDurationMs = NANOSECONDS.toMillis(gcStartNanoTime - watchStartNanoTime);
removeWeaklyReachableReferences();
if (gone(reference)) {
return;
}
gcTrigger.runGc();
removeWeaklyReachableReferences();
if (!gone(reference)) {
//do HeapDump, HeapAnalyzer
Log.d("RefWatcher", Thread.currentThread().getName());
Log.d("RefWatcher",referenceName + " leaked!");
}
return;
}
整个流程很简单，精简后的代码只有不到200行。需要说明的是，LeakCanary在新线程里检测，这里为了代码简单，用Handle postDelayed 5秒后在主线程检测，原理都一样。跑Demo时，看ensureGone里泄露时的Log。SecondActivity，ThirdActivity之所以内存泄露是因为里面的内部类持有外部引用。仔细看看Log,应该就理解原理了。
