LeakCanary 原理分析
LeakCanary 以1.5版本为例子，简单分析其中的原理。 LeakCanary 可以检测App的内存泄漏，在我们自定义的 Application 的 onCreate() 方法中执行 LeakCanary.install(this); 这行代码即可。代码很简单，我们看看它做了什么
public static RefWatcher install(Application application) {
return refWatcher(application).listenerServiceClass(DisplayLeakService.class)
.excludedRefs(AndroidExcludedRefs.createAppDefaults().build())
.buildAndInstall();
}这个方法前两行是作一些参数配置，重点看 buildAndInstall() 方法
public RefWatcher buildAndInstall() {
RefWatcher refWatcher = build();
if (refWatcher != DISABLED) {
LeakCanary.enableDisplayLeakActivity(context);
ActivityRefWatcher.installOnIcsPlus((Application) context, refWatcher);
}
return refWatcher;
}通过 build() 创建一个 RefWatcher 对象，这是个build模式，看看它的代码
public final RefWatcher build() {
if (isDisabled()) {
return RefWatcher.DISABLED;
}
ExcludedRefs excludedRefs = this.excludedRefs;
if (excludedRefs == null) {
excludedRefs = defaultExcludedRefs();
}
HeapDump.Listener heapDumpListener = this.heapDumpListener;
if (heapDumpListener == null) {
heapDumpListener = defaultHeapDumpListener();
}
DebuggerControl debuggerControl = this.debuggerControl;
if (debuggerControl == null) {
debuggerControl = defaultDebuggerControl();
}
HeapDumper heapDumper = this.heapDumper;
if (heapDumper == null) {
heapDumper = defaultHeapDumper();
}
WatchExecutor watchExecutor = this.watchExecutor;
if (watchExecutor == null) {
watchExecutor = defaultWatchExecutor();
}
GcTrigger gcTrigger = this.gcTrigger;
if (gcTrigger == null) {
gcTrigger = defaultGcTrigger();
}
return new RefWatcher(watchExecutor, debuggerControl, gcTrigger, heapDumper, heapDumpListener,
excludedRefs);
}其中 DebuggerControl 对应 AndroidDebuggerControl，HeapDumper 对应 AndroidHeapDumper，WatchExecutor 对应 AndroidWatchExecutor，GcTrigger 对应它内部的DEFAULT 对象，这几个类都比较简单，但比较有意思。
第一个就不说了，看 AndroidHeapDumper，这里面有几个知识点：FutureResult 的成员变量 AtomicReference 和 CountDownLatch，这是为了并发而准备的，CountDownLatch 是一个线程等待其他线程各自执行完毕后再执行本身，AtomicReference 则是保证原子性的安全；在showToast()方法中设置toast时，这里用了Looper队列MessageQueue的 addIdleHandler() 方法，它是UI空闲时执行，返回值为false则表示执行一次，true则是UI一旦空闲，就执行，没次数限制。
AndroidWatchExecutor 类是个执行功能类，它的构造方法中创建一个 HandlerThread 的子线程，然后把它对应的Looper作为参数，传入Handler的构造方法中，此时这个Handler就一直是在子线程中执行各种逻辑了，它里面通过代码执行延迟操作。 GcTrigger 这个里面执行的是GC操作， Runtime.getRuntime().gc() 比着 System.gc() 的优先级要高，所以优先使用这个。
继续回到 buildAndInstall() 方法，LeakCanary.enableDisplayLeakActivity(context) 的意思是打开显示内存泄漏的页面，这个页面把泄漏的数据以列表的形式展示出来；ActivityRefWatcher.installOnIcsPlus((Application) context, refWatcher) 这行代码则是对Activity执行监听的入口，看看对应的方法
public static void installOnIcsPlus(Application application, RefWatcher refWatcher) {
if (SDK_INT < ICE_CREAM_SANDWICH) {
// If you need to support Android < ICS, override onDestroy() in your base activity.
return;
}
ActivityRefWatcher activityRefWatcher = new ActivityRefWatcher(application, refWatcher);
activityRefWatcher.watchActivities();
}
public void watchActivities() {
// Make sure you don't get installed twice.
stopWatchingActivities();
application.registerActivityLifecycleCallbacks(lifecycleCallbacks);
}
public void stopWatchingActivities() {
application.unregisterActivityLifecycleCallbacks(lifecycleCallbacks);
}
首先是个版本判断，要大于或等于14版本，这里其实就是给 application 注册一个Activity的生命周期回调，注册之前先取消之前的，防止重复注册，看看 lifecycleCallbacks 的方法
private final Application.ActivityLifecycleCallbacks lifecycleCallbacks =
new Application.ActivityLifecycleCallbacks() {
...
@Override public void onActivityDestroyed(Activity activity) {
ActivityRefWatcher.this.onActivityDestroyed(activity);
}
};
void onActivityDestroyed(Activity activity) {
refWatcher.watch(activity);
}在Activity销毁时，执行了 refWatcher.watch(activity)，看看它里面的代码
public void watch(Object watchedReference) {
watch(watchedReference, "");
}
public void watch(Object watchedReference, String referenceName) {
if (this == DISABLED) {
return;
}
checkNotNull(watchedReference, "watchedReference");
checkNotNull(referenceName, "referenceName");
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);
}
private void ensureGoneAsync(final long watchStartNanoTime, final KeyedWeakReference reference) {
watchExecutor.execute(new Retryable() {
@Override public Retryable.Result run() {
return ensureGone(reference, watchStartNanoTime);
}
});
}通过 randomUUID() 方法创建随机的字符串，然后把它存入set中；KeyedWeakReference 是个然引用，这里面传入的也有 ReferenceQueue 队列，看到这里，是不是很熟悉，Glide 的图片缓存中的软引用缓存，也是用的这种技术。看到这里，了解软引用和队列知识点的童鞋，就可以猜测出下面的步骤了
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);
heapdumpListener.analyze(
new HeapDump(heapDumpFile, reference.key, reference.name, excludedRefs, watchDurationMs,
gcDurationMs, heapDumpDurationMs));
}
return DONE;
}对象的引用，如果强引用还有链接，则软引用中对象也会一直存在，如果强引用的链接都被切断了，那么软引用中很容易就被gc回收了，并且会把它放入传入软引用构造中的队列里面，所以 removeWeaklyReachableReferences() 的意思就是检查队列中是否有对象，如果有，说明正常回收，没有内存泄漏，因为此时 Activity 是执行了onDestroy() 方法，如果有内存泄漏，它被别的对象持有，那么它是无法释放资源。 gone() 方法是判断key是否在set中，还是判断Activity是否被回收，如果没被回收，为了保险，这里执行了 gcTrigger.runGc()，也就是主动触发 gc 回收机制，睡眠100毫秒，重新执行 removeWeaklyReachableReferences() 和 gone() 方法，如果此时 Activity 还没被回收，那就说明是内存泄漏了，heapDumper 是 AndroidHeapDumper，在它里面去读取对象的引用路径等信息。读取分析数据用的是 haha 三方库。
在 LeakCanary 1.6 版本中，有对 Fragment 的监听：在手机系统O版本以上，Fragment功能中也新增了对它的声明周期监听回调，
public @NonNull RefWatcher buildAndInstall() {
if (LeakCanaryInternals.installedRefWatcher != null) {
throw new UnsupportedOperationException("buildAndInstall() should only be called once.");
}
RefWatcher refWatcher = build();
if (refWatcher != DISABLED) {
LeakCanaryInternals.setEnabledAsync(context, DisplayLeakActivity.class, true);
if (watchActivities) {
ActivityRefWatcher.install(context, refWatcher);
}
if (watchFragments) {
FragmentRefWatcher.Helper.install(context, refWatcher);
}
}
LeakCanaryInternals.installedRefWatcher = refWatcher;
return refWatcher;
}
AndroidOFragmentRefWatcher:
private final FragmentManager.FragmentLifecycleCallbacks fragmentLifecycleCallbacks =
new FragmentManager.FragmentLifecycleCallbacks() {
@Override public void onFragmentViewDestroyed(FragmentManager fm, Fragment fragment) {
View view = fragment.getView();
if (view != null) {
refWatcher.watch(view);
}
}
@Override
public void onFragmentDestroyed(FragmentManager fm, Fragment fragment) {
refWatcher.watch(fragment);
}
};
@Override public void watchFragments(Activity activity) {
FragmentManager fragmentManager = activity.getFragmentManager();
fragmentManager.registerFragmentLifecycleCallbacks(fragmentLifecycleCallbacks, true);
}这里是根据声明周期，把 rootview 和 fragment 添加到 RefWatcher 的监听方法中，关键就是 watchFragments(Activity activity) 方法是如何触发的，继续看 FragmentRefWatcher，创建了 Helper 对象，把 fragmentRefWatchers 作为参数传入构造方法中，用 ActivityLifecycleCallbacks 包裹了一层，ActivityLifecycleCallbacks 被添加到Application 的回调中，activity销毁时执行 ActivityLifecycleCallbacks 的 onActivityCreated() 方法，此时就触发了 AndroidOFragmentRefWatcher 的 watchFragments()方法。
如果我们想对其他类型的对象进行内存泄漏检测怎么办？Application中的 LeakCanary.install(this) 返回的是 RefWatcher 对象，此时可以做一个单例的Application对象，对外暴露 RefWatcher，这样其他地方就可以直接使用 RefWatcher 的 watch(Object watchedReference) 方法了，但这里需要自己控制时机，因为这里不会根据Activity的声明周期来触发。
LeakCanary 的2.0版本，做了部分修改，使用它时不需要手动LeakCanary.install(this)初始化了，应为它自己做了。里面有个继承 ContentProvider 的内容观察者，观察者的初始化方法居然比 Application 的初始化方法还要早；用了新的内存解析库代替了haha库，极大的减少了内存占用，提高了n被的速度。