以LeakCanary2.6源碼分析LeakCanary檢測內存泄露原理，為減少篇幅長度，突出關鍵點，不粘貼大量源碼，閱讀時需搭配源碼食用。

如何獲取context

LeakCanary只需引入依賴，不需要初始化代碼，就能執行內存泄漏檢測了，它是通過ContentProvider獲取應用的context。這種獲取context方式在開源第三方庫中十分流行。如下AppWatcherInstaller在LeakCanary的aar包中manifest文件中注冊。

internal sealed class AppWatcherInstaller : ContentProvider() { override fun onCreate(): Boolean { val application = context!!.applicationContext as Application AppWatcher.manualInstall(application)//1 return true } ...}默認檢測哪些類對象的內存泄露

（1）處的方法將調用如下方法注冊需要檢測泄露的對象：

fun appDefaultWatchers( application: Application, reachabilityWatcher: ReachabilityWatcher = objectWatcher ): List<InstallableWatcher> { return listOf( ActivityWatcher(application, reachabilityWatcher), FragmentAndViewModelWatcher(application, reachabilityWatcher), RootViewWatcher(reachabilityWatcher), ServiceWatcher(reachabilityWatcher) ) }

可以看到LeakCanary會把Activity，Fragment，ViewModel，RootView和Service納入檢測，這些對象都是有明確的生命周期，而且占用內存較高，它們的內存泄露是需要我們重點關注的。

如何將這些生命周期對象納入監測

（1）處的manualInstall方法將遍歷調用上述Watcher的install方法以適時將這些生命周期對象納入檢測。

ActivityWatcher

ActivityWatcher中install方法通過向application注冊Application.ActivityLifecycleCallbacks接口回調實現對Activity生命周期的檢測。這里有一個很棒的技巧，利用Kotlin委托與Java動態代理，將不需要關注的方法給出默認空實現，（2）（3）處代碼提取出來，可以在平時開發中有需求的地方使用。

//ActivityWatcher private val lifecycleCallbacks = object : Application.ActivityLifecycleCallbacks by noOpDelegate() { override fun onActivityDestroyed(activity: Activity) { reachabilityWatcher.expectWeaklyReachable( activity, '${activity::class.java.name} received Activity#onDestroy() callback' )//4 } }internal inline fun <reified T : Any> noOpDelegate(): T { val javaClass = T::class.java return Proxy.newProxyInstance( javaClass.classLoader, arrayOf(javaClass), NO_OP_HANDLER ) as T}//2private val NO_OP_HANDLER = InvocationHandler { _, _, _ -> // no op}//3

（4）調用的objectWatcher.expectWeaklyReachable方法是將對象納入監測的通用方法，如其名稱所示，WeaklyReachable相較的是StronglyReachable，當一個對象不再需要時，我們希望它從WeaklyReachable變為StronglyReachable。

我們可以在不再需要某對象時主動調用該方法，檢測任意對象（除上節的默認對象）的內存泄露：

AppWatcher.objectWatcher.expectWeaklyReachable(obj, '')

onActivityDestroyed回調中就通過該方式將activity納入監測。

通過上述對Activity的納入內存泄露源碼的分析，可以發現其中2個關鍵點，首先需要能獲取應用中所有待檢測對象的引用，其次需要一個待檢測對象生命周期結束的時機。而這兩點通過注冊Application.ActivityLifecycleCallbacks接口能夠同時滿足，可對于其他類對象，就沒有如此便捷的方式了。

下面介紹Fragment，ViewModel，RootView和Service這些類對象是如何納入檢測的。

FragmentAndViewModelWatcher

Fragment為了兼容在Android源碼中幾個不同包名的實現，對它們的檢測也需要分別實現，我們在FragmentAndViewModelWatcher中只關注AndroidXFragmentDestroyWatcher對AndroidX中Fragment的內存泄露檢測即可，其他幾個實現類似。

FragmentAndViewModelWatcher先同樣通過注冊Application.ActivityLifecycleCallbacks回調，適時獲取Activity引用，并在AndroidXFragmentDestroyWatcher獲取Activity的supportFragmentManager，向其注冊FragmentManager.FragmentLifecycleCallbacks。在其中的onFragmentDestroyed與onFragmentViewDestroyed回調中將Fragment和Fragment的View納入內存泄露檢測。

對于ViewModel的檢測，則需要關注ViewModelClearedWatcher，通過用上一步獲取的Activity引用，添加名為ViewModelClearedWatcher的spy ViewModel，來獲得收到onCleared回調的能力，因為對于一個ViewModelStoreOwner（Activity，Fragment）來說，自己的一個ViewModel回調了onCleared，則其他ViewModel的onCleared也應該被調用。這些ViewModel是通過ViewModelStore的mMap屬性反射獲取的。在spy ViewModel的onCleared回調中，納入內存泄露檢測。

RootViewWatcher

對于Android里Window中的RootView，即DecorView，可以通過注冊addOnAttachStateChangeListener在View的onViewDetachedFromWindow時進行檢測。而獲取待檢測對象的引用就不像Activity和Fragment一樣有回調可以依賴了。LeakCanary采取了Hook的方式在install方法對RootView的容器進行替換，具體來說就是通過反射機制將WindowManagerGlobal中的mViews（包含所有Window中的DecorView）的ArrayList容器的實現修改，在其add方法中獲取DecorView的引用，之后設置OnAttachStateChangeListener回調進行檢測。

ServiceWatcher

而Android中Service，無論是獲取引用還是監測時機的確定都沒有系統的回調可以依賴，LeakCanary都是采用Hook的方式達到目的。首先通過反射拿到ActivityThread中的mServices，這是包含app中全部Service的一個Map。在install方法中有兩個Hook點，首先是Android 消息機制的中轉中心，名為H的Handler，系統側對應用側的全部回調都需要經過它的周轉。因為Handler中mCallback執行的優先級大于handleMessage方法，Leakcanary替換H的mCallback實現，當消息為STOP_SERVICE時，便從mServices取出該消息對應的Service作為待檢測Service引用。第二個Hook點為ActivityManagerService，通過動態代理修改它的serviceDoneExecuting方法，在其真正實現前增加內存泄露檢測，其余方法保持不變。

這些類納入檢測納入檢測的時機，可總結為如下表格：

如何獲取引用 何時納入監測 Activity ActivityLifecycleCallbacks回調 onActivityDestroyed Fragment FragmentLifecycleCallbacks回調 onFragmentDestroyed Fragment中的View FragmentLifecycleCallbacks回調 onFragmentViewDestroyed ViewModel 反射獲取ViewModelStore的mMap spy ViewModel的onCleared Window中的DecorView Hook WindowManagerGlobal中的mViews onViewDetachedFromWindow Service Hook H的mCallback實現，當消息為STOP_SERVICE時，從ActivityThread中的mServices獲取 Hook ActivityManagerService，serviceDoneExecuting中檢測

如何確定內存泄露的對象

在確定待檢測對象與時機后，查看ObjectWatcher的expectWeaklyReachable方法，可以得知如何實現將泄露對象從待檢測對象（默認即上節我們分析的那些有生命周期的類對象）挑出來的。確定內存泄露對象的原理是我們常用的WeakReference，其雙參數構造函數支持傳入一個ReferenceQueue，當其關聯的對象回收時，會將WeakReference加入ReferenceQueue中。LeakCanary的做法是繼承ReferenceQueue，增加一個值為UUID的屬性key，同時將每個需要監測的對象WeakReference以此UUID作為鍵加入一個map中。這樣，在GC過后，removeWeaklyReachableObjects方法通過遍歷ReferenceQueue，通過key值刪除map中已回收的對象，剩下的對象就基本可以確定發生了內存泄露。

如何確定從GC root到泄露對象的引用鏈

在確定內存泄露的對象后，就需要其他手段來確定泄露對象引用鏈了，這一過程開始于checkRetainedObjects方法，跟蹤調用可以看到啟動了前臺服務HeapAnalyzerService，這在我們使用LeakCanary時可以在通知欄看到。服務中調用了HeapAnalyzer的analyze方法進行堆內存分析，由Shark庫實現該功能，就不再進行追蹤。

以上就是分析LeakCanary檢測內存泄露原理的詳細內容，更多關于LeakCanary檢測內存泄露的資料請關注好吧啦網其它相關文章！