三悦有了新工作（古代对三的雅称）

img

LeakCanary 附带一个已知泄漏的数据库，它通过引用名称的模式匹配来识别。例如：

Library Leaks 通常我们都无力对齐进行修复 您可以在AndroidReferenceMatchers类中查看已知泄漏的完整列表。如果您发现无法识别的 Android SDK 泄漏，请报告。您还可以自定义已知库泄漏的列表。

三，监测activity，fragment，rootView和viewmodel

前面提到初始化的代码如下,所以我们 查看manualInstall 的内部细节。

AppWatcher 作为Android 平台使用 ObjectWatcher 封装的api中心。自动安装配置默认的监听。 以上代码关键的地方用数字标出了

（1）Install 默认的监听观察

标注(1)处的代码执行了 InstallableWatcher 的 install 操作，在调用的时候并没有传递 watchersToInstall 参数，所以使用的是 appDefaultWatchers(application)。该处代码在下面，提供了 四个默认监听的Watcher

用数字标出的四个我们逐个分析

（1.1） reachabilityWatcher 参数

标注(1.1)处的代码是一个 ReachabilityWatcher 参数，reachabilityWatcher 在后续的四个实例创建时候都有用到，代码中可以看到reachabilityWatcher实例是AppWatcher 的成员变量：objectWatcher，对应的实例化代码如下。

可以看到objectWatcher 是一个 ObjectWatcher对象，该对象负责检测持有对象的泄漏情况，会在第三小节进行分析。 回到 ActivityWatcher 实例的创建，继续往下看标注的代码

（1.2）ActivityWatcher 实例 完成Activity 实例的监听

回到之前，标注(1.2)处的代码创建了ActivityWatcher实例，并在install 的时候安装，查看ActivityWatcher 类的源码，看监听Activity泄漏是怎么实现的

(1.2.1) lifecycleCallbacks 实例

标注(1.2.1)处的代码创建了
ActivityLifecycleCallbacks实例，该实例实现了Application.ActivityLifecycleCallbacks。通过 by “*noOpDelegate*“() ，利用动态代理实现了其他回调方法，感兴趣的可以查看 noOpDelegate 的源码

(1.2.2) activity监听器的 install 方法

标注(1.2.2)处的代码是初始化的主要代码，该方法很简单，就是在application的 中注册 lifecycleCallbacks，在activity 被destroy 的时候会走到其中实现的方法

(1.2.3) 监听activity 的 onActivityDestroyed 回调

标注(1.2.3)处的代码是初始化的主要代码，在 activity被销毁的时候，回调该方法，在其中检查该实例是否有泄漏，调用AppWatcher.objectWatcher. expectWeaklyReachable 方法，在其中完成activity的泄漏监测。 这时候又回到了 1.1 提到的 ObjectWatcher源码，相关分析看第四节 。

(1.2-end)Activity监测相关总结

这样ActivityInstaller 就看完了，了解了Activity 的初始化代码以及加入监听的细节。总结一下分为如下几步：

1. 调用ActivityInstaller.install 初始化方法
2. 在Application 注册ActivityLifecycleCallbacks
3. 在所有activity onDestroy的时候调用ObjectWatcher的 expectWeaklyReachable方法，检查过五秒后activity对象是否有被内存回收。标记内存泄漏。下一节分析。
4. 检测到内存泄漏的后续操作。后文分析。

(1.3) FragmentAndViewModelWatcher 监测 Fragment 和Viewodel实例

（1.3）处是创建了
FragmentAndViewModelWatcher 实例。监测fragment和viewmodel的内存泄漏。

该类实现了 SupportFragment和 androidxFragment以及androidO 的兼容，作为sdk开发来说，这种 兼容方式可以学习一下。

和ActivityWatcher 同样的，install是注册了生命周期监听。不过是在对每个 activity create 的时候，交给 fragmentDestroyWatchers 元素们监听。所以 fragmentDestroyWatchers才是真正的fragment和viewmodel 监听者。 接下来看 fragmentDestroyWatchers 的元素们创建:

