今日头条 Android ‘秒‘ 级编译速度优化

2401_84123094

于 2024-04-06 09:33:29 发布

阅读量1k

点赞数 23

分类专栏：程序员文章标签： android

本文链接：https://blog.csdn.net/2401_84123094/article/details/137419528

版权

由于 18 年左右客户端基础技术相关同学已经对今日头条 Android 工程做了许多 gradle 相关的优化，且这些优化是近期优化的基础，因此先挑选几个具有代表性的方案进行介绍，作为下文的背景同步。

maven 代理优化 sync 时间

背景

gradle 工程往往会在 repositories 中添加一些列的 maven 仓库地址，作为组件依赖获取的查找路径，早期在今日头条的项目中配置了十几个 maven 的地址，但是依赖获取是按照 maven 仓库配置的顺序依次查找的，如果某个组件存在于最后一个仓库中，那前面的十几个仓库得依次发起网络请求查找，并在网络请求返回失败后才查找下一个，如果项目中大多组件都在较后仓库的位置，累加起来的查找时间就会很长。

优化方案

使用公司内部搭建的 maven 私服，在私服上设置代理仓库，为其他仓库配置代理（例如 google、jcenter、mavenCentral 等仓库），代理仓库创建好后，在 Negative Cache 配置项中关闭其 cache 开关：如果查找时没有找到某版本依赖库时会缓存失败结果，一段时间内不会重新去 maven 仓库查找对应依赖库，即使 maven 仓库中已经有该版本的依赖库，查找时仍然返回失败的结果。
建立仓库组，将所有仓库归放到一个统一的仓库组里，依赖查找时只需要去这个组仓库中查找，这样能大大降低多次发起网络请求遍历仓库的耗时。

模块 aar 化

背景

今日头条项目进行了多次组件化和模块化的重构，分拆出了 200 多个子模块，这些子模块如果全都 include 进项目，那么在 clean build 的时候，所有子模块的代码需要重新编译，而对于大多数开发人员来说，基本上只关心自己负责的少数几个模块，根本不需要改动其他模块的代码，这些其他 project 的配置和编译时间就成为了不必要的代价。

优化方案

对于以上子模块过多的解决方案是：将所有模块发布成 aar ，在项目中全部默认通过 maven 依赖这些编译好的组件，而在需要修改某个模块时，通过配置项将该模块的依赖形式改为源码依赖，做到在编译时只编译改动的模块。但是这样做会导致模块渐渐的又全部变为源码依赖的形式，除非规定每次修改完对应模块后，开发人员自己手动将模块发布成 aar ，并改回依赖形式。这种严重依赖开发人员自觉，并且在模块数量多依赖关系复杂的时候会显得异常繁琐，因此为了开发阶段的便利，设计了一整套更完整细致的方案:

开发时，从主分支拉取的代码一定是全 aar 依赖的，除了 app 模块没有任何子模块是源码引入。
需要修改对应模块时，通过修改 local.properties 里的 INCLUDES 参数指定源码引入的模块。
开发完成后，push 代码至远端，触发代码合并流程后，在 ci 预编译过程与合码目标分支对比，检测修改的模块，将这些模块按照依赖关系依次发布成 aar ，并在工程中修改依赖为新版本的 aar, 这一步保证了每次代码合入完成后，主分支上的依赖都是全 aar 依赖的。