示例程序如下：

示例程序

// 自定義 LeakCanary 配置
LeakCanary.config = LeakCanary.config.copy(
    // 自定義對(duì)象檢索器
    objectInspectors = LeakCanary.config.objectInspectors + ObjectInspector { reporter ->
        // reporter.notLeakingReasons += "非泄漏原因"
        // reporter.leakingReasons += "泄漏原因"
    } + AppSingletonInspector(
        // 標(biāo)記全局類(lèi)的類(lèi)名即可
    )
)

另外，引用鏈 LEAKING 節(jié)點(diǎn)以后到第一個(gè) NOT_LEAKING 節(jié)點(diǎn)中間的節(jié)點(diǎn)，才會(huì)用 ~~~ 下劃線(xiàn)標(biāo)記為懷疑對(duì)象。例如：

6. LeakCanary 實(shí)現(xiàn)原理分析

使用一張示意圖表示 LeakCanary 的基本架構(gòu)：

6.1 LeakCanary 如何實(shí)現(xiàn)自動(dòng)初始化？

舊版本的 LeakCanary 需要在 Application 中調(diào)用相關(guān)初始化 API，而在 LeakCanary v2 版本中卻不再需要手動(dòng)初始化，為什么呢？—— 這是因?yàn)?LeakCanary 利用了 ContentProvider 的初始化機(jī)制來(lái)間接調(diào)用初始化 API。

ContentProvider 的常規(guī)用法是提供內(nèi)容服務(wù)，而另一個(gè)特殊的用法是提供無(wú)侵入的初始化機(jī)制，這在第三方庫(kù)中很常見(jiàn)，Jetpack 中提供的輕量級(jí)初始化框架 App Startup 也是基于 ContentProvider 的方案。

MainProcessAppWatcherInstaller.kt

internal class MainProcessAppWatcherInstaller : ContentProvider() {
    override fun onCreate(): Boolean {
        // 初始化 LeakCanary
        val application = context!!.applicationContext as Application
        AppWatcher.manualInstall(application)
        return true
    }
    ...
}

6.2 LeakCanary 初始化過(guò)程分析

LeakCanary 的初始化工程可以概括為 2 項(xiàng)內(nèi)容：

• 1、初始化 LeakCanary 內(nèi)部分析引擎；
• 2、在 Android Framework 上注冊(cè)五種 Android 泄漏場(chǎng)景的監(jiān)控。

AppWathcer.kt

// LeakCanary 初始化 API
@JvmOverloads
fun manualInstall(
    application: Application,
    retainedDelayMillis: Long = TimeUnit.SECONDS.toMillis(5),
    watchersToInstall: List<InstallableWatcher> = appDefaultWatchers(application)
) {
    checkMainThread()
    ...
    // 初始化 InternalLeakCanary 內(nèi)部引擎 (已簡(jiǎn)化為等價(jià)代碼，后文會(huì)提到）
    InternalLeakCanary(application)
    // 注冊(cè)五種 Android 泄漏場(chǎng)景的監(jiān)控 Hook 點(diǎn)
    watchersToInstall.forEach {
        it.install()
    }
}

fun appDefaultWatchers(
    application: Application,
    reachabilityWatcher: ReachabilityWatcher = objectWatcher
): List<InstallableWatcher> {
    // 對(duì)應(yīng) 5 種 Android 泄漏場(chǎng)景（后文具體分析）
    return listOf(
        ActivityWatcher(application, reachabilityWatcher),
        FragmentAndViewModelWatcher(application, reachabilityWatcher),
        RootViewWatcher(reachabilityWatcher),
        ServiceWatcher(reachabilityWatcher)
    )
}

下面展開(kāi)具體分析：

初始化內(nèi)容 1 - 初始化 LeakCanary 內(nèi)部分析引擎： 創(chuàng)建 HeapDumpTrigger 觸發(fā)器，并在 Android Framework 上注冊(cè)前后臺(tái)切換監(jiān)聽(tīng)、前臺(tái) Activity 監(jiān)聽(tīng)和 ObjectWatcher 的泄漏監(jiān)聽(tīng)。

InternalLeakCanary.kt

override fun invoke(application: Application) {
    _application = application

    // 1. 檢查是否運(yùn)行在 debug 構(gòu)建變體，否則拋出異常
    checkRunningInDebuggableBuild()

    // 2. 注冊(cè)泄漏回調(diào)，在 ObjectWathcer 判定對(duì)象發(fā)生泄漏會(huì)后回調(diào) onObjectRetained() 方法
    AppWatcher.objectWatcher.addOnObjectRetainedListener(this)

    // 3. 垃圾回收觸發(fā)器（用于調(diào)用 Runtime.getRuntime().gc()）
    val gcTrigger = GcTrigger.Default
    // 4. 配置提供器
    val configProvider = { LeakCanary.config }
    // 5. (主角) 創(chuàng)建 HeapDump 觸發(fā)器
    heapDumpTrigger = HeapDumpTrigger(...)

    // 6. App 前后臺(tái)切換監(jiān)聽(tīng)
    application.registerVisibilityListener { applicationVisible ->
        this.applicationVisible = applicationVisible
        heapDumpTrigger.onApplicationVisibilityChanged(applicationVisible)
    }
    // 7. 前臺(tái) Activity 監(jiān)聽(tīng)（用于發(fā)送 Heap Dump 進(jìn)行中的全局 Toast）
    registerResumedActivityListener(application)

    // 8. 增加可視化分析報(bào)告的桌面快捷入口
    addDynamicShortcut(application)
}

override fun onObjectRetained() = scheduleRetainedObjectCheck()

fun scheduleRetainedObjectCheck() {
    heapDumpTrigger.scheduleRetainedObjectCheck()
}

HeapDumpTrigger.kt

// App 前后臺(tái)切換狀態(tài)變化回調(diào)
fun onApplicationVisibilityChanged(applicationVisible: Boolean) {
    if (applicationVisible) {
        // App 可見(jiàn)
        applicationInvisibleAt = -1L
    } else {
        // App 不可見(jiàn)
        applicationInvisibleAt = SystemClock.uptimeMillis()
        scheduleRetainedObjectCheck(delayMillis = AppWatcher.retainedDelayMillis)
    } 
}

fun scheduleRetainedObjectCheck(delayMillis: Long = 0L) {
    // 已簡(jiǎn)化：源碼此處使用時(shí)間戳攔截，避免重復(fù) postDelayed
    backgroundHandler.postDelayed({
        checkScheduledAt = 0
        checkRetainedObjects()
    }, delayMillis)
}

初始化內(nèi)容 2 - 在 Android Framework 中注入對(duì)五種 Android 泄漏場(chǎng)景的監(jiān)控： 實(shí)現(xiàn)在對(duì)象的使用生命周期結(jié)束后，自動(dòng)將對(duì)象交給 ObjectWatcher 進(jìn)行監(jiān)控。

以下為 5 種 Android 泄漏場(chǎng)景的監(jiān)控原理分析：

• 1、Activity 監(jiān)控： 通過(guò) Application#registerActivityLifecycleCallbacks(…) 接口監(jiān)聽(tīng) Activity#onDestroy 事件，將當(dāng)前 Activity 對(duì)象交給 ObjectWatcher 監(jiān)控；

ActivityWatcher.kt

