全新 LeakCanary 2 ! 徹底基於 Kotlin 重構升級！

時間 2019-11-06

標籤全新 leakcanary 徹底基於 kotlin 升級简体版

原文原文鏈接

大概一年之前，寫過一篇 LeakCanary 源碼解析，當時是基於 1.5.4 版本進行分析的。Square 公司在今年四月份發佈了全新的 2.0 版本，徹底使用 Kotlin 進行重構，核心原理並無太大變化，可是作了必定的性能優化。在本文中，就讓咱們經過源碼來看看 2.0 版本發生了哪些變化。本文不會過多的分析源碼細節，詳細細節能夠閱讀我以前基於 1.5.4 版本寫的文章，兩個版本在原理方面並無太大變化。java

含註釋 fork 版本 LeakCanary 源碼android

使用

首先來對比一下兩個版本的使用方式。git

1.5.4 版本

在老版本中，咱們須要添加以下依賴：github

dependencies {
  debugImplementation 'com.squareup.leakcanary:leakcanary-android:1.5.4'
  releaseImplementation 'com.squareup.leakcanary:leakcanary-android-no-op:1.5.4'
}
複製代碼

leakcanary-android-no-op 庫在 release 版本中使用，其中是沒有任何邏輯代碼的。性能優化

而後須要在本身的 Application 中進行初始化。bash

public class ExampleApplication extends Application {

  @Override public void onCreate() {
    super.onCreate();
    if (LeakCanary.isInAnalyzerProcess(this)) {
      // This process is dedicated to LeakCanary for heap analysis.
      // You should not init your app in this process.
      return;
    }
    LeakCanary.install(this);
    // Normal app init code...
  }
}
複製代碼

LeakCanary.install() 執行後，就會構建 RefWatcher 對象，開始監聽 Activity.onDestroy() 回調, 經過 RefWatcher.watch() 監測 Activity 引用的泄露狀況。發現內存泄露以後進行 heap dump ，利用 Square 公司的另外一個庫 haha（已廢棄）來分析 heap dump 文件，找到引用鏈以後通知用戶。這一套原理在新版本中仍是沒變的。微信

2.0 版本

新版本的使用更加方便了，你只須要在 build.gradle 文件中添加以下依賴：app

debugImplementation 'com.squareup.leakcanary:leakcanary-android:2.0-alpha-2'
複製代碼

是的，你沒看過，這樣就能夠了。你確定會有一個疑問，那它是如何初始化的呢？我剛看到這個使用文檔的時候，一樣也有這個疑問。當你看看源碼以後就一目瞭然了。我先不解釋，看一下源碼中的 LeakSentryInstaller 這個類：less

/** * Content providers are loaded before the application class is created. [LeakSentryInstaller] is * used to install [leaksentry.LeakSentry] on application start. * * Content Provider 在 Application 建立以前被自動加載，所以無需用戶手動在 onCrate() 中進行初始化 */
internal class LeakSentryInstaller : ContentProvider() {

  override fun onCreate(): Boolean {
    CanaryLog.logger = DefaultCanaryLog()
    val application = context!!.applicationContext as Application
    InternalLeakSentry.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
  }
}
複製代碼

看到這個類你應該也明白了。LeakCanary 利用 ContentProvier 進行了初始化。ContentProvier 通常會在 Application 被建立以前被加載，LeakCanary 在其 onCreate() 方法中調用了 InternalLeakSentry.install(application) 進行初始化。這應該是我第一次看到第三方庫這麼進行初始化。這的確是方便了開發者，可是仔細想一想弊端仍是很大的，若是全部第三方庫都這麼幹，開發者就無法控制應用啓動時間了。不少開發者爲了加快應用啓動速度，都下了很大心血，包括按需延遲初始化第三方庫。但在 LeakCanary 中，這個問題並不存在，由於它自己就是一個只在 debug 版本中使用的庫，並不會對 release 版本有任何影響。dom

源碼解析

前面提到了 InternalLeakSentry.install() 就是核心的初始化工做，其地位就和 1.5.4 版本中的 LeakCanary.install() 同樣。下面就從 install() 方法開始，走進 LeakCanary 2.0 一探究竟。

