Matrix 之 TraceCanary 源码分析

今天来分析下 Matrix 框架的 matrix-trace-canary 部分，相关文档可查看《 Matrix Android TraceCanary 》,这份文档是阅读源码的关键，强烈建议先看文档再读源码。

TraceCanary 是检测应用卡顿的模块，在该模块下又细分了以下几个模块：

• StartupTracer ： 启动时间检测模块
• FrameTracer ： FPS 帧率检测模块
• EvilMethodTracer ：耗时函数检测模块
• AnrTracer ：ANR 检测模块

在这些模块当中，又是依赖 MethodBeat 的提早插桩来达到检测的效果，因此，咱们在分析这几个模块以前，得先分析 MethodBeat 干了些什么，他是如何辅助以上几个模块来进行检测的。

为了避免使文章变得枯燥无味，上面的四个模块会另起新的文章标题进行讲解，那么本文将会对 matrix-gradle-plugin 的插桩部分先进行一个大概的讲解，细节部分可能不会去分析，由于牵扯起来东西太多了。

来看下文档中对编译插桩部分的描述：

经过代理编译期间的任务 transformClassesWithDexTask，将全局 class 文件做为输入，利用 ASM 工具，高效地对全部 class 文件进行扫描及插桩。

插桩过程有几个关键点： 一、选择在该编译任务执行时插桩，是由于 proguard 操做是在该任务以前就完成的，意味着插桩时的 class 文件已经被混淆过的。而选择 proguard 以后去插桩，是由于若是提早插桩会形成部分方法不符合内联规则，无法在 proguard 时进行优化，最终致使程序方法数没法减小，从而引起方法数过大问题。

二、为了减小插桩量及性能损耗，经过遍历 class 方法指令集，判断扫描的函数是否只含有 PUT/READ FIELD 等简单的指令，来过滤一些默认或匿名构造函数，以及 get/set 等简单不耗时函数。

三、针对界面启动耗时，由于要统计从 Activity#onCreate 到 Activity#onWindowFocusChange 间的耗时，因此在插桩过程当中须要收集应用内全部 Activity 的实现类，并覆盖 onWindowFocusChange 函数进行打点。

四、为了方便及高效记录函数执行过程，咱们为每一个插桩的函数分配一个独立 ID，在插桩过程当中，记录插桩的函数签名及分配的 ID，在插桩完成后输出一份 mapping，做为数据上报后的解析支持

分析

apply plugin: 'om.tencent.matrix-plugin' 对应的是  matrix-gradle-plugin 中的MatrixPlugin 类：

implementation-class=com.tencent.matrix.plugin.MatrixPlugin

MatrixPlugin.java

该插件作了以下操做：
一、关联 apply MatrixPlugin 设置的 extensions 参数，该参数能够查看 sample 的 app build.gradle
二、插入 transfrom task，该 task 就如文档所描述的 transformClassesWithDexTask
三、移除未使用的资源文件

咱们进入 MatrixTraceTransform.inject 看看：

MatrixTraceTransform.java

配置的部分我省略掉了，因为 sample app build.gradle 中未设置 customDexTransformName 的，因此，hardTask 会返回  transformClassesWithDexBuilderForDebug 和 transformClassesWithDexForDebug，在运行 sample 项目时，复制了全部的 build 过程的日志信息，在查找的过程当中，只有 transformClassesWithDexBuilderForDebug 参与了活动，而且，也打印了如上的 successfully inject task:transformClassesWithDexBuilderForDebug  日志信息。
最后会 hook 掉 transformClassesWithDexBuilderForDebug 的 task，替换成本身的 MatrixTraceTransform，MatrixTraceTransform 的构造方法传入了 transformClassesWithDexBuilderForDebug task，在 MatrixTraceTransform 使用完成后，是须要传递给下一个 transfrom 继续运行的，因此，在 MatrixTraceTransform 的 transfrom 方法中，会看到：

origTransform.transform(transformInvocation);

这个 origTransform 就是系统的 transformClassesWithDexBuilderForDebug

这时候，咱们能够直接来看 MatrixTraceTransform task 了， doTransfrom 是最重要的方法，这个部分我大概去讲解一下，由于涉及跳转太多，篇幅就会很是有影响，好在 Matrix 的开发者留给了咱们三个 step 注释，咱们就按照这三个步骤去解释：

一、step1：
这个地方须要关注几个 executor.submit 的执行，第一个 ParseMappingTask，这个 task 从名称上就能看出是一个解析 Mapping 的任务，这个任务作了以下的操做：

1. 读取 output 下面的 mapping.txt 文件，还原混淆前的类和方法，存放在 MappingCollector 类中 mObfuscatedClassMethodMap 和 mOriginalClassMethodMap 集合中
2. 读取自定义的 baseMethodMapFile 配置，直接生成 TraceMethod 存放到 collectedMethodMap 中，在 sample 中，baseMethodMapFile 未设置配置文件

接着看 CollectDirectoryInputTask 和 CollectJarInputTask 任务，这两个任务主要收集 class 原文件和 traceClassOut 文件，class 原文件咱们都知道，就是扫描到的 class 文件，那 traceClassOut 文件是什么呢？在默认的配置中，会设置一份 traceClassOut 路径，这个配置路径指向的是 output/traceClassOut 路径，咱们能够打开 sample 下面的这个路径：

二、step2
主要看 collect 方法，该方法作了以下的几个操做：

1. 将 DirectoryInput 收集的 class 原文件和 CollectJarInputTask 收集的原文件进行遍历，利用 TraceClassAdapter 来收集须要插入字节码(collectedClassExtendMap)和类和须要忽略掉的类(collectedIgnoreMethodMap)
2. 分类保存上面收集到的两个集合，在写入文件时，会根据原 class 混淆文件 revert 还原 class，而后一并写入到文件中，这样，咱们在查看混淆与对应文件时会很是的方便：

collectedClassExtendMap 集合中的数据是须要作插桩的类，该集合中的数据保存在 output/mapping/methodMapping 下面：

collectedIgnoreMethodMap 集合中的数据是须要忽略掉的类，该集合中的数据保存在 output/mapping/ignoreMethodMapping 下面 : 

三、step3
拿到混淆类集合和还原的类集合，而后拿到在 step1 中收集到的原文件和 traceOut 文件，一并参与 trace 操做。所作的内容有：

1. 遍历原 class 文件，并建立 traceOut 路径文件
2. 对原 class 文件进行插桩操做，插桩的内容有：
3. Activity 的 onWindowFocusChanged 方法插入 AppMethodBeat.getInstance().at 方法
4. 知足类的方法在开头和结尾插入 i/o 方法
5. 对插桩后的 class 文件 copy 一份到 traceOut 路径文件

总结

补充部分：

1. matrix-gradle-plugin 是能够设置黑名单的，在 sample app build.gradle 下能够看到设置的 balckMethodList，对于设置了黑名单的 package 或是 class，是不会被插桩操做
2. 若是想看插桩以后的代码效果，能够直接查看 output/mapping/traceClassOut 路径下的效果类，确实很方便，建议作插桩效果的插件都能像 matrix 这样去作，在看实现效果时，不再用去看 transfrom 下面各类各类的 jar 或是反编译 apk 才能看到本身是否真正被插入成功
3. 对于未被插桩的函数，能够直接查看 output/mapping/ignoreMethodMapping.txt 文件
4. 每一个插桩函数都有对应的 methodId，若是想看对应关系的话，能够直接查看 output/mapping/methodMapping.txt 文件

整体的分析差很少了，但细节部分仍是须要去细扣，本人能力有限，不对之处还望指正。