/ 今日科技快讯 /
近日，有报道称苹果公司在一封致荷兰消费者监管机构的信中称，其已经遵守命令，让旗下苹果应用商店向荷兰约会应用开放第三方支付系统。自1月15日以来，荷兰消费者和市场管理局几乎每周都要对苹果公司处以570万美元的罚款，罚款总次数已经有5次之多，理由是苹果公司提出的解决方案给开发者带来了不公平的负担。苹果公司在2月28日写给ACM的信中说，公司提供的解决方案只需要开发商“在技术层面进行些许调整”，不需要额外成本。
/ 作者简介 /
本篇文章转自程序员江同学的博客，文章主要分享了从性能方面比较了Groovy和Kts两种脚本编译项目的优劣，相信会对大家有所帮助！
原文地址：
https://juejin.cn/post/7069550779454980104
/ 前言 /
大家肯定也都或多或少的写过一些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构建的性能分析和基准化分析信息的工具。工具地址：
https://juejin.cn/post/7069550779454980104
借助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性能报告。除了clean build，gradle-profiler还可以针对增量编译，不同的Gradle插件版本，以及不同的内存/CPU 等执行性能分析。通过gradle-profile命令，可以创建构建场景并多次运行，可以防止结果出现过大差异，并确保结果的可重现性，以帮助我们更好地分析性能。关于gradle-profile的具体使用，可以参考文档：
https://developer.android.google.cn/studio/build/profile-your-build?hl=zh-cn#gradle-profiler
Gradle 6.8 版本性能分析
针对Gradle 6.8版本，我们从以下4个用例来分析KTS性能。
首次运行（即清除所有build cache）
buildSrc abi更改（支持的abi发生变化，可以理解为大多数缓存失效，大部分代码需要重新编译）
buildSrc非abi更改（即buildSrc中的普通修改）
无改动
以下数据来自在Gradle CI上运行的性能测试。这些测试运行在一个包含大量subProject的大型项目中，并且它们在Groovy和Kotlin DSL上运行以进行比较。
可以看出，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插件要快。
以上数据来源于：
https://builds.gradle.org/buildConfiguration/Gradle_Master_Check_PerformanceTestSlowLinux_Trigger?branch=master&buildTypeTab=overview&mode=builds
可以使用访客模式登录查看。
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。
推荐阅读：
再学一遍android:fitsSystemWindows属性
欢迎关注我的公众号
学习技术或投稿
长按上图，识别图中二维码即可关注
876
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
