由 Android Studio 产品经理 Leo Sei 发布
在 Android Studio 中,我们希望让你成为最高效的开发者。通过与开发者的讨论和调查,我们了解到缓慢的构建速度会降低生产力。
在这篇文章中,我们将分享一些新的分析方法,以便更好的指出是什么真正影响了构建速度,并分享一些我们正在为此所作的工作,以及你能做些什么来防止构建速度变慢。
我们做的第一件事情是使用开源项目(SignalAndroid, Tachiyomi, SantaTracker & skeleton of Uber)来创建内部 benchmark,用于测量各种修改(代码,资源,manifest 等)对于项目构建速度的影响。
例如,这是一个研究代码更改对构建速度影响的 benchmark,可以看出,随着时间的推移,构建速度有很大的改善。
我们还研究了真实的数据,主要关注 Android Gradle 插件升级前后构建调试版本的速度。我们用它来体现新版本上构建速度的实际提升。
这表明了在新版本上,构建速度确实改善了很多,自 2.3 版本以来,构建时间提升了将近 50%。
最后,我们在忽略版本变化的情况下,研究了构建时间随着时间的演变。我们用它来表示实际构建速度随时间的变化。遗憾的是,结果表明了构建速度是随着时间的推移而减慢的。
如果每个版本的构建速度确实越来越快,并且我们可以在数据中看到,那么为什么它们会随着时间的推移而变得越来越慢呢?
我们在更深入的研究之后,意识到在我们的生态系统中发生的事情正在导致构建速度减慢,减慢的速度比我们提升的速度更快。
虽然我们知道随着项目的迭代,代码的增加、资源的使用、语言特性的增加,使项目的构建速度越来越慢,但我们还发现,还有许多其他因素超出了我们的直接控制范围:
确定内部流程并持续提升性能。
我们也承认,许多问题来自于谷歌拥有的和推广的功能,我们改变了内部流程,以便在发布过程的早期更好地获得构建反馈。
我们还致力于让注释处理器增量化。截至目前,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 对研究它们的配置延迟没有帮助。
优化构建配置和任务
在研究构建速度时,这里有几个需要注意的最佳实践,可以随时查看我们的最新最佳实践。
配置
优化任务
作为开发者,我们关心你的生产力。随着我们持续努力加快构建速度,希望这里的提示和指导方针能够帮助你缩短构建时间,以便让你能够更加专注于开发精彩的应用程序。
如果发现译文存在错误或其他需要改进的地方,欢迎到 掘金翻译计划 对译文进行修改并 PR,也可获得相应奖励积分。文章开头的 本文永久链接 即为本文在 GitHub 上的 MarkDown 链接。
掘金翻译计划 是一个翻译优质互联网技术文章的社区,文章来源为 掘金 上的英文分享文章。内容覆盖 Android、iOS、前端、后端、区块链、产品、设计、人工智能等领域,想要查看更多优质译文请持续关注 掘金翻译计划、官方微博、知乎专栏。