LeakCanary2解析

1 引言

众所周知，LeakCanary是一个内存泄漏检测的工具。那么，内存泄漏是如何定义的，通常有哪些情况呢？在分析源代码之前，我们先弄清楚这两个问题。这两个问题在LeakCanary - Fundamentals中有提及。

2 什么是内存泄漏 (What is a memory leak?)¶

In a Java based runtime, a memory leak is a programming error that causes an application to keep a reference to an object that is no longer needed. As a result, the memory allocated for that object cannot be reclaimed, eventually leading to an OutOfMemoryError crash.

在基于Java的运行时中，内存泄漏是一种编程错误，它导致应用程序保留对不再需要的对象的引用。这会导致为该对象分配的内存无法回收，最终导致OutOfMemoryError崩溃。

For example, an Android activity instance is no longer needed after its onDestroy() method is called, and storing a reference to that activity in a static field would prevent it from being garbage collected.

例如，在Activity的onDestroy()方法被调用后，Android activity的实例就不再需要了，此时在静态字段中存储该Activity的引用将阻止其被回收。

3 常见的内存泄漏 (Common causes for memory leaks)

Most memory leaks are caused by bugs related to the lifecycle of objects. Here are a few common Android mistakes:

大多数内存泄漏是由与对象生命周期相关的错误引起的。以下是一些常见的Android错误：

Storing an Activity context as a field in an object that survives activity recreation due to configuration changes.

将Activity上下文存储为对象中的字段，这样配置更改后activity会重新创建，但是老的仍然存活。
Registering a listener, broadcast receiver or RxJava subscription which references an object with lifecycle, and forgetting to unregister when the lifecycle reaches its end.

对有生命周期的对象注册了监听器、广播接收者或者RxJava的订阅，且当对象的生命到达了终点时没有取消注册。
Storing a view in a static field, and not clearing that field when the view is detached.

在静态字段中存储了view，且当view detach时没有清空静态变量。

4 LeakCanary2如何检测内存泄漏

LeakCanary v2 与 v1 的代码由略微的不同，下面是两者的检测内存泄漏的原理。

LeakCanary 1.5.1 检测内存泄漏原理：
在Activity destroy后将Activity的弱引用关联到ReferenceQueue中，这样Activity将要被GC前，会出现在ReferenceQueue中。随后，会向主线程的MessageQueue添加一个IdleHandler，用于在idle时触发一个发生在HandlerThread的等待5秒后开始检测内存泄漏的代码。这段代码首先会判断是否对象出现在引用队列中，如果有，则说明没有内存泄漏，结束。否则，调用Runtime.getRuntime().gc()进行GC，等待100ms后再次判断是否已经出现在引用队列中，若还没有被出现，那么说明有内存泄漏，开始dump hprof。

LeakCanary 2.0 beta 3 检测内存泄漏原理：
在Activity destroy后将Activity的弱引用关联到ReferenceQueue中，这样Activity将要被GC前，会出现在ReferenceQueue中。随后，会向主线程的抛出一个5秒后执行的Runnable，用于检测内存泄漏。这段代码首先会将引用队列中出现的对象从观察对象数组中移除，然后再判断要观察的此对象是否存在。若不存在，则说明没有内存泄漏，结束。否则，就说明可能出现了内存泄漏，会调用Runtime.getRuntime().gc()进行GC，等待100ms后再次根据引用队列判断，若仍然出现在引用队列中，那么说明有内存泄漏，此时根据内存泄漏的个数弹出通知或者开始dump hprof。

4.1 LeakCanary2初始化

LeakCanary 2.0使用非常简单，只需要在build.gradle中配置一下，无需在项目中添加任何代码。

    dependencies {
        // debugImplementation because LeakCanary should only run in debug builds.
        debugImplementation 'com.squareup.leakcanary:leakcanary-android:2.0-beta-3'
    }

原理就是利用ContentProvider的特性，其onCreate方法会在Application的onCreate方法之前被系统调用。所以只需要在AndroidManifest.xml中配置一下这个ContentProvider，然后在onCreate方法中进行初始化即可。

