6.2 LeakCanary 初始化过程分析
LeakCanary 的初始化工程可以概括为 2 项内容:
- 1、初始化 LeakCanary 内部分析引擎;
- 2、在 Android Framework 上注册五种 Android 泄漏场景的监控。
AppWathcer.kt
// LeakCanary 初始化 API @JvmOverloads fun manualInstall( application: Application, retainedDelayMillis: Long = TimeUnit.SECONDS.toMillis(5), watchersToInstall: List<InstallableWatcher> = appDefaultWatchers(application) ) { checkMainThread() ... // 初始化 InternalLeakCanary 内部引擎 (已简化为等价代码,后文会提到) InternalLeakCanary(application) // 注册五种 Android 泄漏场景的监控 Hook 点 watchersToInstall.forEach { it.install() } } fun appDefaultWatchers( application: Application, reachabilityWatcher: ReachabilityWatcher = objectWatcher ): List<InstallableWatcher> { // 对应 5 种 Android 泄漏场景(后文具体分析) return listOf( ActivityWatcher(application, reachabilityWatcher), FragmentAndViewModelWatcher(application, reachabilityWatcher), RootViewWatcher(reachabilityWatcher), ServiceWatcher(reachabilityWatcher) ) } 复制代码
下面展开具体分析:
初始化内容 1 - 初始化 LeakCanary 内部分析引擎: 创建 HeapDumpTrigger 触发器,并在 Android Framework 上注册前后台切换监听、前台 Activity 监听和 ObjectWatcher 的泄漏监听。
InternalLeakCanary.kt
override fun invoke(application: Application) { _application = application // 1. 检查是否运行在 debug 构建变体,否则抛出异常 checkRunningInDebuggableBuild() // 2. 注册泄漏回调,在 ObjectWathcer 判定对象发生泄漏会后回调 onObjectRetained() 方法 AppWatcher.objectWatcher.addOnObjectRetainedListener(this) // 3. 垃圾回收触发器(用于调用 Runtime.getRuntime().gc()) val gcTrigger = GcTrigger.Default // 4. 配置提供器 val configProvider = { LeakCanary.config } // 5. (主角) 创建 HeapDump 触发器 heapDumpTrigger = HeapDumpTrigger(...) // 6. App 前后台切换监听 application.registerVisibilityListener { applicationVisible -> this.applicationVisible = applicationVisible heapDumpTrigger.onApplicationVisibilityChanged(applicationVisible) } // 7. 前台 Activity 监听(用于发送 Heap Dump 进行中的全局 Toast) registerResumedActivityListener(application) // 8. 增加可视化分析报告的桌面快捷入口 addDynamicShortcut(application) } override fun onObjectRetained() = scheduleRetainedObjectCheck() fun scheduleRetainedObjectCheck() { heapDumpTrigger.scheduleRetainedObjectCheck() } 复制代码
HeapDumpTrigger.kt
// App 前后台切换状态变化回调 fun onApplicationVisibilityChanged(applicationVisible: Boolean) { if (applicationVisible) { // App 可见 applicationInvisibleAt = -1L } else { // App 不可见 applicationInvisibleAt = SystemClock.uptimeMillis() scheduleRetainedObjectCheck(delayMillis = AppWatcher.retainedDelayMillis) } } fun scheduleRetainedObjectCheck(delayMillis: Long = 0L) { // 已简化:源码此处使用时间戳拦截,避免重复 postDelayed backgroundHandler.postDelayed({ checkScheduledAt = 0 checkRetainedObjects() }, delayMillis) } 复制代码
初始化内容 2 - 在 Android Framework 中注入对五种 Android 泄漏场景的监控: 实现在对象的使用生命周期结束后,自动将对象交给 ObjectWatcher
进行监控。
以下为 5 种 Android 泄漏场景的监控原理分析:
- 1、Activity 监控: 通过
Application#registerActivityLifecycleCallbacks(…)
接口监听 Activity#onDestroy 事件,将当前 Activity 对象交给 ObjectWatcher 监控;
ActivityWatcher.kt
private val lifecycleCallbacks = object : Application.ActivityLifecycleCallbacks by noOpDelegate() { override fun onActivityDestroyed(activity: Activity) { // reachabilityWatcher 即 ObjectWatcher reachabilityWatcher.expectWeaklyReachable(activity /*被监控对象*/, "${activity::class.java.name} received Activity#onDestroy() callback") } } 复制代码
- 2、Fragment 与 Fragment View 监控: 通过
FragmentAndViewModelWatcher
实现,首先是通过Application#registerActivityLifecycleCallbacks(…)
接口监听 Activity#onCreate 事件,再通过FragmentManager#registerFragmentLifecycleCallbacks(…)
接口监听 Fragment 的生命周期:
FragmentAndViewModelWatcher.kt
// fragmentDestroyWatchers 是一个 Lambda 表达式数组 // 对应原生、AndroidX 和 Support 三个版本 Fragment 的 Hook 工具 private val fragmentDestroyWatchers: List<(Activity) -> Unit> = 略... private val lifecycleCallbacks = object : Application.ActivityLifecycleCallbacks by noOpDelegate() { override fun onActivityCreated(activity: Activity, savedInstanceState: Bundle?) { for (watcher in fragmentDestroyWatchers) { // 最终调用到下文的 invokde() 方法 watcher(activity) } } } 复制代码
以 AndroidX Fragment 为例:
AndroidXFragmentDestroyWatcher.kt
override fun invoke(activity: Activity) { // 这里在 Activity#onCreate 状态执行: if (activity is FragmentActivity) { val supportFragmentManager = activity.supportFragmentManager // 注册 Fragment 生命周期监听 supportFragmentManager.registerFragmentLifecycleCallbacks(fragmentLifecycleCallbacks, true) // 注册 Activity 级别 ViewModel Hook ViewModelClearedWatcher.install(activity, reachabilityWatcher) } } private val fragmentLifecycleCallbacks = object : FragmentManager.FragmentLifecycleCallbacks() { override fun onFragmentCreated(fm: FragmentManager, fragment: Fragment, savedInstanceState: Bundle?) { // 注册 Fragment 级别 ViewModel Hook ViewModelClearedWatcher.install(fragment, reachabilityWatcher) } override fun onFragmentViewDestroyed(fm: FragmentManager, fragment: Fragment) { // reachabilityWatcher 即 ObjectWatcher reachabilityWatcher.expectWeaklyReachable(fragment.view /*被监控对象*/, "${fragment::class.java.name} received Fragment#onDestroyView() callback " + "(references to its views should be cleared to prevent leaks)") } override fun onFragmentDestroyed(fm: FragmentManager, fragment: Fragment) { // reachabilityWatcher 即 ObjectWatcher reachabilityWatcher.expectWeaklyReachable(fragment /*被监控对象*/, "${fragment::class.java.name} received Fragment#onDestroy() callback") } } 复制代码
- 3、ViewModel 监控: 由于 Android Framework 未提供设置 ViewModel#onClear() 全局监听的方法,所以 LeakCanary 是通过 Hook 的方式实现。即:在 Activity#onCreate 和 Fragment#onCreate 事件中实例化一个自定义ViewModel,在进入 ViewModel#onClear() 方法时,通过反射获取当前作用域中所有的 ViewModel 对象交给 ObjectWatcher 监控。
ViewModelClearedWatcher.kt
// ViewModel 的子类 internal class ViewModelClearedWatcher( storeOwner: ViewModelStoreOwner, private val reachabilityWatcher: ReachabilityWatcher ) : ViewModel() { // 反射获取 ViewModelStore 中的 ViewModel 映射表,即可获取当前作用域所有 ViewModel 对象 private val viewModelMap: Map<String, ViewModel>? = try { val mMapField = ViewModelStore::class.java.getDeclaredField("mMap") mMapField.isAccessible = true mMapField[storeOwner.viewModelStore] as Map<String, ViewModel> } catch (ignored: Exception) { null } override fun onCleared() { // 遍历当前作用域所有 ViewModel 对象 viewModelMap?.values?.forEach { viewModel -> // reachabilityWatcher 即 ObjectWatcher reachabilityWatcher.expectWeaklyReachable(viewModel /*被监控对象*/, "${viewModel::class.java.name} received ViewModel#onCleared() callback") } } companion object { // 直接在 storeOwner 作用域实例化 ViewModelClearedWatcher 对象 fun install(storeOwner: ViewModelStoreOwner, reachabilityWatcher: ReachabilityWatcher) { val provider = ViewModelProvider(storeOwner, object : Factory { override fun <T : ViewModel?> create(modelClass: Class<T>): T = ViewModelClearedWatcher(storeOwner, reachabilityWatcher) as T }) provider.get(ViewModelClearedWatcher::class.java) } } } 复制代码
- 4、Service 监控: 由于 Android Framework 未提供设置 Service#onDestroy() 全局监听的方法,所以 LeakCanary 是通过 Hook 的方式实现的。
Service 监控这部分源码比较复杂了,需要通过 2 步 Hook 来实现:
- 1、Hook 主线程消息循环的
mH.mCallback
回调,监听其中的 STOP_SERVICE 消息,将即将 Destroy 的 Service 对象暂存起来(由于 ActivityThread.H 中没有 DESTROY_SERVICE 消息,所以不能直接监听到 onDestroy() 事件,需要第 2 步); - 2、使用动态代理 Hook AMS 与 App 通信的的
IActivityManager
Binder 对象,代理其中的serviceDoneExecuting()
方法,视为 Service#onDestroy() 的执行时机,拿到暂存的 Service 对象交给 ObjectWatcher 监控。
源码摘要如下:
ServiceWatcher.kt
private var uninstallActivityThreadHandlerCallback: (() -> Unit)? = null // 暂存即将 Destroy 的 Service private val servicesToBeDestroyed = WeakHashMap<IBinder, WeakReference<Service>>() override fun install() { // 1. Hook mH.mCallback swapActivityThreadHandlerCallback { mCallback /*原对象*/ -> // uninstallActivityThreadHandlerCallback:用于取消 Hook uninstallActivityThreadHandlerCallback = { swapActivityThreadHandlerCallback { mCallback } } // 新对象(lambda 表达式的末行就是返回值) Handler.Callback { msg -> // 1.1 Service#onStop() 事件 if (msg.what == STOP_SERVICE) { val key = msg.obj as IBinder // 1.2 activityThreadServices:反射获取 ActivityThread mServices 映射表 <IBinder, CreateServiceData> activityThreadServices[key]?.let { // 1.3 暂存即将 Destroy 的 Service servicesToBeDestroyed[token] = WeakReference(service) } } // 1.4 继续执行 Framework 原有逻辑 mCallback?.handleMessage(msg) ?: false } } // 2. Hook AMS IActivityManager swapActivityManager { activityManagerInterface, activityManagerInstance /*原对象*/ -> // uninstallActivityManager:用于取消 Hook uninstallActivityManager = { swapActivityManager { _, _ -> activityManagerInstance } } // 新对象(lambda 表达式的末行就是返回值) Proxy.newProxyInstance(activityManagerInterface.classLoader, arrayOf(activityManagerInterface)) { _, method, args -> // 2.1 代理 serviceDoneExecuting() 方法 if (METHOD_SERVICE_DONE_EXECUTING == method.name) { // 2.2 取出暂存的即将 Destroy 的 Service val token = args!![0] as IBinder if (servicesToBeDestroyed.containsKey(token)) { servicesToBeDestroyed.remove(token)?.also { serviceWeakReference -> // 2.3 交给 ObjectWatcher 监控 serviceWeakReference.get()?.let { service -> reachabilityWatcher.expectWeaklyReachable(service /*被监控对象*/, "${service::class.java.name} received Service#onDestroy() callback") } } } } // 2.4 继续执行 Framework 原有逻辑 method.invoke(activityManagerInstance, *args) } } } override fun uninstall() { // 关闭 mH.mCallback 的 Hook uninstallActivityManager?.invoke() uninstallActivityThreadHandlerCallback?.invoke() uninstallActivityManager = null uninstallActivityThreadHandlerCallback = null } // 使用反射修改 ActivityThread 的主线程消息循环的 mH.mCallback // swap 是一个 lambda 表达式,参数为原对象,返回值为注入的新对象 private fun swapActivityThreadHandlerCallback(swap: (Handler.Callback?) -> Handler.Callback?) { val mHField = activityThreadClass.getDeclaredField("mH").apply { isAccessible = true } val mH = mHField[activityThreadInstance] as Handler val mCallbackField = Handler::class.java.getDeclaredField("mCallback").apply { isAccessible = true } val mCallback = mCallbackField[mH] as Handler.Callback? // 将 swap 的返回值作为新对象,实现 Hook mCallbackField[mH] = swap(mCallback) } // 使用反射修改 AMS 与 App 通信的 IActivityManager Binder 对象 // swap 是一个 lambda 表达式,参数为 IActivityManager 的 Class 对象和接口原实现对象,返回值为注入的新对象 private fun swapActivityManager(swap: (Class<*>, Any) -> Any) { val singletonClass = Class.forName("android.util.Singleton") val mInstanceField = singletonClass.getDeclaredField("mInstance").apply { isAccessible = true } val singletonGetMethod = singletonClass.getDeclaredMethod("get") val (className, fieldName) = if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O) { "android.app.ActivityManager" to "IActivityManagerSingleton" } else { "android.app.ActivityManagerNative" to "gDefault" } val activityManagerClass = Class.forName(className) val activityManagerSingletonField = activityManagerClass.getDeclaredField(fieldName).apply { isAccessible = true } val activityManagerSingletonInstance = activityManagerSingletonField[activityManagerClass] // Calling get() instead of reading from the field directly to ensure the singleton is // created. val activityManagerInstance = singletonGetMethod.invoke(activityManagerSingletonInstance) val iActivityManagerInterface = Class.forName("android.app.IActivityManager") // 将 swap 的返回值作为新对象,实现 Hook mInstanceField[activityManagerSingletonInstance] = swap(iActivityManagerInterface, activityManagerInstance!!) } 复制代码
- 5、RootView 监控: 由于 Android Framework 未提供设置全局监听 RootView 从 WindowManager 中移除的方法,所以 LeakCanary 是通过 Hook 的方式实现的,这一块是通过 squareup 另一个开源库
curtains
实现的。
RootView 监控这部分源码也比较复杂了,需要通过 2 步 Hook 来实现:
- 1、Hook WMS 服务内部的
WindowManagerGlobal.mViews
RootView 列表,获取 RootView 新增和移除的时机; - 2、检查 View 对应的 Window 类型,如果是 Dialog 或 DreamService 等类型,则在注册
View#addOnAttachStateChangeListener()
监听,在其中的 onViewDetachedFromWindow() 回调中将 View 对象交给 ObjectWatcher 监控。
LeakCanary 源码摘要如下:
RootViewWatcher.kt
override fun install() { // 1. 注册 RootView 监听 Curtains.onRootViewsChangedListeners += listener } private val listener = OnRootViewAddedListener { rootView -> val trackDetached = when(rootView.windowType) { PHONE_WINDOW -> { when (rootView.phoneWindow?.callback?.wrappedCallback) { // Activity 类型已经在 ActivityWatcher 中监控了,不需要重复监控 is Activity -> false is Dialog -> { // leak_canary_watcher_watch_dismissed_dialogs:Dialog 监控开关 val resources = rootView.context.applicationContext.resources resources.getBoolean(R.bool.leak_canary_watcher_watch_dismissed_dialogs) } // DreamService 屏保等 else -> true } } POPUP_WINDOW -> false TOOLTIP, TOAST, UNKNOWN -> true } if (trackDetached) { // 2. 注册 View#addOnAttachStateChangeListener 监听 rootView.addOnAttachStateChangeListener(object : OnAttachStateChangeListener { val watchDetachedView = Runnable { // 3. 交给 ObjectWatcher 监控 reachabilityWatcher.expectWeaklyReachable(rootView /*被监控对象*/ , "${rootView::class.java.name} received View#onDetachedFromWindow() callback") } override fun onViewAttachedToWindow(v: View) { mainHandler.removeCallbacks(watchDetachedView) } override fun onViewDetachedFromWindow(v: View) { mainHandler.post(watchDetachedView) } }) } } 复制代码
curtains 源码摘要如下:
RootViewsSpy.kt
private val delegatingViewList = object : ArrayList<View>() { // 重写 ArrayList#add 方法 override fun add(element: View): Boolean { // 回调 listeners.forEach { it.onRootViewsChanged(element, true) } return super.add(element) } // 重写 ArrayList#removeAt 方法 override fun removeAt(index: Int): View { // 回调 val removedView = super.removeAt(index) listeners.forEach { it.onRootViewsChanged(removedView, false) } return removedView } } companion object { fun install(): RootViewsSpy { return RootViewsSpy().apply { WindowManagerSpy.swapWindowManagerGlobalMViews { mViews /*原对象*/ -> // 新对象(lambda 表达式的末行就是返回值) delegatingViewList.apply { addAll(mViews) } } } } } 复制代码
WindowManageSpy.kt
// Hook WMS 服务内部的 WindowManagerGlobal.mViews RootView 列表 // swap 是一个 lambda 表达式,参数为原对象,返回值为注入的新对象 fun swapWindowManagerGlobalMViews(swap: (ArrayList<View>) -> ArrayList<View>) { windowManagerInstance?.let { windowManagerInstance -> mViewsField?.let { mViewsField -> val mViews = mViewsField[windowManagerInstance] as ArrayList<View> mViewsField[windowManagerInstance] = swap(mViews) } } } 复制代码
至此,LeakCanary 初始化完成,并且成功在 Android Framework 的各个位置安插监控,实现对 Activity 和 Service 等对象进入无用状态的监听。我们可以用一张示意图描述 LeakCanary 的部分结构:
6.3 LeakCanary 如何判定对象泄漏?
在以上步骤中,当对象的使用生命周期结束后,会交给 ObjectWatcher
监控,现在我们来具体看下它是怎么判断对象发生泄漏的。主要逻辑概括为 3 步:
- 第 1 步: 为被监控对象
watchedObject
创建一个KeyedWeakReference
弱引用,并存储到 <UUID, KeyedWeakReference> 的映射表中; - 第 2 步: postDelay 五秒后检查引用对象是否出现在引用队列中,出现在队列则说明被监控对象未发生泄漏。随后,移除映射表中未泄露的记录,更新泄漏的引用对象的
retainedUptimeMillis
字段以标记为泄漏; - 第 3 步: 通过回调
onObjectRetained
告知 LeakCanary 内部发生新的内存泄漏。
源码摘要如下:
AppWatcher.kt
val objectWatcher = ObjectWatcher( // lambda 表达式获取当前系统时间 clock = { SystemClock.uptimeMillis() }, // lambda 表达式实现 Executor SAM 接口 checkRetainedExecutor = { mainHandler.postDelayed(it, retainedDelayMillis) }, // lambda 表达式获取监控开关 isEnabled = { true } ) 复制代码
ObjectWatcher.kt
class ObjectWatcher constructor( private val clock: Clock, private val checkRetainedExecutor: Executor, private val isEnabled: () -> Boolean = { true } ) : ReachabilityWatcher { if (!isEnabled()) { // 监控开关 return } // 被监控的对象映射表 <UUID,KeyedWeakReference> private val watchedObjects = mutableMapOf<String, KeyedWeakReference>() // KeyedWeakReference 关联的引用队列,用于判断对象是否泄漏 private val queue = ReferenceQueue<Any>() // 1. 为 watchedObject 对象增加监控 @Synchronized override fun expectWeaklyReachable( watchedObject: Any, description: String ) { // 1.1 移除 watchedObjects 中未泄漏的引用对象 removeWeaklyReachableObjects() // 1.2 新建一个 KeyedWeakReference 引用对象 val key = UUID.randomUUID().toString() val watchUptimeMillis = clock.uptimeMillis() watchedObjects[key] = KeyedWeakReference(watchedObject, key, description, watchUptimeMillis, queue) // 2. 五秒后检查引用对象是否出现在引用队列中,否则判定发生泄漏 // checkRetainedExecutor 相当于 postDelay 五秒后执行 moveToRetained() 方法 checkRetainedExecutor.execute { moveToRetained(key) } } // 2. 五秒后检查引用对象是否出现在引用队列中,否则说明发生泄漏 @Synchronized private fun moveToRetained(key: String) { // 2.1 移除 watchedObjects 中未泄漏的引用对象 removeWeaklyReachableObjects() // 2.2 依然存在的引用对象被判定发生泄漏 val retainedRef = watchedObjects[key] if (retainedRef != null) { retainedRef.retainedUptimeMillis = clock.uptimeMillis() // 3. 回调通知 LeakCanary 内部处理 onObjectRetainedListeners.forEach { it.onObjectRetained() } } } // 移除未泄漏对象对应的 KeyedWeakReference private fun removeWeaklyReachableObjects() { var ref: KeyedWeakReference? do { ref = queue.poll() as KeyedWeakReference? if (ref != null) { // KeyedWeakReference 出现在引用队列中,说明未发生泄漏 watchedObjects.remove(ref.key) } } while (ref != null) } // 4. Heap Dump 后移除所有监控时间早于 heapDumpUptimeMillis 的引用对象 @Synchronized fun clearObjectsWatchedBefore(heapDumpUptimeMillis: Long) { val weakRefsToRemove = watchedObjects.filter { it.value.watchUptimeMillis <= heapDumpUptimeMillis } weakRefsToRemove.values.forEach { it.clear() } watchedObjects.keys.removeAll(weakRefsToRemove.keys) } // 获取是否有内存泄漏对象 val hasRetainedObjects: Boolean @Synchronized get() { // 移除 watchedObjects 中未泄漏的引用对象 removeWeaklyReachableObjects() return watchedObjects.any { it.value.retainedUptimeMillis != -1L } } // 获取内存泄漏对象计数 val retainedObjectCount: Int @Synchronized get() { // 移除 watchedObjects 中未泄漏的引用对象 removeWeaklyReachableObjects() return watchedObjects.count { it.value.retainedUptimeMillis != -1L } } } 复制代码
被监控对象 watchedObject
关联的弱引用对象:
KeyedWeakReference.kt
class KeyedWeakReference( // 被监控对象 referent: Any, // 唯一 Key,根据此字段匹配映射表中的记录 val key: String, // 描述信息 val description: String, // 监控开始时间,即引用对象创建时间 val watchUptimeMillis: Long, // 关联的引用队列 referenceQueue: ReferenceQueue<Any> ) : WeakReference<Any>(referent, referenceQueue) { // 记录实际对象 referent 被判定为泄漏对象的时间 // -1L 表示非泄漏对象,或者还未判定完成 @Volatile var retainedUptimeMillis = -1L override fun clear() { super.clear() retainedUptimeMillis = -1L } companion object { // 记录最近一次触发 Heap Dump 的时间 @Volatile @JvmStatic var heapDumpUptimeMillis = 0L } } 复制代码
6.4 LeakCanary 发现泄漏对象后就会触发分析吗?
ObjectWatcher 判定被监控对象发生泄漏后,会通过接口方法 OnObjectRetainedListener#onObjectRetained()
回调到 LeakCanary 内部的管理器 InternalLeakCanary 处理(在前文 AppWatcher 初始化中提到过)。LeakCanary 不会每次发现内存泄漏对象都进行分析工作,而会进行两个拦截:
- 拦截 1:泄漏对象计数未达到阈值,或者进入后台时间未达到阈值;
- 拦截 2:计算距离上一次 HeapDump 未超过 60s。
源码摘要如下:
InternalLeakCanary.kt
// 从 ObjectWatcher 回调过来 override fun onObjectRetained() = scheduleRetainedObjectCheck() private lateinit var heapDumpTrigger: HeapDumpTrigger fun scheduleRetainedObjectCheck() { if (this::heapDumpTrigger.isInitialized) { heapDumpTrigger.scheduleRetainedObjectCheck() } } 复制代码
HeapDumpTrigger.kt
fun scheduleRetainedObjectCheck(delayMillis: Long = 0L) { // 已简化:源码此处使用时间戳拦截,避免重复 postDelayed backgroundHandler.postDelayed({ checkRetainedObjects() }, delayMillis) } private fun checkRetainedObjects() { val config = configProvider() // 泄漏对象计数 var retainedReferenceCount = objectWatcher.retainedObjectCount if (retainedReferenceCount > 0) { // 主动触发 GC,并等待 100 ms gcTrigger.runGc() // 重新获取泄漏对象计数 retainedReferenceCount = objectWatcher.retainedObjectCount } // 拦截 1:泄漏对象计数未达到阈值,或者进入后台时间未达到阈值 if (retainedKeysCount < retainedVisibleThreshold) { // App 位于前台或者刚刚进入后台 if (applicationVisible || applicationInvisibleLessThanWatchPeriod) { // 发送通知提醒 showRetainedCountNotification("App visible, waiting until %d retained objects") // 延迟 2 秒再检查 scheduleRetainedObjectCheck(WAIT_FOR_OBJECT_THRESHOLD_MILLIS) return; } } // 拦截 2:计算距离上一次 HeapDump 未超过 60s val now = SystemClock.uptimeMillis() val elapsedSinceLastDumpMillis = now - lastHeapDumpUptimeMillis if (elapsedSinceLastDumpMillis < WAIT_BETWEEN_HEAP_DUMPS_MILLIS) { // 发送通知提醒 showRetainedCountNotification("Last heap dump was less than a minute ago") // 延迟 (60 - elapsedSinceLastDumpMillis)s 再检查 scheduleRetainedObjectCheck(WAIT_BETWEEN_HEAP_DUMPS_MILLIS - elapsedSinceLastDumpMillis) return } // 移除通知提醒 dismissRetainedCountNotification() // 触发 HeapDump(此时,应用有可能在后台) dumpHeap(...) } // 真正开始执行 Heap Dump private fun dumpHeap(...) { // 1. 获取文件存储提供器 val directoryProvider = InternalLeakCanary.createLeakDirectoryProvider(InternalLeakCanary.application) // 2. 创建 .hprof File 文件 val heapDumpFile = directoryProvider.newHeapDumpFile() // 3. 执行 Heap Dump // Heap Dump 开始时间戳 val heapDumpUptimeMillis = SystemClock.uptimeMillis() // heapDumper.dumpHeap:最终调用 Debug.dumpHprofData(heapDumpFile.absolutePath) configProvider().heapDumper.dumpHeap(heapDumpFile) // 4. 清除 ObjectWatcher 中过期的监控 objectWatcher.clearObjectsWatchedBefore(heapDumpUptimeMillis) // 5. 分析堆快照 InternalLeakCanary.sendEvent(HeapDump(currentEventUniqueId!!, heapDumpFile, durationMillis, reason)) } 复制代码
请求 GC 的源码可以看一眼:
GcTrigger.kt
fun interface GcTrigger { fun runGc() object Default : GcTrigger { override fun runGc() { // Runtime.gc() 相比于 System.gc() 更有可能触发 GC Runtime.getRuntime().gc() // 暂停等待 GC Thread.sleep(100) System.runFinalization() } } } 复制代码
6.5 LeakCanary 在哪个线程分析堆快照?
在前面的工作中,LeakCanary 已经成功生成 .hprof
堆快照文件,并且发送了一个 LeakCanary 内部事件 HeapDump
。那么这个事件在哪里被消费的呢?
一步步跟踪代码可以看到 LeakCanary 的配置项中设置了多个事件消费者 EventListener,其中与 HeapDump 事件有关的是 when{}
代码块中三个消费者。不过,这三个消费者并不是并存的,而是会根据 App 当前的依赖项而选择最优的执行策略:
- 策略 1 - WorkerManager 多进程分析
- 策略 2 - WorkManager 异步分析
- 策略 3 - 异步线程分析(兜底策略)
LeakCanary 配置项中的事件消费者:
LeakCanary.kt
data class Config( val eventListeners: List<EventListener> = listOf( LogcatEventListener, ToastEventListener, LazyForwardingEventListener { if (InternalLeakCanary.formFactor == TV) TvEventListener else NotificationEventListener }, when { // 策略 1 - WorkerManager 多进程分析 RemoteWorkManagerHeapAnalyzer.remoteLeakCanaryServiceInClasspath ->RemoteWorkManagerHeapAnalyzer // 策略 2 - WorkManager 异步分析 WorkManagerHeapAnalyzer.validWorkManagerInClasspath -> WorkManagerHeapAnalyzer // 策略 3 - 异步线程分析(兜底策略) else -> BackgroundThreadHeapAnalyzer } ), ... ) 复制代码
- 策略 1 - WorkerManager 多进程分析: 判断是否可以类加载
RemoteLeakCanaryWorkerService
,这个类位于前文提到的com.squareup.leakcanary:leakcanary-android-process:2.9.1
依赖中。如果可以类加载成功则视为有依赖,使用 WorkerManager 多进程分析;
RemoteWorkManagerHeapAnalyzer.kt
object RemoteWorkManagerHeapAnalyzer : EventListener { // 通过类加载是否成功,判断是否存在依赖 internal val remoteLeakCanaryServiceInClasspath by lazy { try { Class.forName("leakcanary.internal.RemoteLeakCanaryWorkerService") true } catch (ignored: Throwable) { false } } override fun onEvent(event: Event) { if (event is HeapDump) { // 创建并分发 WorkManager 多进程请求 val heapAnalysisRequest = OneTimeWorkRequest.Builder(RemoteHeapAnalyzerWorker::class.java).apply { val dataBuilder = Data.Builder() .putString(ARGUMENT_PACKAGE_NAME, application.packageName) .putString(ARGUMENT_CLASS_NAME, REMOTE_SERVICE_CLASS_NAME) setInputData(event.asWorkerInputData(dataBuilder)) with(WorkManagerHeapAnalyzer) { addExpeditedFlag() } }.build() WorkManager.getInstance(application).enqueue(heapAnalysisRequest) } } } 复制代码
RemoteHeapAnalyzerWorker.kt
internal class RemoteHeapAnalyzerWorker(appContext: Context, workerParams: WorkerParameters) : RemoteListenableWorker(appContext, workerParams) { override fun startRemoteWork(): ListenableFuture<Result> { val heapDump = inputData.asEvent<HeapDump>() val result = SettableFuture.create<Result>() heapAnalyzerThreadHandler.post { // 1.1 分析堆快照 val doneEvent = AndroidDebugHeapAnalyzer.runAnalysisBlocking(heapDump, isCanceled = { result.isCancelled }) { progressEvent -> // 1.2 发送分析进度事件 if (!result.isCancelled) { InternalLeakCanary.sendEvent(progressEvent) } } // 1.3 发送分析完成事件 InternalLeakCanary.sendEvent(doneEvent) result.set(Result.success()) } return result } } 复制代码
- 策略 2 - WorkManager 异步分析: 判断是否可以类加载
androidx.work.WorkManager
,如果可以,则使用 WorkManager 异步分析;
WorkManagerHeapAnalyzer.kt
internal val validWorkManagerInClasspath by lazy { // 判断 WorkManager 依赖,代码略 } override fun onEvent(event: Event) { if (event is HeapDump) { // 创建并分发 WorkManager 请求 val heapAnalysisRequest = OneTimeWorkRequest.Builder(HeapAnalyzerWorker::class.java).apply { setInputData(event.asWorkerInputData()) addExpeditedFlag() }.build() val application = InternalLeakCanary.application WorkManager.getInstance(application).enqueue(heapAnalysisRequest) } } 复制代码
HeapAnalyzerWorker.kt
internal class HeapAnalyzerWorker(appContext: Context, workerParams: WorkerParameters) : Worker(appContext, workerParams) { override fun doWork(): Result { // 2.1 分析堆快照 val doneEvent = AndroidDebugHeapAnalyzer.runAnalysisBlocking(inputData.asEvent()) { event -> // 2.2 发送分析进度事件 InternalLeakCanary.sendEvent(event) } // 2.3 发送分析完成事件 InternalLeakCanary.sendEvent(doneEvent) return Result.success() } } 复制代码
- 策略 3 - 异步线程分析(兜底策略): 如果以上策略未命中,则直接使用子线程兜底执行。
BackgroundThreadHeapAnalyzer.kt
object BackgroundThreadHeapAnalyzer : EventListener { // HandlerThread internal val heapAnalyzerThreadHandler by lazy { val handlerThread = HandlerThread("HeapAnalyzer") handlerThread.start() Handler(handlerThread.looper) } override fun onEvent(event: Event) { if (event is HeapDump) { // HandlerThread 请求 heapAnalyzerThreadHandler.post { // 3.1 分析堆快照 val doneEvent = AndroidDebugHeapAnalyzer.runAnalysisBlocking(event) { event -> // 3.2 发送分析进度事件 InternalLeakCanary.sendEvent(event) } // 3.3 发送分析完成事件 InternalLeakCanary.sendEvent(doneEvent) } } } } 复制代码
可以看到,不管采用那种执行策略,最终执行的逻辑都是一样的:
- 1、分析堆快照;
- 2、发送分析进度事件;
- 3、发送分析完成事件。
6.5 LeakCanary 如何分析堆快照?
在前面的分析中,我们已经知道 LeakCanary 是通过子线程或者子进程执行 AndroidDebugHeapAnalyzer.runAnalysisBlocking
方法来分析堆快照的,并在分析过程中和分析完成后发送回调事件。现在我们来阅读 LeakCanary 的堆快照分析过程:
AndroidDebugHeapAnalyzer.kt
fun runAnalysisBlocking( heapDumped: HeapDump, isCanceled: () -> Boolean = { false }, progressEventListener: (HeapAnalysisProgress) -> Unit ): HeapAnalysisDone<*> { ... // 1. .hprof 文件 val heapDumpFile = heapDumped.file // 2. 分析堆快照 val heapAnalysis = analyzeHeap(heapDumpFile, progressListener, isCanceled) val analysisDoneEvent = ScopedLeaksDb.writableDatabase(application) { db -> // 3. 将分析报告持久化到 DB val id = HeapAnalysisTable.insert(db, heapAnalysis) // 4. 发送分析完成事件(返回到上一级进行发送:InternalLeakCanary.sendEvent(doneEvent)) val showIntent = LeakActivity.createSuccessIntent(application, id) val leakSignatures = fullHeapAnalysis.allLeaks.map { it.signature }.toSet() val leakSignatureStatuses = LeakTable.retrieveLeakReadStatuses(db, leakSignatures) val unreadLeakSignatures = leakSignatureStatuses.filter { (_, read) -> !read}.keys.toSet() HeapAnalysisSucceeded(heapDumped.uniqueId, fullHeapAnalysis, unreadLeakSignatures ,showIntent) } return analysisDoneEvent } 复制代码
核心分析方法是 analyzeHeap(…)
,继续往下走:
AndroidDebugHeapAnalyzer.kt
private fun analyzeHeap( heapDumpFile: File, progressListener: OnAnalysisProgressListener, isCanceled: () -> Boolean ): HeapAnalysis { ... // Shark 堆快照分析器 val heapAnalyzer = HeapAnalyzer(progressListener) ... // 构建对象图信息 val sourceProvider = ConstantMemoryMetricsDualSourceProvider(ThrowingCancelableFileSourceProvider(heapDumpFile) val graph = sourceProvider.openHeapGraph(proguardMapping = proguardMappingReader?.readProguardMapping()) ... // 开始分析 heapAnalyzer.analyze( heapDumpFile = heapDumpFile, graph = graph, leakingObjectFinder = config.leakingObjectFinder, // 默认是 KeyedWeakReferenceFinder referenceMatchers = config.referenceMatchers, // 默认是 AndroidReferenceMatchers computeRetainedHeapSize = config.computeRetainedHeapSize, // 默认是 true objectInspectors = config.objectInspectors, // 默认是 AndroidObjectInspectors metadataExtractor = config.metadataExtractor // 默认是 AndroidMetadataExtractor ) } 复制代码
开始进入 Shark 组件:
shark.HeapAnalyzer.kt
// analyze -> analyze -> FindLeakInput.analyzeGraph private fun FindLeakInput.analyzeGraph( metadataExtractor: MetadataExtractor, leakingObjectFinder: LeakingObjectFinder, heapDumpFile: File, analysisStartNanoTime: Long ): HeapAnalysisSuccess { ... // 1. 在堆快照中寻找泄漏对象,默认是寻找 KeyedWeakReference 类型对象 // leakingObjectFinder 默认是 KeyedWeakReferenceFinder val leakingObjectIds = leakingObjectFinder.findLeakingObjectIds(graph) // 2. 分析泄漏对象的最短引用链,并按照应用链签名分类 // applicationLeaks: Application Leaks // librbuildLeakTracesaryLeaks:Library Leaks // unreachableObjects:LeakCanary 无法分析出强引用链,可以提 Stack Overflow val (applicationLeaks, libraryLeaks, unreachableObjects) = findLeaks(leakingObjectIds) // 3. 返回分析完成事件 return HeapAnalysisSuccess(...) } private fun FindLeakInput.findLeaks(leakingObjectIds: Set<Long>): LeaksAndUnreachableObjects { // PathFinder:引用链分析器 val pathFinder = PathFinder(graph, listener, referenceReader, referenceMatchers) // pathFindingResults:完整引用链 val pathFindingResults = pathFinder.findPathsFromGcRoots(leakingObjectIds, computeRetainedHeapSize) // unreachableObjects:LeakCanary 无法分析出强引用链(相当于 LeakCanary 的 Bug) val unreachableObjects = findUnreachableObjects(pathFindingResults, leakingObjectIds) // shortestPaths:最短引用链 val shortestPaths = deduplicateShortestPaths(pathFindingResults.pathsToLeakingObjects) // inspectedObjectsByPath:标记信息 val inspectedObjectsByPath = inspectObjects(shortestPaths) // retainedSizes:泄漏内存大小 val retainedSizes = computeRetainedSizes(inspectedObjectsByPath, pathFindingResults.dominatorTree) // 生成单个泄漏问题的分析报告,并按照应用链签名分组,按照 Application Leaks 和 Library Leaks 分类,按照 Application Leaks 和 Library Leaks 分类 // applicationLeaks: Application Leaks // librbuildLeakTracesaryLeaks:Library Leaks val (applicationLeaks, librbuildLeakTracesaryLeaks) = buildLeakTraces(shortestPaths, inspectedObjectsByPath, retainedSizes) return LeaksAndUnreachableObjects(applicationLeaks, libraryLeaks, unreachableObjects) } 复制代码
可以看到,堆快照分析最终是交给 Shark 中的 HeapAnalizer 完成的,核心流程是:
- 1、在堆快照中寻找泄漏对象,默认是寻找 KeyedWeakReference 类型对象;
- 2、分析 KeyedWeakReference 对象的最短引用链,并按照引用链签名分组,按照 Application Leaks 和 Library Leaks 分类;
- 3、返回分析完成事件。
第 1 步和第 3 步不用说了,继续分析最复杂的第 2 步:
shark.HeapAnalyzer.kt
// 生成单个泄漏问题的分析报告,并按照应用链签名分组,按照 Application Leaks 和 Library Leaks 分类,按照 Application Leaks 和 Library Leaks 分类 private fun FindLeakInput.buildLeakTraces( shortestPaths: List<ShortestPath> /*最短引用链*/ , inspectedObjectsByPath: List<List<InspectedObject>> /*标记信息*/ , retainedSizes: Map<Long, Pair<Int, Int>>? /*泄漏内存大小*/ ): Pair<List<ApplicationLeak>, List<LibraryLeak>> { // Application Leaks val applicationLeaksMap = mutableMapOf<String, MutableList<LeakTrace>>() // Library Leaks val libraryLeaksMap = mutableMapOf<String, Pair<LibraryLeakReferenceMatcher, MutableList<LeakTrace>>>() shortestPaths.forEachIndexed { pathIndex, shortestPath -> // 标记信息 val inspectedObjects = inspectedObjectsByPath[pathIndex] // 实例化引用链上的每个对象快照(非怀疑对象的 leakingStatus 为 NOT_LEAKING) val leakTraceObjects = buildLeakTraceObjects(inspectedObjects, retainedSizes) val referencePath = buildReferencePath(shortestPath, leakTraceObjects) // 分析报告 val leakTrace = LeakTrace( gcRootType = GcRootType.fromGcRoot(shortestPath.root.gcRoot), referencePath = referencePath, leakingObject = leakTraceObjects.last() ) val firstLibraryLeakMatcher = shortestPath.firstLibraryLeakMatcher() if (firstLibraryLeakMatcher != null) { // Library Leaks val signature: String = firstLibraryLeakMatcher.pattern.toString().createSHA1Hash() libraryLeaksMap.getOrPut(signature) { firstLibraryLeakMatcher to mutableListOf() }.second += leakTrace } else { // Application Leaks applicationLeaksMap.getOrPut(leakTrace.signature) { mutableListOf() } += leakTrace } } val applicationLeaks = applicationLeaksMap.map { (_, leakTraces) -> // 实例化为 ApplicationLeak 类型 ApplicationLeak(leakTraces) } val libraryLeaks = libraryLeaksMap.map { (_, pair) -> // 实例化为 LibraryLeak 类型 val (matcher, leakTraces) = pair LibraryLeak(leakTraces, matcher.pattern, matcher.description) } return applicationLeaks to libraryLeaks } 复制代码
6.6 LeakCanary 如何筛选 ~~~ 怀疑对象?
LeakCanary 会使用 ObjectInspector 对象检索器在引用链上的节点中标记必要的信息和状态,标记信息会显示在分析报告中,并且会影响报告中的提示。而引用链 LEAKING
节点以后到第一个 NOT_LEAKING
节点中间的节点,才会用 ~~~
下划线标记为怀疑对象。
在第 6.5 节中,LeakCanary 通过 leakingObjectFinder
标记引用信息,leakingObjectFinder 默认是 AndroidObjectInspectors.appDefaults
,也可以在配置项中自定义。
// inspectedObjectsByPath:筛选出非怀疑对象(分析报告中 ~~~ 标记的是怀疑对象) val inspectedObjectsByPath = inspectObjects(shortestPaths) 复制代码
看一下可视化报告中相关源码:
DisplayLeakAdapter.kt
... val reachabilityString = when (leakingStatus) { UNKNOWN -> extra("UNKNOWN") NOT_LEAKING -> "NO" + extra(" (${leakingStatusReason})") LEAKING -> "YES" + extra(" (${leakingStatusReason})") } ... 复制代码
LeakTrace.kt
// 是否为怀疑对象 fun referencePathElementIsSuspect(index: Int): Boolean { return when (referencePath[index].originObject.leakingStatus) { UNKNOWN -> true NOT_LEAKING -> index == referencePath.lastIndex || referencePath[index + 1].originObject.leakingStatus != NOT_LEAKING else -> false } } 复制代码
6.7 LeakCanary 分析完成后的处理
有两个位置处理了 HeapAnalysisSucceeded
事件:
- Logcat:打印分析报告日志;
- Notification: 发送分析成功系统通知消息。
LogcatEventListener.kt
object LogcatEventListener : EventListener { ... SharkLog.d { "\u200B\n${LeakTraceWrapper.wrap(event.heapAnalysis.toString(), 120)}" } ... } 复制代码
NotificationEventListener.kt
object NotificationEventListener : EventListener { ... val flags = if (Build.VERSION.SDK_INT >= 23) { PendingIntent.FLAG_UPDATE_CURRENT or PendingIntent.FLAG_IMMUTABLE } else { PendingIntent.FLAG_UPDATE_CURRENT } // 点击通知消息打开可视化分析报告 val pendingIntent = PendingIntent.getActivity(appContext, 1, event.showIntent, flags) showHeapAnalysisResultNotification(contentTitle,pendingIntent) ... } 复制代码
至此,LeakCanary 原理分析完毕。
7. 总结
到这里,LeakCanary 的使用和原理分析就讲完了。不过,LeakCanary 毕竟是实验室使用的工具,如果要实现线上内存泄漏监控,你知道怎么做吗?要实现 Native 内存泄漏监控又要怎么做?关注我,带你了解更多。