LeakCanary 从初始化到堆分析全流程剖析

在 Android 开发中，内存泄漏往往是导致应用崩溃或 ANR 的罪魁祸首。LeakCanary 提供了一个从对象“该死”时刻标记，到最终生成堆转储并分析泄漏链路的完整链路。只是许多开发者在实际使用过程中会遇到一系列痛点：初始化不生效、堆转储文件大小惊人、分析耗时过久、误报与漏报交替出现…，说起来，

主要原因：只要你在 build.gradle 中添加依赖。LeakCanary 就会通过自己的 ContentProvider 自动注入 Application。

为什么比 Application.onCreate 更早？

• 的 onCreate 在所有 Activity/Service 启动前执行。
• MVP 框架或第三方库也可能在 Application.onCreate 前调用，但 LeakCanary 必须最先注入才能监控整个生命周期。

User Pain Point #1： 如果你看到“Application started”日志。却没有任何 LeakCanary 的日志，这通常代表着 Manifest 没有正确注册 ContentProvider 或包名冲突。检查是否存在同名 provider 或 manifest merger 产生冲突。

AppWatcherInstaller.kt

class AppWatcherInstaller : ContentProvider {
override fun onCreate: Boolean {
AppWatcher.manualInstall
return true
}
}

AppWatcher.kt

object AppWatcher {
val objectWatcher = ObjectWatcher(
clock = UptimeClock,checkRetainedExecutor = Executor { command ->
Handler.apply { start }.looper)
.postDelayed)
}
)
fun manualInstall {
// 注册各类监听器
ActivityWatcher.install
FragmentAndViewModelWatcher.install
RootViewWatcher.install
InternalLeakCanary // 组织者
}
}

InternalLeakCanary.kt

internal object InternalLeakCanary : -> Unit。OnObjectRetainedListener {
override fun invoke {
_application = application
AppWatcher.objectWatcher.addOnObjectRetainedListener
val gcTrigger = GcTrigger.inProcess
val configProvider = { LeakCanary.config }
val handlerThread = HandlerThread.apply { start }
val backgroundHandler = Handler
heapDumpTrigger = HeapDumpTrigger(
application,backgroundHandler,AppWatcher.objectWatcher,gcTrigger,configProvider
)
application.registerVisibilityListener { visible ->
applicationVisible = visible
heapDumpTrigger.onApplicationVisibilityChanged
}
registerResumedActivityListener
}
override fun onObjectRetained {
heapDumpTrigger.onObjectRetained
}
}

User Pain Point #2： 如果你发现 “HeapDumpTrigger” 未被创建或 GC 触发无效，请确认你的 app 是否开启了 ProGuard/R8 混淆，还有是否在 debug 模式下运行。混淆可能导致内部类名称被 从而使某些反射调用失败。

2️⃣ 监听入口：对象何时“该死”？

Activity 监听

class ActivityWatcher(
private val application: Application,private val objectWatcher: ObjectWatcher
) : ActivityLifecycleCallbacks {
fun install {
application.registerActivityLifecycleCallbacks
}
override fun onActivityDestroyed {
objectWatcher.watch(
watchedObject = activity。description = "Activity ${activity::class.java.name} received onDestroy"
)
}
}

Fragment + ViewModel 监听

// FragmentAndViewModelWatcher.kt
class FragmentAndViewModelWatcher {
fun install {
application.registerActivityLifecycleCallbacks(object :
ActivityLifecycleCallbacks {
override fun onActivityCreated {
if {
// 安装 ViewModel 清理 watcher
installViewModelClearedWatcher
// 注册 Fragment 生命周期回调，递归观察所有子 fragment
activity.supportFragmentManager.registerFragmentLifecycleCallbacks(
object : FragmentManager.FragmentLifecycleCallbacks {
override fun onFragmentCreated(fm: FragmentManager,f: Fragment,savedInstanceState: Bundle?) {
if {
installViewModelClearedWatcher
}
}
override fun onFragmentDestroyed =
objectViewer.watch")
override fun onFragmentViewDestroyed(fm: FragmentManager,f:
Fragment) =
f.view?.let { objectViewer.watch(it,"Fragment view detached") }
},true /* recursive */ )
}
}
// ... or callbacks omitted for brevity ...
})
}
private fun installViewModelClearedWatcher(owner:
ViewModelStoreOwner。store:
ViewModelStore) {
ViewModelProvider.get.setStore
}
}

User Pain Point #3： 碎片化代码导致某些 fragment 或 view 未被正确注册，例如自定义 fragment 不继承标准类型或使用了第三方 MVVM 框架。请确保所有 fragment 都实现了 FragmentLifecycleCallbacks,而且 view model 使用标准 Android Architecture Components API。

Root View 监听

// RootViewTracker.kt
class RootViewTracker{
fun install{
app.registerActivityLifecycleCallbacks(object :
ActivityLifecycleCallbacks{
override fun onActivityCreated(activity :
Activity,savedInstanceState :
Bundle?){
activity.window.decorView.addOnAttachStateChangeListener(
object : View.OnAttachStateChangeListener{
override fun onViewAttachedToWindow(v:
View){}
override func onViewDetachedFromWindow(v:
View){
objectViewer.watch
}
})
}
})
}
}

3️⃣ ViewModel 清理检测——最巧妙的设计原理与实现细节

⚠️ 注意：由于缺失 T0 时间点，许多基于 ViewModel 的泄漏无法被捕获。例如单例模式持有全局引用，而未显式清除；或者线程池任务未及时 cancel 等场景，只能。

"

{}