leakcanary-object-watcher-android/src/main/AndroidManifest.xml

<?xml version="1.0" encoding="utf-8"?>
<manifest
    xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.squareup.leakcanary.objectwatcher"
    >

  <application>
    <provider
        android:name="leakcanary.internal.AppWatcherInstaller$MainProcess"
        android:authorities="${applicationId}.leakcanary-installer"
        android:exported="false"/>
  </application>
</manifest>

leakcanary-object-watcher-android/src/main/java/leakcanary/internal/AppWatcherInstaller.kt

/**
 * Content providers are loaded before the application class is created. [AppWatcherInstaller] is
 * used to install [leakcanary.AppWatcher] on application start.
 */
internal sealed class AppWatcherInstaller : ContentProvider() {

  /**
   * [MainProcess] automatically sets up the LeakCanary code that runs in the main app process.
   */
  internal class MainProcess : AppWatcherInstaller()

  /**
   * When using the `leakcanary-android-process` artifact instead of `leakcanary-android`,
   * [LeakCanaryProcess] automatically sets up the LeakCanary code
   */
  internal class LeakCanaryProcess : AppWatcherInstaller() {
    override fun onCreate(): Boolean {
      super.onCreate()
      AppWatcher.config = AppWatcher.config.copy(enabled = false)
      return true
    }
  }

  override fun onCreate(): Boolean {
    val application = context!!.applicationContext as Application
    InternalAppWatcher.install(application)
    return true
  }

  override fun query(
    uri: Uri,
    strings: Array<String>?,
    s: String?,
    strings1: Array<String>?,
    s1: String?
  ): Cursor? {
    return null
  }

  override fun getType(uri: Uri): String? {
    return null
  }

  override fun insert(
    uri: Uri,
    contentValues: ContentValues?
  ): Uri? {
    return null
  }

  override fun delete(
    uri: Uri,
    s: String?,
    strings: Array<String>?
  ): Int {
    return 0
  }

  override fun update(
    uri: Uri,
    contentValues: ContentValues?,
    s: String?,
    strings: Array<String>?
  ): Int {
    return 0
  }
}

我们可以看到，该ContentProvider除了在onCreate方法中进行了初始化处理，其他方法都是空实现。在上面的第26行，onCreate方法中初始化代码为InternalAppWatcher.install(application)。

InternalAppWatcher.install(Application) 方法完成了LeakCanary的初始化操作，里面涉及到协作的一些类的定义。

leakcanary-object-watcher-android/src/main/java/leakcanary/internal/InternalAppWatcher.kt

internal object InternalAppWatcher {

  // 通过判断lateinit修饰的Application是否已经初始化，来判断LeakCanary是否已经安装
  val isInstalled
    get() = ::application.isInitialized

  // LeakCanary安装完成的回调，实际上对应的是leakcanary.internal.InternalLeakCanary这个类
  private val onAppWatcherInstalled: (Application) -> Unit

  val isDebuggableBuild by lazy {
    (application.applicationInfo.flags and ApplicationInfo.FLAG_DEBUGGABLE) != 0
  }

  lateinit var application: Application

  // ObjectWatcher参数1
  private val clock = object : Clock {
    override fun uptimeMillis(): Long {
      return SystemClock.uptimeMillis()
    }
  }

  private val mainHandler = Handler(Looper.getMainLooper())

  init {
    // 这里为什么要这么费劲的获取该object的对象呢？
    // 因为InternalLeakCanary类是上层模块的，这里没有办法直接引用
    val internalLeakCanary = try {
      val leakCanaryListener = Class.forName("leakcanary.internal.InternalLeakCanary")
      leakCanaryListener.getDeclaredField("INSTANCE")
          .get(null)
    } catch (ignored: Throwable) {
      NoLeakCanary
    }
    @kotlin.Suppress("UNCHECKED_CAST")
    onAppWatcherInstalled = internalLeakCanary as (Application) -> Unit
  }

