JetBrains Amper 0.10 ，期待它未来替代 Gradle

最近 JetBrains 发布了 Amper 0.10 ，做为一个面向 Kotlin / Java 的实验性构建和配置工具，他的目标是通过更简单的 YAML 配置去支撑 Kotlin Multiplatform、Android、iOS、JVM 等项目管理，然后再通过 Amper CLI 完成构建、运行和工具集成。

这一次 Amper 0.10 更新之所以要聊聊，是因为它经过几年发展，它已经相对变得完善了不少，这次 0.10 主要包括了：

• JDK provisioning，可以自动下载和安装匹配的 JDK，默认是 JDK 21，支持在 module.yaml 里声明需要的版本
• Maven to Amper 转换，可以读取现有 pom.xml，生成 project.yaml / module.yaml
• 支持第三方 Kotlin compiler plugins
• 默认工具链版本包含 Android minSdk 23、Kotlin 2.3.20、Compose 1.10.3、KSP 2.3.6

那 Amper 有什么用？简答来说，通过 Amper 可以替代现在烦人的 Gradle ，AGP 如今的体验可以说是又臭又长，特别是现在 KMP 时代，build.gradle.kts 往往越来越厚 ，而 Amper 的目的是通过 YAML 来让 IDE 更容易理解项目结构、做自动补全、特别是针对 KMP 用 YAML 来声明模块、平台、依赖和平台特定配置。

看 2024--2026 的更新，Amper 不断补充的是 project file tooling、Compose resources、KSP2、Android release builds、run/test UX 这些能力，可以看出来在一步一步地侵蚀 Gradle 原本的场景。

特别是，现在对于 Amper 来说，standalone version （脱离 Gradle）已经变成主要发展方向，Gradle 版本逐步弱化，而对 Android 来说，Amper 可以让项目配置更省心：

• JDK 自动准备好，可以灵活配置
• 模块定义更直观
• KMP/Compose/Android 放在同一套声明模型下

虽然一开始 Amper 是建立在 Gradle 上的配置层，但是后来它自己也逐步发展出 standalone CLI、独立命令体系和自己的项目文件，也就是它既可以在 Gradle 生态逐步发展，也可以独立出自己的运行模式，只是目前越来越脱离 Gradle，大概类似于：

Amper = JetBrains 在 Kotlin/KMP/Android 构建体验上的新抽象层和新入口。

因为 Gradle 本质是一个可编程 DSL，所以它既可以写逻辑，又可以写条件，还可以 hook 生命周期，所以老项目的结果往往就是，配置文件逐渐变成"代码工程本身的一部分"。

而这个问题在 KMP 上变得更明显，因为多平台以来之后，环境，脚本和 CI 也变得更加复杂，但是 Amper 不一样，Amper 的官方定义是：

一个面向 Kotlin 和 Java 的构建工具，使用 YAML 进行声明式配置，并提供 CLI 和 IDE 集成。

例如在之前 Gradle 常见写法是：

kotlin {
    android()
    ios()
​
    sourceSets {
        val commonMain by getting {
            dependencies {
                implementation("xxx")
            }
        }
    }
}

而在 Amper 里，写法就是：

product:
  type: app
​
platforms:
  - android
  - ios
​
dependencies:
  - xxx

那为什么说它会变得更好，因为它的集成度和全自动化，例如 Amper 可以自动下载 JDK 和自动匹配版本，用官方的话说就是：

开发者可以在不手动安装任何东西的情况下就能运行项目。

也就是，用 Amper 的目的是它自己就可以负责"环境一致性"，特别是前面我们说过， 2024--2026 的各种更新内容有：

• project model（项目结构）
• Compose resources（资源处理）
• KSP2（代码生成）
• Android release builds（发布构建）
• run / test UX（运行与测试）
• compiler plugins（编译扩展）
• JDK provisioning（环境管理）

从这些更新，可以看到一个非常清晰的覆盖路径，路径几乎就是 Gradle 在 Android 项目里的核心职责。

另外 Amper 的角度， 构建工具不只是单纯的"工具"，而是带 toolchain、默认版本、项目模型的一体化生态产品，并且 Declarative 的 YAML/TOML 也在逐步替代 Gradle DSL ，因为 AI 时代：

DSL 太强，IDE 太难理解，特别是多平台下，必须要一个更简单的模型。

还有个适配小技巧，复制 gradle 然后粘贴到 module.yaml 时，它会自动转换为 Amper 适配的模式：

所以，目前虽然 Amper 0.10 还不是正式的 Gradle 的替代者，但它已经在系统性接管 Gradle 的职责，至少在 Kotlin/KMP/Android 的 JetBrains 生态里，Amper 已经不只是一个实验配置层，而是在被持续推进成为新的构建入口。

所以可以预期，未来 Amper 完全替代 Gradle 的哪一天，就可以不再面对这个又臭又大的 AGP 了。