private val lifecycleCallbacks = object : Application.ActivityLifecycleCallbacks by noOpDelegate() {
    override fun onActivityDestroyed(activity: Activity) {
        // reachabilityWatcher 即 ObjectWatcher
        reachabilityWatcher.expectWeaklyReachable(activity /*被監(jiān)控對(duì)象*/, "${activity::class.java.name} received Activity#onDestroy() callback")
    }
}

• 2、Fragment 與 Fragment View 監(jiān)控： 通過(guò) FragmentAndViewModelWatcher 實(shí)現(xiàn)，首先是通過(guò) Application#registerActivityLifecycleCallbacks(…) 接口監(jiān)聽(tīng) Activity#onCreate 事件，再通過(guò) FragmentManager#registerFragmentLifecycleCallbacks(…) 接口監(jiān)聽(tīng) Fragment 的生命周期：

FragmentAndViewModelWatcher.kt

// fragmentDestroyWatchers 是一個(gè) Lambda 表達(dá)式數(shù)組
// 對(duì)應(yīng)原生、AndroidX 和 Support 三個(gè)版本 Fragment 的 Hook 工具
private val fragmentDestroyWatchers: List<(Activity) -> Unit> = 略...

private val lifecycleCallbacks = object : Application.ActivityLifecycleCallbacks by noOpDelegate() {
    override fun onActivityCreated(activity: Activity, savedInstanceState: Bundle?) {
        for (watcher in fragmentDestroyWatchers) {
            // 最終調(diào)用到下文的 invokde() 方法
            watcher(activity)
        }
    }
}

以 AndroidX Fragment 為例：

AndroidXFragmentDestroyWatcher.kt

override fun invoke(activity: Activity) {
    // 這里在 Activity#onCreate 狀態(tài)執(zhí)行：
    if (activity is FragmentActivity) {
        val supportFragmentManager = activity.supportFragmentManager
        // 注冊(cè) Fragment 生命周期監(jiān)聽(tīng)
        supportFragmentManager.registerFragmentLifecycleCallbacks(fragmentLifecycleCallbacks, true)
        // 注冊(cè) Activity 級(jí)別 ViewModel Hook
        ViewModelClearedWatcher.install(activity, reachabilityWatcher)
    }
}

private val fragmentLifecycleCallbacks = object : FragmentManager.FragmentLifecycleCallbacks() {

    override fun onFragmentCreated(fm: FragmentManager, fragment: Fragment, savedInstanceState: Bundle?) {
        // 注冊(cè) Fragment 級(jí)別 ViewModel Hook
        ViewModelClearedWatcher.install(fragment, reachabilityWatcher)
    }

    override fun onFragmentViewDestroyed(fm: FragmentManager, fragment: Fragment) {
        // reachabilityWatcher 即 ObjectWatcher
        reachabilityWatcher.expectWeaklyReachable(fragment.view /*被監(jiān)控對(duì)象*/, "${fragment::class.java.name} received Fragment#onDestroyView() callback " + "(references to its views should be cleared to prevent leaks)")
    }

    override fun onFragmentDestroyed(fm: FragmentManager, fragment: Fragment) {
        // reachabilityWatcher 即 ObjectWatcher
        reachabilityWatcher.expectWeaklyReachable(fragment /*被監(jiān)控對(duì)象*/, "${fragment::class.java.name} received Fragment#onDestroy() callback")
    }
}

• 3、ViewModel 監(jiān)控： 由于 Android Framework 未提供設(shè)置 ViewModel#onClear() 全局監(jiān)聽(tīng)的方法，所以 LeakCanary 是通過(guò) Hook 的方式實(shí)現(xiàn)。即：在 Activity#onCreate 和 Fragment#onCreate 事件中實(shí)例化一個(gè)自定義ViewModel，在進(jìn)入 ViewModel#onClear() 方法時(shí)，通過(guò)反射獲取當(dāng)前作用域中所有的 ViewModel 對(duì)象交給 ObjectWatcher 監(jiān)控。

ViewModelClearedWatcher.kt

// ViewModel 的子類(lèi)
internal class ViewModelClearedWatcher(
    storeOwner: ViewModelStoreOwner,
    private val reachabilityWatcher: ReachabilityWatcher
) : ViewModel() {

    // 反射獲取 ViewModelStore 中的 ViewModel 映射表，即可獲取當(dāng)前作用域所有 ViewModel 對(duì)象
    private val viewModelMap: Map<String, ViewModel>? = try {
        val mMapField = ViewModelStore::class.java.getDeclaredField("mMap")
        mMapField.isAccessible = true
        mMapField[storeOwner.viewModelStore] as Map<String, ViewModel>
    } catch (ignored: Exception) {
        null
    }

    override fun onCleared() {
        // 遍歷當(dāng)前作用域所有 ViewModel 對(duì)象
        viewModelMap?.values?.forEach { viewModel ->
            // reachabilityWatcher 即 ObjectWatcher
            reachabilityWatcher.expectWeaklyReachable(viewModel /*被監(jiān)控對(duì)象*/, "${viewModel::class.java.name} received ViewModel#onCleared() callback")
        }
    }

    companion object {
        // 直接在 storeOwner 作用域?qū)嵗?ViewModelClearedWatcher 對(duì)象
        fun install(storeOwner: ViewModelStoreOwner, reachabilityWatcher: ReachabilityWatcher) {
            val provider = ViewModelProvider(storeOwner, object : Factory {
                override fun <T : ViewModel?> create(modelClass: Class<T>): T =
                    ViewModelClearedWatcher(storeOwner, reachabilityWatcher) as T
            })
            provider.get(ViewModelClearedWatcher::class.java)
        }
    }
}

• 4、Service 監(jiān)控： 由于 Android Framework 未提供設(shè)置 Service#onDestroy() 全局監(jiān)聽(tīng)的方法，所以 LeakCanary 是通過(guò) Hook 的方式實(shí)現(xiàn)的。

Service 監(jiān)控這部分源碼比較復(fù)雜了，需要通過(guò) 2 步 Hook 來(lái)實(shí)現(xiàn)：

• 1、Hook 主線(xiàn)程消息循環(huán)的 mH.mCallback 回調(diào)，監(jiān)聽(tīng)其中的 STOP_SERVICE 消息，將即將 Destroy 的 Service 對(duì)象暫存起來(lái)（由于 ActivityThread.H 中沒(méi)有 DESTROY_SERVICE 消息，所以不能直接監(jiān)聽(tīng)到 onDestroy() 事件，需要第 2 步）；
• 2、使用動(dòng)態(tài)代理 Hook AMS 與 App 通信的的 IActivityManager Binder 對(duì)象，代理其中的 serviceDoneExecuting() 方法，視為 Service#onDestroy() 的執(zhí)行時(shí)機(jī)，拿到暫存的 Service 對(duì)象交給 ObjectWatcher 監(jiān)控。

源碼摘要如下：

ServiceWatcher.kt

private var uninstallActivityThreadHandlerCallback: (() -> Unit)? = null

// 暫存即將 Destroy 的 Service
private val servicesToBeDestroyed = WeakHashMap<IBinder, WeakReference<Service>>()