  // 主线程抛出任务，delay 5s
  private val checkRetainedExecutor = Executor {
    mainHandler.postDelayed(it, AppWatcher.config.watchDurationMillis)
  }
  val objectWatcher = ObjectWatcher(
      clock = clock,
      checkRetainedExecutor = checkRetainedExecutor,
      isEnabled = { AppWatcher.config.enabled }
  )

  fun install(application: Application) {
    ...
    checkMainThread()
    // lateinit修饰的对象可以通过::<field>.isInitialized来判断有没有初始化
    // 如果已经初始化了，则不需要再次install
    if (this::application.isInitialized) {
      return
    }
    InternalAppWatcher.application = application

    // 安装ActivityDestroyWatcher、FragmentDestroyWatcher
    val configProvider = { AppWatcher.config }
    ActivityDestroyWatcher.install(application, objectWatcher, configProvider)
    FragmentDestroyWatcher.install(application, objectWatcher, configProvider)
    // 通知上层模块的InternalLeakCanary.invoke方法
    onAppWatcherInstalled(application)
  }
  ...
}

在上面的这个install方法中，干了三件事： 1. 初始化一个ObjectWatcher对象：其clock就是SystemClock.uptimeMillis()，checkRetainedExecutor是利用主线程Handler执行的任务 2. Activity、Fragment销毁的观察者的安装 3. 通知InternalLeakCanary，watcher已经安装完成。

由于Activity、Fragment的销毁不会立刻发生，所以我们先看看第3点中，InternalLeakCanary做了什么工作。

InternalLeakCanary的部分声明为object InternalLeakCanary : (Application) -> Unit，所以它到底实现了什么呢。这其实对应kotlin中Functions.kt文件的Function1接口，P1为Application，R为Unit即void：

/** A function that takes 1 argument. */
public interface Function1<in P1, out R> : Function<R> {
    /** Invokes the function with the specified argument. */
    public operator fun invoke(p1: P1): R
}

所以接着看InternalLeakCanary.invoke方法即可，该方法也是完成了一些初始化操作，如下：

InternalLeakCanary.kt

override fun invoke(application: Application) {
  this.application = application

  // 内存泄漏时回调该类的方法
  AppWatcher.objectWatcher.addOnObjectRetainedListener(this)

  val heapDumper = AndroidHeapDumper(application, leakDirectoryProvider)

  // gcTrigger使用的默认的
  val gcTrigger = GcTrigger.Default

  val configProvider = { LeakCanary.config }

  // HandlerThread + Handler 来处理后台任务
  val handlerThread = HandlerThread(LEAK_CANARY_THREAD_NAME)
  handlerThread.start()
  val backgroundHandler = Handler(handlerThread.looper)

  heapDumpTrigger = HeapDumpTrigger(
      application, backgroundHandler, AppWatcher.objectWatcher, gcTrigger, heapDumper,
      configProvider
  )
  // 自定义的扩展方法来检测App是否可见（处于前台）
  application.registerVisibilityListener { applicationVisible ->
    this.applicationVisible = applicationVisible
    heapDumpTrigger.onApplicationVisibilityChanged(applicationVisible)
  }
  // 动态添加Shortcut
  addDynamicShortcut(application)

  disableDumpHeapInInstrumentationTests()
}

其实上面这些初始化的变量，大部分我们都不会在检测内存泄漏时遇到，这些变量大部分都与dump heap有关。

这里展开说说其中的“自定义的扩展方法来检测App是否可见（处于前台）”这里面的实现原理，这个需求在日常开发中也会用到，也是通过向Application注册Activity生命周期回调，通过计算start-stop的Activity个数来实现的：

leakcanary-android-core/src/main/java/leakcanary/internal/VisibilityTracker.kt

