Android LeakCanary检测内存泄露原理

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

以上就是分析leakcanary检测内存泄露原理的详细内容，更多关于leakcanary检测内存泄露的资料请关注其它相关文章！