使用

参考我之前写的《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<? extends AbstractAnalysisResultService> 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