Android 内存泄漏检查工具LeakCanary源碼浅析

使用

参考我之前写的《Android 内存泄漏工具使用》

监控 Activity 泄露

我们经常把 Activity 当作为 Context 对象使用，在不同场合由各种对象引用 Activity。所以，Activity 泄漏是一个重要的需要检查的内存泄漏之一。

public class ExampleApplication extends Application {
    public static RefWatcher getRefWatcher(Context context) {
        ExampleApplication application = (ExampleApplication) context.getApplicationContext();
        return application.refWatcher;
    }

    private RefWatcher refWatcher;
    @Override public void onCreate() {
        super.onCreate();
        refWatcher = LeakCanary.install(this);
    }
}

LeakCanary.install() 返回一个配置好了的 RefWatcher 实例。它同时安装了 ActivityRefWatcher 来监控 Activity 泄漏。即当 Activity.onDestroy() 被调用之后，如果这个 Activity 没有被销毁，logcat 就会打印出信息告诉你内存泄漏发生了。

leakInfo:In com.example.leakcanary:1.0:1.
* com.example.leakcanary.MainActivity has leaked:
* GC ROOT thread java.lang.Thread.<Java Local> (named 'AsyncTask #1')
* references com.example.leakcanary.MainActivity$2.this$0 (anonymous subclass of android.os.AsyncTask)
* leaks com.example.leakcanary.MainActivity instance                               * 

LeakCanary 自动检测 Activity 泄漏只支持 Android ICS 以上版本。因为 Application.registerActivityLifecycleCallbacks() 是在 API 14 引入的。如果要在 ICS 之前监测 Activity 泄漏，可以重载 Activity.onDestroy() 方法，然后在这个方法里调用 RefWatcher.watch(this) 来实现。

监控 Fragment 泄漏

public abstract class BaseFragment extends Fragment {

    @Override 
    public void onDestroy() {
        super.onDestroy();
        RefWatcher refWatcher = ExampleApplication.getRefWatcher(getActivity());
        refWatcher.watch(this);
    }
}

当 Fragment.onDestroy() 被调用之后，如果这个 fragment 实例没有被销毁，那么就会从 logcat 里看到相应的泄漏信息。

监控其他泄漏

    RefWatcher refWatcher = ExampleApplication.getRefWatcher(getActivity());
    refWatcher.watch(someObjNeedGced);

当 someObjNeedGced 还在内存中时，就会在 logcat 里看到内存泄漏的提示。

原理

1. RefWatcher.watch() 创建一个 KeyedWeakReference 到要被监控的对象。
2. 然后在后台线程检查引用是否被清除，如果没有，调用GC。
3. 如果引用还是未被清除，把 heap 内存 dump 到 APP 对应的文件系统中的一个 .hprof 文件中。
4. 在另外一个进程中的 HeapAnalyzerService 有一个 HeapAnalyzer 使用 另一个开源库HAHA 解析这个hprof文件。（MAT也可以解析hprof，但是是图形化的形式，HAHA完全是非UI形式解析）
5. 得益于唯一的 reference key, HeapAnalyzer 找到 KeyedWeakReference，定位内存泄露。
6. HeapAnalyzer 计算 到 GC roots 的最短强引用路径，并确定是否是泄露。如果是的话，建立导致泄露的引用链。
7. 引用链传递到 APP 进程中的 DisplayLeakService， 并以通知的形式展示出来。

现在就来通过代码来讲解吧
首先，Application的onCreate方法中调用LeakCanary.install(this);做初始化工作
LeakCanary.java

  public static RefWatcher install(Application application) {
    return install(application, DisplayLeakService.class,
        AndroidExcludedRefs.createAppDefaults().build());
  }
  public static RefWatcher install(Application application,
      Class listenerServiceClass,
      ExcludedRefs excludedRefs) {
    //首先判断当前应用程序进程是否在HeapAnalyzerService所在的进程，如果是直接return，HeapAnalyzerService所在的进程是HAHA库专门解析hprof文件的进程
    if (isInAnalyzerProcess(application)) {
      return RefWatcher.DISABLED;
    }
    enableDisplayLeakActivity(application);
    HeapDump.Listener heapDumpListener =
        new ServiceHeapDumpListener(application, listenerServiceClass); //listenerServiceClass就是上面的DisplayLeakService.class，用来显示内存泄漏信息用的
    RefWatcher refWatcher = androidWatcher(application, heapDumpListener, excludedRefs); //构造RefWatcher类对象
    ActivityRefWatcher.installOnIcsPlus(application, refWatcher);  //调用ActivityRefWatcher的方法
    return refWatcher;
  }