override fun install() {
    // 1. Hook mH.mCallback
    swapActivityThreadHandlerCallback { mCallback /*原對(duì)象*/ ->
        // uninstallActivityThreadHandlerCallback：用于取消 Hook
        uninstallActivityThreadHandlerCallback = {
            swapActivityThreadHandlerCallback {
                mCallback
            }
        }
        // 新對(duì)象（lambda 表達(dá)式的末行就是返回值）
        Handler.Callback { msg ->
            // 1.1 Service#onStop() 事件
            if (msg.what == STOP_SERVICE) {
                val key = msg.obj as IBinder
                // 1.2 activityThreadServices：反射獲取 ActivityThread mServices 映射表 <IBinder, CreateServiceData>
                activityThreadServices[key]?.let {
                    // 1.3 暫存即將 Destroy 的 Service
                    servicesToBeDestroyed[token] = WeakReference(service)
                }
            }
            // 1.4 繼續(xù)執(zhí)行 Framework 原有邏輯
            mCallback?.handleMessage(msg) ?: false
        }
    }
    // 2. Hook AMS IActivityManager
    swapActivityManager { activityManagerInterface, activityManagerInstance /*原對(duì)象*/ ->
        // uninstallActivityManager：用于取消 Hook
        uninstallActivityManager = {
            swapActivityManager { _, _ ->
                activityManagerInstance
            }
        }
        // 新對(duì)象（lambda 表達(dá)式的末行就是返回值）
        Proxy.newProxyInstance(activityManagerInterface.classLoader, arrayOf(activityManagerInterface)) { _, method, args ->
            // 2.1 代理 serviceDoneExecuting() 方法
            if (METHOD_SERVICE_DONE_EXECUTING == method.name) {
                // 2.2 取出暫存的即將 Destroy 的 Service
                val token = args!![0] as IBinder
                if (servicesToBeDestroyed.containsKey(token)) {
                    servicesToBeDestroyed.remove(token)?.also { serviceWeakReference ->
                        // 2.3 交給 ObjectWatcher 監(jiān)控
                        serviceWeakReference.get()?.let { service ->
                            reachabilityWatcher.expectWeaklyReachable(service /*被監(jiān)控對(duì)象*/, "${service::class.java.name} received Service#onDestroy() callback")
                        }
                    }
                }
            }
            // 2.4 繼續(xù)執(zhí)行 Framework 原有邏輯
            method.invoke(activityManagerInstance, *args)
        }
    }
}

override fun uninstall() {
    // 關(guān)閉 mH.mCallback 的 Hook
    uninstallActivityManager?.invoke()
    uninstallActivityThreadHandlerCallback?.invoke()
    uninstallActivityManager = null
    uninstallActivityThreadHandlerCallback = null
}

// 使用反射修改 ActivityThread 的主線(xiàn)程消息循環(huán)的 mH.mCallback
// swap 是一個(gè) lambda 表達(dá)式，參數(shù)為原對(duì)象，返回值為注入的新對(duì)象
private fun swapActivityThreadHandlerCallback(swap: (Handler.Callback?) -> Handler.Callback?) {
    val mHField = activityThreadClass.getDeclaredField("mH").apply { isAccessible = true }
    val mH = mHField[activityThreadInstance] as Handler

    val mCallbackField = Handler::class.java.getDeclaredField("mCallback").apply { isAccessible = true }
    val mCallback = mCallbackField[mH] as Handler.Callback?
    // 將 swap 的返回值作為新對(duì)象，實(shí)現(xiàn) Hook
    mCallbackField[mH] = swap(mCallback)
}

// 使用反射修改 AMS 與 App 通信的 IActivityManager Binder 對(duì)象
// swap 是一個(gè) lambda 表達(dá)式，參數(shù)為 IActivityManager 的 Class 對(duì)象和接口原實(shí)現(xiàn)對(duì)象，返回值為注入的新對(duì)象
private fun swapActivityManager(swap: (Class<*>, Any) -> Any) {
    val singletonClass = Class.forName("android.util.Singleton")
    val mInstanceField = singletonClass.getDeclaredField("mInstance").apply { isAccessible = true }

    val singletonGetMethod = singletonClass.getDeclaredMethod("get")

    val (className, fieldName) = if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O) {
        "android.app.ActivityManager" to "IActivityManagerSingleton"
    } else {
        "android.app.ActivityManagerNative" to "gDefault"
    }

    val activityManagerClass = Class.forName(className)
    val activityManagerSingletonField = activityManagerClass.getDeclaredField(fieldName).apply { isAccessible = true }
    val activityManagerSingletonInstance = activityManagerSingletonField[activityManagerClass]

    // Calling get() instead of reading from the field directly to ensure the singleton is
    // created.
    val activityManagerInstance = singletonGetMethod.invoke(activityManagerSingletonInstance)

    val iActivityManagerInterface = Class.forName("android.app.IActivityManager")
    // 將 swap 的返回值作為新對(duì)象，實(shí)現(xiàn) Hook
    mInstanceField[activityManagerSingletonInstance] = swap(iActivityManagerInterface, activityManagerInstance!!)
}

• 5、RootView 監(jiān)控： 由于 Android Framework 未提供設(shè)置全局監(jiān)聽(tīng) RootView 從 WindowManager 中移除的方法，所以 LeakCanary 是通過(guò) Hook 的方式實(shí)現(xiàn)的，這一塊是通過(guò) squareup 另一個(gè)開(kāi)源庫(kù) curtains 實(shí)現(xiàn)的。

RootView 監(jiān)控這部分源碼也比較復(fù)雜了，需要通過(guò) 2 步 Hook 來(lái)實(shí)現(xiàn)：

• 1、Hook WMS 服務(wù)內(nèi)部的 WindowManagerGlobal.mViews RootView 列表，獲取 RootView 新增和移除的時(shí)機(jī)；
• 2、檢查 View 對(duì)應(yīng)的 Window 類(lèi)型，如果是 Dialog 或 DreamService 等類(lèi)型，則在注冊(cè) View#addOnAttachStateChangeListener() 監(jiān)聽(tīng)，在其中的 onViewDetachedFromWindow() 回調(diào)中將 View 對(duì)象交給 ObjectWatcher 監(jiān)控。

LeakCanary 源碼摘要如下：

RootViewWatcher.kt

override fun install() {
    // 1. 注冊(cè) RootView 監(jiān)聽(tīng)
    Curtains.onRootViewsChangedListeners += listener
}

private val listener = OnRootViewAddedListener { rootView ->
    val trackDetached = when(rootView.windowType) {
    PHONE_WINDOW -> {
        when (rootView.phoneWindow?.callback?.wrappedCallback) {
            // Activity 類(lèi)型已經(jīng)在 ActivityWatcher 中監(jiān)控了，不需要重復(fù)監(jiān)控
            is Activity -> false
            is Dialog -> {
                // leak_canary_watcher_watch_dismissed_dialogs：Dialog 監(jiān)控開(kāi)關(guān)
                val resources = rootView.context.applicationContext.resources
                resources.getBoolean(R.bool.leak_canary_watcher_watch_dismissed_dialogs)
            }
            // DreamService 屏保等
            else -> true
        }
    }
    POPUP_WINDOW -> false
    TOOLTIP, TOAST, UNKNOWN -> true
    }
    if (trackDetached) {
        // 2. 注冊(cè) View#addOnAttachStateChangeListener 監(jiān)聽(tīng)
        rootView.addOnAttachStateChangeListener(object : OnAttachStateChangeListener {
            val watchDetachedView = Runnable {
                // 3. 交給 ObjectWatcher 監(jiān)控
                reachabilityWatcher.expectWeaklyReachable(rootView /*被監(jiān)控對(duì)象*/ , "${rootView::class.java.name} received View#onDetachedFromWindow() callback")
            }

            override fun onViewAttachedToWindow(v: View) {
                mainHandler.removeCallbacks(watchDetachedView)
            }

            override fun onViewDetachedFromWindow(v: View) {
                mainHandler.post(watchDetachedView)
            }
        })
    }
}

