构建缓存的用例

即使仅由单个开发人员使用，构建缓存也非常有用。 Gradle 的增量构建功能有助于避免已经完成的工作，但一旦重新执行任务，之前的任何结果都会被忘记。当您来回切换分支时，本地结果会一遍又一遍地重建，即使您正在构建以前已经构建过的东西。构建缓存会记住早期的​​构建结果，并大大减少在本地构建内容时重建它们的需要。这也可以扩展到重建不同的提交，例如运行时git bisect。

当处理具有多个变体的项目时（例如 Android 项目），本地缓存也很有用。每个变体都有许多与之关联的任务，其中一些任务变体维度尽管具有不同的名称，但最终可能会产生相同的输出。启用本地缓存后，任务变体之间的重用将在适用时自动发生。

构建缓存的作用不仅仅是及时来回：它还可以弥合计算机之间的物理距离，允许一台计算机上生成的结果可以被另一台计算机重复使用。在团队中引入构建缓存时，典型的第一步是启用它以仅作为持续集成的一部分运行的构建。使用共享 HTTP 构建缓存后端（例如Develocity 提供的后端）可以显着减少 CI 代理需要完成的工作。这意味着开发人员可以更快获得反馈，并减少在 CI 资源上花费的资金。更快的构建还意味着每个构建中的提交更少，这使得调试问题更加有效。

从 CI 上的构建缓存开始是一个很好的第一步，因为 CI 代理上的环境通常比开发人员机器上更稳定和可预测。这有助于识别可能影响可缓存性的构建中的任何可能问题。

如果您需要遵守有关发送给客户的工件的审核要求，您可能需要禁用某些构建的构建缓存。 Develocity 可以帮助您满足这些要求，同时仍然为所有构建使用构建缓存。它允许您通过构建扫描轻松地找出哪个构建产生了来自构建缓存的工件。

当多个开发人员处理同一个项目时，他们不仅需要构建自己的更改：每当他们从版本控制中提取内容时，他们最终也必须构建彼此的更改。每当开发人员正在处理与拉取的更改无关的事情时，他们可以安全地重用 CI 上已经生成的输出。假设您正在开发模块“A”，并且对模块“B”进行了一些更改（这不依赖于您的模块）。如果这些更改已在 CI 中构建，您可以从缓存下载模块“B”的任务输出，而不是在本地生成它们。一个典型的用例是当开发人员开始一天的工作时，从版本控制中提取所有更改，然后运行他们的第一个构建。

这些更改也不需要完全独立；我们将在有关不同形式的规范化的部分中了解当涉及依赖项时重用结果的策略。

您可以利用本地和远程缓存来实现复合效果。虽然从填充 CI 的远程缓存加载结果有助于避免由于其他开发人员的更改而需要进行的工作，但本地缓存可以加快切换分支和执行git bisect.在 CI 机器上，本地缓存可以充当远程缓存的镜像，从而显着减少网络使用量。

允许开发人员将其结果上传到共享缓存是可能的，但不建议这样做。开发人员可以在任务执行时更改任务输入或输出。他们可能会在无意中且没有注意到的情况下执行此操作，例如在构建运行时在 IDE 中进行更改。目前，Gradle 没有好的方法来防御这些更改，并且在任务完成后只会缓存输出目录中的所有内容。这又可能导致上传到共享缓存的结果损坏。当 Gradle 添加了必要的保护措施以防止意外修改任务输入和输出时，此建议可能会发生变化。