可以看到内部创建了
AndroidOFragmentDestroyWatcher 来针对Fragment 进行监听。原理是利用在 FragmentManager 中注册
FragmentManager.FragmentLifecycleCallbacks 来监听fragment 和 fragment.view 以及viewmodel 的实例泄漏。 从官方文档可知，android内部的 fragment 在Api 26中才添加。所以LeakCanary针对于android框架自带的fragment泄漏监测支持也是从 AndroidO(26)开始,见代码(1.3.1)。 标注的 1.3.1，1.3.2，1.3.3 实例化的三个Wathcer 分别是
AndroidOFragmentDestroyWatcher,
AndroidXFragmentDestroyWatcher,
AndroidSupportFragmentDestroyWatcher。内部实现代码大同小异，通过反射实例化不同的Watcher实现了androidX 和support 以及安卓版本间的兼容。

(1.3.1) AndroidOFragmentDestroyWatcher 实例

(1.3.1)处的代码添加了一个androidO的观察者实例。详情见代码，因为实现大同小异，分析参考1.3.2.

(1.3.2) AndroidXFragmentDestroyWatcher 实例

(1.3.2)处的代码 调用 getWatcherIfAvailable 通过反射创建了
AndroidXFragmentDestroyWatcher实例，如果不存在Androidx库则返回null。 现在跳到
AndroidXFragmentDestroyWatcher 的源码分析

通过源码可以看到，初始化该watcher是通过以下几步。

1. FragmentManager.registerFragmentLifecycleCallbacks 注册监听回调
2. ViewModelClearedWatcher.install 初始化了对于activity.viewModel的监听
3. 在回调onFragmentCreated 中回调中使用ViewModelClearedWatcher.install注册了对于fragment.viewModel的监听。
4. 在 onFragmentViewDestroyed 监听 fragment.view 的泄漏
5. 在 onFragmentDestroyed 监听 fragment的泄漏。 监听方法和ActivityWatcher大同小异，不同是多了个 ViewModelClearedWatcher.install 。现在分析这一块的源码，也就是标注中的 (1.3.2.1)。

通过代码，可以看到viewModel的泄漏监测是通过创建一个新的viewModel实例来实现。在该实例的onCleared处监听storeOwner的其余 viewModel 是否有泄漏。标注出的代码逐一分析：

(1.3.2.2 ) 处代码：

获取ViewModelClearedWatcher 实例，在自定义的 Factory中传入storeOwner 和 reachabilityWatcher。

(1.3.2.3 ) 处代码：

通过反射获取storeOwner 的viewModelMap

(1.3.2.4 ) 处代码：

在ViewModel完成使命OnClear的时候，开始监测storeOwner旗下所有ViewModel的内存泄漏情况。

(1.3-end)Fragment 和 viewmodel 监测泄漏总结：

监测方式都是通过ObjectWatcher的 expectWeaklyReachable 方法进行。fragment 利用
FragmentLifecyclerCallback回调注册实现，ViewModel 则是在对应StoreOwner下创建了监测viewModel来实现生命周期的响应。 其中我们也能学习到通过反射来创建对应的平台兼容实现对象方式。以及借助创建viewModel来监听其余ViewModel生命周期的想法。

(1.4) RootViewWatcher 的源码分析

默认的四个Watcher中，来到了接下来的 RootViewWatcher。window rootview 监听依赖了squre自家的Curtains框架。

类的关键源码如下:

看到关键代码，就是 在Curtains中添加
onRootViewsChangedListeners 监听器。当windowsType类型为 **Dialog** ***TOOLTIP***, ***TOAST***,或者未知的时候 ，在 onViewDetachedFromWindow 的时候监听泄漏情况。 Curtains中的监听器会在windows rootView 变化的时候被全局调用。Curtains是squareup 的另一个开源库，Curtains 提供了用于处理 Android 窗口的集中式 API。具体移步他的官方仓库。

(1.5) ServiceWatcher 监听Service内存泄漏