//ActivityRefWatcher类，专门针对activity，所以在api14以上的onDestroy中不用监控，自动回调
@TargetApi(ICE_CREAM_SANDWICH) public final class ActivityRefWatcher {
  private final Application.ActivityLifecycleCallbacks lifecycleCallbacks =
      new Application.ActivityLifecycleCallbacks() {
        ..............
        @Override public void onActivityDestroyed(Activity activity) {
          ActivityRefWatcher.this.onActivityDestroyed(activity); //当activity退出执行了onDestory方法的时候就会执行该onActivityDestroyed方法
        }
      };

  private final Application application;
  private final RefWatcher refWatcher;

  void onActivityDestroyed(Activity activity) {
    refWatcher.watch(activity); //调用watch方法
  }

  public void watchActivities() {
    // Make sure you don't get installed twice.
    stopWatchingActivities();
    application.registerActivityLifecycleCallbacks(lifecycleCallbacks); //api14才引入的方法，任何activity生命周期的变化都会回调给lifecycleCallbacks
  }

  public void stopWatchingActivities() {
    application.unregisterActivityLifecycleCallbacks(lifecycleCallbacks);
  }
}

excludedRefs
/* References that should be ignored when analyzing this heap dump. /
SDK导致的内存泄露，随着时间的推移，很多SDK 和厂商 ROM 中的内存泄露问题已经被尽快修复了。但是，当这样的问题发生时，一般的开发者能做的事情很有限。LeakCanary有一个已知问题的忽略列表，AndroidExcludedRefs.java中可以查看到
就是说如果发现AndroidExcludedRefs.java类中维护的列表类的内存泄漏，那么在DisplayLeakService并不会显示出来，同时HeapAnalyzer在计算到GC roots的最短强引用路径，也会忽略这些类
下面具体分析。

此时初始化完毕，如果退出一个activity那么就会执行refWatcher.watch(activity);
RefWatcher.java

  public void watch(Object watchedReference, String referenceName) {
    checkNotNull(watchedReference, "watchedReference");
    checkNotNull(referenceName, "referenceName");
    if (debuggerControl.isDebuggerAttached()) { //连上数据线就此时就返回true了
      return;
    }
    final long watchStartNanoTime = System.nanoTime();
    String key = UUID.randomUUID().toString(); //唯一的key
    retainedKeys.add(key); //key保存在retainedKeys集合
    final KeyedWeakReference reference =
        new KeyedWeakReference(watchedReference, key, referenceName, queue); //虚引用KeyedWeakReference

    watchExecutor.execute(new Runnable() { //watchExecutor就不说了，自定义的一个Executor
        @Override
        public void run() {
            ensureGone(reference, watchStartNanoTime); //关键ensureGone方法
        }
    });
  }
  void ensureGone(KeyedWeakReference reference, long watchStartNanoTime) {
    long gcStartNanoTime = System.nanoTime();
    long watchDurationMs = NANOSECONDS.toMillis(gcStartNanoTime - watchStartNanoTime);
    removeWeaklyReachableReferences();
    if (gone(reference) || debuggerControl.isDebuggerAttached()) { //判断reference是否被回收了已经为null,同时是否插了USB线，调试模式下，不去检查内存泄漏
      return;
    }
    gcTrigger.runGc(); //触发GC
    removeWeaklyReachableReferences();
    if (!gone(reference)) { //哈，此时说明强制发生GC，该引用还在，那么就没被回收咯，可能发生内存泄漏，所以才能继续往下走
      long startDumpHeap = System.nanoTime();
      long gcDurationMs = NANOSECONDS.toMillis(startDumpHeap - gcStartNanoTime);

      File heapDumpFile = heapDumper.dumpHeap(); //关键，生成dropf文件

      if (heapDumpFile == HeapDumper.NO_DUMP) { //NO_DUMP类型，木有生成dropf吧，直接return
        // Could not dump the heap, abort.
        return;
      }
      long heapDumpDurationMs = NANOSECONDS.toMillis(System.nanoTime() - startDumpHeap);
      heapdumpListener.analyze(
          new HeapDump(heapDumpFile, reference.key, reference.name, excludedRefs, watchDurationMs,
              gcDurationMs, heapDumpDurationMs)); //heapdumpListener就是上面初始化的ServiceHeapDumpListener
    }
  }

  private boolean gone(KeyedWeakReference reference) {
    //當referent被回收了,因為removeWeaklyReachableReferences方法所以該key被移出了,contains返回false,gone返回true
    //當referent沒被回收了,因為key還在retainedKeys中,contains返回true,gone返回false
    return !retainedKeys.contains(reference.key);
  }

  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;
    //ReferenceQueue的poll方法,當referent被回收了那麼poll方法返回不為null,沒被GC回收才為null
    while ((ref = (KeyedWeakReference) queue.poll()) != null) { 
      retainedKeys.remove(ref.key); //當referent被回收了,那麼從retainedKeys移出該key
    }
  }

先稍微看下KeyedWeakReference的定義,繼承自WeakReference

final class KeyedWeakReference extends WeakReference