AGP 演进与版本升级总览
说实话，做 Android 构建优化这些年，我最大的感触就是：AGP 版本升级从来不是简单改个数字的事。每跳一个大版本，Gradle 的构建行为、任务编排、缓存策略都会跟着变。你要是没搞清楚这些变化背后的逻辑，光看瀑布图找瓶颈，很容易被表象带偏。
1.1 AGP 发展简史：从 1.0 到 8.x 我经历了什么
AGP 最开始就是个打包脚本。我记得 2013 年刚接触 Android Studio 时，AGP 还是 0.x 版，连 MultiDex 都要靠手动配。后来到了 AGP 2.x，才开始有像样的构建变体（Build Variant）概念。真正让构建效率有质的飞跃，是 AGP 3.0 之后引入了增量编译——说白了，就是只编译你改过的文件，不用每次都全量重编。
嗯，这里有个坑我要提下：AGP 3.0 的增量编译默认是开启的，但如果你用了自定义 Task 且没有正确声明输入输出，增量就无效。我曾经被一个混淆配置搞崩溃过——每次改一行代码，构建却要 40 秒，瀑布图分析后才发现是自定义 Task 偷懒用了 @OutputDirectory 指向整个 build 目录。
| AGP 版本 | Gradle 最低要求 | 关键变化（构建相关） | 我的评价 |
|---|---|---|---|
| 1.0 – 2.x | 2.x | 基本打包，无增量 | 慢到怀疑人生 |
| 3.0 – 3.6 | 4.x – 5.x | 引入增量编译、D8、R8 | 终于能用了 |
| 4.0 – 4.2 | 6.x – 7.x | 启用 Java 11、构建缓存优化 | 稳定，我项目里用得最多 |
| 7.0 – 7.4 | 7.x – 8.x | Configuration Cache、非传递式 R 类 | 坑也不少，但值得升 |
| 8.0 – 8.x | 8.x+ | Kotlin 1.9+、并行任务增强 | 当前主力，速度提升明显 |
核心观点：AGP 每次大版本升级，基本上都在做三件事——提高编译效率、减少冗余任务、增强缓存命中率。理解了这三条主线，你才能看懂瀑布图里那些陡峭的柱子到底怎么回事。
1.2 主流版本升级路线图
你可能会问：这么多版本，我该走哪条路线？其实主流就两条：
- 稳妥派：逐个大版本升，比如 4.2 → 7.4 → 8.2，每步停留一个月观察回归。
- 激进派：直接跳到最新稳定版，然后用 AGP Upgrade Assistant 一键迁移。
我个人习惯是走稳妥路线。为什么？因为 AGP 7.0 开始引入了 Configuration Cache，这东西一旦触发 SerializationException，整个项目的构建都会炸。我记得有一次升级到 7.2 后，只要改了 build.gradle 里的一个 ext 属性，配置阶段就会报错，排查了一整天才发现是某个三方插件没适配新缓存格式。
避坑指南：我曾经在 AGP 7.0 升级时，直接跳过了 4.2 的所有小版本，结果开发机上的 Gradle Daemon 频繁 OOM。后来查文档才发现，AGP 7.0 对 Gradle 堆内存的默认分配策略变了，需要手动设 -Xmx4096m。所以升级时一定要看官方的 Migrations Guide。
1.3 大版本升级对构建速度的潜在影响
说白了，每个大版本升级都会改变构建任务的执行顺序、并行度以及缓存策略。我总结了三类最明显的影响：
- 增量编译效果波动：AGP 3.x 到 4.x 增量编译变得激进，但如果你用了 databinding，它反而会拖慢第一次编译。因为 databinding 的注解处理器会在增量模式下重新生成所有绑定类。
- Resource shrinker 性能变化：AGP 4.0 之后，资源缩减（shrinkResources）默认使用 AAPT2 的
--no-version-vectors参数，但如果你项目中用了大量 vector 图片，这步反而变慢。 - Configuration Cache 的双刃剑：AGP 7.0+ 的 Configuration Cache 能让你第二次及以后的构建快 30%~50%，但第一次开启时会额外花时间去序列化配置。而且如果插件不兼容，缓存会无限失效，导致每次都是全量构建。
警告：不要以为升级后瀑布图一定会变平。我曾见过一个项目从 AGP 4.2 升到 7.4 后，:app:mergeDebugNativeLibs 这个 task 执行时间反而从 2 秒暴增到 12 秒。原因就是新版本把 CMake 任务的输出粒度改成了按架构分，导致 I/O 压力增大。所以每次升级后，必须拿 build scan 或 profile.json 跑一遍对比。
1.4 AGP 演进与构建性能影响关系图
下面这张图梳理了 AGP 各版本的关键变化与构建性能的对应关系。节点颜色越深，代表那个版本对构建速度的冲击越大。
从这张图你能看出，每个 AGP 版本其实都在往编译效率、缓存、并行这三个方向走。但具体到你的项目，哪个方向对构建速度提升最大？这就需要后续章节里提到的瀑布图诊断法了。
1.5 小结：升级前必须做的准备
打算升级 AGP 版本？我建议你先做这三件事：
- 跑一次完整的 build scan，记录当前各个阶段耗时（配置、任务、解析）。
- 检查项目依赖的三方插件是否声明了支持的 AGP 版本范围。我见过很多升级卡死在 Kotlin 插件版本不兼容上。
- 准备好回滚方案——用 Git 单独拉一个升级分支，把 build.gradle 和 gradle-wrapper.properties 都锁住。
说白了，AGP 版本升级就像一场手术：不做不行，但动了刀子就可能出并发症。只有把术前检查（瀑布图）做好了，你才知道该切哪块。