internal class VisibilityTracker(
  private val listener: (Boolean) -> Unit
) :
    Application.ActivityLifecycleCallbacks by noOpDelegate() {

  private var startedActivityCount = 0

  /**
   * Visible activities are any activity started but not stopped yet. An activity can be paused
   * yet visible: this will happen when another activity shows on top with a transparent background
   * and the activity behind won't get touch inputs but still need to render / animate.
   */
  private var hasVisibleActivities: Boolean = false

  override fun onActivityStarted(activity: Activity) {
    startedActivityCount++
    if (!hasVisibleActivities && startedActivityCount == 1) {
      hasVisibleActivities = true
      listener.invoke(true)
    }
  }

  override fun onActivityStopped(activity: Activity) {
    // This could happen if the callbacks were registered after some activities were already
    // started. In that case we effectively considers those past activities as not visible.
    if (startedActivityCount > 0) {
      startedActivityCount--
    }
    if (hasVisibleActivities && startedActivityCount == 0 && !activity.isChangingConfigurations) {
      hasVisibleActivities = false
      listener.invoke(false)
    }
  }
}

internal fun Application.registerVisibilityListener(listener: (Boolean) -> Unit) {
  registerActivityLifecycleCallbacks(VisibilityTracker(listener))
}

上面就是LeakCanary的初始化代码了，下一节开始说说Activity与Fragment是如何检测内存泄漏的。

4.2 如何观察Activity、Fragment

在上一节LeakCanary2初始化中，我们还没有讲解下面两行代码：

ActivityDestroyWatcher.install(application, objectWatcher, configProvider)
FragmentDestroyWatcher.install(application, objectWatcher, configProvider)

这两行代码都是通过向Application注册registerActivityLifecycleCallbacks从而获取每个启动的Activity，然后

对于Activity而言，直接观察Activity即可
对于Fragment而言，由于Fragment需要依附于Activity，且需要从Activity中获取FragmentManager，然后通过其registerFragmentLifecycleCallbacks方法观察Fragment

上面两行代码就是这个实现逻辑。先看看Activity的观察逻辑：

leakcanary-object-watcher-android/src/main/java/leakcanary/internal/ActivityDestroyWatcher.kt

internal class ActivityDestroyWatcher private constructor(
  private val objectWatcher: ObjectWatcher,
  private val configProvider: () -> Config
) {

  private val lifecycleCallbacks =
    object : Application.ActivityLifecycleCallbacks by noOpDelegate() {
      // noOpDelegate()是一个动态代理的实现，不过里面没有写任何逻辑 所以是no op
      // 此处相当于一个适配器方法
      override fun onActivityDestroyed(activity: Activity) {
        if (configProvider().watchActivities) {
          objectWatcher.watch(activity)
        }
      }
    }

  companion object {
    fun install(
      application: Application,
      objectWatcher: ObjectWatcher,
      configProvider: () -> Config
    ) {
      val activityDestroyWatcher =
        ActivityDestroyWatcher(objectWatcher, configProvider)
      application.registerActivityLifecycleCallbacks(activityDestroyWatcher.lifecycleCallbacks)
    }
  }
}

上面的逻辑很简单，就是对于每个Activity，在其onDestroy方法调用之后，调用objectWatcher.watch观察这个Activity。该方法的逻辑我们下一节再说。

然后我们看看Fragment里面的观察逻辑，由于Fragment有两种： 1. android.app.Fragment 2. support包里面的androidx.fragment.app.Fragment

前者的FragmentLifecycleCallbacks有API Level限制，限制为O；后者则没有API限制了，但是有androidx限制。所以FragmentDestroyWatcher会判断这两个的是否满足条件，满足条件后才会进行观察。

leakcanary-object-watcher-android/src/main/java/leakcanary/internal/FragmentDestroyWatcher.kt

/**
 * Internal class used to watch for fragments leaks.
 */
internal object FragmentDestroyWatcher {

  private const val ANDROIDX_FRAGMENT_CLASS_NAME = "androidx.fragment.app.Fragment"
  private const val ANDROIDX_FRAGMENT_DESTROY_WATCHER_CLASS_NAME =
    "leakcanary.internal.AndroidXFragmentDestroyWatcher"

