LeakCanary源码分析

LeakCanary源码解析

内存泄露

今天来讲解一下老生常谈的问题了，内存泄露以及讲解LeakCanary是如果检测内存泄露的。

大家都在讲内存泄露，那么内存泄露的最根本的原因是什么？**最根本的原因就是该回收的对象没有被即使回收掉，导致了内存泄露。**要理解这句话，就要对java的垃圾回收机制有一定的了解了。什么是垃圾回收呢？就是java虚拟机在运行的时候会触发垃圾回收的机制，将那些没有用的，占用内存的对象回收掉。java虚拟机是怎么判断这个对象有没有用呢？是根据GC ROOT的可达性算法去判断的。就是如果一个对象，通过GC ROOT可达，那么它就是有用的对象。否则他就是没用的对象。

引用

无论是哪种方法，判断对象的存活都与“引用”有关。那么现在虚拟机对引用的期望是：当内存空间足够的时候，能保存在内存中；如果内存空间在进行垃圾回收之后还是非常紧张，则可以抛弃这些对象。所以就产生了四种引用

1.强引用：通过关键字new出来的对象，只要强引用还在，那么垃圾回收器就不会回收被引用的对象。

2.软引用：在系统将要发生内存溢出异常之前，将会把这些对象列入回收范围之中进行第二次回收。

3.弱引用：被弱引用引用的对象只能存活到下一垃圾回收发生之前。

4.虚引用：一个对象有无虚引用的存在，完全不影响其生存时间。也无法通过虚引用获取一个对象实例，为对象设置虚引用的目的就是能在这个对象被回收的时候，收到一个系统通知。

结合以上两点，可以得出，如果一个对象是被强引用，那么垃圾回收是不会回收这一部分对象的。那么同时如果虚拟机判断了GC ROOT不可达，那么又回收不了这个对象，那么就可以说这个对象造成了内存泄露。因为没有地方使用到这个对象了，而这个对象却还占用着的内存，所以他导致了内存的浪费，就是我们所说的内存泄露。

弱引用与引用队列

fun main() {
    val referenceQueue = ReferenceQueue<Pair<String, Int>?>()
    var pair: Pair<String, Int>? = Pair("小黄", 24)
    val weakReference = WeakReference(pair, referenceQueue)

    println(referenceQueue.poll()) //null

    pair = null

    System.gc()
    //GC 后休眠一段时间，等待 pair 被回收
    Thread.sleep(4000)

    println(referenceQueue.poll()) //java.lang.ref.WeakReference@d716361
}

可以看到，在 GC 过后 referenceQueue.poll() 的返回值变成了非 null，这是由于 WeakReference 和 ReferenceQueue 的一个组合特性导致的：在声明一个 WeakReference 对象时如果同时传入了 ReferenceQueue 作为构造参数的话，那么当 WeakReference 持有的对象被 GC 回收时，JVM 就会把这个弱引用存入与之关联的引用队列之中。依靠这个特性，我们就可以实现内存泄露的检测了

例如，当用户按返回键退出 Activity 时，正常情况下该 Activity 对象应该在不久后就被系统回收，我们可以监听 Activity 的 onDestroy 回调，在回调时把 Activity 对象保存到和 ReferenceQueue 关联的 WeakReference 中，在一段时间后（可以主动触发几次 GC）检测 ReferenceQueue 中是否有值，如果一直为 null 的话就说明发生了内存泄露。LeakCanary 就是通过这种方法来实现的。

LeakCanary源码分析

讲解了上面的一些前置知识，有助于大家更好的理解LeakCanary的工作原理。接下来就是讲解LeakCanary的工作流程和具体的细节了。这篇博客是基于2.8.1版本讲解的。

LeakCanary 2.8.1 版本中，LeakCanary 将初始过程交由 MainProcessAppWatcherInstaller 这个 ContentProvider 来自动完成

MainProcessAppWatcherInstaller#onCreate

//这是一个ContentProvider
internal class MainProcessAppWatcherInstaller : ContentProvider() {
    
  override fun onCreate(): Boolean {
    val application = context!!.applicationContext as Application
    AppWatcher.manualInstall(application)
    return true
  }

}

由于 ContentProvider 会在 Application 被创建之前就由系统调用其 onCreate() 方法来完成初始化，所以 LeakCanary 通过 AppWatcherInstaller 就可以拿到 Context 来完成初始化并随应用一起启动，通过这种方式就简化了使用者的引入成本。

MainProcessAppWatcherInstaller 最终会将 Application 对象传给 AppWatcher 的 manualInstall(Application) 方法

AppWatcher#manualInstall

@JvmOverloads
fun manualInstall(
    application: Application,
    retainedDelayMillis: Long = TimeUnit.SECONDS.toMillis(5),//这里也是一个默认的参数，5秒
    watchersToInstall: List<InstallableWatcher> = appDefaultWatchers(application)//这里有默认的参数
) {
    checkMainThread()
    if (isInstalled) {
        throw IllegalStateException(
            "AppWatcher already installed, see exception cause for prior install call", installCause
        )
    }
    check(retainedDelayMillis >= 0) {
        "retainedDelayMillis $retainedDelayMillis must be at least 0 ms"
    }
    installCause = RuntimeException("manualInstall() first called here")
    this.retainedDelayMillis = retainedDelayMillis
    if (application.isDebuggableBuild) {
        LogcatSharkLog.install()
    }
   //初始化一些配置，InternalLeakCanary类invoke方法，配置泄漏Listener，GC触发器，Dump类。
    LeakCanaryDelegate.loadLeakCanary(application)

    //调用各种install，其实就是为各种InstallableWatcher注册一些监听事件，这里有四个InstallableWatcher
    watchersToInstall.forEach {
        it.install()
    }
}

