前言
你被概率性的 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 畫的饺鹃。
