最新消息:欢迎访问Android开发中文站!商务联系微信:loading_in

LeakCanary检测内存泄露原理

热点资讯 loading 133浏览 0评论

以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
}//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这些类对象是如何纳入检测的。

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库实现该功能,就不再进行追踪。

转载请注明:Android开发中文站 » LeakCanary检测内存泄露原理

您必须 登录 才能发表评论!