AppWatcher#appDefaultWatchers

fun appDefaultWatchers(
  application: Application,
  reachabilityWatcher: ReachabilityWatcher = objectWatcher
): List<InstallableWatcher> {
  return listOf(
    ActivityWatcher(application, reachabilityWatcher),
    FragmentAndViewModelWatcher(application, reachabilityWatcher),
    RootViewWatcher(reachabilityWatcher),
    ServiceWatcher(reachabilityWatcher)
  )
}

可以看出这里面有四中类型的InstallableWatcher。里面的实现大同小异

ActivityWatcher

class ActivityWatcher(
  private val application: Application,
  private val reachabilityWatcher: ReachabilityWatcher
) : InstallableWatcher {

  private val lifecycleCallbacks =
    object : Application.ActivityLifecycleCallbacks by noOpDelegate() {
      override fun onActivityDestroyed(activity: Activity) {
        reachabilityWatcher.expectWeaklyReachable(
          activity, "${activity::class.java.name} received Activity#onDestroy() callback"
        )
      }
    }

  override fun install() {
    application.registerActivityLifecycleCallbacks(lifecycleCallbacks)
  }

  override fun uninstall() {
    application.unregisterActivityLifecycleCallbacks(lifecycleCallbacks)
  }
}

看一下ActivityWatcher就可以了，调用install方法，其实就是为了注册监听而已，看一下这个lifecycleCallbacks，可以看出，当Acrivity发生onDestory的时候，会回调到onActivityDestroyed这里面来。而这里面调用的是 reachabilityWatcher.expectWeaklyReachable。所以去看一下这个函数大概就知道LeakCanary到底是怎么工作的了。这之前，看一下reachabilityWatcher是什么东西，看会appDefaultWatchers函数可以知道，appDefaultWatchers其实就是objectWatcher。

objectWatcher的初始化

val objectWatcher = ObjectWatcher(
    clock = { SystemClock.uptimeMillis() },
    checkRetainedExecutor = {
        check(isInstalled) {
            "AppWatcher not installed"
        }
        mainHandler.postDelayed(it, retainedDelayMillis)
    },
    isEnabled = { true }
)

所以expectWeaklyReachable其实就是ObjectWatcher的expectWeaklyReachable函数

ObjectWatcher#expectWeaklyReachable

这个函数我们需要一步一步慢慢看

  @Synchronized override fun expectWeaklyReachable(
    watchedObject: Any,
    description: String
  ) {
    if (!isEnabled()) {
      return
    }
    //首先去移除那些没有发生泄露的对象，第一次先忽略
    removeWeaklyReachableObjects()
    //生成一个key
    val key = UUID.randomUUID()
      .toString()
    val watchUptimeMillis = clock.uptimeMillis()
   //通过这个key，构建一个弱引用对象，同时传入一个引用队列
    val reference =
      KeyedWeakReference(watchedObject, key, description, watchUptimeMillis, queue)
    SharkLog.d {
      "Watching " +
        (if (watchedObject is Class<*>) watchedObject.toString() else "instance of ${watchedObject.javaClass.name}") +
        (if (description.isNotEmpty()) " ($description)" else "") +
        " with key $key"
    }
	//然后将这个弱引用对象存入watchedObjects
    watchedObjects[key] = reference
    checkRetainedExecutor.execute {
      moveToRetained(key)//这个方法会延迟5秒执行
    }
  }

ObjectWatcher#moveToRetained

@Synchronized private fun moveToRetained(key: String) {
    //移除那些没有发生泄露的对象
    removeWeaklyReachableObjects()
    //执行了移除操作后，在watchedObjects中还能找到对饮的弱引用的话，说明这个对象发生了泄露了
    val retainedRef = watchedObjects[key]
    if (retainedRef != null) {
        retainedRef.retainedUptimeMillis = clock.uptimeMillis()///记录当前时间
        onObjectRetainedListeners.forEach { it.onObjectRetained() }
    }
}

ObjectWatcher#removeWeaklyReachableObjects

private fun removeWeaklyReachableObjects() {
   //根据弱引用与引用队列那一节的分析，我们可以知道如果能在queue中的对象都是没有泄露的对象。这里的操作是遍历queue中的对象，然后根据它的key，将key对应的watchedObjects里面的对象移除。如果执行了该操作之后watchedObjects中还存在对应的key，那么说明发生GC的时候，这个对象没有被放入引用队列，也就是说该对象没有被回收，所以可以确定该对象造成了内存泄露
    var ref: KeyedWeakReference?
    do {
        ref = queue.poll() as KeyedWeakReference?
        if (ref != null) {
            watchedObjects.remove(ref.key)
        }
    } while (ref != null)
}

moveToRetained 方法就用于判断指定 key 关联的对象是否已经泄露，如果没有泄露则移除对该对象的弱引用，有泄露的话则更新其 retainedUptimeMillis 值，以此来标记其发生了泄露，并同时通过回调 onObjectRetained 来分析内存泄露链。

以上就是LeakCanary的关于如何检测内存泄露的源码分析了。其实检测内存泄露这一部分代码确实也比较简单，难的是获取内存泄露链和Dump那一部分。不过这两部分不在今天的讨论范围了，后续有机会的话，可以单独拿出来讲一下。好了今天的博客就这么多了，喜欢的小伙伴点个关注和赞吧。