[译]改善 Android Studio 的构建速度

• 原文地址：Improving build speed in Android Studio
• 原文做者：Android Developers
• 译文出自：掘金翻译计划
• 本文永久连接：github.com/xitu/gold-m…
• 译者：qiuyuezhong
• 校对者：csming1995

由 Android Studio 产品经理 Leo Sei 发布

改善构建速度

在 Android Studio 中，咱们但愿让你成为最高效的开发者。经过与开发者的讨论和调查，咱们了解到缓慢的构建速度会下降生产力。

在这篇文章中，咱们将分享一些新的分析方法，以便更好的指出是什么真正影响了构建速度，并分享一些咱们正在为此所做的工做，以及你能作些什么来防止构建速度变慢。

• 感谢不少开发者选择在 “preference > data sharing” 中与咱们共享他们的使用统计信息，使得这件事情变得可能。

不一样的速度测量方式

咱们作的第一件事情是使用开源项目（SignalAndroid, Tachiyomi, SantaTracker & skeleton of Uber）来建立内部 benchmark，用于测量各类修改（代码，资源，manifest 等）对于项目构建速度的影响。

例如，这是一个研究代码更改对构建速度影响的 benchmark，能够看出，随着时间的推移，构建速度有很大的改善。

咱们还研究了真实的数据，主要关注 Android Gradle 插件升级先后构建调试版本的速度。咱们用它来体现新版本上构建速度的实际提高。

这代表了在新版本上，构建速度确实改善了不少，自 2.3 版本以来，构建时间提高了将近 50%。

最后，咱们在忽略版本变化的状况下，研究了构建时间随着时间的演变。咱们用它来表示实际构建速度随时间的变化。遗憾的是，结果代表了构建速度是随着时间的推移而减慢的。

若是每一个版本的构建速度确实愈来愈快，而且咱们能够在数据中看到，那么为何它们会随着时间的推移而变得愈来愈慢呢？

咱们在更深刻的研究以后，意识到在咱们的生态系统中发生的事情正在致使构建速度减慢，减慢的速度比咱们提高的速度更快。

虽然咱们知道随着项目的迭代，代码的增长、资源的使用、语言特性的增长，使项目的构建速度愈来愈慢，但咱们还发现，还有许多其余因素超出了咱们的直接控制范围：

1. 2017 年底的 Spectre 和 Meltdown 补丁对新流程和 I/O 产生了必定影响，使清除构建的速度减慢了 50% 到 140% 之间。
2. 第三方和客制化的 Gradle 插件：96% 的 Android Studio 开发者使用一些额外的 Gradle 插件（其中一些并无采用最新的最佳实践）。
3. 大多数使用的注释处理器都是非增量化的，每次进行编辑时都会致使代码从新全量编译。
4. 使用 Java 8 语言特性会致使须要执行去语法糖操做，这将影响构建时间。然而，咱们已经用 D8 下降了去语法糖操做的影响。
5. 使用Kotlin，尤为是 Kotlin（KAPT）中的注释处理，也会影响构建性能。咱们将继续与 JetBrains 合做，以将影响降至最低。

• 和真实的项目不一样，那些项目的构建时间不会随着时间的推移而增加。Benchmark 模拟更改，而后撤销更改，仅测量咱们的插件随时间推移而受到的影响。

• 3.3 版本专一于将来改善的基础工做（例如，名称空间资源、增量注释处理器支持、Gradle workers），所以提高了 0%。

咱们在作什么？

肯定内部流程并持续提高性能。

咱们也认可，许多问题来自于谷歌拥有的和推广的功能，咱们改变了内部流程，以便在发布过程的早期更好地得到构建反馈。

咱们还致力于让注释处理器增量化。截至目前，Glide、Dagger 和 Auto Service 都是增量化的，而且咱们还在研究其余的。

在最近的版本中，咱们还加入了 R light class generation、lazy task 和 worker API，并继续与 Gradle Inc. 和 JetBrains 合做，以持续改善整体构建性能。

属性工具

最近的一项调查显示，约 60% 的开发者不去分析构建的影响或不知道如何分析。所以，咱们但愿改善 Android Studio 中的工具，在社区中提升对构建时间影响的意识和透明度。

咱们正在探索如何在 Android Studio 中更好地提供插件和任务对构建时间影响的相关信息。

你如今能作些什么？

虽然配置时间可能因变量、模块和其余因素的数量而有所不一样，但咱们但愿将与 Android Gradle 插件相关联的配置时间做为参考点，并和实际场景共享数据。

若是发现构建时间慢不少，多是有客制化的构建逻辑（或者三方的 Gradle 插件）影响到构建时间。

使用的工具

Gradle 提供了一组免费的工具来帮助分析构建中正在发生的事情。

咱们建议你使用 Gradle scan，它提供了关于构建的大部分信息。若是你不但愿构建信息上传到 Gradle 服务器上，可使用 Gradle profiler，相对于 Gradle scan，它提供的信息要少一些，可是能够保证全部内容都在本地。

注意：对于那些你可能想使用传统 JVM profiler 的项目，Gradle scan 对研究它们的配置延迟没有帮助。

优化构建配置和任务

在研究构建速度时，这里有几个须要注意的最佳实践，能够随时查看咱们的最新最佳实践。

配置

• 仅使用配置来建立任务（使用 lazy API），避免在其中执行任何 I/O 或任何其余工做。（配置不适合查询 git、读取文件、搜索链接的设备、进行计算等）。
• 在配置中建立全部的任务。配置不会知道实际生成了什么内容。

优化任务

• 保证每一个任务都声明了输入/输出（即使是非文件性的），而且是增量化的和可缓存的。
• 将复杂的步骤拆分为多个任务，以帮助实现增量化和可缓存性。 （有些任务能够是最新的，而另外一些任务能够执行或并行执行）。
• 确保任务不会写入或删除其余任务的输出。
• 在插件或 buildSrc 中用 Java/Kotlin 编写任务，而不是在 build.gradle 中用 Groovy 直接编写。

做为开发者，咱们关心你的生产力。随着咱们持续努力加快构建速度，但愿这里的提示和指导方针可以帮助你缩短构建时间，以便让你可以更加专一于开发精彩的应用程序。

若是发现译文存在错误或其余须要改进的地方，欢迎到 掘金翻译计划 对译文进行修改并 PR，也可得到相应奖励积分。文章开头的 本文永久连接 即为本文在 GitHub 上的 MarkDown 连接。

---

掘金翻译计划 是一个翻译优质互联网技术文章的社区，文章来源为 掘金 上的英文分享文章。内容覆盖 Android、iOS、前端、后端、区块链、产品、设计、人工智能等领域，想要查看更多优质译文请持续关注 掘金翻译计划、官方微博、知乎专栏。