2.2 排除非class文件的干扰，对源文件路径进行递归遍历

代码的编译长短对研发的影响很大，所以编译时长很宝贵，需要我们尽量的减少编译的时长，所以我们在执行自定义的Transform过程中，需要过滤并排除非Class文件，减少不必要的浪费。经过整理主要为：R文件以及R文件的内部类R$*文件，包括R$string、R$styleable等等，所以，在遍历处理过程中我们需要对R文件及R$*文件过滤。

2.3 提供ClassVisitor类和MethodClass去搜集Class及对应Method，并定位

这个步骤是最主要的一部分，这一部分主要获取两部分数据，第一部分是研发修改直接影响到的类和方法；第二部分是遍历整个源文件的所获得的类信息，主要包括类+各个方法以及各个方法体，也就是方法中的指令；

在拿到transformInvocation后我们进行源文件文件夹遍历和所有jar包的遍历，在外层我们定义好存储被影响的类列表（changedClassesList），和包含类信息的列表（classesInfoList），将两个列表作为参数，传递进去在遍历过程中赋值。这里值得注意的是，在进行jar解析过程中不需要进行changedClassesList，因为对于本工程来说研发人员不会直接对jar文件中文件操作。

在对源文件遍历过程中，我们进行定位搜寻。

遍历源文件根节点并读取：

在上述的visit中我们定位了当前类是否与上次git提交的是否有关，接下来我们需要MethodVisitor中进行有选择的拦截对应的Method的访问。

重写MethodVisitor在visitMethod中进行拦截处理，如果git修改相关在当前类中，则我们在访问Method时，进行方法体行数定位。

在MethodVisitor中，我们可以通过系统方法定位访问方法的每条方法指令及指令对应的行数，所以我们只要重写visitLineNumber方法即可实时的在visitMethodInsn方法中拿到方法体访问行数，这里有个小的注意点就是，我们在调用visitLineNumber返回的line不是我们理解意义上的方法名称部分开始，而是从方法体的第一行代码计算开始，所以我们在做判断的时候，需要注意，相对方法体的首行，我们更关心方法体的变更，所以我们只需要判定落在visitMethodInsn中的更改即可。有需要更加精细的判定，小伙伴可以进行更加精细的调研。

以下是visitLineNumber方法：

知道了方法体开始的地方，我们也需要知道结束的位置，获取到结束位置后，我们就能轻松的定位到我们需要定位的方法体，从而获得方法名称，进一步获得类的名称。ASM在MethodVisitor中提供了visitEnd方法，表示方法体访问结束，那么我们就可以在visitEnd中进行定位：

至此，我们通过自定义ClassVisitor和MethodVisitor完成了对源文件的搜集和定位。

总结一下思路：首先我们拉取了研发最后一次在Git上提交的代码，通过分析并找出规律，配合正则表达式匹配的方式，拿到修改的后缀为java的文件，又进一步的寻找规律筛选出对应java文件修改的行号；其次遍历工程源文件，利用自定义ClassVisitor和MethodVisitor进行类信息的收集包括类名、方法以及方法体指令，并在访问过程中提交后有修改痕迹的文件通过行号进行定位；最后完成收集集合的填充。这整个过程中用到很多比较重要方法，比如：CLassVisitor中的visit、visitMethod、visitEnd，以及MethodVisitor中的visitLineNumber、visitMethodInsn、visitEnd等。

遍历查找对应方法的上行链路和下行链路

在二步骤中完成了定位类与方法，并且完成了整个工程的源文件遍历收集，接下来就能逐步的整理出来，修改方法在整个工程中所带来的影响。

方法上行链路数据生成

这一步骤相对来说比较简单，对于在上一步骤中，我们得到的上次的git提交定位数据，及整个工程的源文件类中方法信息的集合，我们只需要将改变的list集合在工程源文件信息集合递归循环，便能得到对应方法的上行调用链。而遍历的思路则是，递归向上扫描调用了变更集合中的类以及方法，以此递归循环遍历，只要调用到相关联的方法就被收集，对于Android应用来说，研发所写业务逻辑，基本上终止于Activity或者Applicantion中，所以向上的是有终点的。

如下是一个简图：

方法下行链路数据生成

对于系统的API以及一些三方库，我们大致总结了一下几种，供大家参考：

示意图如下：

至此，我们完成了方法上/下行链路的搜索。

注释及自定义Tag

上面三个步骤，我们们完成了对应方法上/下行链路功能开发，但是整条链路上只是包含了对应的类名+方法名，对于研发来讲，对应的类的作用以及方法的实现是什么逻辑比较清楚，但是仅仅局限于研发，对于测试人员可能没什么用，也只是一堆代码而已。针对这一问题，我们想到了注释，各个研发组在很早之前就开始接入京东自研的EOS来规范代码的注释，经过这么长时间的打磨也趋于完善。我们可以通过注释的方式来与对应的业务逻辑。我们设想能够通过某些手段去完成注释的获取，但是注释可能也不能完全的去表达当前的业务逻辑，我们还需要提供具体的业务逻辑标注。

怎么解决呢？其实，总结起来就是，我们要说明上/下行链路涉及到的类和方法解释以及业务说明，并且可以利用一些特殊的标记去完成对应的一些特殊逻辑说明。

基于代码的注释，我们可以很容易的想到JavaDoc，包括Android的开发环境Android studio中也自带了可以生成源文件的javadoc（路径：Tools-->Generate JavaDoc），执行命令后几秒钟后，生成了一份完整的文档。

既然自带的工具可以完成Java文件注释的提取，那么我们也可以在代码中获取到对应的注释，经过相关资料了解到JDK中自带的tools.jar包可以完成JavaDoc的提取。

在将tools包上传Maven后在gradle中进行依赖，基本就完成了环境的配置。经过多方资料的查找及demo实验，tools包支持命令的形式生JavaDoc。这里需要注意的是，我们不需要html形式的javadoc文档形式，所以需要进行一些自定义的东西来达到我们自己的要求。

官方文档是这样说的：

If you run javadoc without the -doclet command-line option, it will default to the standard doclet to produce HTML-format API documentation.

也就是说，我们需要在命令行中添加-doclet来进行自定义文档。并且给出自定义的Doclet类：

接下来简单的封装tools中的execute方法：

其中命令中参数，感兴趣的小伙伴可以查看官方文档，这里就不再赘述了。

基本封装完成后，就可以直接使用了，但是考虑到在遍历使用的过程中会出现多次调用解析ClassDoc的问题，这里还是建议将解析过的Java文件进行缓存处理，方便直接调用，也能减少整个编译的时间，并且在解析过程中我们也需要排除系统类的解析。

这里我们也给出自定义Tag，当然，在项目中可以根据自己的业务名称进行命名。

当我们的方法调用链涉及到getPrintMethod时，就会提取@LogicIntroduce标签后面的内容，达到了获取业务逻辑说明注释的目的。这样对于那些不懂代码的非研发人员，也能够非常清晰的看懂这部分代码涉及到的业务逻辑，测试也能够着重的进行测试了。

本地输出：

推荐实际业务使用

方法的调用上下链路在上述步骤中已经生成，我们可以在MarkDown中简单的生成调用链，至于要遵循什么样的格式，大家可以自己查阅，相对比较简单不再展开。下面是推荐位最近一次修改涉及到的部分流程图：

代码修改位置输出为：