AGP 版本演进：从 3.x 到 8.x 的变与不变
如果你做过几年 Android 构建，一定被 AGP 版本折腾过。说实话，AGP 的版本跨度非常大，从 3.x 到 8.x，每次升级都像是一次“大考”。我自己就经历过几次迁移翻车，后来才慢慢摸清规律。这一节，咱们就捋一捋每个版本到底改了啥、哪些特性值得你记住。
3.x 时代：奠基
AGP 3.0 是 Android 构建工具链的一个分水岭。为什么这么说？从 3.0 开始，Gradle Plugin 强制要求使用 Gradle 4.x 以上，并且引入了 Java8+ 支持 —— 你可以在 Android 中愉快地使用 Lambda 和 Stream 了。我个人记得，当时为了把项目从 2.x 迁移到 3.x，光解决依赖冲突就花了两天。不过，从那以后构建速度确实快了不少。
4.x 时代：转型
AGP 4.x 最大的标志是 强制使用 AndroidX。那时我正在做一个大型电商 APP，support 库的依赖多到爆炸。迁移到 AndroidX 简直是一场噩梦，但长期来看，这为后来的 Jetpack 生态铺平了路。另外，4.x 也默认开启 R8 替代 ProGuard，并且原生支持 AAPT2。你想想看，之前用 AAPT 编译，遇到资源文件重复就得手工排除，AAPT2 直接解决了这个问题。
5.x 与 6.x：稳扎稳打
这两个版本其实是迭代优化期。5.x 重点改进了 Dexing 性能，尤其是多模块项目，增量编译终于不像以前那么慢。而 6.x 则把 JDK 11 作为推荐编译环境。我曾经在升级到 6.x 时忽略了这个配置，结果编译报了一大堆 “Unsupported class file major version”，后来发现只是 JDK 版本没跟上。
// AGP 6.x 推荐 gradle-wrapper.properties
distributionUrl=https\://services.gradle.org/distributions/gradle-7.0.2-all.zip
// 同时项目 JDK 必须 >= 11
7.x：新起点
AGP 7.x 最低要求 Gradle 7.x，这意味着你不能再偷懒用老版本的 wrapper 了。这个版本最让我印象深刻的是 Kotlin 构建脚本的完整支持 —— 你可以用 .gradle.kts 写全量配置，还能和 Java Plugin 无缝混用。另外，Android Test Coverage 的生成机制也改了，如果你之前用 Jacoco 手动配置，现在可以直接用官方 API。
8.x：未来已来
到了 8.x，AGP 变得更加激进。它 移除了大量旧版兼容性 API，比如默认关闭 Jack、禁用旧的 Dx 编译，强制使用 D8/R8。还有一个坑——AndroidManifest 合并行为变了，如果你的项目中有多个 module 定义了同样的 activity，8.x 会直接报错。我曾经在升级时遇到一个 app 无法安装，查了半天才发现是一个第三方库的 manifest 里多写了一个未注册 activity。
关键版本速览表
| AGP 版本 | 最低 Gradle | 核心变化 | 我的评价 |
|---|---|---|---|
| 3.x | 4.4+ | Java8+, 注解处理器分离 | 奠基之作，迁移成本高 |
| 4.x | 5.1+ | AndroidX, R8 默认, AAPT2 | 最伤筋动骨的一次升级 |
| 5.x | 6.1+ | Dexing 优化, AAPT2 增强 | 构建效率明显提升 |
| 6.x | 7.0+ | 增量构建, JDK 11 支持 | 稳定过渡，几乎无坑 |
| 7.x | 7.3+ | Kotlin DSL 全支持, 测试覆盖优化 | 值得升级，但注意 VariantFilter |
| 8.x | 8.0+ | 强制 R8, 移除旧 API, 性能飞跃 | 最新最强，但有破坏性变更 |
说白了，每个版本都藏着一些“暗雷”。我的建议是：不要盲目追新，也别死守旧版。先读 release note，再看自己的 CI 环境是否兼容，最后在小项目中验证。嗯，这样折腾下来，基本不会翻车。