记一次AAR找不到分支的囧境

组件化之后,主工程就变成了一个壳子,作用基本就是集成各种aar进行打包,那么随之而来的问题就是:一旦AAR出了什么问题,怎么知道这个AAR是从哪儿来的。当然AAR从哪儿生成的,总能够追查到是哪个子工程。所以一般情况下,这个问题会被细化为:这个AAR包是从这个子工程的哪个分支打出来的。一般情况下:

  • AAR的版本号可以约定与分支具有映射关系,从团队规范角度规避一些问题
  • 可以通过集成工具管理工程中的组件依赖关系,包括子工程AAR出包。这样包本身只依赖于集成工具输出,集成工具来记录工程地址、分支与输出包的关系。这个可谓是万全之策——虽然相对而言成本比较大

然而总是会存在一些特殊情况的。集成工具尚在迭代、团队规范无从约束的情况下——幺蛾子就来了。日前接到一个隔壁组同事提出的问题,一个他们需要更新的AAR包,找不到具体的分支,无从下手。按照命名规范和一些开发规律看过去,只能找到对应工程的最近的一个版本的git提交;并且主工程的版本依赖修改commit又相当糙,根本想不起来这个更新的原因和责任人。最终只能判断当时是:为了解决临时BUG,相关人员在本地推了AAR到maven服务器,但是代码并没有上传。

问题还是要解决的。既然找不到人,唯一的期待就是能够搞清楚这个找不着跟脚的AAR跟能找到的最近的AAR有什么改动,如果改动不大的话,还是有救的。

定位

所以问题就变成了如何比较两个不同版本的AAR内容,并且分析出改动点在哪里。

好在有Beyond compare这种神器。从maven上把两个版本的AAR下载下来,解压之后进行文件夹对比:

aar-compare

Beyond Compare直接对比JAR包的功能还是很彪悍的。本来也可以判断h1版本,一般是hotfix——修改BUG的一些更新。这样结果就比较直观了,so库可能有更新,这一点不用管太多,大不了更新成新的就好;另外只有一个类代码有修改。进入类代码内部,基本就可以判断修改内容了。

总结

  • 组件化必然会带来包版本管理的各种问题,最好的解决方式还是通过成熟的集成平台来处理各个组件的发布;最终状态应该是发布版本杜绝使用手动发布的方式上传AAR,让线上使用的每个AAR都能找到开发分支
  • git commit不应该成为摆设,书到用时方恨少,对commit也是一样的
  • 编程规范,或者一些团队性质的开发流程约束,最后最好可以有检查的环节,无论是使用工具还是人工,最终目的是形成闭环,而不是让它变成一纸空文
感谢您赏个荷包蛋~