LeakCanary的原理初探

一、前言：

LeakCanary是很早之前的大名鼎鼎的square推出的一款安卓排查内存泄漏的工具。其功嫩相当强大，还记得19年的时候刚刚接触这款工具时，我们之前花了一整天找到的内存泄漏问题，用这款工具只用了大约十分钟就顺利的定位到了问题原因。

LeakCanary主要分为两块内容，第一块是发现排查内存泄漏问题，第二块是根据内存的状态输出泄漏的堆栈。本文主要讲解第一块内容，后续有时间会把第二块内容也补上。

PS：目前LeakCanary已经更新到2.8.1的版本，但是新版本代码结构较为复杂。所以本文还是机基于1.6.3的源码进行分析。

项目地址：https://github.com/square/leakcanary

二、原理简介：

LeakCanary的核心原理是在application中，注册所有activity的生命周期回调。当一个activity调用destory方法的时候，生成一个弱引用对象，然后加入到ReferenceQueue中。当一个对象如果可以被释放，那么其弱引用对象就会加入到ReferenceQueue中。

我们只要多次检查ReferenceQueue中是否存在这个activity的弱引用对象，就可以知道这个activity是否被泄漏了。

三、原理分析：

3.1 两个LeakCanary类

其实LeakCanary有两个实现类，第一个在leakcanary-android的library中，第二个在leakcanary-android-no-op的library中，区别很简单。第二个里面是空实现，LeakCanary是不推荐线上使用的，所以写了一个空实现，release包时使用。

3.2 LeakCanary注册

 protected void setupLeakCanary() {
    enabledStrictMode();
    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(this);
  }

我们项目中有可能有多个进程，我们只要对对主进程进行检查即可。

3.3 何时开启的回调注册

1.上述调用install后，会调用到AndroidRefWatcherBuilder的buildAndInstall()方法。

这里有两个参数watchActivities和watchFragments，分别对activity和fragment进行泄漏检查。

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) {
        ActivityRefWatcher.install(context, refWatcher);
      }
      if (watchFragments) {
        FragmentRefWatcher.Helper.install(context, refWatcher);
      }
    }
    LeakCanaryInternals.installedRefWatcher = refWatcher;
    return refWatcher;
  }

2.这里以Activity的注册为例，ActivityRefWatcher.install方法中，注册了所有activity的生命周期回调。

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

    application.registerActivityLifecycleCallbacks(activityRefWatcher.lifecycleCallbacks);
  }

3.4 activity在destroy的时候如何去检查的

1.首先，会通过RefWatcher的watch方法开启检查。

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

2.watch方法中，首先会针对activity生成一个弱引用对象。key值是随机生成的，主要是为了识别唯一的一个activity弱引用对象。

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);
  }

3.ensureGoneAsync中，利用线程池中的线程，开启对内存泄漏的检查。这也是自然，毕竟不能在主线程进行检查。

这里的watchExecutor可以由外部传入，经典的组合模式。watchExecutor的不同，最终的组合逻辑就有区别了。可以满足不同的场景需求。

private void ensureGoneAsync(final long watchStartNanoTime, final KeyedWeakReference reference) {
    watchExecutor.execute(new Retryable() {
      @Override public Retryable.Result run() {
        return ensureGone(reference, watchStartNanoTime);
      }
    });
  }

4.ensureGone方法是整篇文章的核心。所以这里会拆成好多步讲解

 @SuppressWarnings("ReferenceEquality") // Explicitly checking for named null.
  Retryable.Result ensureGone(final KeyedWeakReference reference, final long watchStartNanoTime) {
    ...
    removeWeaklyReachableReferences();//第一步

    ...
    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;
  }

5.第一步，removeWeaklyReachableReferences方法。前文讲到了ReferenceQueue的属性，一个弱引用对象如果可以被释放，那么就会加入到这个队列中。我们遍历queue队列，把queue中的每一个key从retainedKeys中删除。这个操作对应上面3.4.2中的retainedKeys.add()。

retainedKeys中有，代表其所对应的Activity已经destory，但还未被释放。从retainedKeys中删除，则代表已经被释放（虽然这时候如果没有GC的话，其对象的内存空间还在）。

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);
    }
  }

6.第二步，使用gone方法检查是否符合被释放条件。

private boolean gone(KeyedWeakReference reference) {
    return !retainedKeys.contains(reference.key);
  }

7.第三步，尝试同志虚拟机进行一次垃圾回收操作。

我们知道，Java是由虚拟机控制的回收机制，所以一个对象复合了回收条件后，并不一定是会被立马释放掉的，同样的，也不会立马去检查是否符合释放条件。所以这时候就需要我们主动通知一下虚拟机去进行对应的操作。

这里也是经典的组合模式，触发runGc的对象也是可以被传入的。

public void runGc() {
      // Code taken from AOSP FinalizationTest:
      // https://android.googlesource.com/platform/libcore/+/master/support/src/test/java/libcore/
      // java/lang/ref/FinalizationTester.java
      // System.gc() does not garbage collect every time. Runtime.gc() is
      // more likely to perform a gc.
      Runtime.getRuntime().gc();
      enqueueReferences();
      System.runFinalization();
    }

Runtime.getRuntime().gc();//是通知虚拟机进行gc操作的。

enqueueReferences方法其实只是sleep了当前线程100毫秒，毕竟垃圾回收不是一下子就可以完成的。

System.runFinalization();  //强制调用已经失去引用的对象的finalize方法 

8.第四步，再次调用removeWeaklyReachableReferences方法检查是否符合释放条件。

9.第五步，再次调用gone进行判断。

10.第六步，如果这时候还没有符合被释放的条件，那么就说明这个activity有可能被泄漏了，这时候就要获取一下当前的内存堆栈信息，调用分析工具进行分析了。