前言
大家必定也都或多或少的写过一些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执行的场景：
# <root-project>/scenarios.txtclean_build { tasks = [":app:assembleDebug"] cleanup-tasks = ["clean"]}如需运行此场景，请应用以下命令：
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 | 33.5s | 76.2s | Groovy DSL is 2.2x faster |
| buildSrc abi change | 13.2s | 42.3s | Groovy DSL is 3.2x faster |
| buildSrc non-abi change | 13s | 5.2s | Kotlin DSL is 2.5x faster |
| Nothing changes | 1.7s | 1.8s | Similar performance |
能够看出，Groovy脚本在性能上还是有肯定劣势
- 在首次运行时，Groovy DSL比KTS快2.2倍
- 在buildSrc abi更改时，Groovy DSL比KTS快3.2倍
- 在buildSrc非abi更改时，KTS比Groovy快2.5倍
- 在代码没有产生更改时，两者性能相似
能够看出，KTS只有在buildSrc非abi更改时有性能劣势，这是因为buildSrc中的groovy的更改会导致整个我的项目过期，导致我的项目从新编译
而buildSrc中的kts批改能够跳过未受影响的构建脚本文件的编译，因而当批改buildsrc时，kts编译会远比groovy插件要快
Gradle 7.4 版本性能剖析
针对Gradle 7.4版本，咱们通过以下3个用例来剖析KTS性能
- 首次运行(即革除所有build cache)
- buildSrc abi 更改(反对的abi发生变化，能够了解为大多数缓存生效，大部分代码须要从新编译)
- buildSrc 非 abi 更改(即buildSrc中的一般批改)
| Use Case | Groovy | Kotlin | Difference |
|---|---|---|---|
| First use | 38.855s | 63.54s | Groovy DSL is 1.6x faster |
| buildSrc abi change | 25.307 | 35.014s | Groovy DSL is 1.4x faster |
| buildSrc non-abi change | 24.526s | 4.732s | Kotlin DSL is 5x faster |
能够看出，针对Gradle 7.4版本，KTS的编译性能有肯定改善，性能差距缩小到了1.5倍左右
总结
总得来说，KTS在可读性，易用性，编译时查看与IDE反对等方面比起Groovy都有微小的劣势，然而在性能方面存在肯定劣势，具体如下：
- 针对Gradle 6.8版本，如果缓存大部分生效或者没有缓存，Groovy DSL比KTS快2到3倍
- Gradle 7.4版本KTS性能有肯定改善，如果缓存大部分生效或者没有缓存，Groovy DSL比KTS快1.5倍左右。
- 当buildSrc中产生非abi更改时，kts脚本编译比Groovy DSL快4到5倍，这是因为buildSrc中的kts能够跳过未受影响的构建脚本的编译，而groovy暂不反对
- 当我的项目没有产生更改时，KTS与Groovy DSL的编译速度相差不大
由上可知，KTS目前的优缺点都非常明显，在易用性上十分突出，在性能方面有肯定劣势，Gradle官网也始终在优化中，读者能够依据本人的我的项目状况决定是否将构建配置从 Groovy 迁徙到 KTS。
转自：程序员江同学