从Matrix-ResourceCanary看内存泄漏监控

不同于LeakCanary，在Matrix中，主要是通过Resource Canary来监控内存泄漏问题的，且监听的泄漏对象只支持Activity，官方说明如下：

结合分析LeakCanary的经验可知，要实现Activity内存泄漏监听，总体上应该要实现两大功能：

1. Activity生命周期监控
2. 查找泄漏对象并得到GC Root Path

Activity生命周期监控

从Activity生命周期监控实现方案可知，我们可以通过Application.registerActivityLifecycleCallbacks来实现Activity生命周期监控，那么Matrix中又是怎么实现的呢？

在Matrix中Resource Canary的实现类是ResourcePlugin，Matrix装载所有的plugin对象并通过调用startAllPlugins启动，startAllPlugins最终调用的是各个plugin的start方法，实现如下：

而在ResourcePlugin中，主要的实现都托管给了ActivityRefWatcher这个类，那么必然是在这个类中包含了Activity泄漏监听的主要逻辑，该类的start方法如下所示：

通过代码明显可以看到其是通过Application.registerActivityLifecycleCallbacks来实现Activity生命周期监控的，当Activity生命周期变化时，会回调到mRemovedActivityMonitor对象中，我们来看下mRemovedActivityMonitor对象的实现：

可以看到在onActivityDestroyed中主要干了两件事，将销毁的Activity信息存储到mDestroyedActivityInfos中，延时两秒触发GC，不同于LeakCanary的是，这里并没有通过ReferenceQueue来检查Activity对象泄漏情况，接下来我们来看下它是怎么检查泄漏的？

确定泄漏对象

重新回到ActivityRefWatcher.start方法中，可以看到除了注册Activity生命周期监听外，还执行了scheduleDetectProcedure方法，这个方法是用来干嘛的呢？

 private void scheduleDetectProcedure() {
  mDetectExecutor.executeInBackground(mScanDestroyedActivitiesTask);
 }

结合注释，我们可以看到这里通过mDestroyedActivityInfos对象来实现线程阻塞，当该队列不为空时，唤醒该Task进行对象泄漏检测（通过判断弱引用对象是否为空来确定回收状况，弱引用对象为空说明已回收，不存在泄漏），可以看到这里在外部和每次循环读取列表数据时，都进行了GC以保证对象充分回收，规避误报情况，当发现达到mMaxRedetectTimes（可配置的参数，默认取值10）次后，该Activity对象仍未回收，则触发泄漏处理机制。

Matrix中提供的泄漏处理器如下图所示：

其中各处理器处理方式如下：

• AutoDumpProcessor:java层自动生成hprof后裁剪并回调报告issue
• ForkAnalyseProcessr:在native层fork进程后，hook生成hprof文件，解析hprof文件
• ForkDumpProcessor:在native层fork进程够，hook生成hprof文件后并回调报告issue
• LazyForkAnalyseProcessor:当应用在后台时分析hprof，其他与ForkAnalyseProcessr一致
• ManualDumpProcessor:在native层生成hprof文件并分析
• NativeForkAnalyzeProcessor:实现和ManualDumpProcessor基本一样
• NoDumpProcessor:报告issue不做任何处理
• SilenceAnalyseProcessor:java层操作生成hprof文件，native层解析

Resource Canary内存泄漏监控实现原理

结合以上内容，我们不难看出Matrix中Resource Canary中的内存泄漏主要是通过主+子线程配合实现的，主线程做对象信息收集，子线程做轮巡泄漏查找对象，如下图所示：