代码影响范围工具探索

作者：京东零售田创新、耿蕾

一、背景

1.祖传代码不敢随意改动，影响规模无法评估。而且组内经常有由于修正了某块代码，导致其他事务受到影响，发生bug，影响生产。

2.研制提测完结后，测验进入测验后经常会向研制询问本次需求改动影响规模，以此来承认测验用例，以到达精准测验，提升整个需求的质量，缩短交给周期。

那么，怎样才干躲避这种危险？有没有一种东西能够帮忙代码研制及review人员愈加准确的判别当时代码改动影响规模，有没有一种办法能够供给除了事务逻辑条件验证，针对代码效果规模，给测验人员供给准确验证链路？

二、计划调研

技能计划调研

通过各方资料查找及比对，终究咱们收拾了两个满意咱们需求的计划：

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

2.开源框架调研：wala/soot静态代码剖析东西。

针对上述的调研，大致承认了两种计划，集中剖析两种计划的好坏，来拟定契合咱们现在情况的计划：

东西称号	优势	劣势	是否契合
Call Hierarchy	支撑办法向上调用链	功用比较单一，数据无操作性	否
wala/soot静态代码剖析	能够完善的剖析Java中任何逻辑包括办法调用链，且满意咱们现在的需求	臃肿，杂乱繁琐，功用过于巨大	否

通过前期的比较以及相关东西的资料调研、东西功用剖析，并考虑到后期一些个性化功用定制开发，以上东西不太满意咱们现在的需求，所以决议自己着手，锦衣玉食，测验重新开发一个能够满意咱们需求的东西，来帮忙研制以及测验人员。

三、计划拟定

预期：东西尽量满意全自动化，研制只需求接入即可，削减研制参与，提升整个调用链展现和测验的效率。而且调用链路应该在研制打包的进程中触发，然后将数据上传至服务端，生成调用链路图。

上述计划拟定完结后，需求进一步承认完结进程。前期咱们承认了东西的大约的方向，并进行进程分化，依据详细的功用将整个东西拆分红六个进程

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$\ast 文件，包括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-docletcommand-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的模板等等。这些功用会在事务使用进程中进行调整。后续，也会在服务端铺开，逐渐的拓宽事务面，为咱们的事务开发交给降本增效。

参阅文档：

docs.oracle.com/javase/7/do…

git-scm.com/docs/git-di…

​