接下来就是AppWatcher中的最后一个Watcher。 ServiceWatcher。代码比较长，截取关键点分析。

（1.5.1）先看成员变量 activityThreadServices ：

activityThreadServices 是个装了所有<IBinder, Service> 对的Map。代码中可以看到很粗暴地，直接通过反射从ActivityThread实例中拿到了mServices 变量 。赋值给activityThreadServices。 源码中有多个swap操作，在install的时候执行，主要目的是将原来的一些service相关生命周期回调加上一些钩子，用来监测内存泄漏，并且会在unInstall的时候给换回来。

（1.5.2）swapActivityThreadHandlerCallback ：

拿到ActivityThread 的Handler，将其回调的 handleMessage，换成加了料的Handler.Callback，加料代码如下

代码中可以看到，主要是对于 STOP_SERVICE 的操作做了一个钩子，在之前执行 onServicePreDestroy。主要作用是为该service 创建一个弱引用，并且加到servicesToBeDestroyed[token] 中 。

（1.5.3）然后再看 swapActivityManager 方法。

该方法完成了将ActivityManager替换成IActivityManager的一个动态代理类。代码如下：

代码所示，替换后的ActivityManager 在调用serviceDoneExecuting 方法的时候添加了个钩子，如果该service在之前加入的servicesToBeDestroyed map中，则调用onServiceDestroyed 监测该service内存泄漏。

（1.5.4）代码的onServiceDestroyed具体代码如下

这里面的代码很熟悉，和之前监测activity等是一样的。 回到swapActivityManager方法，看代理ActivityManager的具体类型。 可以看到代理的对象如下面代码所示，根据版本不同可能是ActivityManager 实例或者是ActivityManagerNative实例。 代理的接口是 Class.forName(“
android.app.IActivityManager”)。

（1.5-end）Service 泄漏监测总结

总结一下，service的泄漏分析通过加钩子的方式，对一些系统执行做了监听。主要分为以下几步：

1. 获取ActivityThread中mService变量，得到service实例的引用
2. 通过swapActivityThreadHandlerCallback 在ActivityThread 的 Handler.sendMessage 中添加钩子，在执行到msg.what==STOP_SERVICE 的时候

四，ObjectWatcher 保留对象检查分析

我们转到 ObjectWatcher 的 expectWeaklyReachable 方法看看

继续分析源码中标注的地方。

(1) 创建弱引用

标注(1.2.4)处的代码是初始化的主要代码，创建要观察对象的弱引用，传入queue 作为gc 后的对象信息存储队列，WeakReference 中，当持有对象呗gc的时候，会将其包装对象压入队列中。可以在后续对该队列进行观察。

(2) moveToRetained(key)，检查对应key对象的保留

作为Executor的runner 执行，在AppWatcher中，默认延迟五秒后执行该方法 查看源码分析

从上述代码可知，ObjectWatcher 监测内存泄漏总共有以下几步

1. 清除已经被内存回收的监听对象
2. 创建弱引用，传入 ReferenceQueue 作为gc 信息保存队列
3. 在延迟指定的时间后，再次检查针对的对象是否被回收（通过检查ReferenceQueue队列内有无该WeakReference实例）
4. 检测到对象没有被回收后,回调 onObjectRetainedListeners 们的 onObjectRetained

五，dumpHeap，怎么个DumpHeap流程

（1.1）objectWatcher 添加 OnObjectRetainedListeners 监听

回到最初AppWatcher的 manualInstall 方法。 可以看到其中执行了loadLeakCanary 方法。 代码如下:

该方法通过反射获取了 InternalLeakCanary 的静态实例。 并且调用了他的 invoke(application: Application)方法，所以我们接下来看InternalLeakCanary的该方法：

我们看到初始化的时候做了这么6步

