前言
这篇文章，其实在一年之前的时候就已经写好了。当时是在公司内部分享的，作为一个监控框架。当时是想着过一段时间之后，分享到技术论坛上面的，没想到计划赶不上变化，过完国庆被裁了。
当时忙着找工作，就一直没有更新了，放在笔记里面吃灰。
最近，发现好久没有分享技术文章了，从笔记里面找了一下，就拿来分享了。
在项目开发中，会有很多第三方依赖，通过 gradle 引入进来的。比如 androidxdesignversion、androidxsupportversion、 rxjava2version、 okhttpversion 等第三方库。有时候第三方库改到了或者升级了，我们并不能及时发现，往往需要等到出问题的时候，去排查的时候，才发现是某个依赖版本改动导致的。
这时候其实是有点晚了，如果能够提前暴露，那么我们能够大大地减少风险，因此我们希望能够监控起来。
基本原理
- 代码 merge 到 dev 分支的时候，借助 gitlab ci，促发 gradle task 任务，自动分析 dependency 链表
- 对比上一次打包的 dependency 链表，如果发现变更了，会通过 机器人进行通知。并附上最新的 commit，提交作者信息，需要 author 确认一下
执行流程
目前主要对 dev 分支进行监控，以下几种场景会促发 diff 检查
- mr 合并进 dev 分支的时候
- 在 dev 分支直接提交代码的时候
diff 报告
diff 报告主要包括以下几种信息
- 作者，当前 commitid 的 author
- branch 分支名
- commitid 当前的 commitid, basecommitid：基准 id
- 变动依赖，这里最多显示 6 行，超过会截断，具体变动可以见详情
- 提交：如果是 mr 合并进来的，会显示 mr 链接，否则，会显示 commit 链接
不同分支 merge 过来的 diff 报告
检测到 dependency 变化
分支: 573029_test
作者: 徐俊
commitid: 4844590b basecommitid: bed4cb64
变动依赖:
\--- project :component-matrix
\--- com.google.code.gson:gson:2.8.2 -> 2.8.9
详情: {url}
提交:{url}/merge_requests/4425/diffs
同个分支产生的 merge 报告
检测到 dependency 变化
分支: 573029_dep_diff
作者: xujun
commitid: 16145365 basecommitid: 4844590b
变动依赖:
\--- project :component-matrix
\--- com.squareup.retrofit2:converter-gson:2.4.0 (*)
详情: {url}
提交: {url)/commit/16145365
同个分支提交的 diff 报告
检测到 dependency 变化
分支: 573029_dep_diff
作者: xujun
commitid: 19f22516 basecommitid: 8c90d512
变动依赖:
\--- project :component-tcpcache
\--- com.google.code.gson:gson:2.8.2 -> 2.8.9
详情: {url}
提交: {url)/commit/16145365
我们主要讲述以下几点
- 我们需要监控怎样的 dendenpency 变化
- 怎样获取 dependency tree
- dependency tree 怎样做 diff
- 如何找到基准点，进行 diff 计算
- 怎样结合 ci 进行计算
具体实现原理
我们需要监控怎样的 dendenpency 变化
众所周知，android 的 dependency 是通过 gradle 进行配置的，如果我们在 build.gradle 下面配置了这样，证明了我们依赖 recyclerview 这个库。
dependencies {
implementation androidx.recyclerview:recyclerview:1.1.0 ”
}
那一行代码会给我们的 dendenpency 带来怎样的变化呢？
有人说，它是新增了 recyclerview 这个库。
这个说法对嘛？
不全对。
因为 gradle 依赖默认是有传递性的。他还会同时引入 recyclerview 自身所依赖的库。
--- androidx.recyclerview:recyclerview:1.1.0
| --- androidx.annotation:annotation:1.1.0
| --- androidx.core:core:1.1.0
| --- androidx.customview:customview:1.1.0
| \--- androidx.collection:collection:1.0.0 -> 1.1.0 (*)
- 如果项目当中当前没有这些库的，会同时导入这些库。
- 如果项目中有这些库了，库的版本比较低，会升级到相应的版本。比如 collection 会从 1.0.0 升级到 1.1.0
然而这些情况就是我们往往所忽略的，即使有代码 review，有时候也会漏了。即使 review 待了，可能下意识也只以为只引入了这个库，却很难看到它背后的变化。
而这些如果带到线上去，有时候会发生一些难以预测的结果，因此，我们需要有专门的手段来监控这些变化。能够监测到整条链路的变化，而不仅仅只是 implementation androidx.recyclerview:recyclerview:1.1.0 ” 这行代码的变化
至于如果依赖的传递性，可以通过 transitive、exclude 等用法做到。 可以看这些文章，这里不再一一展开。
怎样获取 dependency tree
获取 dependency tree 的话，有多种方式
- 通过
project.configurations这种方式获取 - 通过
gradlew :app:dependenciestask - 通过
asciidependencyreportrenderer获取，需要适配不同版本的 gradle 版本
project.configurations 方式
通过这种方式获取的，他是能够获取到所有的 dependencies，但是并不能看到 dependencies 的树形关系。
伪代码如下
def configuration = project.configurations.getbyname("debugcompileclasspath")
configuration.resolvedconfiguration.lenientconfiguration.allmoduledependencies.each {
def identifer = it.module.id
deplist.add(identifer)
}
./gradlew dependencies
./gradlew dependencies 会输出所有 configuration 的 dependcency tree。包括 testdebugimplementation、testdebugprovided、testdebugruntimeonly 等等
事实上，我们只关心打进 apk 包里面的 dependencies。因此我们可以指定更详细的 configuration 。即
gradlew :app:dependencies --configuration releaseruntimeclasspath
这样，就只会输出 release 包 runtimeclasspath 相关的东西。
runtimeclasspath 跟我们常用的 implementation，关系大概如下
在输出的 dependencies tree 报告中，我们看到的格式一般是这样的
** 这里有几个格式需要说明一下**
- x.x.x (*), 比如图中的 4.2.2(*), 该依赖已经有了，将不再重复依赖，
- x.x.x -> x.x.x 该依赖的版本被箭头所指的版本代替
- x.x.x -> x.x.x(*) 该依赖的版本被箭头所指的版本代替，并且该依赖已经有了，不再重复依赖
asciidependencyreportrenderer
asciidependencyreportrenderer 这个东东，在不同的 gradle 版本有不同的差异，需要适配一下。
如果要这种方案，建议将某个版本的代码剥离出来，伪代码一般如下，单独集成一个库。
project.afterevaluate {
log.i(tag, "afterevaluate")
val renderer = asciidependencyreportrenderer()
val sb = stringbuilder()
val f = streamingstyledtextoutputfactory(sb)
renderer.setoutput(f.create(javaclass, loglevel.info))
val projectdetails = projectdetails.of(project)
renderer.startproject(projectdetails)
// sort all dependencies
val configuration: org.gradle.api.artifacts.configuration =
project.configurations.getbyname("releaseruntimeclasspath")
renderer.startconfiguration(configuration)
renderer.render(configuration)
renderer.completeconfiguration(configuration)
// finish the whole processing
renderer.completeproject(projectdetails)
val textoutput = renderer.textoutput
textoutput.println()
log.i(tag, "end sb is $sb")
}
方案选择
从上面阐述可知，第一种方案 project.configurations, 通过这种方式获取的，他是能够获取到所有的 dependencies，但是并不能看到 dependencies 的树形关系。
第二种方案 ./gradlew dependencies 的优点是简单，直接采用 gradle 原生 task，输出特定格式的文本。然后根据规律将所有的 dependency tree 提出出来。
可能有人担心 ./gradlew dependencies 的输出格式会变化。
其实还好，看了几个 gradle 版本的输出格式，基本都是一样的。
第三种方案 asciidependencyreportrenderer 的优点是可定制性高，缺点是麻烦，需要适配不同版本的 gradle。
最终我选择的方案是方案二。
怎样对 dependency tree 进行 diff 计算
传统 diff 方案
可能很多人想到的方案是使用 git diff 进行 diff 计算。但是这种方式有局限性。
- 当有多个修改的时候，key -value 可能无法一一对应。
- 他的 diff 类型 add、remove、 change 并不能一一对应我们 dependency add、remove、 change 的类型。
这无法达到我们想要的结果。因此，我们需要整合自己的 diff 算法。
自定义的 diff 方案
这里的方案是借鉴了 jakewharton 大神的方案，在其基础之上进行了改造。
原理大概如下
- 分别计算当前，上一次的 dependency tree，用 set
- 储存，分别表示为 oldpaths，newpaths
- 接着根据 oldpaths 和 newpaths 计算出 removedtree， addedtree， changedtree
- 最后，根据 removedtree， addedtree 计算出 diff
第一步
对于这里的依赖，我们会使用 set 的数据结构储存
转换之后的数据结构
这样的好处就是可以看到每一个 dependency 的全路径，如果 dependency 的全路径不一样，那么可以 diff 出来。
第二步 计算 remove 树 和 add 树
有了第一步的基础，其实很简单，直接调用 kotlin 的扩展方法 set
如何找到一个基准点，进行 diff 计算
其实，这个说到底，就是找到上一个 commit 提交的 diff 文件。
- 看是不是 mr，如果是 mr，我们应该找到 mr 合并前的一个 commit
- 不是 mr 合并进来的，我们直接找到上一个 commit 即可
因此，我们可以借助 git 命令来处理。对于 merge request，目前主要有几种情况会产生 merge request。
- 直接 mr 合并进来的，这时候 parent 会产生两个点，我们去 parent[0] 即可
- 当前本地分支落后远程分支， 且 local 分支有 commit 的时候，pull 或者 push 的时候，会产生一个 merge 节点，这时候 parent 会产生两个点，我们去 parent[1] 即可
原理图如下：
怎样集合 gialab ci 进行计算
gialab push 或者 merge 的时候，我们需要感知到，接着执行特定的 task，进行计算。 每个公司的 ci 可能不太一样，具体可以修改一下
gradlew :{appname}:checkdepdiff
总结
dependency diff 监控的原理其实不难，主要是涉及到挺多方面的，有兴趣的可以看一下。如果觉得对你有所帮助的话，希望可以一键三连。
