Android自动构建平台（Air Force）的功能与实现

背景

在组件管理和发布流程中，开发工具链之间处于信息孤岛状态，各个节点较为分散配置文件有很多，繁琐且易出错。

正式包发布流程复杂，需要和各个业务线来回确认很多次信息，沟通成本高、容易出错。

AirForce在这一背景下提上日程，大目标是承载组件化相关业务、提高组件管理和发布的稳定性和效率。

根据开发阶段不同的场景，把基线划分为三个状态开发中、预发布、已发布：

• 开发中

  这个阶段没有限制，开发人员可以自由的添加、删除、修改组件版本等操作。

• 预发布

  到这个阶段，不允许添加SNAPSHOT的组件，如果当前有SNAPSHOT类型组件一个小时通知一次，直到清零。

• 已发布

  只有SNAPSHOT类型组件清零才允许流转到此状态，到这个阶段不允许修改任何组件信息。

开发阶段组件变更单提交的较为频繁，很容易出现在未感知组件列表发生变化的情况下又提交了一个组件变更单，为了解决这个问题引入了traceId的机制，每次合入一个组件变更单时使用。

UUID.randomUUID()随机生成一个字符串作为所属基线的traceId，前端页面每次提交组件变更单时把拉取基线组件列表时返回的基线traceId带上来，这样就能判断出来本次变更是否有冲突。

经过一段时间的观察，发现这个机制虽然可以避免数据一致性问题，但是冲突概率很高，原因是第一次进入基线详情页面时才会拉取一次基线组件列表和traceId，大家都习惯一直开着这个页面等有需要时直接在当前页面上操作，这个时候离第一次打开页面已经过去很久了，组件列表可能已经被其它开发人员修改过了。

经过和业务方的沟通其实每个开发人员经常改的组件就四五个左右，基线组件列表有几百个组件，显然traceId方案力度太大，需要寻找一个更细化的比对方案。

这个时候想起了mysql的机制，traceId方案可以想象成数据库的表锁，更为细化的有行锁，模仿这个思想为每条基线组件数据加一个修改编号mod_number，每次这条记录有变动时+1，前端页面修改组件配置时把组件mod_number一并带过来，后台服务根据传过来的mod_number和当前组件的mod_number做对比就可以得知这个组件信息是否被修改过、添加组件时只判断这个组件不能存在、删除组件时判断这个组件要存在，新的机制在保证稳定的前提下大大减低了提交时的冲突概率。

之前对比两条基线组件变化情况使用手工对比JSON的方式，不太方便且容易遗漏，所以提供了此功能。

两条基线对比结果分为新增组件、组件变更、删除组件三种类型，对比的过程就是两个列表取差集。

首先把基线1的组件列表和基线2的组件列表分别转换为以ID为key的HashMap，然后分别把两个HashMap的KeySet拿出来创建新的HashSet。

• 新增组件 = KeySet2 - KeySet1

• 删除组件 = KeySet1- KeySet2

• 组件的变更内容是两个Set取交集，然后在做进一步比对

组件管理

发布插件执行完成publishMavenPublicationToMavenRepository任务后，把此次发布组件相关信息上报到AirForce后端服务，上传的信息大致如下:

• git仓库地址

• 发布人邮箱

• Maven groupId

• Maven artifactId

• 版本号

• gradle工程文件夹名

• 插件类型

• git分支

• pom url

• 发布插件版本

• pom文件sha1

• Source jar的sha1

• 包sha1

• Git comitId

• ...... 

后端拿到组件发布信息后，保存git仓库、组件、组件版本信息，从gitlab同步本次发布commit信息，最后发送飞书通知。

目前客户端的发版阶段，依赖发版人与业务线核对版本再统一打包，这一模式随着业务线的增加出现了发版时间长、沟通成本高、容易出错的问题。

提测阶段，打包产物可用性不高，偶尔出现代码错误导致的运行时异常，打包阻塞的问题也时有发生。

为了解决上述问题将发版模式改为班车发版。

由各业务线决定是否跟车，以及跟车的可发布版本，如果此次发布不跟车平台自动选择业务线上一个可用版本；发版人只维护App版本号、发版日期等基本信息。