curtains 源碼摘要如下：

RootViewsSpy.kt

private val delegatingViewList = object : ArrayList<View>() {
    // 重寫(xiě) ArrayList#add 方法
    override fun add(element: View): Boolean {
        // 回調(diào)
        listeners.forEach { it.onRootViewsChanged(element, true) }
        return super.add(element)
    }

    // 重寫(xiě) ArrayList#removeAt 方法
    override fun removeAt(index: Int): View {
        // 回調(diào)
        val removedView = super.removeAt(index)
        listeners.forEach { it.onRootViewsChanged(removedView, false) }
        return removedView
    }
}

companion object {
    fun install(): RootViewsSpy {
        return RootViewsSpy().apply {
            WindowManagerSpy.swapWindowManagerGlobalMViews { mViews /*原對(duì)象*/ ->
                // 新對(duì)象（lambda 表達(dá)式的末行就是返回值）
                delegatingViewList.apply { addAll(mViews) }
            }
        }
    }
}

WindowManageSpy.kt

// Hook WMS 服務(wù)內(nèi)部的 WindowManagerGlobal.mViews RootView 列表
// swap 是一個(gè) lambda 表達(dá)式，參數(shù)為原對(duì)象，返回值為注入的新對(duì)象
fun swapWindowManagerGlobalMViews(swap: (ArrayList<View>) -> ArrayList<View>) {
    windowManagerInstance?.let { windowManagerInstance ->
        mViewsField?.let { mViewsField ->
            val mViews = mViewsField[windowManagerInstance] as ArrayList<View>
            mViewsField[windowManagerInstance] = swap(mViews)
        }
    }
}

至此，LeakCanary 初始化完成，并且成功在 Android Framework 的各個(gè)位置安插監(jiān)控，實(shí)現(xiàn)對(duì) Activity 和 Service 等對(duì)象進(jìn)入無(wú)用狀態(tài)的監(jiān)聽(tīng)。我們可以用一張示意圖描述 LeakCanary 的部分結(jié)構(gòu)：

6.3 LeakCanary 如何判定對(duì)象泄漏？

在以上步驟中，當(dāng)對(duì)象的使用生命周期結(jié)束后，會(huì)交給 ObjectWatcher 監(jiān)控，現(xiàn)在我們來(lái)具體看下它是怎么判斷對(duì)象發(fā)生泄漏的。主要邏輯概括為 3 步：

• 第 1 步： 為被監(jiān)控對(duì)象 watchedObject 創(chuàng)建一個(gè) KeyedWeakReference 弱引用，并存儲(chǔ)到 <UUID, KeyedWeakReference> 的映射表中；
• 第 2 步： postDelay 五秒后檢查引用對(duì)象是否出現(xiàn)在引用隊(duì)列中，出現(xiàn)在隊(duì)列則說(shuō)明被監(jiān)控對(duì)象未發(fā)生泄漏。隨后，移除映射表中未泄露的記錄，更新泄漏的引用對(duì)象的 retainedUptimeMillis 字段以標(biāo)記為泄漏；
• 第 3 步： 通過(guò)回調(diào) onObjectRetained 告知 LeakCanary 內(nèi)部發(fā)生新的內(nèi)存泄漏。

源碼摘要如下：

AppWatcher.kt

val objectWatcher = ObjectWatcher(
    // lambda 表達(dá)式獲取當(dāng)前系統(tǒng)時(shí)間
    clock = { SystemClock.uptimeMillis() },
    // lambda 表達(dá)式實(shí)現(xiàn) Executor SAM 接口
    checkRetainedExecutor = {
        mainHandler.postDelayed(it, retainedDelayMillis)
    },
    // lambda 表達(dá)式獲取監(jiān)控開(kāi)關(guān)
    isEnabled = { true }
)

ObjectWatcher.kt

class ObjectWatcher constructor(
    private val clock: Clock,
    private val checkRetainedExecutor: Executor,
    private val isEnabled: () -> Boolean = { true }
) : ReachabilityWatcher {

    if (!isEnabled()) {
        // 監(jiān)控開(kāi)關(guān)
        return
    }

    // 被監(jiān)控的對(duì)象映射表 <UUID,KeyedWeakReference>
    private val watchedObjects = mutableMapOf<String, KeyedWeakReference>()

    // KeyedWeakReference 關(guān)聯(lián)的引用隊(duì)列，用于判斷對(duì)象是否泄漏
    private val queue = ReferenceQueue<Any>()

    // 1. 為 watchedObject 對(duì)象增加監(jiān)控
    @Synchronized 
    override fun expectWeaklyReachable(
        watchedObject: Any,
        description: String
    ) {
        // 1.1 移除 watchedObjects 中未泄漏的引用對(duì)象
        removeWeaklyReachableObjects()
        // 1.2 新建一個(gè) KeyedWeakReference 引用對(duì)象
        val key = UUID.randomUUID().toString()
        val watchUptimeMillis = clock.uptimeMillis()
        watchedObjects[key] = KeyedWeakReference(watchedObject, key, description, watchUptimeMillis, queue)
        // 2. 五秒后檢查引用對(duì)象是否出現(xiàn)在引用隊(duì)列中，否則判定發(fā)生泄漏
        // checkRetainedExecutor 相當(dāng)于 postDelay 五秒后執(zhí)行 moveToRetained() 方法
        checkRetainedExecutor.execute {
            moveToRetained(key)
        }
    }

    // 2. 五秒后檢查引用對(duì)象是否出現(xiàn)在引用隊(duì)列中，否則說(shuō)明發(fā)生泄漏
    @Synchronized 
    private fun moveToRetained(key: String) {
        // 2.1 移除 watchedObjects 中未泄漏的引用對(duì)象
        removeWeaklyReachableObjects()
        // 2.2 依然存在的引用對(duì)象被判定發(fā)生泄漏
        val retainedRef = watchedObjects[key]
        if (retainedRef != null) {
            retainedRef.retainedUptimeMillis = clock.uptimeMillis()
            // 3. 回調(diào)通知 LeakCanary 內(nèi)部處理
            onObjectRetainedListeners.forEach { it.onObjectRetained() }
        }
    }

    // 移除未泄漏對(duì)象對(duì)應(yīng)的 KeyedWeakReference
    private fun removeWeaklyReachableObjects() {
        var ref: KeyedWeakReference?
        do {
            ref = queue.poll() as KeyedWeakReference?
            if (ref != null) {
                // KeyedWeakReference 出現(xiàn)在引用隊(duì)列中，說(shuō)明未發(fā)生泄漏
                watchedObjects.remove(ref.key)
            }
        } while (ref != null)
    }

    // 4. Heap Dump 后移除所有監(jiān)控時(shí)間早于 heapDumpUptimeMillis 的引用對(duì)象
    @Synchronized 
    fun clearObjectsWatchedBefore(heapDumpUptimeMillis: Long) {
        val weakRefsToRemove = watchedObjects.filter { it.value.watchUptimeMillis <= heapDumpUptimeMillis }
        weakRefsToRemove.values.forEach { it.clear() }
        watchedObjects.keys.removeAll(weakRefsToRemove.keys)
    }

    // 獲取是否有內(nèi)存泄漏對(duì)象
    val hasRetainedObjects: Boolean
    @Synchronized get() {
        // 移除 watchedObjects 中未泄漏的引用對(duì)象
        removeWeaklyReachableObjects()
        return watchedObjects.any { it.value.retainedUptimeMillis != -1L }
    }

    // 獲取內(nèi)存泄漏對(duì)象計(jì)數(shù)
    val retainedObjectCount: Int
    @Synchronized get() {
        // 移除 watchedObjects 中未泄漏的引用對(duì)象
        removeWeaklyReachableObjects()
        return watchedObjects.count { it.value.retainedUptimeMillis != -1L }
    }
}

