2021年展望Android原生开发的现状，你不懂还不学？

背景介绍

Android 项目一般使用 gradle 作为构建打包工具，而其执行速度慢也一直为人所诟病，对于今日头条 Android 项目这种千万行级别的大型工程来说，全量编译一次的时间可能高达六七分钟，在某些需要快速验证功能的场景，改动一行代码的增量编译甚至也需要等两三分钟，这般龟速严重影响了开发体验与效率，因此针对 gradle 编译构建耗时进行优化显得尤为重要。

在今日头条 Android 项目上，编译构建速度的优化和恶化一直在交替执行，18 年时由于模块化拆分等影响，clean build 一次的耗时达到了顶峰 7 分 30s 左右，相关同学通过模块 aar 化，maven 代理加速，以及增量 java 编译等优化手段，将 clean build 耗时优化到 4 分钟，增量编译优化到 20~30s 。但是后面随着 kotlin 的大规模使用，自定义 transform 以及 apt 库泛滥，又将增量编译速度拖慢到 2 分 30s ，且有进一步恶化的趋势。为了优化现有不合理的编译耗时，防止进一步的恶化，最近的 5，6 双月又针对编译耗时做了一些列专项优化(kapt,transform,dexBuilder,build-cache 等) 并添加了相关的防恶化管控方案。 从 4.27 截止到 6.29 ，整体的优化效果如下:

历史优化方案

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

maven 代理优化 sync 时间

背景

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

优化方案

1. 使用公司内部搭建的 maven 私服，在私服上设置代理仓库，为其他仓库配置代理（例如 google、jcenter、mavenCentral 等仓库），代理仓库创建好后，在 Negative Cache 配置项中关闭其 cache 开关：如果查找时没有找到某版本依赖库时会缓存失败结果，一段时间内不会重新去 maven 仓库