开发和测试阶段，增加集成组件的卡口检查，避免代码问题影响持续集成的稳定性，后期还将完善测试、审核流程。

业务线Owner从候选版本中选择一个作为发布版本, 平台会做必要检查。

如果不发布, 默认使用之前发布版本。

发版人预先创建发布计划，明确App版本信息，基线和计划发版日期，平台通知业务线Owner。

打包构建的时候平台自动收集业务组件和三方组件，业务组件的版本来自业务线Owner的发布历史，三方组件来自基线。

在没有AirForce平台之前，打包都是在jenkins上打包的，业务线的Owner都要手动在jenkins上选择要打包的业务线的组件，而每个打包的产物和上传的产物也是不能动态配置的，打正式包和打测试包也没有区分开，每个打包的产物也要去oss后台上去看，可以说对于开发人员来说无疑增加了开发的时间，和对于文档需求的成本。

因此AirForce平台在把打包这任务构建这块变得更为的简洁，开发人员甚至不用关心oss后台和jenkins，直接在AirForce平台上操作就可以了。

在编译插件中，实现了通过参数配置的下发来判断是AirForce发布还是本地打包，从而实现无缝的可切换的过程，在此之外，在AirForce平台中，我们在开发时基于每个基线构建的时候也有动态的配置classpath的组件和动态的配置implementation的组件，从而实现完全的动态可配的特性。

客户端发布计划，主要兼容了AirForce发布和本地打包，原本的Baseline的参数不变，在AirForce发布计划的情况下新增了AirForce.Baseline，所以我们在build.gradle加载Classpath前统一做了拦截，保持了其他插件读取Baseline参数的统一。

而在构建详情中，原本我们从读取本地配置的渠道包，上传固定的产物到oss后台，而现在，我们把所有的逻辑统一收敛到了AirForce的平台,包括了动态的获取上传的产物，动态的配置渠道包的配置，从而让AirForce串起了整个流程，包括了获取和配置app的组件，获取和配置app的渠道包，获取和配置app上传的产物等，大大减少了各个业务线的发版和配置难度。

由于得物App采用的是壳工程+aar的形式，故修改或者重构底层的模块就显得要异常的小心，尤其是重构底层的模块。

举个例子，如果重构du_common 那就需要把其关联修改的类从aar的依赖变成源码依赖的模式，此举会导致编译过慢，而且如果此module被上层依赖的module过多，就很有可能会导致开发人员漏了修改某一个上层的aar，从而导致此重构的底层module发上去，有可能造成运行期的异常。

解决方案:

因此，为了解决此痛点，我们在打整包时执行了检测的task，通过在每个aar中生成每个info信息，然后调用compare.jar，此jar包能让下列aar中的异常情况都能被检测到，从而避免运行期异常，可以检测的异常情况如下:

1. 某一个模块的里的接口或者抽象类里的方法名字变更了或者是参数有变更，调用此task能检测出被影响的组件列表。

2. 某一个模块里的类重命名或者被删除了,调用此task能检测出被影响的组件。

3. 某一个模块里的方法名字或者方法参数发生变化了，调用此task能检测出被影响的组件。

实现图如下:

可以看到这里主要是获取被检测的业务组件的信息：

自己的类信息(shelfClassInfo)

• 包括了类的签名

• 类的访问权限

• 方法的访问权限

• 其父类信息

• 父类所在的module名字

• 接口信息

• 接口所在的module名字

• 方法的描述符

继承类的信息(inheritClassInfo)

• 类名

• 类的访问权限

实现接口的信息（inheritClassInfo）

• 类名
  

• 类的访问权限

调用其他module的类的信息(libsJarInfo)

• 方法名字

• 调用者的方法

• 方法描述符

• 调用者的类

然后把这些信息写到一个json文件中，通过封装的compare的jar包做统一的调用，从而分析出哪些类调用其他组件出现方法名缺失或者方法参数发生改变，要重写的方法未重写等,最后把比对的结果上传上去，然后去做统一的通知。

所以我们编译插件中，也添加了关于整包的runtime的crash的预检测的task，从而在包打出来之前提前发现此包会出现的runtime的异常，从而提前通知开发人员，从而减少运行时异常给开发人员带来的block，当然，此开关也是在AirForce平台上可配置的。