前言
大家肯定也都或多或少的写过一些Groovy代码，但由于不支持代码提示及编译时检查，使用Groovy开发的体验并不太好，Android Gradle插件4.0之后支持在Gradle构建配置中使用Kotlin 脚本 (KTS)，用于替代 Groovy（过去在 Gradle 配置文件中使用的编程语言）。
KTS 比 Groovy 更适合用于编写 Gradle 脚本，因为采用 Kotlin 编写的代码可读性更高，并且 Kotlin 提供了更好的编译时检查和 IDE 支持。
但是文档中也提到了，虽然与 Groovy 相比，KTS 当前能更好地在 Android Studio 的代码编辑器中集成，但采用 KTS 的构建速度往往比采用 Groovy 慢，因此在迁移到 KTS 时应考虑构建性能。
那么我们今天就来看下相比Groovy，KTS性能到底怎么样？为大家决定是否迁移到KTS提供一定的参考。
KTS性能分析
性能分析工具
要分析KTS的性能，我们首先需要稳定的测量编译的时间，编译速度可能受build cache等多种因素的影响，所以很难测量kts插件对性能的影响到底有多大
我们可以使用Gradle 性能剖析器来准确测量性能，这是一款用于收集 Gradle 构建的性能分析和基准化分析信息的工具。借助 Gradle性能剖析器，您可以创建构建场景并多次运行这些场景，以防止结果出现过大差异，并确保结果的可重现性。
基准化分析的部分项目设置配置包括：
- 插件版本
- Gradle 版本
- JVM 设置（堆大小、永久代大小、垃圾回收等）
- Gradle 工作器数量 (org.gradle.workers.max)
- 按插件选项进一步优化性能
比如我们需要对clean build进行基准化分析，您可以创建一个gradle-profiler执行的场景：
代码语言：txt复制# <root-project>/scenarios.txt
clean_build {
tasks = [":app:assembleDebug"]
cleanup-tasks = ["clean"]
}如需运行此场景，请使用以下命令：
代码语言：txt复制gradle-profiler --benchmark --project-dir <root-project> --scenario-file scenarios.txt通过以上命令，就可以多次运行clean build，并生成clean build性能报告。除了clan build，gradle-profiler还可以针对增量编译，不同的 Gradle 插件版本，以及不同的内存/CPU 等执行性能分析。
通过gradle-profile命令，可以创建构建场景并多次运行，可以防止结果出现过大差异，并确保结果的可重现性，以帮助我们更好地分析性能。
关于gradle-profile的具体使用，可以参考文档：分析构建性能
Gradle 6.8 版本性能分析
针对Gradle 6.8版本，我们从以下4个用例来分析KTS性能
- 首次运行(即清除所有build cache)
- buildSrc abi 更改(支持的abi发生变化，可以理解为大多数缓存失效，大部分代码需要重新编译)
- buildSrc 非 abi 更改(即buildSrc中的普通修改)
- 无改动
以下数据来自在Gradle CI上运行的性能测试。这些测试运行在一个包含大量subProject的大型项目中，并且它们在 Groovy 和 Kotlin DSL 上运行以进行比较。
Use case | Groovy | Kotlin | Differences |
|---|---|---|---|
First use |
|