  fun install(
    application: Application,
    objectWatcher: ObjectWatcher,
    configProvider: () -> AppWatcher.Config
  ) {
    val fragmentDestroyWatchers = mutableListOf<(Activity) -> Unit>()

    // 如果SDK大于等于O，则添加android.app.Fragment的观察者
    if (SDK_INT >= O) {
      fragmentDestroyWatchers.add(
          AndroidOFragmentDestroyWatcher(objectWatcher, configProvider)
      )
    }

    // 通过反射判定androidx.fragment.app.Fragment以及其观察者是否存在
    if (classAvailable(ANDROIDX_FRAGMENT_CLASS_NAME) &&
        classAvailable(ANDROIDX_FRAGMENT_DESTROY_WATCHER_CLASS_NAME)
    ) {
      // 反射实例化androidx Fragment的观察者并添加到里面list里面
      val watcherConstructor = Class.forName(ANDROIDX_FRAGMENT_DESTROY_WATCHER_CLASS_NAME)
          .getDeclaredConstructor(ObjectWatcher::class.java, Function0::class.java)
      @kotlin.Suppress("UNCHECKED_CAST")
      fragmentDestroyWatchers.add(
          watcherConstructor.newInstance(objectWatcher, configProvider) as (Activity) -> Unit
      )
    }

    // 如果watcher为空，则不需要进行观察了
    if (fragmentDestroyWatchers.size == 0) {
      return
    }

    // 对每个Activity里面的所有的Fragment进行观察
    application.registerActivityLifecycleCallbacks(object : Application.ActivityLifecycleCallbacks by noOpDelegate() {
      override fun onActivityCreated(
        activity: Activity,
        savedInstanceState: Bundle?
      ) {
        for (watcher in fragmentDestroyWatchers) {
          watcher(activity)
        }
      }
    })
  }

  private fun classAvailable(className: String): Boolean {
    return try {
      Class.forName(className)
      true
    } catch (e: ClassNotFoundException) {
      false
    }
  }
}

AndroidOFragmentDestroyWatcher、AndroidXFragmentDestroyWatcher两者的源码非常类似，只是针对的Fragment不同而调用的API不同而已，下面以AndroidXFragmentDestroyWatcher为例看看里面是如何实现的。

leakcanary-object-watcher-android-androidx/src/main/java/leakcanary/internal/AndroidXFragmentDestroyWatcher.kt

internal class AndroidXFragmentDestroyWatcher(
  private val objectWatcher: ObjectWatcher,
  private val configProvider: () -> Config
) : (Activity) -> Unit {

  private val fragmentLifecycleCallbacks = object : FragmentManager.FragmentLifecycleCallbacks() {

    override fun onFragmentViewDestroyed(
      fm: FragmentManager,
      fragment: Fragment
    ) {
      val view = fragment.view
      if (view != null && configProvider().watchFragmentViews) {
        objectWatcher.watch(view)
      }
    }

    override fun onFragmentDestroyed(
      fm: FragmentManager,
      fragment: Fragment
    ) {
      if (configProvider().watchFragments) {
        objectWatcher.watch(fragment)
      }
    }
  }

  override fun invoke(activity: Activity) {
    if (activity is FragmentActivity) {
      val supportFragmentManager = activity.supportFragmentManager
      supportFragmentManager.registerFragmentLifecycleCallbacks(fragmentLifecycleCallbacks, true)
    }
  }
}

实现就是向Activity的FragmentManager注册FragmentLifecycleCallbacks，这样在Fragment调用onDestroyView和onDestory之后就能观察Fragment的View或者Fragment本身了。

4.3 内存泄漏判定

现在我们来看看ObjectWatcher.watch(Any)方法，在上面一节中我们看到，Activity、Fragment的View、Fragment都是由该方法进行观察的，所以最后还是统一回到了这里。

leakcanary-object-watcher/src/main/java/leakcanary/ObjectWatcher.kt

/**
  * Identical to [watch] with an empty string reference name.
  */
@Synchronized fun watch(watchedObject: Any) {
  watch(watchedObject, "")
}

