Buck vs Gradle，Android 构建系统的优缺点

Question

我目前正在使用 ant 构建 Android 项目，但它根本不适合大型项目，并且维护不同的可交付成果变得很痛苦。

我正在研究的两个替代方案是 Facebook 的 Buck (http://facebook.github.io/buck/) 和 Google 支持 Android Studio (http://tools.android.com/tech-docs/new-build-system/user-guide) 的 Gradle。

除了试用它们并阅读它们的报道外，我还想向 Stackoverflow 的优秀人士请教您的建议。如果您已经使用过这两种工具有一段时间了，最​​好给 Buck 加分，因为它没有得到那么多的覆盖。

重点是

• 构建速度，专门用于开发构建
• 来自同一代码库的多个可交付成果
• 易于使用

我也愿意接受其他选择。你有什么建议，为什么？

Answer 1

正如我在Buck documentation 中所强调的那样：“Buck 是一个用于 Android 的构建系统，它鼓励创建由代码和资源组成的小型、可重用模块。”

按照设计，Buck 鼓励您创建小型模块，以便您可以轻松地从现有构建块中构建新应用程序。这意味着维护多个可交付成果非常简单：它消除了样板文件，而无需您将存储库组织成预定义的结构。您还可以使用 Buck 通过宏和类型创建临时构建步骤以满足您的需求。 （更正式的扩展系统正在开发中。）

我们也非常关心速度，尤其是增量构建的速度。因为 Buck 有很强的依赖概念，所以我们通常可以避免重建中间工件。其他构建系统也尝试这样做（如 Ant），但结果经常牺牲正确性。我们没有。

我们认识到 IDE 支持很重要。当然，谷歌与 Gradle 的合作让他们在这方面占据了一席之地。但是，Buck 有一个命令可以从 Buck 构建文件中定义的依赖关系图生成一个 IntelliJ 项目，而且我们已经在自己的 IntelliJ 插件上破土动工，所以这也是我们非常关心的事情。

最后，请记住，Buck 用于构建适用于 Android 的 Facebook、Facebook Messenger 和 Instagram。巴克不会离开。此外，所有三个应用程序的代码（以及应用程序的简化版本，以实现更快的开发周期）都位于 Facebook 的一个 Git 存储库中，因此我们这些在内部从事 Buck 工作的人对支持多个可交付成果的大型代码库的需求很敏感.

Answer 2

从长远来看，新的 Gradle 构建系统将成为标准，并且看起来非常好。 但是，看起来它还没有准备好用于非平凡的项目。例如，它看起来还不支持 apklib 依赖项。

这是可以理解的，体现在当前版本是0.3 我期待看到它的发展。

对于今天需要构建的项目，我会使用 Maven。实际上，我现在正在将客户端的构建从 Eclipse-only 转移到 Maven，以便他们可以拥有可重复的构建过程、良好的依赖关系管理和 CI。 新的 Gradle 构建看起来会更加灵活，但现在 Maven 可以处理 apklib。由于 Gradle 可以使用 Maven 依赖项，我希望我们将来能够轻松地从 Maven 迁移到 Gradle。

我对巴克一无所知。然而，这本身就是一个危险信号。我会犹豫使用很少有人知道的构建系统。这并不意味着它不好——它可能很棒。但现在使用它可能是一场赌博。

Answer 3

这是一个 gradle 插件OkBuck，它可以让您在当前的 Android Studio + Gradle 构建系统上开始使用 BUCK，只需 10 行配置。看看吧。

OkBuck 可以让您同时使用 gradle 和 buck 构建您的项目，具有 gradle 和 buck 的所有优点。

Answer 4

我想补充一下 Buck 的以下优点：

• Exopackage，即增量 apk 构建；只需在该页面上查看包含构建时间的表格
• Network cache。如果您有多个开发人员在使用一个应用，则无需重新构建已由其他开发人员构建的组件。