你被概率性的 OOM 困擾么？有時候，OOM 像幽靈一樣，揮之不去，可真想把它揪出來時，又捉之不著。或許，是時候用 LeakCanary 來診斷一下了。它是一個用來檢查 Android 下內存泄漏的開源庫，這篇文章主要介紹其用法、架構和其背后的實現原理。
Square 有篇文章介紹了開發這個庫的原因。他們的一個付款流程里，需要用到用戶的簽名，他們直接用 Bitmap 來畫簽名，Bitmap 大小和屏幕分辨率是一樣的。問題來了，在試圖創建這個 Bitmap 對象時，概率性 OOM 如幽靈般相隨。他們試了幾個方法：
使用 Bitmap.Config.ALPHA_8
來節省內存
捕獲 OutOfMemoryError
異常，調用 gc 清理內存，然后重試幾次

最終這些都不起作用。最終他們發現他們在錯誤的方向上走得太遠了。當存在內存泄漏時，可用內存越來越少，這個時候 OOM 可以發生在任何地方，特別是試圖創建一些大內存對象，如 Bitmap 的時候。
我們在上一篇文章《Android 內存與性能》里介紹了使用 MAT 來分析內存泄漏的方法。概括起來核心步驟是：
發生 OOM 或做一些可能存在內存泄漏的操作后，導出 HPROF 文件
利用 MAT 結合代碼分析，來發現一些引用異常，比如哪些對象本來應該被回收的，卻還在系統堆中，那么它就是內存泄漏

如果有一個工具能自動完成這些事情，甚至在發生 OOM 之前，就把內存泄漏報告給你，那是多么美好的一件事情啊。LeakCanary 就是用來干這個事情的。在測試你的 App 時，如果發生了內存泄漏，狀態欄上會有通知告訴你。logcat 上也會有相應的 log 通知你。
啟發
LeakCanary 產生的背后有幾個有意思的啟發。一是像 Square 這樣公司一樣會被 OOM 這種問題困擾；二是他們也會犯錯，試了幾種方法都不起作用；三是他們最終用一個優雅的方式解決了這個問題，并且通過開源庫的方式讓所有人共享他們的工作成果。

用法
監控 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 就會打印出如下信息告訴你內存泄漏發生了。

 * 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 class extends android.os.AsyncTask)
    * leaks com.example.leakcanary.MainActivity instance
    * Reference Key: c4d32914-618d-4caf-993b-4b835c255873
    * Device: Genymotion generic Google Galaxy Nexus - 4.2.2 - API 17 - 720x1280 vbox86p
    * Android Version: 4.2.2 API: 17
    * Durations: watch=5100ms, gc=104ms, heap dump=82ms, analysis=3008ms

Notes
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 里看到內存泄漏的提示。
集成 LeakCanary 庫

dependencies {
    debugCompile 'com.squareup.leakcanary:leakcanary-android:1.3'
    releaseCompile 'com.squareup.leakcanary:leakcanary-android-no-op:1.3'
}

在 debug 版本上，集成 LeakCanary 庫，并執行內存泄漏監測，而在 release 版本上，集成一個無操作的 wrapper ，這樣對程序性能就不會有影響。
原理
LeakCanary 流程圖

leakcanary

LeakCanary 的機制如下：

RefWatcher.watch()會以監控對象來創建一個 KeyedWeakReference弱引用對象
在 AndroidWatchExecutor的后臺線程里，來檢查弱引用已經被清除了，如果沒被清除，則執行一次 GC
如果弱引用對象仍然沒有被清除，說明內存泄漏了，系統就導出 hprof 文件，保存在 app 的文件系統目錄下
HeapAnalyzerService
 啟動一個單獨的進程，使用 HeapAnalyzer
 來分析 hprof 文件。它使用另外一個開源庫 [HAHA](https://github.com/square/haha)。
HeapAnalyzer
 通過查找 KeyedWeakReference
 弱引用對象來查找內在泄漏
HeapAnalyzer
 計算 KeyedWeakReference
 所引用對象的最短強引用路徑，來分析內存泄漏，并且構建出對象引用鏈出來。
內存泄漏信息送回給 DisplayLeakService
，它是運行在 app 進程里的一個服務。然后在設備通知欄顯示內存泄漏信息。

幾個有意思的代碼
如何導出 hprof 文件

File heapDumpFile = new File("heapdump.hprof");
Debug.dumpHprofData(heapDumpFile.getAbsolutePath());

可以參閱 AndroidHeapDumper.java 的代碼。
如何分析 hprof 文件
這是個比較大的話題，感興趣的可以移步另外一個開源庫 HAHA，它的祖先是 MAT。
如何使用 HandlerThread
可以參閱 AndroidWatchExecutor.java的代碼，特別是關于 Handler, Loop 的使用。
怎么知道某個變量已經被 GC 回收
可以參閱 RefWatcher.java 的 ensureGone()
函數。最主要是利用 WeakReference
和 ReferenceQueue
機制。簡單地講，就是當弱引用 WeakReference
所引用的對象被回收后，這個 WeakReference
對象就會被添加到 ReferenceQueue
隊列里，我們可以通過其 poll()
方法獲取到這個被回收的對象的 WeakReference
實例，進而知道需要監控的對象是否被回收了。
關于內存泄漏
內存泄漏可能很容易發現，比如 Cursor 沒關閉；比如在 Activity.onResume()
里 register 了某個需要監聽的事件，但在 Activity.onPause()
里忘記 unregister 了；內存泄漏也可能很難發現，比如 LeakCanary 示例代碼，隱含地引用，并且只有在旋轉屏幕時才會發生。還有更難發現，甚至無能為力的內存泄漏，比如 Android SDK 本身的 BUG 導致內存泄漏。AndroidExcludedRefs.java 里就記錄了一些己知的 AOSP 版本的以及其 OEM 實現版本里存在的內存泄漏。