被監(jiān)控對(duì)象 watchedObject 關(guān)聯(lián)的弱引用對(duì)象：

KeyedWeakReference.kt

class KeyedWeakReference(
    // 被監(jiān)控對(duì)象
    referent: Any,
    // 唯一 Key，根據(jù)此字段匹配映射表中的記錄
    val key: String,
    // 描述信息
    val description: String,
    // 監(jiān)控開(kāi)始時(shí)間，即引用對(duì)象創(chuàng)建時(shí)間
    val watchUptimeMillis: Long,
    // 關(guān)聯(lián)的引用隊(duì)列
    referenceQueue: ReferenceQueue<Any>
) : WeakReference<Any>(referent, referenceQueue) {
  
    // 記錄實(shí)際對(duì)象 referent 被判定為泄漏對(duì)象的時(shí)間
    // -1L 表示非泄漏對(duì)象，或者還未判定完成
    @Volatile
    var retainedUptimeMillis = -1L

    override fun clear() {
        super.clear()
        retainedUptimeMillis = -1L
    }

    companion object {
        // 記錄最近一次觸發(fā) Heap Dump 的時(shí)間
        @Volatile
        @JvmStatic var heapDumpUptimeMillis = 0L
    }
}

6.4 LeakCanary 發(fā)現(xiàn)泄漏對(duì)象后就會(huì)觸發(fā)分析嗎？

ObjectWatcher 判定被監(jiān)控對(duì)象發(fā)生泄漏后，會(huì)通過(guò)接口方法 OnObjectRetainedListener#onObjectRetained() 回調(diào)到 LeakCanary 內(nèi)部的管理器 InternalLeakCanary 處理（在前文 AppWatcher 初始化中提到過(guò)）。LeakCanary 不會(huì)每次發(fā)現(xiàn)內(nèi)存泄漏對(duì)象都進(jìn)行分析工作，而會(huì)進(jìn)行兩個(gè)攔截：

• 攔截 1：泄漏對(duì)象計(jì)數(shù)未達(dá)到閾值，或者進(jìn)入后臺(tái)時(shí)間未達(dá)到閾值；
• 攔截 2：計(jì)算距離上一次 HeapDump 未超過(guò) 60s。

源碼摘要如下：

InternalLeakCanary.kt

// 從 ObjectWatcher 回調(diào)過(guò)來(lái)
override fun onObjectRetained() = scheduleRetainedObjectCheck()

private lateinit var heapDumpTrigger: HeapDumpTrigger

fun scheduleRetainedObjectCheck() {
    if (this::heapDumpTrigger.isInitialized) {
        heapDumpTrigger.scheduleRetainedObjectCheck()
    }
}

HeapDumpTrigger.kt

fun scheduleRetainedObjectCheck(delayMillis: Long = 0L) {
    // 已簡(jiǎn)化：源碼此處使用時(shí)間戳攔截，避免重復(fù) postDelayed
    backgroundHandler.postDelayed({
        checkRetainedObjects()
    }, delayMillis)
}

private fun checkRetainedObjects() {
    val config = configProvider()

    // 泄漏對(duì)象計(jì)數(shù)
    var retainedReferenceCount = objectWatcher.retainedObjectCount
    if (retainedReferenceCount > 0) {
        // 主動(dòng)觸發(fā) GC，并等待 100 ms
        gcTrigger.runGc()
        // 重新獲取泄漏對(duì)象計(jì)數(shù)
        retainedReferenceCount = objectWatcher.retainedObjectCount
    }

    // 攔截 1：泄漏對(duì)象計(jì)數(shù)未達(dá)到閾值，或者進(jìn)入后臺(tái)時(shí)間未達(dá)到閾值
    if (retainedKeysCount < retainedVisibleThreshold) {
        // App 位于前臺(tái)或者剛剛進(jìn)入后臺(tái)
        if (applicationVisible || applicationInvisibleLessThanWatchPeriod) {
            // 發(fā)送通知提醒
            showRetainedCountNotification("App visible, waiting until %d retained objects")
            // 延遲 2 秒再檢查
            scheduleRetainedObjectCheck(WAIT_FOR_OBJECT_THRESHOLD_MILLIS)
            return;
        }
    }

    // 攔截 2：計(jì)算距離上一次 HeapDump 未超過(guò) 60s
    val now = SystemClock.uptimeMillis()
    val elapsedSinceLastDumpMillis = now - lastHeapDumpUptimeMillis
    if (elapsedSinceLastDumpMillis < WAIT_BETWEEN_HEAP_DUMPS_MILLIS) {
        // 發(fā)送通知提醒
        showRetainedCountNotification("Last heap dump was less than a minute ago")
        // 延遲 (60 - elapsedSinceLastDumpMillis)s 再檢查
        scheduleRetainedObjectCheck(WAIT_BETWEEN_HEAP_DUMPS_MILLIS - elapsedSinceLastDumpMillis)
        return
    }
    
    // 移除通知提醒
    dismissRetainedCountNotification()
    // 觸發(fā) HeapDump（此時(shí)，應(yīng)用有可能在后臺(tái)）
    dumpHeap(...)
}

// 真正開(kāi)始執(zhí)行 Heap Dump
private fun dumpHeap(...) {
    // 1. 獲取文件存儲(chǔ)提供器
    val directoryProvider = InternalLeakCanary.createLeakDirectoryProvider(InternalLeakCanary.application)

    // 2. 創(chuàng)建 .hprof File 文件
    val heapDumpFile = directoryProvider.newHeapDumpFile()

    // 3. 執(zhí)行 Heap Dump
    // Heap Dump 開(kāi)始時(shí)間戳
    val heapDumpUptimeMillis = SystemClock.uptimeMillis()
    // heapDumper.dumpHeap：最終調(diào)用 Debug.dumpHprofData(heapDumpFile.absolutePath) 
    configProvider().heapDumper.dumpHeap(heapDumpFile)

    // 4. 清除 ObjectWatcher 中過(guò)期的監(jiān)控
    objectWatcher.clearObjectsWatchedBefore(heapDumpUptimeMillis)

    // 5. 分析堆快照
    InternalLeakCanary.sendEvent(HeapDump(currentEventUniqueId!!, heapDumpFile, durationMillis, reason))
}

請(qǐng)求 GC 的源碼可以看一眼：

