比构建速度，Bazel是Gradle的10倍，不服不行！！！

不服的，请关注本公众号：

在文章开始前，简单介绍一下文章中涉及到的术语：

• Gradle：通用的构建工具，支持多语言；

• Bulk：Facebook正在使用的构建工具；

• Bazel：Google内部构建工具Blaze的开源版本；

• Dropbox：一个云盘工具，可以理解为国内的百度云盘；

• Android Studio：一个为Android平台开发程序的集成开发环境。

2018年，Dropbox移动开发者社区发现他们的自建构建系统又慢又难使用。你是否也正在遭遇？为此，Dropbox希望改进自己的构建系统，他们的目标很明确：

1. 创建新模块是容易的；

2. 开发者能轻松的修改构建文件；

3. 减少本地构建时间；

4. 是行业标准的方法和工具，工程师可以很容易地谷歌到解决问题的方法；

5. 门槛低，对新员工友好；

6. 能集成Android Studio。

Dropbox自建的构建系统称为BMBF（Buildy McBuildface Basic Modular Build Format）。说实在的，它并不是严格意义的构建系统，更准确说像是一个Gradle的构建文件代码的生成器。

Dropbox在2019年时，同样的代码，对比多种构建工具的构建速度，结果如下表：

场景1没有可比性，因为不同的工具缓存的方式不一样；场景2，Gradle缓存与Bazel的缓存不是一个层面的东西，所以，也没有可比性；场景3是没有任何修改的情况执行build，Bazel的速度是Gradle的20到30倍；场景4和场景5是现实中运行最多的场景，看到4倍到9倍之间。

所以，本文标题中的10倍并不是夸张。

只可惜，Dropbox并没有告诉我们他们在做实验时的代码的行数，模块数等更多的可对比的信息。

在经过实验后，Dropbox列出了Bazel、BMBF、Gradle的优缺点：https://dropbox.tech/mobile/modernizing-our-android-build-system-part-i-the-planning 。注意，现在已经是2021年，这个评估发生在2019年。

最后，Dropbox还提到了Buck。因为在2019年时，它的社区支持不是很好，且不支持Kotlin，所以，没有使用Buck。

那么，Dropbox在2019年时的决定是什么呢？首先，他们决定废除自建的构建系统BMBF，然后决定使用Gradle，他们认为当时的Bazel还不够成熟。

不过，有点出乎我意料的是，他们居然会担心Bazel的速度太快，会影响开发者本地开发的体验。难道是因为构建速度太快，没时间摸鱼了吗？

想了解更多关于Bazel的内容，请关注本公众号 持续交付实践指南：

往期好文推荐：

资深DevOps揭秘：DevOps的最大问题是？

实践持续交付一年后的反思

一些持续交付的实践经验