/**
  * Watches the provided [watchedObject].
  *
  * @param name A logical identifier for the watched object.
  */
@Synchronized fun watch(
  watchedObject: Any,
  name: String
) {
  if (!isEnabled()) {
    return
  }
  // 将ReferenceQueue中出现的弱引用移除
  // 这是一个出现频率很高的方法，也是内存泄漏检测的关键点之一
  removeWeaklyReachableObjects()
  val key = UUID.randomUUID()
      .toString()
  // 记下观测开始的时间
  val watchUptimeMillis = clock.uptimeMillis()
  // 这里创建了一个自定义的弱引用，且调用了基类的WeakReference<Any>(referent, referenceQueue)构造器
  // 这样的话，弱引用被回收之前会出现在ReferenceQueue中
  val reference =
    KeyedWeakReference(watchedObject, key, name, watchUptimeMillis, queue)
  SharkLog.d {
      "Watching " +
          (if (watchedObject is Class<*>) watchedObject.toString() else "instance of ${watchedObject.javaClass.name}") +
          (if (name.isNotEmpty()) " named $name" else "") +
          " with key $key"
  }

  // 将key-reference保存到map中
  watchedObjects[key] = reference
  // 主线程5秒之后执行moveToRetained(key)方法
  checkRetainedExecutor.execute {
    moveToRetained(key)
  }
}

上面这段代码便是LeakCanary的关键代码之一： 1. 将要观测的对象使用WeakReference保存起来，并在构造时传入一个ReferenceQueue，这样待观测的对象在被回收之前，会出现在ReferenceQueue中。 2. 5秒钟之后再检查一下是否出现在了引用队列中，若出现了，则没有泄露。

为什么会是5S，这里猜测与Android GC有关。在Activity.H中，收到GC_WHEN_IDLE消息时会进行Looper.myQueue().addIdleHandler(mGcIdler)，而mGcIdler最后会触发doGcIfNeeded操作，在该方法中会判断上次GC与现在时间的差值，而这个值就是MIN_TIME_BETWEEN_GCS = 5*1000。

回到上面的代码，需要了解两个方法removeWeaklyReachableObjects()与moveToRetained(key)。前者比较简单，就会将引用队列中出现的对象从map中移除，因为它们没有发生内存泄漏。但是注意一下注释，这里强调了一点：弱引用入队列发生在终结函数或者GC发生之前。

private fun removeWeaklyReachableObjects() {
  // WeakReferences are enqueued as soon as the object to which they point to becomes weakly
  // reachable. This is before finalization or garbage collection has actually happened.
  var ref: KeyedWeakReference?
  do {
    ref = queue.poll() as KeyedWeakReference?
    if (ref != null) {
      watchedObjects.remove(ref.key)
    }
  } while (ref != null)
}

然后我们接着看重头戏moveToRetained方法：

@Synchronized private fun moveToRetained(key: String) {
  removeWeaklyReachableObjects()
  val retainedRef = watchedObjects[key]
  if (retainedRef != null) {
    retainedRef.retainedUptimeMillis = clock.uptimeMillis()
    onObjectRetainedListeners.forEach { it.onObjectRetained() }
  }
}

5秒钟到了，还是先将引用队列中出现的对象从map中移除，因为它们没有内存泄漏。然后判断key还在不在map中，如果在的话，说明可能发生了内存泄漏。此时记下内存泄漏发生的时间，即更新retainedUptimeMillis字段，然后通知所有的对象，内存泄漏发生了。

我们回忆一下，此处的onObjectRetainedListeners只有一个，就是我们在Activity、Fragment的观测者安装完毕后，通知了InternalLeakCanary，而InternalLeakCanary添加了一个监听器，就是它自己。所以我们看看InternalLeakCanary.onObjectRetained()方法：

leakcanary-android-core/src/main/java/leakcanary/internal/InternalLeakCanary.kt

override fun onObjectRetained() {
  if (this::heapDumpTrigger.isInitialized) {
    heapDumpTrigger.onObjectRetained()
  }
}

跟踪一下HeapDumpTrigger.onObjectRetained()方法：