GcTrigger.kt

fun interface GcTrigger {

    fun runGc()

    object Default : GcTrigger {
        override fun runGc() {
            // Runtime.gc() 相比于 System.gc() 更有可能觸發(fā) GC
            Runtime.getRuntime().gc()
            // 暫停等待 GC 
            Thread.sleep(100)
            System.runFinalization()
        }
    }
}

6.5 LeakCanary 在哪個(gè)線(xiàn)程分析堆快照？

在前面的工作中，LeakCanary 已經(jīng)成功生成 .hprof 堆快照文件，并且發(fā)送了一個(gè) LeakCanary 內(nèi)部事件 HeapDump。那么這個(gè)事件在哪里被消費(fèi)的呢？

一步步跟蹤代碼可以看到 LeakCanary 的配置項(xiàng)中設(shè)置了多個(gè)事件消費(fèi)者 EventListener，其中與 HeapDump 事件有關(guān)的是 when{} 代碼塊中三個(gè)消費(fèi)者。不過(guò)，這三個(gè)消費(fèi)者并不是并存的，而是會(huì)根據(jù) App 當(dāng)前的依賴(lài)項(xiàng)而選擇最優(yōu)的執(zhí)行策略：

• 策略 1 - WorkerManager 多進(jìn)程分析
• 策略 2 - WorkManager 異步分析
• 策略 3 - 異步線(xiàn)程分析（兜底策略）

LeakCanary 配置項(xiàng)中的事件消費(fèi)者：

LeakCanary.kt

data class Config(
    val eventListeners: List<EventListener> = listOf(
        LogcatEventListener,
        ToastEventListener,
        LazyForwardingEventListener {
            if (InternalLeakCanary.formFactor == TV) TvEventListener else NotificationEventListener
        },
        when {
            // 策略 1 - WorkerManager 多進(jìn)程分析
            RemoteWorkManagerHeapAnalyzer.remoteLeakCanaryServiceInClasspath ->RemoteWorkManagerHeapAnalyzer
            // 策略 2 - WorkManager 異步分析
            WorkManagerHeapAnalyzer.validWorkManagerInClasspath -> WorkManagerHeapAnalyzer
            // 策略 3 - 異步線(xiàn)程分析（兜底策略）
            else -> BackgroundThreadHeapAnalyzer
        }
    ),
    ...
)

• 策略 1 - WorkerManager 多進(jìn)程分析： 判斷是否可以類(lèi)加載 RemoteLeakCanaryWorkerService ，這個(gè)類(lèi)位于前文提到的 com.squareup.leakcanary:leakcanary-android-process:2.9.1 依賴(lài)中。如果可以類(lèi)加載成功則視為有依賴(lài)，使用 WorkerManager 多進(jìn)程分析；

RemoteWorkManagerHeapAnalyzer.kt

object RemoteWorkManagerHeapAnalyzer : EventListener {

    // 通過(guò)類(lèi)加載是否成功，判斷是否存在依賴(lài)
    internal val remoteLeakCanaryServiceInClasspath by lazy {
        try {
            Class.forName("leakcanary.internal.RemoteLeakCanaryWorkerService")
            true
        } catch (ignored: Throwable) {
            false
        }
    }

    override fun onEvent(event: Event) {
        if (event is HeapDump) {
            // 創(chuàng)建并分發(fā) WorkManager 多進(jìn)程請(qǐng)求
            val heapAnalysisRequest = OneTimeWorkRequest.Builder(RemoteHeapAnalyzerWorker::class.java).apply {
                val dataBuilder = Data.Builder()
                    .putString(ARGUMENT_PACKAGE_NAME, application.packageName)
                    .putString(ARGUMENT_CLASS_NAME, REMOTE_SERVICE_CLASS_NAME)
                setInputData(event.asWorkerInputData(dataBuilder))
                with(WorkManagerHeapAnalyzer) {
                    addExpeditedFlag()
                }
            }.build()
            WorkManager.getInstance(application).enqueue(heapAnalysisRequest)
        }
    }
}

RemoteHeapAnalyzerWorker.kt

internal class RemoteHeapAnalyzerWorker(appContext: Context, workerParams: WorkerParameters) : RemoteListenableWorker(appContext, workerParams) {
    override fun startRemoteWork(): ListenableFuture<Result> {
        val heapDump = inputData.asEvent<HeapDump>()
        val result = SettableFuture.create<Result>()
        heapAnalyzerThreadHandler.post {
            // 1.1 分析堆快照
            val doneEvent = AndroidDebugHeapAnalyzer.runAnalysisBlocking(heapDump, isCanceled = {
                result.isCancelled
            }) { progressEvent ->
                // 1.2 發(fā)送分析進(jìn)度事件
                if (!result.isCancelled) {
                    InternalLeakCanary.sendEvent(progressEvent)
                }
            }
            // 1.3 發(fā)送分析完成事件
            InternalLeakCanary.sendEvent(doneEvent)
            result.set(Result.success())
        }
        return result
    }
}

• 策略 2 - WorkManager 異步分析： 判斷是否可以類(lèi)加載 androidx.work.WorkManager ，如果可以，則使用 WorkManager 異步分析；

WorkManagerHeapAnalyzer.kt

internal val validWorkManagerInClasspath by lazy {
    // 判斷 WorkManager 依賴(lài)，代碼略
}

override fun onEvent(event: Event) {
    if (event is HeapDump) {
        // 創(chuàng)建并分發(fā) WorkManager 請(qǐng)求
        val heapAnalysisRequest = OneTimeWorkRequest.Builder(HeapAnalyzerWorker::class.java).apply {
            setInputData(event.asWorkerInputData())
            addExpeditedFlag()
        }.build()
        val application = InternalLeakCanary.application
        WorkManager.getInstance(application).enqueue(heapAnalysisRequest)
    }
}

HeapAnalyzerWorker.kt

internal class HeapAnalyzerWorker(appContext: Context, workerParams: WorkerParameters) : Worker(appContext, workerParams) {
    override fun doWork(): Result {
        // 2.1 分析堆快照
        val doneEvent = AndroidDebugHeapAnalyzer.runAnalysisBlocking(inputData.asEvent()) { event ->
            // 2.2 發(fā)送分析進(jìn)度事件
            InternalLeakCanary.sendEvent(event)
        }
        // 2.3 發(fā)送分析完成事件
        InternalLeakCanary.sendEvent(doneEvent)
        return Result.success()
    }
}

• 策略 3 - 異步線(xiàn)程分析（兜底策略）： 如果以上策略未命中，則直接使用子線(xiàn)程兜底執(zhí)行。

BackgroundThreadHeapAnalyzer.kt

object BackgroundThreadHeapAnalyzer : EventListener {

    // HandlerThread
    internal val heapAnalyzerThreadHandler by lazy {
        val handlerThread = HandlerThread("HeapAnalyzer")
        handlerThread.start()
        Handler(handlerThread.looper)
    }

    override fun onEvent(event: Event) {
        if (event is HeapDump) {
            // HandlerThread 請(qǐng)求
            heapAnalyzerThreadHandler.post {
                // 3.1 分析堆快照
                val doneEvent = AndroidDebugHeapAnalyzer.runAnalysisBlocking(event) { event ->
                    // 3.2 發(fā)送分析進(jìn)度事件
                    InternalLeakCanary.sendEvent(event)
                }
                // 3.3 發(fā)送分析完成事件
                InternalLeakCanary.sendEvent(doneEvent)
            }
        }
    }
}

