前言
你被概率性的 OOM 困擾么？有時候，OOM 像幽靈一樣，揮之不去，可真想把它揪出來時，又捉之不著。或許，是時候用 LeakCanary 來診斷一下了。它是一個用來檢查 Android 下內(nèi)存泄漏的開源庫，這篇文章主要介紹其用法、架構(gòu)和其背后的實現(xiàn)原理。
Square 有篇文章介紹了開發(fā)這個庫的原因。他們的一個付款流程里，需要用到用戶的簽名，他們直接用 Bitmap 來畫簽名，Bitmap 大小和屏幕分辨率是一樣的。問題來了，在試圖創(chuàng)建這個 Bitmap 對象時，概率性 OOM 如幽靈般相隨。他們試了幾個方法：
- 使用
Bitmap.Config.ALPHA_8來節(jié)省內(nèi)存 - 捕獲
OutOfMemoryError異常，調(diào)用 gc 清理內(nèi)存，然后重試幾次
最終這些都不起作用。最終他們發(fā)現(xiàn)他們在錯誤的方向上走得太遠了。當存在內(nèi)存泄漏時，可用內(nèi)存越來越少，這個時候 OOM 可以發(fā)生在任何地方，特別是試圖創(chuàng)建一些大內(nèi)存對象，如 Bitmap 的時候。
我們在上一篇文章《Android 內(nèi)存與性能》里介紹了使用 MAT 來分析內(nèi)存泄漏的方法。概括起來核心步驟是：
- 發(fā)生 OOM 或做一些可能存在內(nèi)存泄漏的操作后，導出 HPROF 文件
- 利用 MAT 結(jié)合代碼分析，來發(fā)現(xiàn)一些引用異常，比如哪些對象本來應該被回收的，卻還在系統(tǒng)堆中，那么它就是內(nèi)存泄漏
如果有一個工具能自動完成這些事情，甚至在發(fā)生 OOM 之前，就把內(nèi)存泄漏報告給你，那是多么美好的一件事情啊。LeakCanary 就是用來干這個事情的。在測試你的 App 時，如果發(fā)生了內(nèi)存泄漏，狀態(tài)欄上會有通知告訴你。logcat 上也會有相應的 log 通知你。
!!! notes "啟發(fā)"
LeakCanary 產(chǎn)生的背后有幾個有意思的啟發(fā)。一是像 Square 這樣公司一樣會被 OOM 這種問題困擾；二是他們也會犯錯，試了幾種方法都不起作用；三是他們最終用一個優(yōu)雅的方式解決了這個問題，并且通過開源庫的方式讓所有人共享他們的工作成果。
用法
監(jiān)控 Activity 泄露
我們經(jīng)常把 Activity 當作為 Context 對象使用，在不同場合由各種對象引用 Activity。所以，Activity 泄漏是一個重要的需要檢查的內(nèi)存泄漏之一。
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 來監(jiān)控 Activity 泄漏。即當 Activity.onDestroy() 被調(diào)用之后，如果這個 Activity 沒有被銷毀，logcat 就會打印出如下信息告訴你內(nèi)存泄漏發(fā)生了。
* 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 之前監(jiān)測 Activity 泄漏，可以重載 Activity.onDestroy() 方法，然后在這個方法里調(diào)用 RefWatcher.watch(this) 來實現(xiàn)。
監(jiān)控 Fragment 泄漏
public abstract class BaseFragment extends Fragment {
@Override
public void onDestroy() {
super.onDestroy();
RefWatcher refWatcher = ExampleApplication.getRefWatcher(getActivity());
refWatcher.watch(this);
}
}
當 Fragment.onDestroy() 被調(diào)用之后，如果這個 fragment 實例沒有被銷毀，那么就會從 logcat 里看到相應的泄漏信息。
監(jiān)控其他泄漏
...
RefWatcher refWatcher = ExampleApplication.getRefWatcher(getActivity());
refWatcher.watch(someObjNeedGced);
當 someObjNeedGced 還在內(nèi)存中時，就會在 logcat 里看到內(nèi)存泄漏的提示。
集成 LeakCanary 庫
dependencies {
debugCompile 'com.squareup.leakcanary:leakcanary-android:1.3'
releaseCompile 'com.squareup.leakcanary:leakcanary-android-no-op:1.3'
}
在 debug 版本上，集成 LeakCanary 庫，并執(zhí)行內(nèi)存泄漏監(jiān)測，而在 release 版本上，集成一個無操作的 wrapper ，這樣對程序性能就不會有影響。
原理
LeakCanary 流程圖
LeakCanary 的機制如下：
-
RefWatcher.watch()會以監(jiān)控對象來創(chuàng)建一個KeyedWeakReference弱引用對象 - 在
AndroidWatchExecutor的后臺線程里，來檢查弱引用已經(jīng)被清除了，如果沒被清除，則執(zhí)行一次 GC - 如果弱引用對象仍然沒有被清除，說明內(nèi)存泄漏了，系統(tǒng)就導出 hprof 文件，保存在 app 的文件系統(tǒng)目錄下
-
HeapAnalyzerService啟動一個單獨的進程，使用HeapAnalyzer來分析 hprof 文件。它使用另外一個開源庫 HAHA。 -
HeapAnalyzer通過查找KeyedWeakReference弱引用對象來查找內(nèi)在泄漏 -
HeapAnalyzer計算KeyedWeakReference所引用對象的最短強引用路徑，來分析內(nèi)存泄漏，并且構(gòu)建出對象引用鏈出來。 - 內(nèi)存泄漏信息送回給
DisplayLeakService，它是運行在 app 進程里的一個服務(wù)。然后在設(shè)備通知欄顯示內(nèi)存泄漏信息。
幾個有意思的代碼
如何導出 hprof 文件
File heapDumpFile = new File("heapdump.hprof");
Debug.dumpHprofData(heapDumpFile.getAbsolutePath());
可以參閱 AndroidHeapDumper.java 的代碼。
如何分析 hprof 文件
這是個比較大的話題，感興趣的可以移步另外一個開源庫 HAHA，它的祖先是 MAT。
如何使用 HandlerThread
可以參閱 AndroidWatchExecutor.java的代碼，特別是關(guān)于 Handler, Loop 的使用。
怎么知道某個變量已經(jīng)被 GC 回收
可以參閱 RefWatcher.java 的 ensureGone() 函數(shù)。最主要是利用 WeakReference 和 ReferenceQueue 機制。簡單地講，就是當弱引用 WeakReference 所引用的對象被回收后，這個 WeakReference 對象就會被添加到 ReferenceQueue 隊列里，我們可以通過其 poll() 方法獲取到這個被回收的對象的 WeakReference 實例，進而知道需要監(jiān)控的對象是否被回收了。
關(guān)于內(nèi)存泄漏
內(nèi)存泄漏可能很容易發(fā)現(xiàn)，比如 Cursor 沒關(guān)閉；比如在 Activity.onResume() 里 register 了某個需要監(jiān)聽的事件，但在 Activity.onPause() 里忘記 unregister 了；內(nèi)存泄漏也可能很難發(fā)現(xiàn)，比如 LeakCanary 示例代碼，隱含地引用，并且只有在旋轉(zhuǎn)屏幕時才會發(fā)生。還有更難發(fā)現(xiàn)，甚至無能為力的內(nèi)存泄漏，比如 Android SDK 本身的 BUG 導致內(nèi)存泄漏。AndroidExcludedRefs.java 里就記錄了一些己知的 AOSP 版本的以及其 OEM 實現(xiàn)版本里存在的內(nèi)存泄漏。
本期推薦
推薦一個畫圖工具 planUML，其最大的特色是使用腳本來畫圖。它和 starUML 的最大區(qū)別是，前者是畫圖工具，類似于微軟的 visio，而且支持腳本畫圖，后者是建模工具。這里是 planUML 的官方文檔。它還支持一堆擴展，比如 Sublime Text等。本文的流程圖就是用 planUML 畫的。