1. LeakCanary.install()

fun install(application: Application) {
    CanaryLog.d("Installing LeakSentry")
    checkMainThread() // 只能在主線程調用，不然會拋出異常
    if (this::application.isInitialized) {
      return
    }
    InternalLeakSentry.application = application

    val configProvider = { LeakSentry.config }
    ActivityDestroyWatcher.install( // 監聽 Activity.onDestroy()，見 1.1
        application, refWatcher, configProvider
    )
    FragmentDestroyWatcher.install( // 監聽 Fragment.onDestroy()，見 1.2
        application, refWatcher, configProvider
    )
    listener.onLeakSentryInstalled(application) // 見 1.3
}
複製代碼

install() 方法主要作了三件事:

註冊 Activity.onDestroy() 監聽
註冊 Fragment.onDestroy() 監聽
監聽完成後進行一些初始化工做

依次看一看。

1.1 ActivityDestroyWatcher.install()

ActivityDestroyWatcher 類的源碼很簡單：

internal class ActivityDestroyWatcher private constructor(
  private val refWatcher: RefWatcher,
  private val configProvider: () -> Config
) {

  private val lifecycleCallbacks = object : ActivityLifecycleCallbacksAdapter() {
    override fun onActivityDestroyed(activity: Activity) {
      if (configProvider().watchActivities) {
        refWatcher.watch(activity) // 監聽到 onDestroy() 以後，經過 refWatcher 監測 Activity
      }
    }
  }

  companion object {
    fun install( application: Application, refWatcher: RefWatcher, configProvider: () -> Config
    ) {
      val activityDestroyWatcher =
        ActivityDestroyWatcher(refWatcher, configProvider)
      // 註冊 Activity 生命週期監聽
      application.registerActivityLifecycleCallbacks(activityDestroyWatcher.lifecycleCallbacks) 
    }
  }
}
複製代碼

install() 方法中註冊了 Activity 生命週期監聽，在監聽到 onDestroy() 時，調用 RefWatcher.watch() 方法開始監測 Activity。

1.2 FragmentDestroyWatcher.install()

FragmentDestroyWatcher 是一個接口，它有兩個實現類 AndroidOFragmentDestroyWatcher 和 SupportFragmentDestroyWatcher。

internal interface FragmentDestroyWatcher {

  fun watchFragments(activity: Activity)