可以看到，不管采用那種執(zhí)行策略，最終執(zhí)行的邏輯都是一樣的：

• 1、分析堆快照；
• 2、發(fā)送分析進(jìn)度事件；
• 3、發(fā)送分析完成事件。

6.5 LeakCanary 如何分析堆快照？

在前面的分析中，我們已經(jīng)知道 LeakCanary 是通過(guò)子線(xiàn)程或者子進(jìn)程執(zhí)行 AndroidDebugHeapAnalyzer.runAnalysisBlocking 方法來(lái)分析堆快照的，并在分析過(guò)程中和分析完成后發(fā)送回調(diào)事件?，F(xiàn)在我們來(lái)閱讀 LeakCanary 的堆快照分析過(guò)程：

AndroidDebugHeapAnalyzer.kt

fun runAnalysisBlocking(
    heapDumped: HeapDump,
    isCanceled: () -> Boolean = { false },
    progressEventListener: (HeapAnalysisProgress) -> Unit
): HeapAnalysisDone<*> {
    ...
    // 1. .hprof 文件
    val heapDumpFile = heapDumped.file
    // 2. 分析堆快照
    val heapAnalysis = analyzeHeap(heapDumpFile, progressListener, isCanceled)
    val analysisDoneEvent = ScopedLeaksDb.writableDatabase(application) { db ->
    // 3. 將分析報(bào)告持久化到 DB
    val id = HeapAnalysisTable.insert(db, heapAnalysis)
    // 4. 發(fā)送分析完成事件（返回到上一級(jí)進(jìn)行發(fā)送：InternalLeakCanary.sendEvent(doneEvent)）
    val showIntent = LeakActivity.createSuccessIntent(application, id)
    val leakSignatures = fullHeapAnalysis.allLeaks.map { it.signature }.toSet()
    val leakSignatureStatuses = LeakTable.retrieveLeakReadStatuses(db, leakSignatures)
    val unreadLeakSignatures = leakSignatureStatuses.filter { (_, read) -> !read}.keys.toSet()
        HeapAnalysisSucceeded(heapDumped.uniqueId, fullHeapAnalysis, unreadLeakSignatures ,showIntent)
    }
    return analysisDoneEvent
}

核心分析方法是 analyzeHeap(…)，繼續(xù)往下走：

AndroidDebugHeapAnalyzer.kt