• （1.2） 将自己加入到ObjectWatcher 的对象异常持有监听器中
• （1.3）创建内存快照转储触发器 HeapDumpTrigger
• （1.4）监听application 前后台变动，并且记录来到后台时间，便于LeakCanary 针对刚刚切入后台的一些destroy操作做泄漏监测
• （1.5）注册activity生命周期回调，获取当前resumed的activity实例
• （1.6）添加动态的桌面快捷入口
• （1.7）在异步线程中，判断是否处于可dumpHeap的状态，如果处于触发一次内存泄漏检查 其中最重要的是 1.2，我们重点分析作为ObjectRetainedListener 他在回调中做了哪些工作。

（1.2）添加对象异常持有监听

可以看到代码(1.2)，在objectWatcher将自己加入到泄漏监测回调中。 当ObjectWatcher监测到对象依然被异常持有的时候，会回调 onObjectRetained 方法。 从源码中可知，其中调用了 heapDumpTrigger的
scheduleRetainedObjectCheck方法， 代码如下。

HeapDumpTrigger 顾名思义，就是内存快照转储的触发器。在回调中最终调用了HeapDumpTrigger 的 checkRetainedObjects方法来检查内存泄漏。

（1.3）检查内存泄漏checkRetainedObjects

这一块也可以看出检测是否需要dumpHeap分为4步。

1. 如果没有检测到异常持有的对象，返回
2. 如果有异常对象，主动触发gc
3. 如果还有异常对象，就是内存泄漏了。
4. 判断泄漏数量是否到达需要dump的地步
5. 判断一分钟内是否叫进行过dump了
6. dumpHeap 前面都是判断代码，关键重点在于dumpHeap方法

（1.4）dumpHeap 转储内存快照

HeapDumpTrigger#dumpHeap中调用到了 AndroidHeapDumper#dumpHeap方法。 并且在dump后马上调用
HeapAnalyzerService.runAnalysis 进行内存分析工作，该方法在下一节分析。先看AndroidHeapDumper#dumHeap源码

在该方法内，最终调用 Debug.dumpHprofData 方法 完成hprof 快照的生成。

六，分析内存 HeapAnalyzerService

上面代码分析中可以看到，在dumpHeap后紧跟着就是启动内存分析服务的方法。 现在我们跳转到HeapAnalyzerService的源码处。

可以看到重点在于 analyzeHeap，其中调用了 HeapAnalyzer#analyze HeapAnalyzer 类位于shark模块中。

（1）HeapAnalyzer#analyze

内存分析方法代码如下：

通过分析代码可知：分析内存快照分为以下5步：

1. 读取hprof内存快照文件
2. 找到LeakCanary 标记的泄漏对象们的数量和弱引用包装 ids，class name 为com.squareup.leakcanary.KeyedWeakReference

代码在 KeyedWeakReferenceFinder#findLeakingObjectIds

1. 找到泄漏对象的gcRoot开始的路径

代码在PathFinder#findPathsFromGcRoots

1. 返回分析结果，走结果回调
2. 回调内 展示内存分析成功或者失败的通知栏消息，并将泄漏列表存储到数据库中

详情代码看
DefaultOnHeapAnalyzedListener#onHeapAnalyzed 以及 LeaksDbHelper

1. 点开通知栏跳转到LeaksActivity 展示内存泄漏信息。

七，总结

终于从头到尾，总算是梳理了一波LeakCanary 源码

过程中学习到了这么多—>

• 主动调用Gc的方式 GcTrigger.Default.runGc()

• seald class 密封类来表达状态，比如以下几个（关键好处在于使用when可以直接覆盖所有情况，而不必使用else）。

• 了解了系统创建内存快照的api

• 知道了通过 ReferenceQueue 检测内存对象是否被gc，之前WeakReference都很少用。
• 学习了leakCanary的分模块思想。作为sdk,很多功能模块引入自动开启。比如 leakcanary-android-process 自动开启对应进程等。
• 学习了通过反射hook代码，替换实例达成添加钩子的操作。比如在Service泄漏监听代码中，替换Handler和activityManager的操作。

多多看源码还是有好处的。难怪我之前工作都找不到。看的太少了。