关于代码优化:代码影响范围工具探索

作者：京东批发 田翻新、耿蕾

一、背景

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 命令执行后，输入以下内容：

技术计划：

a. 按行读取输入内容，读取到到 diff 行，则辨认为一个新的文件，并用正则表达式提取文件名：

String[] lines = out.toString().split("\r?\n");
Pattern pattern = Pattern.compile("^diff --git a/\S+ b/(\S+)");

![]()

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

Pattern pattern = Pattern.compile("^@@ -[0-9]+(,[0-9]+)? \+([0-9]+)(,[0-9]+)? @@");

![]()

c. 针对咱们的需要，咱们只关怀本次批改影响的是那个办法，不关怀具体影响了哪些行数，所以咱们只须要

int changeLineStart = Integer.parseInt(m.group(2));

![]()

就拿到了本次批改，批改开始的代码行数, 在联合 ASM 就能够获取到本次改变影响的具体方法。

2. 利用获取的行号定位具体的办法。

​ 根据上述 1 步骤中定位出研发每次提交的批改的 Java 源文件和改变的行号地位，咱们须要定位批改代码行号所归属的办法名称，再由办法名称 + 类名 + 包名去定位本次批改的影响链路。

如何去定位？

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

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

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

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

    @Override
    public FieldVisitor visitField(int access, String name, String desc, String signature, Object value) {Log.i("jingdong","Field name is :%s desc is %s:",name,desc);
        return super.visitField(access, name, desc, signature, value);
    }

所以咱们能够在文件中间接取得整个类的 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 办法中须要进行辨别解决，代码如下：

project.afterEvaluate {
            def android = project.extensions.android
            def config = project.method
                  if (config.enable) {
                      // 利用级别
            if (project.plugins.hasPlugin('com.android.application')) {
                android.applicationVariants.all { variant ->
                    MethodTransform.inject(project, variant)
                }
            }else{
                  //aar 编译解决 --
                // 这里咱们是在 compileReleaseJavaWithJavac 之后运行自定义 Task
                Task javaWithJavacTask = project.tasks.findByName("compileReleaseJavaWithJavac")
                if (javaWithJavacTask != null) {def customTask = project.tasks.create("JDcustomTask", JdParseClassTask.class)
                     javaWithJavacTask.finalizedBy(customTask)
                    }else {new GradleException("创立 task 失败~~")
                    }
                    }
                        }
        }

两者的解决逻辑统一，也就是在 Task 的监听有些区别，所以上面咱们不反复复述，以 MethodTransform 为主线进行解说。

那有的同学就问了，为啥咱们不间接对源文件.java 文件进行解决呢？

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

接下来是代码实现，咱们监听工作执行，并针对须要监听的工作发展咱们的 Class 收集操作：

 //Project