private fun analyzeHeap(
    heapDumpFile: File,
    progressListener: OnAnalysisProgressListener,
    isCanceled: () -> Boolean
): HeapAnalysis {
    ...
    // Shark 堆快照分析器
    val heapAnalyzer = HeapAnalyzer(progressListener)
    ...
    // 構(gòu)建對(duì)象圖信息
    val sourceProvider = ConstantMemoryMetricsDualSourceProvider(ThrowingCancelableFileSourceProvider(heapDumpFile)
    val graph = sourceProvider.openHeapGraph(proguardMapping = proguardMappingReader?.readProguardMapping())
    ...
    // 開(kāi)始分析
    heapAnalyzer.analyze(
    heapDumpFile = heapDumpFile,
    graph = graph,
    leakingObjectFinder = config.leakingObjectFinder, // 默認(rèn)是 KeyedWeakReferenceFinder
    referenceMatchers = config.referenceMatchers, // 默認(rèn)是 AndroidReferenceMatchers
    computeRetainedHeapSize = config.computeRetainedHeapSize, // 默認(rèn)是 true
    objectInspectors = config.objectInspectors, // 默認(rèn)是 AndroidObjectInspectors
    metadataExtractor = config.metadataExtractor // 默認(rèn)是 AndroidMetadataExtractor
    )
}

開(kāi)始進(jìn)入 Shark 組件：

shark.HeapAnalyzer.kt

// analyze -> analyze -> FindLeakInput.analyzeGraph
private fun FindLeakInput.analyzeGraph(
    metadataExtractor: MetadataExtractor,
    leakingObjectFinder: LeakingObjectFinder,
    heapDumpFile: File,
    analysisStartNanoTime: Long
): HeapAnalysisSuccess {
    ...
    // 1. 在堆快照中尋找泄漏對(duì)象，默認(rèn)是尋找 KeyedWeakReference 類(lèi)型對(duì)象
    // leakingObjectFinder 默認(rèn)是 KeyedWeakReferenceFinder
    val leakingObjectIds = leakingObjectFinder.findLeakingObjectIds(graph)
    // 2. 分析泄漏對(duì)象的最短引用鏈，并按照應(yīng)用鏈簽名分類(lèi)
    // applicationLeaks: Application Leaks
    // librbuildLeakTracesaryLeaks：Library Leaks
    // unreachableObjects：LeakCanary 無(wú)法分析出強(qiáng)引用鏈，可以提 Stack Overflow
    val (applicationLeaks, libraryLeaks, unreachableObjects) = findLeaks(leakingObjectIds)
    // 3. 返回分析完成事件
    return HeapAnalysisSuccess(...)
}

private fun FindLeakInput.findLeaks(leakingObjectIds: Set<Long>): LeaksAndUnreachableObjects {
    // PathFinder：引用鏈分析器
    val pathFinder = PathFinder(graph, listener, referenceReader, referenceMatchers)
    // pathFindingResults：完整引用鏈
    val pathFindingResults = pathFinder.findPathsFromGcRoots(leakingObjectIds, computeRetainedHeapSize)
    // unreachableObjects：LeakCanary 無(wú)法分析出強(qiáng)引用鏈（相當(dāng)于 LeakCanary 的 Bug）
    val unreachableObjects = findUnreachableObjects(pathFindingResults, leakingObjectIds)
    // shortestPaths：最短引用鏈
    val shortestPaths = deduplicateShortestPaths(pathFindingResults.pathsToLeakingObjects)
    // inspectedObjectsByPath：標(biāo)記信息
    val inspectedObjectsByPath = inspectObjects(shortestPaths)
    // retainedSizes：泄漏內(nèi)存大小
    val retainedSizes = computeRetainedSizes(inspectedObjectsByPath, pathFindingResults.dominatorTree)
    // 生成單個(gè)泄漏問(wèn)題的分析報(bào)告，并按照應(yīng)用鏈簽名分組，按照 Application Leaks 和 Library Leaks 分類(lèi)，按照 Application Leaks 和 Library Leaks 分類(lèi)
    // applicationLeaks: Application Leaks
    // librbuildLeakTracesaryLeaks：Library Leaks
    val (applicationLeaks, librbuildLeakTracesaryLeaks) = buildLeakTraces(shortestPaths, inspectedObjectsByPath, retainedSizes)
    return LeaksAndUnreachableObjects(applicationLeaks, libraryLeaks, unreachableObjects)
}

可以看到，堆快照分析最終是交給 Shark 中的 HeapAnalizer 完成的，核心流程是：

• 1、在堆快照中尋找泄漏對(duì)象，默認(rèn)是尋找 KeyedWeakReference 類(lèi)型對(duì)象；
• 2、分析 KeyedWeakReference 對(duì)象的最短引用鏈，并按照引用鏈簽名分組，按照 Application Leaks 和 Library Leaks 分類(lèi)；
• 3、返回分析完成事件。

第 1 步和第 3 步不用說(shuō)了，繼續(xù)分析最復(fù)雜的第 2 步：

shark.HeapAnalyzer.kt

// 生成單個(gè)泄漏問(wèn)題的分析報(bào)告，并按照應(yīng)用鏈簽名分組，按照 Application Leaks 和 Library Leaks 分類(lèi)，按照 Application Leaks 和 Library Leaks 分類(lèi)
private fun FindLeakInput.buildLeakTraces(
    shortestPaths: List<ShortestPath> /*最短引用鏈*/ ,
    inspectedObjectsByPath: List<List<InspectedObject>> /*標(biāo)記信息*/ ,
    retainedSizes: Map<Long, Pair<Int, Int>>? /*泄漏內(nèi)存大小*/
): Pair<List<ApplicationLeak>, List<LibraryLeak>> {
    // Application Leaks
    val applicationLeaksMap = mutableMapOf<String, MutableList<LeakTrace>>()
    // Library Leaks
    val libraryLeaksMap = mutableMapOf<String, Pair<LibraryLeakReferenceMatcher, MutableList<LeakTrace>>>()

    shortestPaths.forEachIndexed { pathIndex, shortestPath ->
        // 標(biāo)記信息
        val inspectedObjects = inspectedObjectsByPath[pathIndex]
        // 實(shí)例化引用鏈上的每個(gè)對(duì)象快照（非懷疑對(duì)象的 leakingStatus 為 NOT_LEAKING）
        val leakTraceObjects = buildLeakTraceObjects(inspectedObjects, retainedSizes)
        val referencePath = buildReferencePath(shortestPath, leakTraceObjects)
        // 分析報(bào)告
        val leakTrace = LeakTrace(
            gcRootType = GcRootType.fromGcRoot(shortestPath.root.gcRoot),
            referencePath = referencePath,
            leakingObject = leakTraceObjects.last()
        )
        val firstLibraryLeakMatcher = shortestPath.firstLibraryLeakMatcher()
        if (firstLibraryLeakMatcher != null) {
            // Library Leaks
            val signature: String = firstLibraryLeakMatcher.pattern.toString().createSHA1Hash()
            libraryLeaksMap.getOrPut(signature) { firstLibraryLeakMatcher to mutableListOf() }.second += leakTrace
        } else {
            // Application Leaks
            applicationLeaksMap.getOrPut(leakTrace.signature) { mutableListOf() } += leakTrace
        }
    }
    val applicationLeaks = applicationLeaksMap.map { (_, leakTraces) ->
        // 實(shí)例化為 ApplicationLeak 類(lèi)型
        ApplicationLeak(leakTraces)
    }
    val libraryLeaks = libraryLeaksMap.map { (_, pair) ->
        // 實(shí)例化為 LibraryLeak 類(lèi)型
        val (matcher, leakTraces) = pair
        LibraryLeak(leakTraces, matcher.pattern, matcher.description)
    }
    return applicationLeaks to libraryLeaks
}

6.6 LeakCanary 如何篩選 ~~~ 懷疑對(duì)象？

LeakCanary 會(huì)使用 ObjectInspector 對(duì)象檢索器在引用鏈上的節(jié)點(diǎn)中標(biāo)記必要的信息和狀態(tài)，標(biāo)記信息會(huì)顯示在分析報(bào)告中，并且會(huì)影響報(bào)告中的提示。而引用鏈 LEAKING 節(jié)點(diǎn)以后到第一個(gè) NOT_LEAKING 節(jié)點(diǎn)中間的節(jié)點(diǎn)，才會(huì)用 ~~~ 下劃線(xiàn)標(biāo)記為懷疑對(duì)象。

在第 6.5 節(jié)中，LeakCanary 通過(guò) leakingObjectFinder 標(biāo)記引用信息，leakingObjectFinder 默認(rèn)是 AndroidObjectInspectors.appDefaults ，也可以在配置項(xiàng)中自定義。

// inspectedObjectsByPath：篩選出非懷疑對(duì)象（分析報(bào)告中 ~~~ 標(biāo)記的是懷疑對(duì)象）
val inspectedObjectsByPath = inspectObjects(shortestPaths)

看一下可視化報(bào)告中相關(guān)源碼：

DisplayLeakAdapter.kt

...
val reachabilityString = when (leakingStatus) {
    UNKNOWN -> extra("UNKNOWN")
    NOT_LEAKING -> "NO" + extra(" (${leakingStatusReason})")
    LEAKING -> "YES" + extra(" (${leakingStatusReason})")
}
...

LeakTrace.kt

// 是否為懷疑對(duì)象
fun referencePathElementIsSuspect(index: Int): Boolean {
    return  when (referencePath[index].originObject.leakingStatus) {
        UNKNOWN -> true
        NOT_LEAKING -> index == referencePath.lastIndex || referencePath[index + 1].originObject.leakingStatus != NOT_LEAKING
        else -> false
    }
}

6.7 LeakCanary 分析完成后的處理

有兩個(gè)位置處理了 HeapAnalysisSucceeded 事件：

• Logcat：打印分析報(bào)告日志；
• Notification： 發(fā)送分析成功系統(tǒng)通知消息。

LogcatEventListener.kt

object LogcatEventListener : EventListener {
    ...
    SharkLog.d { "\u200B\n${LeakTraceWrapper.wrap(event.heapAnalysis.toString(), 120)}" }
    ...
}

NotificationEventListener.kt

object NotificationEventListener : EventListener {
    ...
    val flags = if (Build.VERSION.SDK_INT >= 23) {
        PendingIntent.FLAG_UPDATE_CURRENT or PendingIntent.FLAG_IMMUTABLE
    } else {
        PendingIntent.FLAG_UPDATE_CURRENT
    }
    // 點(diǎn)擊通知消息打開(kāi)可視化分析報(bào)告
    val pendingIntent = PendingIntent.getActivity(appContext, 1,  event.showIntent, flags)
    showHeapAnalysisResultNotification(contentTitle,pendingIntent)
    ...
}

至此，LeakCanary 原理分析完畢。

7. 總結(jié)

到這里，LeakCanary 的使用和原理分析就講完了。不過(guò)，LeakCanary 畢竟是實(shí)驗(yàn)室使用的工具，如果要實(shí)現(xiàn)線(xiàn)上內(nèi)存泄漏監(jiān)控，你知道怎么做嗎？要實(shí)現(xiàn) Native 內(nèi)存泄漏監(jiān)控又要怎么做？關(guān)注我，帶你了解更多。

參考資料

• LeakCanary 官網(wǎng)
• LeakCanary Github 倉(cāng)庫(kù)
• How Leakcanary leverages WorkManager multi-process —— Pierre-Yves Ricau 著
• Matrix Android ResourceCanary —— 騰訊 Matrix 說(shuō)明文檔
• KOOM —— 高性能線(xiàn)上內(nèi)存監(jiān)控方案 —— 快手 Koom 說(shuō)明文檔
• 內(nèi)存優(yōu)化（下）：內(nèi)存優(yōu)化這件事，應(yīng)該從哪里著手？ —— 張紹文 著
• Android內(nèi)存泄露檢測(cè) LeakCanary 2.0 (Kotlin版) 的實(shí)現(xiàn)原理 —— vivo 技術(shù)團(tuán)隊(duì) 著