leakcanary-android-core/src/main/java/leakcanary/internal/HeapDumpTrigger.kt

fun onObjectRetained() {
  scheduleRetainedObjectCheck("found new object retained")
}

private fun scheduleRetainedObjectCheck(reason: String) {
  if (checkScheduled) {
    SharkLog.d { "Already scheduled retained check, ignoring ($reason)" }
    return
  }
  checkScheduled = true
  backgroundHandler.post {
    checkScheduled = false
    checkRetainedObjects(reason)
  }
}

private fun checkRetainedObjects(reason: String) {
  val config = configProvider()
  // A tick will be rescheduled when this is turned back on.
  if (!config.dumpHeap) {
    SharkLog.d { "No checking for retained object: LeakCanary.Config.dumpHeap is false" }
    return
  }
  SharkLog.d { "Checking retained object because $reason" }

  var retainedReferenceCount = objectWatcher.retainedObjectCount

  if (retainedReferenceCount > 0) {
    gcTrigger.runGc()
    retainedReferenceCount = objectWatcher.retainedObjectCount
  }

  if (checkRetainedCount(retainedReferenceCount, config.retainedVisibleThreshold)) return

  if (!config.dumpHeapWhenDebugging && DebuggerControl.isDebuggerAttached) {
    showRetainedCountWithDebuggerAttached(retainedReferenceCount)
    scheduleRetainedObjectCheck("debugger was attached", WAIT_FOR_DEBUG_MILLIS)
    SharkLog.d {
        "Not checking for leaks while the debugger is attached, will retry in $WAIT_FOR_DEBUG_MILLIS ms"
    }
    return
  }

  SharkLog.d { "Found $retainedReferenceCount retained references, dumping the heap" }
  val heapDumpUptimeMillis = SystemClock.uptimeMillis()
  KeyedWeakReference.heapDumpUptimeMillis = heapDumpUptimeMillis
  dismissRetainedCountNotification()
  val heapDumpFile = heapDumper.dumpHeap()
  if (heapDumpFile == null) {
    SharkLog.d { "Failed to dump heap, will retry in $WAIT_AFTER_DUMP_FAILED_MILLIS ms" }
    scheduleRetainedObjectCheck("failed to dump heap", WAIT_AFTER_DUMP_FAILED_MILLIS)
    showRetainedCountWithHeapDumpFailed(retainedReferenceCount)
    return
  }
  lastDisplayedRetainedObjectCount = 0
  objectWatcher.clearObjectsWatchedBefore(heapDumpUptimeMillis)

  HeapAnalyzerService.runAnalysis(application, heapDumpFile)
}

上面的代码就是对于内存泄漏判定的代码了，首先进入onObjectRetained方法，该方法会调用scheduleRetainedObjectCheck方法。此方法也就是在后台线程中执行checkRetainedObjects方法来检查泄漏的对象： 1. 首先获取泄漏对象的个数，如果大于0，则GC一次之后再次获取 2. 如果此时泄漏对象的个数大于等于5个config.retainedVisibleThreshold，则继续执行下面的代码，准备dump heap 3. 如果config里面配置的“调试时不允许dump heap”为false（默认值）且正在调试，则20s之后再试 4. 否则可以开始dump heap：此时会先记下dump发生的时间，取消内存泄漏通知，dump heap，清除所有观测事件小于等于dump发生时间的对象（因为这些对象已经处理完毕了），最后运行HeapAnalyzerService开始分析heap。

第26行的代码是如何获取泄露对象的个数的呢？我们想一下，在前面的代码中，主线程5秒之后执行了一段检测的代码，在这里面将所有泄露的对象都记下了当时的时间，存在retainedUptimeMillis字段里面。那么我们遍历所有元素，统计一下该字段不为默认值（-1）的个数即可：

leakcanary-object-watcher/src/main/java/leakcanary/ObjectWatcher.kt

/**
  * Returns the number of retained objects, ie the number of watched objects that aren't weakly
  * reachable, and have been watched for long enough to be considered retained.
  */
