提高 Gradle 构建性能

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

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

插件编写者不断改进其插件的性能。如果您使用的是旧版本的插件，那么您将错过这些改进带来的好处。特别是 Android、Java 和 Kotlin 插件会对构建性能产生重大影响。更新到这些插件的最新版本以提高性能。

构建扫描为您提供了任务执行的视觉时间线。在以下示例构建中，您可以看到构建开始和结束时运行时间较长的任务

调整构建配置以尽早并行运行两个缓慢的任务，将整体构建时间从 8 秒缩短到 5 秒

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

查看构建扫描时间线视图，以识别可以从增量构建中受益的任务。这也可以帮助您了解为什么在您期望 Gradle 跳过任务时，任务会执行。

如您在上面的构建扫描中看到的那样，该任务不是最新的，因为它的一个输入（“时间戳”）发生了变化，迫使该任务重新运行。

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

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

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

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

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

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

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

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

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

您可以通过静态 Groovy 编译来降低这种成本：当您明确不需要动态特性时，在您的 Groovy 类中添加 @CompileStatic 注解。如果您需要在方法中使用动态 Groovy，请在该方法中添加 @CompileDynamic 注解。

或者，您可以使用 Java 或 Kotlin 等静态编译语言编写插件和任务。

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

以下示例定义了一个没有动态特性的复制文件的任务

此示例使用所有 Gradle“域对象容器”上可用的 register() 和 getByName() 方法。域对象容器包括任务、配置、依赖项、扩展等。一些集合，例如 TaskContainer，具有专用类型，这些类型具有额外的方法，例如 create，它接受一个任务类型。

当您使用静态编译时，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 及更高版本默认启用守护进程。如果您使用的是旧版本，您应该更新到最新版本的 Gradle。如果您无法更新 Gradle 版本，您可以手动启用守护进程。

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

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

升级到 3.4 以上的 Gradle 版本以从编译避免中获益。