原理通过注册activity和fragment的callback监听来观察当前页面是否destroy
Application中
监听activity 调用 registerActivityLifecycleCallbacks(this)
监听Fragment如下 ：
// 注册 Activity 生命周期监听器，以监听每个 Activity 的 Fragment 生命周期
registerActivityLifecycleCallbacks(object : ActivityLifecycleCallbacks {
override fun onActivityCreated(activity: Activity, savedInstanceState: Bundle?) {
if (activity is FragmentActivity) {
// 对于 FragmentActivity，注册 Fragment 生命周期回调
activity.supportFragmentManager.registerFragmentLifecycleCallbacks(object : FragmentManager.FragmentLifecycleCallbacks() {
override fun onFragmentCreated(fm: FragmentManager, f: Fragment, savedInstanceState: Bundle?) {
Log.d("FragmentLifecycle", "Fragment ${f.javaClass.simpleName} onCreated in ${activity.javaClass.simpleName}")
}
override fun onFragmentStarted(fm: FragmentManager, f: Fragment) {
Log.d("FragmentLifecycle", "Fragment ${f.javaClass.simpleName} onStarted in ${activity.javaClass.simpleName}")
}
override fun onFragmentResumed(fm: FragmentManager, f: Fragment) {
Log.d("FragmentLifecycle", "Fragment ${f.javaClass.simpleName} onResumed in ${activity.javaClass.simpleName}")
}
override fun onFragmentPaused(fm: FragmentManager, f: Fragment) {
Log.d("FragmentLifecycle", "Fragment ${f.javaClass.simpleName} onPaused in ${activity.javaClass.simpleName}")
}
override fun onFragmentStopped(fm: FragmentManager, f: Fragment) {
Log.d("FragmentLifecycle", "Fragment ${f.javaClass.simpleName} onStopped in ${activity.javaClass.simpleName}")
}
override fun onFragmentDestroyed(fm: FragmentManager, f: Fragment) {
Log.d("FragmentLifecycle", "Fragment ${f.javaClass.simpleName} onDestroyed in ${activity.javaClass.simpleName}")
}
}, true)
}
}
override fun onActivityStarted(activity: Activity) {}
override fun onActivityResumed(activity: Activity) {}
override fun onActivityPaused(activity: Activity) {}
override fun onActivityStopped(activity: Activity) {}
override fun onActivitySaveInstanceState(activity: Activity, outState: Bundle) {}
override fun onActivityDestroyed(activity: Activity) {}
})
当任意一个 Fragment 被创建、启动、恢复、暂停、停止或销毁时，都会通过 FragmentLifecycleCallbacks 打印日志。
通过这种方式，你可以在全局范围内监听每个 Activity 中的 Fragment 的生命周期。
在onDestroy方法中检测到对象的弱引用还有没有值，有值说明没有被回收存在内存泄漏，没有值说明已经被回收了，当前对象不存在泄漏
存在问题：
-
性能开销（只能检测debug环境 线上会很卡顿（线上检测方式可以用KOOM类库快手开源的））
image.png
内存和CPU负担：LeakCanary 在进行内存快照（Heap Dump）和分析时会消耗额外的内存和CPU资源。对于较大的应用或复杂的场景，生成和分析堆内存快照可能会导致明显的性能下降，尤其是在低性能设备上。
内存使用增加：LeakCanary 本身会消耗一定的内存来跟踪对象，并且 Heap Dump 文件会占用设备存储空间，这可能导致在调试环境中内存压力增大。
误报问题
假阳性（False Positive）：由于 LeakCanary 基于弱引用和GC回收机制来判断对象是否被泄漏，在某些情况下，系统可能延迟回收对象或者强制回收未及时发生，导致 LeakCanary 误报内存泄漏。
复杂场景的误报：对于某些复杂的引用关系（如系统级别的引用或长期存在的静态引用），LeakCanary 可能无法准确判断是否为实际内存泄漏，尤其是在多线程或异步操作较多的情况下。嵌套的fragment会被漏掉检查
比如app首页有三个tab(fragment) 在tab1中 嵌套了一个viewpager，viewpager中又有很多fragment，LeakCanary源码中原理是通过activity的fragmentManager中监听第一层的fragment，无法监听到第二层第三层的所以会导致漏掉检查。
4 activity也会存在此问题
LeakCanary观察的是能够执行到onDestroy生命周期的类，如果观察不到那就会漏掉，申请情况下会观察不到呢 以下举例说明：
activity A启动activity B
在 Android 中，当 ActivityA 启动 ActivityB 时，ActivityA 的生命周期会随着 ActivityB 的启动过程发生变化。具体来说：
ActivityB 的启动：当 ActivityB 被启动时，它的生命周期依次执行 onCreate()、onStart() 和 onResume()。
ActivityA 的 onStop()：当 ActivityB 完成 onResume()，也就是 ActivityB 显示在前台并获得焦点时，此时 ActivityA 会进入后台，然后 ActivityA 的 onStop() 方法被调用。
源码分析：为什么ActivityB 完成 onResume()后才执行ActivityA 的 onStop()
因为AMS的管理机制，当 ActivityB 执行onResume()的时候 消息队列中会add一个idlehandler 告诉Activity主线程空闲了，然后会通知ams ams收到这个消息后会通知ActivityA该执行onStop了.
如果在执行ActivityB onResume()的时候一直在刷新UI 比如动画此时Activity主线程没有空闲，所以就不会执行idlehandler ams就不会通知ActivityA 执行 onStop() 所以就会导致ActivityA无法被回收。 当 ActivityB 执行onResume()的时候 AMS会设置一个定时机制10s后会通知ActivityA 执行onStop方法
（补充和详细分析：
- AMS 与消息队列的调度机制
当 ActivityB 执行到 onResume() 时，它会获取焦点并进入前台。此时，AMS 会将一个 IdleHandler 添加到 ActivityThread 的消息队列中，这个 IdleHandler 负责通知 AMS ActivityB 进入前台且 ActivityA 已经不再处于活跃状态，因此可以让 ActivityA 执行 onStop()。
这里的关键点是：消息队列的空闲状态。如果 ActivityB 在 onResume() 阶段执行耗时任务（例如动画、UI 刷新等），消息队列可能不会很快进入空闲状态，导致 IdleHandler 没有机会执行，从而延迟 ActivityA 的 onStop()。
AMS 定时机制
AMS 确实会设置一个超时机制（通常是 10 秒左右），以确保 ActivityA 能及时执行 onStop()。这个定时机制是为了防止某些情况下 ActivityThread 长时间无法进入空闲状态，导致 onStop() 被过度延迟。如果超时后还没有进入空闲状态，AMS 会强制要求 ActivityA 执行 onStop() 以避免资源浪费。进一步分析和建议
UI 线程占用问题：如果 ActivityB 在 onResume() 期间执行了大量的 UI 刷新操作或者动画，使得主线程忙碌而无法空闲，确实会延迟 IdleHandler 的执行。为了解决这种情况，可以考虑将耗时操作（如动画或复杂 UI 刷新）放在合适的地方进行，比如在 onPostResume()、onWindowFocusChanged() 或者通过 Handler 延迟执行，这样可以确保主线程有足够的时间空闲，从而让 IdleHandler 触发 onStop()。
定时机制的作用：AMS 的定时机制是作为安全网的一部分，用来保证生命周期的正确性。然而，依赖定时机制并不是最佳实践，因为这可能会导致性能问题或内存泄漏。应尽量避免阻塞 onResume() 的主线程操作。
总的来说，你的理解是正确的，但需要注意的是，延迟 onStop() 并不是常态，应该尽量优化 Activity 的启动和 UI 刷新操作，避免占用主线程资源过多导致生命周期回调被阻塞。）