val retainedObjectCount: Int
  @Synchronized get() {
    removeWeaklyReachableObjects()
    return watchedObjects.count { it.value.retainedUptimeMillis != -1L }
  }

第29行，如果有内存泄漏的话，会调用gcTrigger.runGc()方法，这里的gcTrigger我们提到过，是GcTrigger.Default：

leakcanary/leakcanary-object-watcher/src/main/java/leakcanary/GcTrigger.kt

/**
  * Default implementation of [GcTrigger].
  */
object Default : GcTrigger {
  override fun runGc() {
    // Code taken from AOSP FinalizationTest:
    // https://android.googlesource.com/platform/libcore/+/master/support/src/test/java/libcore/
    // java/lang/ref/FinalizationTester.java
    // System.gc() does not garbage collect every time. Runtime.gc() is
    // more likely to perform a gc.
    Runtime.getRuntime()
        .gc()
    enqueueReferences()
    System.runFinalization()
  }

  private fun enqueueReferences() {
    // Hack. We don't have a programmatic way to wait for the reference queue daemon to move
    // references to the appropriate queues.
    try {
      Thread.sleep(100)
    } catch (e: InterruptedException) {
      throw AssertionError()
    }
  }
}

在上面注释中提到，System.gc()并不会每次都会执行GC，Runtime.gc()更有可能执行GC。执行一次GC操作之后，下面粗暴的等待100ms，这样有足够的时间可以让弱引用移动到合适的引用队列里面。这就是GcTrigger.Default所干的事情。

GCTrigger触发GC之后，再次判断一下发生内存泄漏的对象的个数，如果仍然还有，那么肯定是泄漏无疑了，实锤！！随后调用checkRetainedCount(retainedReferenceCount, config.retainedVisibleThreshold)方法，判断泄漏对象的个数是否达到了阈值，如果达到了则直接dump heap；否则发出一个内存泄漏的通知。

我们看一下这个方法：

private fun checkRetainedCount(
  retainedKeysCount: Int,
  retainedVisibleThreshold: Int
): Boolean {
  // lastDisplayedRetainedObjectCount默认值为0，此处我们肯定有内存泄漏，因此countChanged为true
  val countChanged = lastDisplayedRetainedObjectCount != retainedKeysCount
  // 保存下当前的内存泄漏对象的个数
  lastDisplayedRetainedObjectCount = retainedKeysCount
  // 如果内存泄漏个数为0，则说明已经处理了所有的内存泄漏
  if (retainedKeysCount == 0) {
    SharkLog.d { "No retained objects" }
    if (countChanged) {
      showNoMoreRetainedObjectNotification()
    }
    return true
  }

  // 如果泄漏个数小于5个
  if (retainedKeysCount < retainedVisibleThreshold) {
    if (applicationVisible || applicationInvisibleLessThanWatchPeriod) {
      SharkLog.d {
          "Found $retainedKeysCount retained objects, which is less than the visible threshold of $retainedVisibleThreshold"
      }
      // 展示一个内存泄漏发生的通知
      showRetainedCountBelowThresholdNotification(retainedKeysCount, retainedVisibleThreshold)
      // 2秒钟之后再次执行检查泄漏对象的方法，看看泄漏个数是否有变化
      scheduleRetainedObjectCheck(
          "Showing retained objects notification", WAIT_FOR_OBJECT_THRESHOLD_MILLIS
      )
      return true
    }
  }
  // 如果泄漏个数大于等于5个，返回false，则返回后checkRetainedObjects方法会继续执行
  // 此时就会dump heap
  return false
}

至此，我们已经知道了内存泄漏是如何判定的。

LeakCanary2往后就是如何生成hprof文件以及如何解析了

生成hprof可以使用android.os.Debug.dumpHprofData(String fileName)方法 LeakCanary2中对应代码在/leakcanary-android-core/src/main/java/leakcanary/internal/AndroidHeapDumper.kt +88
解析hprof文件，LeakCanary2使用是Shark

LeakCanary2