原标题：代码影响范围工具探索

一、背景

1. 祖传代码不敢随意改动，影响范围无法评估。并且组内时常有因为修改了某块代码，导致其他业务受到影响，产生bug，影响生产。

2. 研发提测完成后，进入测试后经常会向研发询问本次需求改动影响范围，以此来确定测试用例，以达到精准测试，提升整个需求的质量，缩短交付周期。

那么，如何才能规避这种隐患？有没有一种工具能够协助代码研发及review人员更加精确的判断当前代码改动影响范围，有没有一种方法能够提供除了业务逻辑条件验证，针对代码作用范围，给测试人员提供精确验证链路？

二、方案调研

技术方案调研

经过各方资料查找及比对，最终我们整理了两个满足我们需求的方案：

1. IDEA提供了显示调用指定Java方法向上的完整调用链的功能，可以通过“Navigate -> Call Hierarchy”菜单(快捷键：control+option+H)使用，缺点是并没有向下的调用链生成。

2. 开源框架调研：wala/soot静态代码分析工具。

针对上述的调研，大致确认了两种方案，集中分析两种方案的优劣，来制定符合我们目前情况的方案：

经过前期的比较以及相关工具的资料调研、工具功能分析，并考虑到后期一些个性化功能定制开发，以上工具不太满足我们目前的需求，所以决定自己动手，丰衣足食，尝试重新开发一个能够满足我们需求的工具，来协助研发以及测试人员。

三、方案制定

预期：工具尽量满足全自动化，研发只需要接入即可，减少研发参与，提升整个调用链展示和测试的效率。并且调用链路应该在研发打包的过程中触发，然后将数据上传至服务端，生成调用链路图。

上述方案制定完成后，需要进一步确认实现步骤。前期我们确认了工具的大概方向，并进行步骤分解，根据具体的功能将整个工具拆分成六个步骤：

1. 确认修改代码位置（行号）。与git代码管理关联，能够使用git命令，去提取研发最近一次提交代码的有变动的代码行数。

2. 根据步骤1确认收集到影响的类+方法名+类变量。

3. 根据2中确认的类+方法名称生成向上和向上的调用链。包括jar/aar包。

4. 根据3中生成的调用链完成流程图的展示。

5. 自定义注释标签Tag说明当前业务，并提取Tag内容。

6. 本地数据生成并上传服务端生成调用流程图。

整体流程图如下：

四、方案实施

1

定位源代码修改位置行号

首先我们使用 git diff --unified=0 --diff-filter=d HEAD~1 HEAD命令 输出最近一次提交修改的内容，且已知git diff 会按照固定格式输出。

通过提交增、删、改的修改，执行git diff命令，对输出内容进行观察。

举例：某次提交修改了两个文件，如下

RecommendVideoManager.java

ScrollDispatchHelper.java

git diff命令执行后，输出以下内容：

技术方案：

b. 用正则表达式提取 @@ -149 +148,0 @@ ，用来解析代码修改行数：

c. 针对我们的需求，我们只关心本次修改影响的是哪个方法，不关心具体影响了哪些行数，所以我们只需要

就拿到了本次修改，修改开始的代码行数，在结合ASM就可以获取到本次改动影响的具体方法。

2

利用获取的行号定位具体的方法

根据上述1步骤中定位出研发每次提交修改的Java源文件和改动的行号位置，我们需要定位修改代码行号所归属的方法名称，再由方法名称+类名+包名去定位本次修改的影响链路。

如何去定位？

首先确定的是，研发在工程中只能修改的是工程中的源文件，所以我们可以在遍历收集整个工程的源文件的过程中根据已知的修改行号来确定修改的方法名称，进而知道整个方法的调用链路。而对于那些没有落到方法体范围之内的行号，基本上可以确认为类变量或常量，考虑到对于常量修改也可能影响到业务逻辑，所以我们也会对修改的Field进行上下调用的范围的查找，所以需要记录。所以整个过程分成两个部分：

a. 遍历源码Class文件，获取整个类的Field；

b. 遍历Class文件的过程中，通过visitMethod遍历整个方法体，记录方法的初始行号和结束行号，来定位方法；

首先是a部分，确认Field，ClassVisitor提供现成的方法：

所以我们可以在文件中直接获得整个类的Field。然后去根据行数去判断是否有对Fields有修改。如果Fields有修改，那么我们可以根据上述方法去比对，那么就可以获得哪个Field被修改。

接下来是b部分，在遍历Class文件的过程中，通过visitMethod方法，重写AdviceAdapter类来提供MethodVisitor，在遍历过程中，确定研发修改影响的类及方法，具体实现可分为以下步骤：

2.1 获取源文件编译好的Class文件

apk的编译过程中有很多的task需要执行，各个任务环环相扣有序的执行，我们要获取编译好的Class文件，需要在特定的任务之间。我们知道在Java Compiler之后，不管是R.java抑或是aidl，再或者是Java interfaces都会编译成.class文件，在编译完成后会接着完成dex的编译，所以我们尽可能的在dex编译之前完成class文件的处理，这种仅仅是考虑到宿主或者单独的插件工程方案，但是对于主站业务来说，会有各种各样的组件aar，aar的编译不会走dex编译，所以针对这些组件工程，我们也需要考虑到，简单的方式就是我们去监听aar编译的task，然后再做一些处理，所以在Plugin的apply方法中需要进行区分处理，代码如下：

两者的处理逻辑一致，也就是在Task的监听有些区别，所以下面我们不重复复述，以MethodTransform为主线进行讲解。

那么有的同学就会问了，为什么我们不直接对源文件.java文件进行处理呢？

因为，就目前京东主站项目而言，各个aar模块相互调用，如果我们仅仅使用源文件进行扫描，各个aar或者jar包的调用链会断掉不全面，影响代码review人员及测试人员的测试用例完整度。

接下来是代码实现，我们监听任务执行，并针对需要监听的任务开展我们的Class收集操作：

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等。

3

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

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

3.1

方法上行链路数据生成

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

如下是一个简图：

3.2

方法下行链路数据生成

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

示意图如下：

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

4

注释及自定义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文件进行缓存处理，方便直接调用，也能减少整个编译的时间，并且在解析过程中我们也需要排除系统类的解析。