构建缓存的使用场景

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

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

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

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

如果您受到关于交付给客户的构件的审计要求，您可能需要为某些构建禁用构建缓存。Develocity 可以帮助您满足这些要求，同时仍然为所有构建使用构建缓存。它允许您通过构建扫描轻松找出哪个构建生成了来自构建缓存的构件。

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

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

您可以同时使用本地缓存和远程缓存以获得复合效果。虽然从 CI 填充的远程缓存加载结果有助于避免因其他开发者的更改而需要的工作，但本地缓存可以加速切换分支和执行 git bisect。在 CI 机器上，本地缓存可以充当远程缓存的镜像，从而显著减少网络使用量。

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