关于android:Android安卓进阶之相比-Groovy-脚本-KTS-性能到底怎么样

前言

大家必定也都或多或少的写过一些 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.txt
clean_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 上运行以进行比拟。

能够看出，Groovy 脚本在性能上还是有肯定劣势

1. 在首次运行时，Groovy DSL 比 KTS 快 2.2 倍
2. 在 buildSrc abi 更改时，Groovy DSL 比 KTS 快 3.2 倍
3. 在 buildSrc 非 abi 更改时，KTS 比 Groovy 快 2.5 倍
4. 在代码没有产生更改时，两者性能相似

能够看出，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 中的一般批改)

能够看出，针对 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。

转自：程序员江同学