提升 Gradle 构建的性能

Gradle 团队不断改进 Gradle 构建的性能。如果你正在使用旧版本的 Gradle，你将错过这项工作带来的好处。跟上 Gradle 版本升级的风险很低，因为 Gradle 团队确保了 Gradle 次要版本之间的向后兼容性。保持最新状态还可以使过渡到下一个主要版本更容易，因为你将获得早期的弃用警告。

Gradle 运行在 Java 虚拟机 (JVM) 上。Java 性能改进通常有利于 Gradle。为了获得最佳的 Gradle 性能，请使用最新版本的 Java。

插件编写者不断改进其插件的性能。如果你正在使用旧版本的插件，你将错过这项工作带来的好处。特别是 Android、Java 和 Kotlin 插件，它们可以显著影响构建性能。更新到这些插件的最新版本以获得性能改进。

构建扫描为你提供 task 执行的可视化时间线。在以下示例构建中，你可以看到构建开始和结束时的长时间运行的 task

调整构建配置以尽早并行运行两个慢速 task，可以将总构建时间从 8 秒减少到 5 秒

配置缓存也带来了其他好处。启用后，Gradle：

查看构建扫描时间线视图，以识别可能从增量构建中受益的 task。这也可以帮助你理解为什么 task 在你期望 Gradle 跳过它们时执行。

正如你在上面的构建扫描中看到的，该 task 不是最新的，因为它的一个输入（"timestamp"）已更改，迫使该 task 重新运行。

按持续时间对 task 进行排序，以查找项目中速度最慢的 task。

构建扫描可以帮助你调查构建缓存的有效性。在性能屏幕中，“构建缓存”选项卡显示有关以下内容的统计信息：

“Task 执行”选项卡显示有关 task 可缓存性的详细信息。单击类别以查看时间线屏幕，该屏幕突出显示该类别的 task。

在时间线屏幕上按 task 持续时间排序，以突出显示具有巨大节省时间潜力的 task。上面的构建扫描显示 :task1 和 :task3 可以改进并使其可缓存，并显示了 Gradle 没有缓存它们的原因。

你应该避免在配置阶段进行耗时的工作。但有时它会偷偷潜入你的构建中，出现在不明显的地方。如果该代码在构建文件中，那么在配置期间加密数据或调用远程服务通常是很明显的。但像这样的逻辑更常见于插件，偶尔也会出现在自定义 task 类中。插件的 apply() 方法或 task 的构造函数中的任何昂贵的工作都是一个危险信号。

你应用于项目的每个插件和脚本都会增加整体配置时间。有些插件的影响比其他插件更大。这并不意味着你应该避免使用插件，但你应该注意只在需要它们的地方应用它们。例如，即使并非每个项目都需要插件，也很容易通过 allprojects {} 或 subprojects {} 将插件应用于所有子项目。

在上面的构建扫描示例中，你可以看到根构建脚本将 script-a.gradle 脚本应用于构建中的 3 个子项目

此脚本需要 1 秒才能运行。由于它应用于 3 个子项目，因此该脚本累积延迟配置阶段 3 秒。在这种情况下，有几种方法可以减少延迟

插件和 task 作者通常编写 Groovy，因为它语法简洁、API 扩展到 JDK 以及使用闭包的函数式方法。但 Groovy 语法带来了动态解释的成本。因此，Groovy 中的方法调用比 Java 或 Kotlin 中的方法调用花费更多的时间并使用更多的 CPU。

你可以使用静态 Groovy 编译来降低此成本：当你不需要显式动态功能时，将 @CompileStatic 注解添加到你的 Groovy 类中。如果你在方法中需要动态 Groovy，请将 @CompileDynamic 注解添加到该方法。

或者，你可以使用静态编译语言（如 Java 或 Kotlin）编写插件和 task。

警告： Gradle 的 Groovy DSL 严重依赖 Groovy 的动态功能。要在插件中使用静态编译，请切换到类似 Java 的语法。

以下示例定义了一个复制文件而无需动态功能的 task

此示例使用所有 Gradle “域对象容器”上可用的 register() 和 getByName() 方法。域对象容器包括 task、配置、依赖项、扩展等。某些集合（如 TaskContainer）具有专用类型，其中包含额外的 create 等方法，该方法接受 task 类型。

