<p>OOM 是 Android 开发中常见的问题，而内存泄漏往往是罪魁祸首。</p>    <p>为了简单方便的检测内存泄漏，Square 开源了 <a href="/misc/goto?guid=4958874766191309432" rel="nofollow,noindex"> LeakCanary </a> ，它可以实时监测 Activity 是否发生了泄漏，一旦发现就会自动弹出提示及相关的泄漏信息供分析。</p>    <p>本文的目的是试图通过分析 LeakCanary 源码来探讨它的 Activity 泄漏检测机制。</p>    <h2>LeakCanary 使用方式</h2>    <p>为了将 LeakCanary 引入到我们的项目里，我们只需要做以下两步：</p>    <pre>  <code class="language-java">dependencies {   debugCompile 'com.squareup.leakcanary:leakcanary-android:1.5.1'   releaseCompile 'com.squareup.leakcanary:leakcanary-android-no-op:1.5.1'   testCompile 'com.squareup.leakcanary:leakcanary-android-no-op:1.5.1'  }    public class ExampleApplication extends Application {    @Override public void onCreate() {      super.onCreate();      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);    }  }  </code></pre>    <p>可以看出，最关键的就是 LeakCanary.install(this); 这么一句话，正式开启了 LeakCanary 的大门，未来它就会自动帮我们检测内存泄漏，并在发生泄漏是弹出通知信息。</p>    <h2>从 LeakCanary.install(this); 开始</h2>    <p>下面我们来看下它做了些什么？</p>    <pre>  <code class="language-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) {    if (isInAnalyzerProcess(application)) {      return RefWatcher.DISABLED;    }    enableDisplayLeakActivity(application);    HeapDump.Listener heapDumpListener =        new ServiceHeapDumpListener(application, listenerServiceClass);    RefWatcher refWatcher = androidWatcher(application, heapDumpListener, excludedRefs);    ActivityRefWatcher.installOnIcsPlus(application, refWatcher);    return refWatcher;  }  </code></pre>    <p>首先，我们先看最重要的部分，就是：</p>    <pre>  <code class="language-java">RefWatcher refWatcher = androidWatcher(application, heapDumpListener, excludedRefs);  ActivityRefWatcher.installOnIcsPlus(application, refWatcher);  </code></pre>    <p>先生成了一个 RefWatcher ，这个东西非常关键，从名字可以看出，它是用来 watch Reference 的，也就是用来一个监控引用的工具。然后再把 refWatcher 和我们自己提供的 application 传入到 ActivityRefWatcher.installOnIcsPlus(application, refWatcher); 这句里面，继续看。</p>    <pre>  <code class="language-java">public static void installOnIcsPlus(Application application, RefWatcher refWatcher) {      ActivityRefWatcher activityRefWatcher = new ActivityRefWatcher(application, refWatcher);      activityRefWatcher.watchActivities();  }  </code></pre>    <p>创建了一个 ActivityRefWatcher ，大家应该能感受到，这个东西就是用来监控我们的 Activity 泄漏状况的，它调用 watchActivities() 方法，就可以开始进行监控了。下面就是它监控的核心原理：</p>    <pre>  <code class="language-java">public void watchActivities() {    application.registerActivityLifecycleCallbacks(lifecycleCallbacks);  }  </code></pre>    <p>它向 application 里注册了一个 ActivitylifecycleCallbacks 的回调函数，可以用来监听 Application 整个生命周期所有 Activity 的 lifecycle 事件。再看下这个 lifecycleCallbacks 是什么？</p>    <pre>  <code class="language-java">private final Application.ActivityLifecycleCallbacks lifecycleCallbacks =      new Application.ActivityLifecycleCallbacks() {        @Override public void onActivityCreated(Activity activity, Bundle savedInstanceState) {        }          @Override public void onActivityStarted(Activity activity) {        }          @Override public void onActivityResumed(Activity activity) {        }          @Override public void onActivityPaused(Activity activity) {        }          @Override public void onActivityStopped(Activity activity) {        }          @Override public void onActivitySaveInstanceState(Activity activity, Bundle outState) {        }          @Override public void onActivityDestroyed(Activity activity) {          ActivityRefWatcher.this.onActivityDestroyed(activity);        }      };  </code></pre>    <p>原来它只监听了所有 Activity 的 onActivityDestroyed 事件，当 Activity 被 Destory 时，调用 ActivityRefWatcher.this.onActivityDestroyed(activity); 函数。</p>    <p>猜测下，正常情况下，当一个这个函数应该 activity 被 Destory 时，那这个 activity 对象应该变成 null 才是正确的。如果没有变成null，那么就意味着发生了内存泄漏。</p>    <p>因此我们向，这个函数 ActivityRefWatcher.this.onActivityDestroyed(activity); 应该是用来监听 activity 对象是否变成了 null。继续看。</p>    <pre>  <code class="language-java">void onActivityDestroyed(Activity activity) {    refWatcher.watch(activity);  }  RefWatcher refWatcher = androidWatcher(application, heapDumpListener, excludedRefs);  </code></pre>    <p>可以看出，这个函数把目标 activity 对象传给了 RefWatcher ，让它去监控这个 activity 是否被正常回收了，若未被回收，则意味着发生了内存泄漏。</p>    <h2>RefWatcher 如何监控 activity 是否被正常回收呢？</h2>    <p>我们先来看看这个 RefWatcher 究竟是个什么东西？</p>    <pre>  <code class="language-java">public static RefWatcher androidWatcher(Context context, HeapDump.Listener heapDumpListener,      ExcludedRefs excludedRefs) {    AndroidHeapDumper heapDumper = new AndroidHeapDumper(context, leakDirectoryProvider);    heapDumper.cleanup();      int watchDelayMillis = 5000;    AndroidWatchExecutor executor = new AndroidWatchExecutor(watchDelayMillis);      return new RefWatcher(executor, debuggerControl, GcTrigger.DEFAULT, heapDumper,        heapDumpListener, excludedRefs);  }  </code></pre>    <p>这里面涉及到两个新的对象： AndroidHeapDumper 和 AndroidWatchExecutor ，前者用来 dump 堆内存状态的，后者则是用来 watch 一个引用的监听器。具体原理后面再看。总之，这里已经生成好了一个 RefWatcher 对象了。</p>    <p>现在再看上面 onActivityDestroyed(Activity activity) 里调用的 refWatcher.watch(activity); ，下面来看下这个最为核心的 watch(activity) 方法，了解它是如何监控 activity 是否被回收的。</p>    <pre>  <code class="language-java">private final Set<String> retainedKeys;  public void watch(Object activity, String referenceName) {    String key = UUID.randomUUID().toString();    retainedKeys.add(key);      final KeyedWeakReference reference =        new KeyedWeakReference(activity, key, referenceName, queue);      watchExecutor.execute(new Runnable() {      @Override public void run() {        ensureGone(reference, watchStartNanoTime);      }    });  }    final class KeyedWeakReference extends WeakReference<Object> {    public final String key;    public final String name;  }  </code></pre>    <p>可以看到，它首先把我们传入的 activity 包装成了一个 KeyedWeakReference （可以暂时看成一个普通的 WeakReference），然后 watchExecutor 会去执行一个 Runnable，这个 Runnable 会调用 ensureGone(reference, watchStartNanoTime) 函数。</p>    <p>看这个函数之前猜测下，我们知道 watch 函数本身就是用来监听 activity 是否被正常回收，这就涉及到两个问题：</p>    <ol>     <li>何时去检查它是否回收？</li>     <li>如何有效地检查它真的被回收？</li>    </ol>    <p>所以我们觉得 ensureGone 函数本身要做的事正如它的名字，就是确保 reference 被回收掉了，否则就意味着内存泄漏。</p>    <p>核心函数：ensureGone(reference) 检测回收</p>    <p>下面来看这个函数实现：</p>    <pre>  <code class="language-java">void ensureGone(KeyedWeakReference reference, long watchStartNanoTime) {    removeWeaklyReachableReferences();    if (gone(reference) || debuggerControl.isDebuggerAttached()) {      return;    }    gcTrigger.runGc();    removeWeaklyReachableReferences();    if (!gone(reference)) {      File heapDumpFile = heapDumper.dumpHeap();      heapdumpListener.analyze(          new HeapDump(heapDumpFile, reference.key, reference.name, excludedRefs, watchDurationMs,              gcDurationMs, heapDumpDurationMs));    }  }    private boolean gone(KeyedWeakReference reference) {    return !retainedKeys.contains(reference.key);  }    private void removeWeaklyReachableReferences() {    KeyedWeakReference ref;    while ((ref = (KeyedWeakReference) queue.poll()) != null) {      retainedKeys.remove(ref.key);    }  }  </code></pre>    <p>这里先来解释下 WeakReference 和 ReferenceQueue 的工作原理。</p>    <ol>     <li>弱引用 WeakReference<br> 被强引用的对象就算发生 OOM 也永远不会被垃圾回收机回收；被弱引用的对象，只要被垃圾回收器发现就会立即被回收；被软引用的对象，具备内存敏感性，只有内存不足时才会被回收，常用来做内存敏感缓存器；虚引用则任意时刻都可能被回收，使用较少。</li>     <li>引用队列 ReferenceQueue<br> 我们常用一个 WeakReference<Activity> reference = new WeakReference(activity); ，这里我们创建了一个 reference 来弱引用到某个 activity ，当这个 activity 被垃圾回收器回收后，这个 reference 会被放入内部的 ReferenceQueue 中。也就是说，从队列 ReferenceQueue 取出来的所有 reference ，它们指向的真实对象都已经成功被回收了。</li>    </ol>    <p>然后再回到上面的代码。</p>    <p>在一个 activity 传给 RefWatcher 时会创建一个唯一的 key 对应这个 activity，该key存入一个集合 retainedKeys 中。也就是说，所有我们想要观测的 activity 对应的唯一 key 都会被放入 retainedKeys 集合中。</p>    <p>基于我们对 ReferenceQueue 的了解，只要把队列中所有的 reference 取出来，并把对应 retainedKeys 里的key移除，剩下的 key 对应的对象都没有被回收。</p>    <ol>     <li>ensureGone 首先调用 removeWeaklyReachableReferences 把已被回收的对象的 key 从 retainedKeys 移除，剩下的 key 都是未被回收的对象；</li>     <li>if (gone(reference)) 用来判断某个 reference 的key是否仍在 retainedKeys 里，若不在，表示已回收，否则继续；</li>     <li>gcTrigger.runGc(); 手动出发 GC，立即把所有 WeakReference 引用的对象回收；</li>     <li>removeWeaklyReachableReferences(); 再次清理 retainedKeys，如果该 reference 还在 retainedKeys里 (if (!gone(reference)))，表示泄漏；</li>     <li>利用 heapDumper 把内存情况 dump 成文件，并调用 heapdumpListener 进行内存分析，进一步确认是否发生内存泄漏。</li>     <li>如果确认发生内存泄漏，调用 DisplayLeakService 发送通知。</li>    </ol>    <p>至此，核心的内存泄漏检测机制便看完了。</p>    <h2>内存泄漏检测小结</h2>    <p>从上面我们大概了解了内存泄漏检测机制，大概是以下几个步骤：</p>    <ol>     <li>利用 application.registerActivityLifecycleCallbacks(lifecycleCallbacks) 来监听整个生命周期内的 Activity onDestoryed 事件;</li>     <li>当某个 Activity 被 destory 后，将它传给 RefWatcher 去做观测，确保其后续会被正常回收；</li>     <li>RefWatcher 首先把 Activity 使用 KeyedWeakReference 引用起来，并使用一个 ReferenceQueue 来记录该 KeyedWeakReference 指向的对象是否已被回收；</li>     <li>AndroidWatchExecutor 会在 5s 后，开始检查这个弱引用内的 Activity 是否被正常回收。判断条件是：若 Activity 被正常回收，那么引用它的 KeyedWeakReference 会被自动放入 ReferenceQueue 中。</li>     <li>判断方式是：先看 Activity 对应的 KeyedWeakReference 是否已经放入 ReferenceQueue 中；如果没有，则手动GC： gcTrigger.runGc(); ；然后再一次判断 ReferenceQueue 是否已经含有对应的 KeyedWeakReference 。若还未被回收，则认为可能发生内存泄漏。</li>     <li>利用 HeapAnalyzer 对 dump 的内存情况进行分析并进一步确认，若确定发生泄漏，则利用 DisplayLeakService 发送通知。</li>    </ol>    <h2>探讨一些关于 LeakCanary 有趣的问题</h2>    <p>在学习了 LeakCanary 的源码之后，我想再提几个有趣的问题做些探讨。</p>    <h3>LeakCanary 项目目录结构为什么这样分？</h3>    <p>下面是整个 LeakCanary 的项目结构：</p>    <p><img src="https://simg.open-open.com/show/eabc028d156252a98fbb7fd2425c3f7e.png"></p>    <p>对于开发者而言，只需要使用到 LeakCanary.install(this); 这一句即可。那整个项目为什么要分成这么多个 module 呢？</p>    <p>实际上，这里面每一个 module 都有自己的角色。</p>    <ul>     <li> <p>leakcanary-watcher : 这是一个通用的内存检测器，对外提供一个 RefWatcher#watch(Object watchedReference)，可以看出，它不仅能够检测 Activity ，还能监测任意常规的 Java Object 的泄漏情况。</p> </li>     <li> <p>leakcanary-android : 这个 module 是与 Android 世界的接入点，用来专门监测 Activity 的泄漏情况，内部使用了 application#registerActivityLifecycleCallbacks 方法来监听 onDestory 事件，然后利用 leakcanary-watcher 来进行弱引用＋手动 GC 机制进行监控。</p> </li>     <li> <p>leakcanary-analyzer : 这个 module 提供了 HeapAnalyzer ，用来对 dump 出来的内存进行分析并返回内存分析结果 AnalysisResult ，内部包含了泄漏发生的路径等信息供开发者寻找定位。</p> </li>     <li> <p>leakcanary-android-no-op : 这个 module 是专门给 release 的版本用的，内部只提供了两个完全空白的类 LeakCanary 和 RefWatcher ，这两个类不会做任何内存泄漏相关的分析。为什么？因为 LeakCanary 本身会由于不断 gc 影响到 app 本身的运行，而且主要用于开发阶段的内存泄漏检测。因此对于 release 则可以 disable 所有泄漏分析。</p> </li>     <li> <p>leakcanary-sample : 这个很简单，就是提供了一个用法 sample。</p> </li>    </ul>    <h3>当 Activity 被 destory 后，LeakCanary 多久后会去进行检查其是否泄漏呢？</h3>    <p>在源码中可以看到，LeakCanary 并不会在 destory 后立即去检查，而是让一个 AndroidWatchExecutor 去进行检查。它会做什么呢？</p>    <pre>  <code class="language-java">@Override public void execute(final Runnable command) {    if (isOnMainThread()) {      executeDelayedAfterIdleUnsafe(command);    } else {      mainHandler.post(new Runnable() {        @Override public void run() {          executeDelayedAfterIdleUnsafe(command);        }      });    }  }    void executeDelayedAfterIdleUnsafe(final Runnable runnable) {    // This needs to be called from the main thread.    Looper.myQueue().addIdleHandler(new MessageQueue.IdleHandler() {      @Override public boolean queueIdle() {        backgroundHandler.postDelayed(runnable, delayMillis);        return false;      }    });  }  </code></pre>    <p>可以看到，它首先会向主线程的 MessageQueue 添加一个 IdleHandler 。</p>    <p>什么是 IdleHandler ？我们知道 Looper 会不断从 MessageQueue 里取出 Message 并执行。当没有新的 Message 执行时，Looper 进入 Idle 状态时，就会取出 IdleHandler 来执行。</p>    <p>换句话说， IdleHandler 就是 优先级别较低的 Message ，只有当 Looper 没有消息要处理时才得到处理。而且，内部的 queueIdle() 方法若返回 true ，表示该任务一直存活，每次 Looper 进入 Idle 时就执行；反正，如果返回 false ，则表示只会执行一次，执行完后丢弃。</p>    <p>那么，这件优先级较低的任务是什么呢？ backgroundHandler.postDelayed(runnable, delayMillis); ，runnable 就是之前 ensureGone() 。</p>    <p>也就是说，当主线程空闲了，没事做了，开始向后台线程发送一个延时消息，告诉后台线程，5s(delayMillis)后开始检查 Activity 是否被回收了。</p>    <p>所以，当 Activity 发生 destory 后，首先要等到主线程空闲，然后再延时 5s(delayMillis)，才开始执行泄漏检查。</p>    <p>知识点：</p>    <ol>     <li> <p>如何创建一个优先级低的主线程任务，它只会在主线程空闲时才执行，不会影响到app的性能？</p> <pre>  <code class="language-java">Looper.myQueue().addIdleHandler(new MessageQueue.IdleHandler() {        @Override public boolean queueIdle() {          // do task          return false; // only once        }      });  </code></pre> </li>     <li> <p>如何快速创建一个主／子线程handler？</p> <pre>  <code class="language-java">//主线程handler  mainHandler = new Handler(Looper.getMainLooper());    //子线程handler  HandlerThread handlerThread = new HandlerThread(“子线程任务”);  handlerThread.start();  Handler backgroundHandler = new Handler(handlerThread.getLooper());  </code></pre> </li>     <li> <p>如何快速判断当前是否运行在主线程？</p> <pre>  <code class="language-java">Looper.getMainLooper().getThread() == Thread.currentThread();  </code></pre> </li>    </ol>    <h3>System.gc() 可以触发立即 gc 吗？如果不行那怎么才能触发即时 gc 呢？</h3>    <p>在 LeakCanary 里，需要立即触发 gc，并在之后立即判断弱引用是否被回收。这意味着该 gc 必须能够立即同步执行。</p>    <p>常用的触发 gc 方法是 System.gc() ，那它能达到我们的要求吗？</p>    <p>我们来看下其实现方式：</p>    <pre>  <code class="language-java">/**   * Indicates to the VM that it would be a good time to run the   * garbage collector. Note that this is a hint only. There is no guarantee   * that the garbage collector will actually be run.   */  public static void gc() {      boolean shouldRunGC;      synchronized(lock) {          shouldRunGC = justRanFinalization;          if (shouldRunGC) {              justRanFinalization = false;          } else {              runGC = true;          }      }      if (shouldRunGC) {          Runtime.getRuntime().gc();      }  }  </code></pre>    <p>注释里清楚说了， System.gc() 只是建议垃圾回收器来执行回收，但是 不能保证真的去回收 。从代码也能看出，必须先判断 shouldRunGC 才能决定是否真的要 gc。</p>    <p>知识点：</p>    <p>那要怎么实现 即时 GC 呢？</p>    <p>LeakCanary 参考了一段 <a href="/misc/goto?guid=4959748808121367148" rel="nofollow,noindex">AOSP 的代码</a></p>    <pre>  <code class="language-java">// System.gc() does not garbage collect every time. Runtime.gc() is  // more likely to perfom a gc.  Runtime.getRuntime().gc();  enqueueReferences();  System.runFinalization();  public static void enqueueReferences() {      /*       * Hack. We don't have a programmatic way to wait for the reference queue       * daemon to move references to the appropriate queues.       */      try {          Thread.sleep(100);      } catch (InterruptedException e) {          throw new AssertionError();      }  }  </code></pre>    <h3>可以怎样来改造 LeakCanary 呢？</h3>    <p>忽略某些已知泄漏的类或Activity</p>    <p>LeakCanary 提供了 ExcludedRefs 类，可以向里面添加某些主动忽略的类。比如已知 Android 源代码里有某些内存泄漏，不属于我们 App 的泄漏，那么就可以 exclude 掉。</p>    <p>另外，如果不想监控某些特殊的 Activity，那么可以在 onActivityDestroyed(Activity activity) 里，过滤掉特殊的 Activity，只对其它 Activity 调用 refWatcher.watch(activity) 监控。</p>    <p>把内存泄漏数据上传至服务器</p>    <p>在 LeakCanary 提供了 AbstractAnalysisResultService ，它是一个 intentService，接收到的 intent 内包含了 HeapDump 数据和 AnalysisResult 结果，我们只要继承这个类，实现自己的 listenerServiceClass ，就可以将堆数据和分析结果上传到我们自己的服务器上。</p>    <h2>小结</h2>    <p>本文通过源代码分析了 LeakCanary 的原理，并提出了一些有趣的问题，学习了一些实用的知识点。希望对读者有所启发，欢迎与我讨论。</p>    <p>之后会继续挑选优质开源项目进行分析，欢迎提意见。</p>    <p>  </p>   <p>来自：http://wingjay.com/2017/05/14/dig_into_leakcanary/</p>    <p></p>    <p> </p>