  companion object {

    private const val SUPPORT_FRAGMENT_CLASS_NAME = "androidx.fragment.app.Fragment"

    fun install( application: Application, refWatcher: RefWatcher, configProvider: () -> LeakSentry.Config
    ) {
      val fragmentDestroyWatchers = mutableListOf<FragmentDestroyWatcher>()

      if (SDK_INT >= O) { // >= 26，使用 AndroidOFragmentDestroyWatcher
        fragmentDestroyWatchers.add(
            AndroidOFragmentDestroyWatcher(refWatcher, configProvider)
        )
      }

      if (classAvailable(
              SUPPORT_FRAGMENT_CLASS_NAME
          )
      ) {
        fragmentDestroyWatchers.add( // androidx 使用 SupportFragmentDestroyWatcher
            SupportFragmentDestroyWatcher(refWatcher, configProvider)
        )
      }

      if (fragmentDestroyWatchers.size == 0) {
        return
      }

      application.registerActivityLifecycleCallbacks(object : ActivityLifecycleCallbacksAdapter() {
        override fun onActivityCreated( activity: Activity, savedInstanceState: Bundle? ) {
          for (watcher in fragmentDestroyWatchers) {
            watcher.watchFragments(activity)
          }
        }
      })
    }

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

若是我沒記錯的話，1.5.4 是不監測 Fragment 的泄露的。而 2.0 版本提供了對 Android O 以及 androidx 版本中的 Fragment 的內存泄露檢測。 AndroidOFragmentDestroyWatcher 和 SupportFragmentDestroyWatcher 的實現代碼實際上是一致的，Android O 及之後，androidx 都具有對 Fragment 生命週期的監聽功能。以 AndroidOFragmentDestroyWatcher 爲例，簡單看一下它的實現。

@RequiresApi(Build.VERSION_CODES.O) //
internal class AndroidOFragmentDestroyWatcher(
  private val refWatcher: RefWatcher,
  private val configProvider: () -> Config
) : FragmentDestroyWatcher {

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

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

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

  override fun watchFragments(activity: Activity) {
    val fragmentManager = activity.fragmentManager
    fragmentManager.registerFragmentLifecycleCallbacks(fragmentLifecycleCallbacks, true)
  }
}
複製代碼

一樣，仍是使用 RefWatcher.watch() 方法來進行監測。

1.3 listener.onLeakSentryInstalled()

onLeakSentryInstalled() 回調中會初始化一些檢測內存泄露過程當中須要的對象，以下所示：

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

    val heapDumper = AndroidHeapDumper(application, leakDirectoryProvider) // 用於 heap dump

    val gcTrigger = GcTrigger.Default // 用於手動調用 GC

    val configProvider = { LeakCanary.config } // 配置項

    val handlerThread = HandlerThread(LEAK_CANARY_THREAD_NAME)
    handlerThread.start()
    val backgroundHandler = Handler(handlerThread.looper) // 發起內存泄漏檢測的線程

    heapDumpTrigger = HeapDumpTrigger(
        application, backgroundHandler, LeakSentry.refWatcher, gcTrigger, heapDumper, configProvider
    )
    application.registerVisibilityListener { applicationVisible ->
      this.applicationVisible = applicationVisible
      heapDumpTrigger.onApplicationVisibilityChanged(applicationVisible)
    }
    addDynamicShortcut(application)
}
複製代碼

對老版本代碼熟悉的同窗，看到這些對象應該很熟悉。

heapDumper 用於確認內存泄漏以後進行 heap dump 工做。
gcTrigger 用於發現可能的內存泄漏以後手動調用 GC 確認是否真的爲內存泄露。

這兩個對象是 LeakCanary 檢測內存泄漏的核心。後面會進行詳細分析。

到這裏，整個 LeakCanary 的初始化工做就完成了。與 1.5.4 版本不一樣的是，新版本增長了對 Fragment 以及 androidx 的支持。當發生 Activity.onDestroy() ，Fragment.onFragmentViewDestroyed() , Fragment.onFragmentDestroyed() 三者之一時，RefWatcher 就開始工做了，調用其 watch() 方法開始檢測引用是否泄露。

2. RefWatcher.watch()

在看源碼以前，咱們先來看幾個後面會使用到的隊列。

/** * References passed to [watch] that haven't made it to [retainedReferences] yet. * watch() 方法傳進來的引用，還沒有斷定爲泄露 */
  private val watchedReferences = mutableMapOf<String, KeyedWeakReference>()
  /** * References passed to [watch] that we have determined to be retained longer than they should * have been. * watch() 方法傳進來的引用，已經被斷定爲泄露 */
  private val retainedReferences = mutableMapOf<String, KeyedWeakReference>()
  private val queue = ReferenceQueue<Any>() // 引用隊列，配合弱引用使用
複製代碼

經過 watch() 方法傳入的引用都會保存在 watchedReferences 中，被斷定泄露以後保存在 retainedReferences 中。注意，這裏的斷定過程不止會發生一次，已經進入隊列 retainedReferences 的引用仍有可能被移除。queue 是一個 ReferenceQueue 引用隊列，配合弱引用使用，這裏記住一句話：

弱引用一旦變得弱可達，就會當即入隊。這將在 finalization 或者 GC 以前發生。

也就是說，會被 GC 回收的對象引用，會保存在隊列 queue 中。

回頭再來看看 watch() 方法的源碼。

@Synchronized fun watch( watchedReference: Any, referenceName: String ) {
    if (!isEnabled()) {
      return
    }
    removeWeaklyReachableReferences() // 移除隊列中將要被 GC 的引用，見 2.1
    val key = UUID.randomUUID()
        .toString()
    val watchUptimeMillis = clock.uptimeMillis()
    val reference = // 構建當前引用的弱引用對象，並關聯引用隊列 queue
      KeyedWeakReference(watchedReference, key, referenceName, watchUptimeMillis, queue)
    if (referenceName != "") {
      CanaryLog.d(
          "Watching instance of %s named %s with key %s", reference.className,
          referenceName, key
      )
    } else {
      CanaryLog.d(
          "Watching instance of %s with key %s", reference.className, key
      )
    }

    watchedReferences[key] = reference // 將引用存入 watchedReferences
    checkRetainedExecutor.execute {
      moveToRetained(key) // 若是當前引用未被移除，仍在 watchedReferences 隊列中，
                          // 說明仍未被 GC，移入 retainedReferences 隊列中,暫時標記爲泄露
                          // 見 2.2
    }
  }
複製代碼

邏輯仍是比較清晰的，首先會調用 removeWeaklyReachableReferences() 方法，這個方法在整個過程當中會屢次調用。其做用是移除 watchedReferences 中將被 GC 的引用。

2.1 removeWeaklyReachableReferences()

private fun removeWeaklyReachableReferences() {
    // 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.
    // 弱引用一旦變得弱可達，就會當即入隊。這將在 finalization 或者 GC 以前發生。
    var ref: KeyedWeakReference?
    do {
      ref = queue.poll() as KeyedWeakReference? // 隊列 queue 中的對象都是會被 GC 的
      if (ref != null) {
        val removedRef = watchedReferences.remove(ref.key)
        if (removedRef == null) {
          retainedReferences.remove(ref.key)
        }
        // 移除 watchedReferences 隊列中的會被 GC 的 ref 對象，剩下的就是可能泄露的對象
      }
    } while (ref != null)
  }
複製代碼

整個過程當中會屢次調用，以確保將已經入隊 queue 的將被 GC 的對象引用移除掉，避免無謂的 heap dump 操做。而仍在 watchedReferences 隊列中的引用，則可能已經泄露，移到隊列 retainedReferences 中，這就是 moveToRetained() 方法的邏輯。代碼以下：

2.2 moveToRetained()

@Synchronized private fun moveToRetained(key: String) {
    removeWeaklyReachableReferences() // 再次調用，防止遺漏
    val retainedRef = watchedReferences.remove(key)
    if (retainedRef != null) {
      retainedReferences[key] = retainedRef
      onReferenceRetained()
    }
  }
複製代碼

這裏的 onReferenceRetained() 最後會回調到 InternalLeakCanary.kt 中。

override fun onReferenceRetained() {
    if (this::heapDumpTrigger.isInitialized) {
      heapDumpTrigger.onReferenceRetained()
    }
  }
複製代碼

調用了 HeapDumpTrigger 的 onReferenceRetained() 方法。

fun onReferenceRetained() {
    scheduleRetainedInstanceCheck("found new instance retained")
  }
  
