AGP版本差异瀑布图分析构建速度瓶颈案例 - 第1节
一、AGP 的诞生：为什么我们需要它？
说实话，早期的 Android 开发更像是一场“手工打造”的过程。
2013 年之前，Android 团队用的还是 Ant 这种老古董来打包。后来出了 Gradle，它本身只是个构建框架，不懂 Android 特性。于是 Google 在 2013 年推出了——Android Gradle Plugin（简称 AGP）。
它扮演的角色是什么呢？说白了，就是个“翻译官”。
- Gradle 负责流程和依赖管理
- AGP 负责把 Android 特有的资源、代码、清单文件，打包成一个可运行的 APK
我刚开始接触 AGP 是在 2014 年，那时候还只有 0.x 版本。记得第一次用它打包，看着控制台刷屏的信息，心里想的是：这东西到底比我用 Ant 快在哪？嗯……后来我知道了，慢，恰恰是我们今天要分析的主题。
一句话总结：AGP 是 Android 项目的“打包引擎”，它决定了你的构建速度、产物质量，以及能不能跟上 Android 生态的更新节奏。
二、版本号规则：别被数字骗了
AGP 的版本号一直在变。我见过不少朋友以为版本号越大越好，其实不是这么回事。
它的版本规则经历了三个阶段：
1. 早期：0.x → 1.x（2013-2015）
- 0.x 时期：功能不全，频繁更新，几乎每两周一个版本
- 1.0.0：2014 年底发布，标志着 AGP 走向稳定
2. 中期：1.x → 3.x（2015-2018）
- 1.x 到 2.x：引入了多维度构建、Jack 工具链
- 2.3.0：开始支持 Instant Run（虽然很鸡肋）
- 3.0.0：开始强制配合 Gradle 4.x 使用
3. 近期：3.x → 8.x（2018-至今）
- 3.2.0：正式引入 D8 编译器
- 4.1.0：引入 R8 混淆
- 7.0.0：强制使用 Java 11，移除 Jack
- 8.0.0（2023）：支持 Gradle 8.x，构建速度提升
这里我提个避坑指南：我曾经看到有人直接升级到 AGP 8.x 而不升级 Gradle，结果构建直接炸了。 为什么呢？因为 AGP 和 Gradle 版本必须严格匹配。
| AGP 版本 | 最低 Gradle 版本 | 推荐 Java 版本 |
|---|---|---|
| 4.0.x | 6.1.1 | Java 8 |
| 7.0.x | 7.0 | Java 11 |
| 8.0.x | 8.0 | Java 17 |
注意：AGP 高版本会逐步淘汰旧特性。比如 Android 12 开始，不再支持旧的 compile 配置，必须改用 implementation。如果你还在用 compile，升级就是灾难。
三、主要里程碑：哪些改变影响了我们的构建速度？
从 1.0 到 8.x，AGP 经历了无数次更新。但真正对构建速度产生“质变”的，只有几个关键节点。
1. D8 编译器替代 DX（AGP 3.2 开始）
DX 是 Google 自己的字节码转换工具，但它太老了。D8 更高效，编译速度提升约 20%。
我记得当时我们有个项目，从 DX 换成 D8 后，增量编译从 45 秒降到了 35 秒。听起来不多，但对每天打包几十次的我来说，节省的时间就很可观了。
2. R8 替代 ProGuard（AGP 4.1 开始）
ProGuard 在 2019 年基本不更新了。R8 是 D8 的兄弟，它把混淆和优化合并到同一个阶段。构建速度提升 10%-15%。
为什么快？ 因为 R8 不再像 ProGuard 那样做两次字节码转换，而是一次到位。
3. 构建缓存与配置缓存（Gradle 4.6+）
这其实不是 AGP 的功劳，但 Gradle 的性能优化直接影响了 AGP。构建缓存让第二次构建快了 30% 以上。
避坑指南：我曾经在一个旧项目里发现构建缓存根本没生效，原因是缓存的路径包含了系统用户名，换了人编译就失效。后来我们统一了 GRADLE_USER_HOME 环境变量，才算真正用上。
四、知识框架图
下面这张图，是我梳理的 AGP 版本演进关键脉络。你可以把它当作后续分析的“地图”。
五、对我构建速度分析的启发
你可能会问：知道这些历史有什么用？
嗯，我个人习惯是——分析问题之前，先搞清楚工具的“前世今生”。
- 如果你项目还在用 AGP 3.x，那构建慢可能来自 D8 未启用
- 如果用了 AGP 7.x 还慢，那大概率是配置缓存或依赖的问题
- 如果你升级到 AGP 8.x 后变慢，别慌，可能是 Kotlin 版本不匹配
实战建议：打开你的 build.gradle 文件，看看当前 AGP 版本。如果低于 7.0，我建议你至少升级到 7.4，因为那之后的优化最明显。