小编给大家分享一下Android LeakCanary检测内存泄露原理是什么，相信大部分人都还不怎么了解，因此分享这篇文章给大家参考一下，希望大家阅读完这篇文章后大有收获，下面让我们一起去了解一下吧！
以LeakCanary2.6源码分析LeakCanary检测内存泄露原理，为减少篇幅长度，突出关键点，不粘贴大量源码，阅读时需搭配源码食用。
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中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
}//2
private 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这些类对象是如何纳入检测的。
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回调中，纳入内存泄露检测。
对于Android里Window中的RootView，即DecorView，可以通过注册addOnAttachStateChangeListener在View的onViewDetachedFromWindow时进行检测。而获取待检测对象的引用就不像Activity和Fragment一样有回调可以依赖了。LeakCanary采取了Hook的方式在install方法对RootView的容器进行替换，具体来说就是通过反射机制将WindowManagerGlobal中的mViews（包含所有Window中的DecorView）的ArrayList容器的实现修改，在其add方法中获取DecorView的引用，之后设置OnAttachStateChangeListener回调进行检测。
而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中已回收的对象，剩下的对象就基本可以确定发生了内存泄露。
在确定内存泄露的对象后，就需要其他手段来确定泄露对象引用链了，这一过程开始于checkRetainedObjects方法，跟踪调用可以看到启动了前台服务HeapAnalyzerService，这在我们使用LeakCanary时可以在通知栏看到。服务中调用了HeapAnalyzer的analyze方法进行堆内存分析，由Shark库实现该功能，就不再进行追踪。
以上是“Android LeakCanary检测内存泄露原理是什么”这篇文章的所有内容，感谢各位的阅读！相信大家都有了一定的了解，希望分享的内容对大家有所帮助，如果还想学习更多知识，欢迎关注亿速云行业资讯频道！
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