project.getGradle().getTaskGraph().addTaskExecutionGraphListener(new TaskExecutionGraphListener() {
     @Override
     public void graphPopulated(TaskExecutionGraph taskGraph) {for (Task task : taskGraph.getAllTasks()) {
           // 对满足咱们需要的 Task 执行前，if(task.name.equalsIgnoreCase("transformClassesWithDexForDebug")){
             // 执行咱们的 TrasnsformTask
             // 省略。。。。}}}})

2.2 排除非 class 文件的烦扰，对源文件门路进行递归遍历；

代码的编译长短对研发的影响很大，所以编译时长很贵重，须要咱们尽量的缩小编译的时长，所以咱们在执行咱们自定义的 Transform 过程中，须要过滤并排除非 Class 文件，缩小不必要的节约。通过整顿次要为：R 文件以及 R 文件的外部类 R$* 文件，包含 R$string、R$styleable 等等，所以，在遍历处理过程中咱们须要对 R 文件及 R$* 文件过滤。

public static final String[] UN_VISITOR_CLASS = {"R.class", "R$"};

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

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

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

// 批改类列表
List<LinkedClassInfo> changedClassesList = new ArrayList<>()
// 类信息列表
List<Map<String, List<Map<String, List<MethodInsInfo>>>>> classesInfoList = new ArrayList<Map<String, List<Map<String, List<MethodInsInfo>>>>>()
transformInvocation.inputs.each { TransformInput input ->
      // 所有源文件生成的 class
      input.directoryInputs.each { DirectoryInput dirInput ->
           collectDir(dirInput, isIncremental, classesInfoList, changedClassesList)
       }
       // 所有 jar 包汇合
       input.jarInputs.each { JarInput jarInput ->
           if (jarInput.getStatus() != Status.REMOVED) {
                // 能够取到 jar 包汇合
                collectJar(jarInput, isIncremental, classesInfoList,jarOutputFile)
                }
         }
   }

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

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

if (file != null) {
            // 根布局目录进行循环遍历
            File[] files = file.listFiles()
            files.each { File f ->
                if (f.isDirectory()) {collectJar(f, classList,changedClasss,changedLineInfoMap)
                } else {
                    boolean isNeed = true
                    // 对文件类型进行校验，排除一些无意义的配置性文件
                    // 省略。。。if (isNeed) {
                        try {
                          // 类汇合（蕴含：类名 + 办法名 + 办法指令）Map<String, List<Map<String, List<MethodInsInfo>>>> mClassMethodsList = new HashMap<String, List<Map<String, List<MethodInsInfo>>>>()
                            ClassReader cr = new ClassReader(new FileInputStream(f))
                            ClassWriter cw = new ClassWriter(ClassWriter.COMPUTE_FRAMES)
                          // 重写 ClassVisitorAdapter
                            ClassVisitorAdapter ca = new ClassVisitorAdapter(cw, mClassMethodsList,changedClasss ,changedLineInfoMap)
                            cr.accept(ca, ClassReader.EXPAND_FRAMES)
                            classList.add(mClassMethodsList) // 将类的整个办法和指令加进去
                        } catch (RuntimeException re) {re.printStackTrace()
                        } catch (IOException e) {e.printStackTrace()
                        }
                    }
                }
            }
        }

重写 ClassVisitor，ASM 提供的 visit 办法能够很不便的去辨认这个类的各种信息，而咱们用到的信息为两种，一种是接口类型的断定，一种是以后类的类名。对于接口，咱们没有必要去进行 Method 的拜访，对取得的类名信息咱们进行断定以后类是否是 git 最初提交有做过批改的的类：

@Override
    public void visit(int version, int access, String name, String signature, String superName, String[] interfaces) {cv.visit(version, access, name, signature, superName, interfaces);
        owner = name;// 类名
          // 断定不为接口类型
        isInterface = (access & Opcodes.ACC_INTERFACE) != 0;
        // 这里判断是否批改是否蕴含此类
        if (this.mChangedLineInfoMap!=null&&mChangedLineInfoMap.size()>0){for (Map.Entry<String,ChangedLineInfo> changedLineInfoEntry:this.mChangedLineInfoMap.entrySet()){String filePath = changedLineInfoEntry.getKey();
                if(filePath.contains(owner)){
                    // 蕴含此类
                    linkedClassInfo= new LinkedClassInfo();
                    linkedClassInfo.className = owner;
                    mChangedLineInfo= changedLineInfoEntry.getValue();
                    methodNameList = new ArrayList<>();
                    linkedClassInfo.methodNameList = methodNameList;
                }
            }
        }
    }

` 在上述的 visit 中咱们定位了以后类是否与上次 git 提交的是否无关，接下来咱们须要 MethodVisitor 中进行有抉择的拦挡对应的 Method 的拜访。

重写 MethodVisitor 在 visitMethod 中进行拦挡解决，如果 git 批改相干在以后类中，则咱们在拜访 Method 时，进行办法体行数定位。

mv = new MethodVisterAdapter(mv,
                    owner,
                    access,
                    // 省略。。。mChangedLineInfo // 更改行数地位
                    );

在 MethodVisitor 中，咱们能够通过零碎办法定位拜访办法的每条办法指令及指令对应的行数，所以咱们只有重写 visitLineNumber 办法即可实时的在 visitMethodInsn 办法中拿到办法体拜访行数，这里有个小的留神点就是，咱们在调用 visitLineNumber 返回的 line 不是咱们了解意义上的办法名称局部开始，而是从办法体的第一行代码计算开始，所以咱们在做判断的时候，须要留神，绝对办法体的首行，咱们更关怀办法体的变更，所以咱们只须要断定落在 visitMethodInsn 中的更改即可。有须要更加精密的断定，小伙伴能够进行更加精密的调研。

以下是 visitLineNumber 办法：

    @Override
    public void visitLineNumber(int line, Label start) {
        this.lineNumber = line;// 置换 lineNumber
        super.visitLineNumber(line, start);
    }

晓得了办法体开始的中央，咱们也须要晓得完结的地位，获取到完结地位后，咱们就能轻松的定位到咱们须要的定位的办法体，从而取得办法名称，进一步取得类的名称。ASM 在 MethodVisitor 中提供了 visitEnd 办法，示意办法体拜访完结，那么咱们就能够在 visitEnd 中进行定位：

@Override
public void visitEnd() {super.visitEnd();
    int startLine = this.startLineNumber;
    int endLine = this.lineNumber;
    boolean isContained = false;
    if (this.mChangedLineInfo!=null&&mChangedLineInfo.lineNumbers!=null&&mChangedLineInfo.lineNumbers.size()>0){for (String line : this.mChangedLineInfo.lineNumbers){if (line!=null){int lineNum = Integer.parseInt(line);
              // 是否落在 xx 办法中
               if (lineNum>=startLine&&lineNum<=endLine){
                   isContained = true;
                    break;
                 }
              }
          }
      }
      if (isContained&&this.methodNameList!=null){
         // 蕴含在此办法中
         MethodName nameContained = new MethodName();
         nameContained.methodName = name;
         this.methodNameList.add(nameContained);
        }
              // 保留
        methodInsMapList.put(name, mMethodInsInfoList);
    }

至此，咱们通过自定义 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，所以上行链路的扫描比照上行链路更为简单。而对于研发或者测试，零碎的 API 可能对咱们的影响较小，所以在扫描上行链路的过程中，咱们须要去辨认以后办法体指令是否为零碎 API。

在辨认去除零碎 API 后，剩下的即是咱们的业务逻辑办法，那么又回到了办法体中各个指令的上行链路扫描，办法跟上行链路统一。

对于零碎的 API 以及一些三方库，咱们大抵总结了一下几种，供大家参考：

public static final String[] SYSTEM_PACKAGES = {"java/*", "javax/*", "android/*", "androidx/*","retrofit2/*","com/airbnb/*","org/apache/*"};

示意图如下：

至此，咱们实现了办法上 / 上行链路的搜寻。

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 类：

    public static  class JDDoclet {public static boolean start(RootDoc root) {
            JDJavaDocReader.root = root;
            return true;
        }
    }

接下来简略的封装 tools 中的 execute 办法：

public synchronized static RootDoc readDocs(String source, String classpath,String sourcepath) {if (!Strings.isNullOrEmpty(source)){ //java 源文件或者为包名
            List<String> args = Lists.newArrayList("-doclet",
                    JDDoclet.class.getName(), "-quiet","-encoding","utf-8","-private");
            if(!Strings.isNullOrEmpty(classpath)){args.add("-classpath");//source 的 class 地位，能够为 null，如果不提供无奈获取残缺正文信息（比方无奈辨认 androidx.annotation.NonNull）args.add(classpath);
            }
            if(!Strings.isNullOrEmpty(sourcepath)){args.add("-sourcepath");
                args.add(sourcepath);
            }
            args.add(source);
            int returnCode = com.sun.tools.javadoc.Main.execute(JDJavaDocReader.class.getClassLoader(),args.toArray(new String[args.size()]));
            if(0 != returnCode){Log.i(TAG,"javadoc ERROR CODE = %d\n", returnCode);
            }
        }
        return root;
    }

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

根本封装实现后，就能够间接应用了，然而思考到在遍历应用的过程中会呈现屡次调用解析 ClassDoc 的问题，这里还是倡议将解析过的 Java 文件进行缓存解决，不便间接调用，也能缩小整个编译的工夫，并且在解析过程中咱们也须要排除零碎类的解析。

//.... 略
if(classDoc!=null){javaDocFile.append("\n\n")
      // 获取类正文并写入文件
     javaDocFile.append(classDoc.getClassComment())
     javaDocFile.append(className+"\n")
     doc = classDoc.getClassDoc()}
//.... 略
if (doc!=null){for (MethodDoc methodDoc : doc.methods()) {
         // 增加自定义 Tag
         methodDoc.tags(MethodBuildConstants.CUSTOM_TAG)
         if (method.methodName.trim() == methodDoc.name().trim()){Tag[] tags = methodDoc.tags()
             if (tags!=null&&tags.length>0){
                     // 取自定义 Tag 内容
                 for (int i = 0;i<tags.length;i++){if (tags[i].name() == "@"+MethodBuildConstants.CUSTOM_TAG){javaDocFile.append(tags[i].text()+"\n")
                          javaDocFile.append(method.methodName+"\n")
                        }
              }
           }else{// 如果没有 tag 则输入对应的所有正文
                javaDocFile.append(methodDoc.commentText()+"\n")
                javaDocFile.append(method.methodName+"\n")
            }
         }
      }
  }

这里咱们也给出自定义 Tag，当然，在我的项目中能够依据本人的业务名称进行命名。

/**
 * 自定义 tag 标签
 */
public static final String CUSTOM_TAG = "LogicIntroduce";

实现了性能的开发，咱们须要在代码中中进行验证，测试如下：

/**
 * 打印办法（谁调用就会被打印），会打印两次
 * @LogicIntroduce 这个是自定义 Tag  getPrintMethod 办法
 */
public static void getPrintMethod(){System.out.println("我被调用了");
    getPrintMethod2();}

当咱们的办法调用链波及到 getPrintMethod()时，就会提取 @LogicIntroduce 标签前面的内容，达到了获取业务逻辑阐明正文的目标。这样对于那些不动代码的非研发人员，也可能十分清晰的看懂这部分代码波及到的业务逻辑，测试也可能着重的进行测试了。

本地输入：

影响类：com/jd/fragment/test/utils/TestUtils.java（测试类）影响办法：getPrintMethod（这个是自定义 Tag  getPrintMethod 办法）

5. 举荐理论业务应用

办法的调用高低链路在上述步骤中曾经生成，咱们能够在 MarkDown 中简略的生成调用链，至于要遵循什么样的格局，大家能够本人查阅，绝对比较简单不再开展。上面是举荐位最近一次批改波及到的局部流程图：

代码批改地位输入为：

com/jingdong/xxx/RecommendItem.java // 被批改的文件
252     // 批改的行

向上调用链展现：

向下调用链，咱们只取本办法体：

相干 Javadoc 输入：

// 上行调用链
影响类：com/jingdong/xxx/RecommendItem（举荐位根底数据 bean 对象）影响办法：productExpoData（生成曝光数据给内部应用）generateExpoData（商卡结构曝光用数据）setData（服务端 JSON 数据解析）影响类：com/jingdong/xxx/RecommendProductPageView（举荐 UI 组件）影响办法：toRecomendList（网络接口返回数据）影响类：com/jingdong/xxx/RecommendProductPageView$3（服务端数据处理（外部类））影响办法：toList（接口数据处理）// 上行调用链
影响类：com/jingdong/xxx/RecommendItem（举荐位根底数据 bean 对象）影响办法：productExpoData（生成曝光数据给内部应用）-com/jd/xxx/JDJSONObject

五、总结

通过下面的形容，咱们整体上实现了再 Android 端的代码影响范畴工具摸索，过程中实现了 Git 定位，生成办法调用的上、下链路，以及通过 JDK 工具 jar 包实现正文以及自定义 Tag 的内容获取，也通过 MarkDown 生成了对应的流程图。上面是整个工程的流程阐明图：

对于这个工具来说，咱们仅仅是对 Android 客户端的摸索开发，目前已在举荐组进行试用，应用过程中还有一些问题以及流程须要进一步改善和优化，比方，当一个办法被多处调用则生成的关系图就会过来宏大，不容易被浏览；无奈突出调用链节点的一些要害节点；JavaDoc 强依赖于研发，如果正文不标准或者不写，那整个链路的阐明就会断掉等等，咱们会持续性的去优化打磨这个工具，也会在应用过程中增加一些更贴近业务的性能，或者调整局部流程，比如说会在本地编译触发或者手动触发，或者增加一些 JavaDoc 的模板等等。这些性能会在业务应用过程中进行调整。后续，也会在服务端铺开，逐渐的拓展业务面，为咱们的业务开发交付降本增效。

参考文档：

https://docs.oracle.com/javas…

https://git-scm.com/docs/git-…

​