    private fun scheduleRetainedInstanceCheck(reason: String) {
    if (checkScheduled) {
      return
    }
    checkScheduled = true
    backgroundHandler.post {
      checkScheduled = false
      checkRetainedInstances(reason) // 檢測泄露實例
    }
  }
複製代碼

checkRetainedInstances() 方法是肯定泄露的最後一個方法了。這裏會確認引用是否真的泄露，若是真的泄露，則發起 heap dump，分析 dump 文件，找到引用鏈，最後通知用戶。總體流程和老版本是一致的，但在一些細節處理，以及 dump 文件的分析上有所區別。下面仍是經過源碼來看看這些區別。

private fun checkRetainedInstances(reason: String) {
    CanaryLog.d("Checking retained instances because %s", reason)
    val config = configProvider()
    // A tick will be rescheduled when this is turned back on.
    if (!config.dumpHeap) {
      return
    }

    var retainedKeys = refWatcher.retainedKeys

    // 當前泄露實例個數小於 5 個，不進行 heap dump
    if (checkRetainedCount(retainedKeys, config.retainedVisibleThreshold)) return

    if (!config.dumpHeapWhenDebugging && DebuggerControl.isDebuggerAttached) {
      showRetainedCountWithDebuggerAttached(retainedKeys.size)
      scheduleRetainedInstanceCheck("debugger was attached", WAIT_FOR_DEBUG_MILLIS)
      CanaryLog.d(
          "Not checking for leaks while the debugger is attached, will retry in %d ms",
          WAIT_FOR_DEBUG_MILLIS
      )
      return
    }

    // 可能存在被觀察的引用將要變得弱可達，可是還未入隊引用隊列。
    // 這時候應該主動調用一次 GC，可能能夠避免一次 heap dump
    gcTrigger.runGc()

    retainedKeys = refWatcher.retainedKeys

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

    HeapDumpMemoryStore.setRetainedKeysForHeapDump(retainedKeys)

    CanaryLog.d("Found %d retained references, dumping the heap", retainedKeys.size)
    HeapDumpMemoryStore.heapDumpUptimeMillis = SystemClock.uptimeMillis()
    dismissNotification()
    val heapDumpFile = heapDumper.dumpHeap() // AndroidHeapDumper
    if (heapDumpFile == null) {
      CanaryLog.d("Failed to dump heap, will retry in %d ms", WAIT_AFTER_DUMP_FAILED_MILLIS)
      scheduleRetainedInstanceCheck("failed to dump heap", WAIT_AFTER_DUMP_FAILED_MILLIS)
      showRetainedCountWithHeapDumpFailed(retainedKeys.size)
      return
    }

    refWatcher.removeRetainedKeys(retainedKeys) // 移除已經 heap dump 的 retainedKeys

    HeapAnalyzerService.runAnalysis(application, heapDumpFile) // 分析 heap dump 文件
  }
複製代碼

首先調用 checkRetainedCount() 函數判斷當前泄露實例個數若是小於 5 個，僅僅只是給用戶一個通知，不會進行 heap dump 操做，並在 5s 後再次發起檢測。這是和老版本一個不一樣的地方。

private fun checkRetainedCount( retainedKeys: Set<String>, retainedVisibleThreshold: Int // 默認爲 5 個 ): Boolean {
    if (retainedKeys.isEmpty()) {
      CanaryLog.d("No retained instances")
      dismissNotification()
      return true
    }

    if (retainedKeys.size < retainedVisibleThreshold) {
      if (applicationVisible || applicationInvisibleLessThanWatchPeriod) {
        CanaryLog.d(
            "Found %d retained instances, which is less than the visible threshold of %d",
            retainedKeys.size,
            retainedVisibleThreshold
        )
        // 通知用戶 "App visible, waiting until 5 retained instances"
        showRetainedCountBelowThresholdNotification(retainedKeys.size, retainedVisibleThreshold)
        scheduleRetainedInstanceCheck( // 5s 後再次發起檢測
            "Showing retained instance notification", WAIT_FOR_INSTANCE_THRESHOLD_MILLIS
        )
        return true
      }
    }
    return false
  }
複製代碼

當集齊 5 個泄露實例以後，也並不會立馬進行 heap dump。而是先手動調用一次 GC。固然不是使用 System.gc()，以下所示：

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()
    }
複製代碼

那麼，爲何要進行此次 GC 呢？可能存在被觀察的引用將要變得弱可達，可是還未入隊引用隊列的狀況。這時候應該主動調用一次 GC，可能能夠避免一次額外的 heap dump 。GC 以後再次調用 checkRetainedCount() 判斷泄露實例個數。若是此時仍然知足條件，就要發起 heap dump 操做了。具體邏輯在 AndroidHeapDumper.dumpHeap() 方法中，核心方法就是下面這句代碼：

Debug.dumpHprofData(heapDumpFile.absolutePath)
複製代碼

生成 heap dump 文件以後，要刪除已經處理過的引用，

refWatcher.removeRetainedKeys(retainedKeys)
複製代碼

最後啓動一個前臺服務 HeapAnalyzerService 來分析 heap dump 文件。老版本中是使用 Square 本身的 haha 庫來解析的，這個庫已經廢棄了，Square 徹底重寫了解析庫，主要邏輯都在 moudle leakcanary-analyzer 中。這部分我尚未閱讀，就不在這裏分析了。對於新的解析器，官網是這樣介紹的：