大家知道Android系統(tǒng)對app的內(nèi)存有一個上限，如果代碼風格不好，業(yè)務龐大，時間緊沒有代碼評審來約束，是很容易引起OOM異常的，通常我們碰到這種問題，需要用profile工具去仔細的分析和排查，才能找到可能的原因?，F(xiàn)在向大家介紹LeakCanary，是一款監(jiān)測內(nèi)存泄露的工具，由大名鼎鼎的Square公司開發(fā)并開源。

基本用法

參見LeakCanary官方的介紹，一步搞定！
官網(wǎng)介紹的方法非常簡單，可以自動監(jiān)測Activity泄露，原理很直接，就是用application的ActivityLifeCycleCallback，在onActivityDestroyed時去watch。那我們遵循這個套路，自己構(gòu)建一個RefWatcher，就可以做到監(jiān)聽任何一個實例，只需要在該實例理論上應該銷毀的時候watch一下就可以了。此處說銷毀并不是真的要銷毀，而是沒有引用，也就是所謂的jvm內(nèi)存管理的不可達狀態(tài)。

原理

jvm內(nèi)存管理

我們知道，java相對C++有一個巨大的好處就是可以不用做復雜且容易出錯的內(nèi)存管理，jvm有一個內(nèi)存回收器會周期性的回收不用的內(nèi)存，細節(jié)性的東西很多，也不影響我們理解LeakCanary的原理，我們暫且跳過。只需知道jvm會自動幫我們回收不需要的內(nèi)存，但是還是有內(nèi)存泄露的可能。

總體設計圖

流程圖

Main.jpg

核心類介紹

LeakCanary

入口類。接口很簡單，簡單到只有一個install函數(shù)就可以運行，默認配置已經(jīng)可以應對絕大部分場景，除非你想定制一些行為。

/**
   * Creates a {@link RefWatcher} that works out of the box, and starts watching activity
   * references (on ICS+).
   */
  public static RefWatcher install(Application application) {
    return refWatcher(application).listenerServiceClass(DisplayLeakService.class)
        .excludedRefs(AndroidExcludedRefs.createAppDefaults().build())
        .buildAndInstall();
  }

/** Builder to create a customized {@link RefWatcher} with appropriate Android defaults. */
  public static AndroidRefWatcherBuilder refWatcher(Context context) {
    return new AndroidRefWatcherBuilder(context);
  }

對設計模式有了解，或者看過一些開源框架的代碼，可能知道這塊使用了Builder模式，這個Builder其實很好理解，個人認為主要的使用場景，就是在構(gòu)建一個實例時，有太多參數(shù)可以配置，如果都放到構(gòu)造函數(shù)去做，那就顯得太羅嗦，接口不簡潔。使用setter，好像也不太好，我們希望實例構(gòu)建后直接是可用狀態(tài)。關于AndroidRefWatcherBuilder和RefWatcherBuilder后面會有介紹。install方法返回RefWatcher，接下來我們就看看這個RefWatcher。

RefWatcher

顧名思義，引用監(jiān)控，它可以說是一個調(diào)度類，從判斷泄漏，內(nèi)存堆日志分析，結(jié)果展示，這些功能都在RefWatcher里面串起來

/**
 * Watches references that should become weakly reachable. When the {@link RefWatcher} detects that
 * a reference might not be weakly reachable when it should, it triggers the {@link HeapDumper}.
 *
 * <p>This class is thread-safe: you can call {@link #watch(Object)} from any thread.
 */
public final class RefWatcher {
private final WatchExecutor watchExecutor;
  private final DebuggerControl debuggerControl;
  private final GcTrigger gcTrigger;
  private final HeapDumper heapDumper;
  private final Set<String> retainedKeys;
  private final ReferenceQueue<Object> queue;
  private final HeapDump.Listener heapdumpListener;
  private final ExcludedRefs excludedRefs;
}

先了解這里的每一個成員：

• WatchExecutor 提供后臺線程支持以及重試的機制
• DebuggerControl 提供debug狀態(tài)的判斷，調(diào)試時有可能持有引用，規(guī)避誤報泄漏
• GcTrigger 觸發(fā)gc，盡量避免dump heap
• HeapDumper
• retainedKeys 存儲所有監(jiān)控的引用key，key是在watch時UUID生成的
• ReferenceQueue<Object> 監(jiān)控系統(tǒng)gc的結(jié)果
• HeapDump.Listener dump完成的回調(diào)，可以認為是analysis的入口
• ExcludedRefs 預置的忽略引用，Android系統(tǒng)的已知內(nèi)存泄漏，就可以不用管了

AndroidRefWatcherBuilder

這個類就是通常的Builder寫法，只是多了一個RefWatcherBuilder基類，看整個包結(jié)構(gòu)就知道LeakCanary的設計不只是用于Android，而是在java的外面再包一層android實現(xiàn)，這樣擴展性好，watcher層定義行為和流程，android層對應具體的實現(xiàn)。

主流程

前面已經(jīng)把主要的準備工作都介紹了，現(xiàn)在我們開始看看到底是如何監(jiān)聽泄漏的。

RefWatcher.java
 /**
   * Watches the provided references and checks if it can be GCed. This method is non blocking,
   * the check is done on the {@link WatchExecutor} this {@link RefWatcher} has been constructed
   * with.
   *
   * @param referenceName An logical identifier for the watched object.
   */
  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);
  }

1. 記錄當前時間
2. 生成key，生成KeyedWeakReference，記錄弱引用和key

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

  @SuppressWarnings("ReferenceEquality") // Explicitly checking for named null.
  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;
  }

常見泄露場景

1. 匿名內(nèi)部類和非靜態(tài)內(nèi)部類 隱式持有外部類的引用
2. 注冊了引用，沒有解注冊

reference

開源項目之LeakCanary源碼分析
LeakCanary核心原理源碼淺析