极速 Android 构建
简介
在今天的 Google I/O 大会上，Android Studio 团队发布了 Android Gradle 插件 3.0 的首个预览版本，该版本基于 Gradle 4.0 M2。它带来了主要的性能改进，特别是对于包含大量子项目的构建。在这篇博文中，我们将解释您可以从这个预览版本中期待什么，以及 Android Studio 和 Gradle 团队是如何实现这些改进的。在深入探讨之前，让我们回顾一下是什么目标促成了当前 Android 构建系统的创建。
移动开发的复杂性 #
开发移动应用程序本质上比构建类似规模的传统 Web 或服务器应用程序更复杂。一个应用程序需要支持各种各样的设备，这些设备具有不同的外围设备、不同的屏幕尺寸和相对较慢的硬件。流行的免费增值模式增加了另一层多样性，要求免费版和付费版应用程序使用不同的代码路径。为了为每个设备和目标受众提供快速、精简的应用程序，构建系统需要预先完成大量繁重的工作。
为了提高开发人员的生产力并减少运行时开销，Android 构建工具提供了几种语言和源代码生成器，例如 Java、RenderScript、AIDL 和 Native 代码。将应用程序与其库打包在一起涉及高度可定制的合并和精简步骤。Android Studio 团队面临着自动化所有这些步骤的挑战，同时又不向开发人员暴露底层的复杂性。开发人员可以专注于编写他们的生产代码。
最后但并非最不重要的一点是，开发人员期望构建工具能够管理他们的依赖项、具有可扩展性并提供深入的 IDE 集成。
Gradle 非常适合这些挑战，Android Studio 团队在 Gradle 平台上创建了一个出色的 Android 构建工具。
性能挑战 #
无论插件多么优雅和可扩展，无论 IDE 集成多么无缝，当事情花费的时间过长时，开发人员都会变得效率低下和沮丧。Android Studio 团队在过去几年中在性能方面取得了稳步进展。模拟器变得更快，使用 Instant Run 和其他改进，部署应用程序的时间减少了几个数量级。这些步骤现在已经将构建本身暴露为最终的瓶颈。Android Studio 团队和 Gradle 团队一直在不断改进插件和平台的性能，但到目前为止，这还不够。根本的设计问题阻碍了卓越的性能。
因此，Gradle Inc. 和 Google 于 2016 年底联手控制了这种情况。这项工作分为三个领域
- Gradle 及其 Java 支持的总体改进：更快的最新检查、编译避免、稳定的增量编译和并行依赖项下载。
- Android 工具的总体改进，例如 dex 和代码精简，包括增量 dexing。
- Gradle 中用于变体感知依赖项管理的新 API 以及使用这些新 API 的 Android 插件。
后者使 Android Studio 团队最终摆脱了许多由于缺少这些 API 而不得不构建的低效的解决方法。
为了理解变体感知依赖项管理为何如此重要，假设您有一个应用程序，它依赖于一个库。它们都支持 ARM 和 x86 架构，它们都有免费版和付费版，并且它们都可以为调试和生产构建。这总共创建了 8 个变体。但是在任何给定的时间点，开发人员只在一个变体上工作，例如“免费 x86 调试”变体。
到目前为止，Android 插件必须在构建生命周期的早期检查应用程序的依赖项，以选择要构建的库的正确变体。这个早期阶段称为配置时间，在此期间，Gradle 确定它需要按什么顺序运行哪些任务。配置时间的工作越多，构建速度就越慢，无论用户选择了哪些任务。它还会影响将构建与 IDE 同步所需的时间。随着更多子项目添加到构建中，Android 插件的热切依赖项检查导致配置时间的组合爆炸。
Gradle 的新变体感知依赖项管理完全改变了这一点。Android 插件现在可以为不同的变体维度（如产品风味和构建类型）提供匹配策略，Gradle 在依赖项解析期间使用这些策略来选择上游库的正确变体。这完全消除了在配置时解析依赖项的需要，并且还允许 Android 插件仅构建应用程序需要的部分库。
在一个特别大型应用程序中，包含 130 个子项目，使用 Android 2.3 工具配置项目所需的时间从 3 分钟降至 10 秒，而使用 Android 3.0 则降至 2 秒以下。清理构建时间从超过 5 分钟降至约 1 分钟。当与新的 编译避免 功能结合使用时，对增量构建的影响是巨大的。进行单行更改并组装项目的时间缩短至约 9 秒。对于单体项目，这些数字不会那么令人印象深刻，但它们表明构建系统现在可以非常高效地处理模块化应用程序。
最后但并非最不重要的一点是，Android Studio 团队将使 Android 插件 3.0 与 Gradle 构建缓存 兼容。构建缓存允许在清理构建和跨机器边界重用构建输出。这意味着开发人员可以重用 CI 生成的构建输出，构建管道可以重用早期阶段的结果。它还加快了开发人员机器上功能分支之间的切换速度。初步测试很有希望，上述大型 Android 应用程序的清理构建时间在使用缓存时从 60 秒降至约 20 秒。
试一试 #
Android Studio 团队编写了一份全面的 迁移指南。社区插件可能存在兼容性问题，因为许多插件依赖于现在工作方式不同的内部结构。
如果您正在开发 Android 项目，请试用预览版，并告诉我们您的构建时间在开箱即用后改进了多少。尝试将您的应用程序模块化，并为 api 和 implementation 依赖项进行拆分，以获得更大的性能提升。您可以使用 构建扫描 及其 时间线 视图来深入了解您的构建性能、执行了哪些任务以及它们花费了多长时间。
如果您是 Android 插件作者，新版本可能需要您对插件进行一些更改才能保持兼容性。如果您在迁移时遇到任何问题，请提交问题。
下一步是什么？ #
您可以期待 Gradle 方面有更多改进。例如，我们目前正在默认情况下进行并行任务执行。
可以肯定的是，Android Studio 团队也会提供更多的性能智能，包括 Android Studio 优化，以便在同步项目时尽可能少地工作。Gradle 和 Android Studio 团队也在就此进行合作。
随着 alpha 版本的成熟和插件作者的调整，对社区插件的支持将会得到改善。提供反馈的人越多，这些巨大的改进就能越快地作为稳定版本发布。