组件化之后，主工程就变成了一个壳子，作用基本就是集成各种aar进行打包，那么随之而来的问题就是：一旦AAR出了什么问题，怎么知道这个AAR是从哪儿来的。当然AAR从哪儿生成的，总能够追查到是哪个子工程。所以一般情况下，这个问题会被细化为：这个AAR包是从这个子工程的哪个分支打出来的。一般情况下：
- AAR的版本号可以约定与分支具有映射关系，从团队规范角度规避一些问题
- 可以通过集成工具管理工程中的组件依赖关系，包括子工程AAR出包。这样包本身只依赖于集成工具输出，集成工具来记录工程地址、分支与输出包的关系。这个可谓是万全之策——虽然相对而言成本比较大
然而总是会存在一些特殊情况的。集成工具尚在迭代、团队规范无从约束的情况下——幺蛾子就来了。日前接到一个隔壁组同事提出的问题，一个他们需要更新的AAR包，找不到具体的分支，无从下手。按照命名规范和一些开发规律看过去，只能找到对应工程的最近的一个版本的git提交；并且主工程的版本依赖修改commit又相当糙，根本想不起来这个更新的原因和责任人。最终只能判断当时是：为了解决临时BUG，相关人员在本地推了AAR到maven服务器，但是代码并没有上传。
问题还是要解决的。既然找不到人，唯一的期待就是能够搞清楚这个找不着跟脚的AAR跟能找到的最近的AAR有什么改动，如果改动不大的话，还是有救的。
定位
所以问题就变成了如何比较两个不同版本的AAR内容，并且分析出改动点在哪里。
好在有Beyond compare这种神器。从maven上把两个版本的AAR下载下来，解压之后进行文件夹对比：
Beyond Compare直接对比JAR包的功能还是很彪悍的。本来也可以判断h1版本，一般是hotfix——修改BUG的一些更新。这样结果就比较直观了，so库可能有更新，这一点不用管太多，大不了更新成新的就好；另外只有一个类代码有修改。进入类代码内部，基本就可以判断修改内容了。
总结
- 组件化必然会带来包版本管理的各种问题，最好的解决方式还是通过成熟的集成平台来处理各个组件的发布；最终状态应该是发布版本杜绝使用手动发布的方式上传AAR，让线上使用的每个AAR都能找到开发分支
- git commit不应该成为摆设，书到用时方恨少，对commit也是一样的
- 编程规范，或者一些团队性质的开发流程约束，最后最好可以有检查的环节，无论是使用工具还是人工，最终目的是形成闭环，而不是让它变成一纸空文