当你使用静态编译时，IDE 可以

管理第三方库及其传递依赖项会给项目维护和构建时间增加显著成本。

注意未使用的依赖项：当第三方库停止使用但未从依赖项列表中删除时。这在重构期间经常发生。你可以使用 Gradle Lint 插件来识别未使用的依赖项。

如果你仅在第三方库中使用少量方法或类，请考虑

当 Gradle 解析依赖项时，它会按照声明的顺序搜索每个仓库。为了减少搜索依赖项花费的时间，请首先声明托管最多依赖项的仓库。这最大限度地减少了解析所有依赖项所需的网络请求数。

将声明的仓库数量限制为使你的构建能够工作的最小值。

如果你正在使用自定义仓库服务器，请创建一个虚拟仓库，将多个仓库聚合在一起。然后，仅将该仓库添加到你的构建文件中。

动态版本（例如“2.+”）和更改的版本（快照）强制 Gradle 联系远程仓库以查找新版本。默认情况下，Gradle 仅每 24 小时检查一次。但你可以使用以下设置以编程方式更改此设置

如果构建文件或初始化脚本降低了这些值，Gradle 会更频繁地查询仓库。当你不需要每次构建时都使用依赖项的绝对最新版本时，请考虑删除这些设置的自定义值。

依赖解析是一个昂贵的过程，无论是在 I/O 方面还是在计算方面。Gradle 通过缓存减少了所需的网络流量。但仍然存在成本。Gradle 在每次构建时都运行配置阶段。如果你在配置阶段触发依赖解析，则每次构建都会支付该成本。

Gradle 允许用户以最适合他们的方式建模依赖解析。简单的自定义，例如强制使用特定版本的依赖项或将一个依赖项替换为另一个依赖项，对依赖解析时间没有太大的影响。更复杂的自定义，例如下载和解析 POM 的自定义逻辑，可能会显著减慢依赖解析速度。

使用构建扫描或性能分析报告来检查自定义依赖解析逻辑是否会对依赖解析时间产生不利影响。这可能是你自行编写的自定义逻辑，也可能是插件的一部分。

缓慢的依赖项下载会影响你的整体构建性能。有几个原因可能导致这种情况，包括互联网连接速度慢或仓库服务器过载。在构建扫描的“性能”页面上，你会找到“网络活动”选项卡。此选项卡列出了包括以下信息：

在以下示例中，两次缓慢的依赖项下载分别花费了 20 秒和 40 秒，并减慢了构建的整体性能

检查下载列表中是否有意外的依赖项下载。例如，你可能会看到由使用动态版本的依赖项引起的下载。

通过切换到其他仓库或依赖项来消除这些缓慢或意外的下载。

项目通常花费大量构建时间进行测试。这些测试可能是单元测试和集成测试的混合。集成测试通常需要更长的时间。构建扫描可以帮助您识别最慢的测试。然后，您可以专注于加速这些测试。

上面的构建扫描显示了所有运行测试的项目的交互式测试报告。

Gradle 提供了几种加速测试的方法

让我们依次查看这些方法。

Java 编译器速度很快。但是，如果您要编译数百个 Java 类，即使是很短的编译时间也会累积起来。Gradle 为 Java 编译提供了几种优化

Gradle 3.0 及更高版本默认启用 Daemon。如果您使用的是旧版本，则应更新到最新版本的 Gradle。如果您无法更新 Gradle 版本，则可以手动启用 Daemon。

Gradle 可以分析依赖项，细化到单个类级别，以仅重新编译受更改影响的类。Gradle 4.10 及更高版本默认启用增量编译。要在旧版本的 Gradle 中默认启用增量编译，请将以下设置添加到您的 build.gradle 文件中

通常，更新仅更改代码的内部实现细节，例如方法的主体。这些更新称为ABI 兼容更改：它们对项目的二进制接口没有影响。在 Gradle 3.4 及更高版本中，ABI 兼容的更改不再触发下游项目的重新编译。这尤其提高了具有深度依赖链的大型多项目构建的构建时间。

升级到 Gradle 3.4 以上的版本以受益于编译避免。