我目前正在使用 ant 构建 Android 项目，但它根本不适合大型项目，并且维护不同的可交付成果变得很痛苦。
我正在研究的两个替代方案是 Facebook 的 Buck ( http://facebook.github.io/buck/ ) 和 Google 支持 Android Studio 的 Gradle ( http://tools.android.com/tech-docs/new-构建系统/用户指南）。
除了试用它们并阅读它们的报道外，我还想向 Stackoverflow 的优秀人士请教您的建议。最好是如果您已经使用过任何一种工具一段时间，因为它没有得到那么多的覆盖面，所以可以为 Buck 获得奖励积分。
重点是
我也对其他选择持开放态度。你有什么建议，为什么？
正如我在Buck 文档中提到的那样：“Buck 是一个用于 Android 的构建系统，它鼓励创建由代码和资源组成的小型、可重用模块。”
按照设计，Buck 鼓励您创建小模块，以便您可以轻松地从现有构建块中构建新应用程序。这意味着维护多个可交付成果很简单：它消除了样板文件，而无需您将存储库组织成预定义的结构。您还可以使用 Buck 通过宏和类型创建临时构建步骤以满足您的需求。（一个更正式的扩展系统正在开发中。）
我们也非常关心速度，尤其是增量构建的速度。因为 Buck 有很强的依赖概念，所以我们通常可以避免重建中间工件。其他构建系统也尝试这样做（如 Ant），但结果经常牺牲正确性。我们没有。
我们认识到 IDE 支持很重要。当然，谷歌与 Gradle 的合作让他们在这方面占据了一席之地。但是，Buck 有一个命令可以从 Buck 构建文件中定义的依赖图生成一个 IntelliJ 项目，并且我们已经在我们自己的 IntelliJ 插件上取得了突破，所以这也是我们非常关心的事情。
最后，请记住，Buck 用于为 Android 构建 Facebook、Facebook Messenger 和 Instagram。巴克不会离开。此外，所有三个应用程序的代码（以及应用程序的简化版本，以实现更快的开发周期）都位于 Facebook 的一个 Git 存储库中，因此我们这些在内部从事 Buck 工作的人对支持多个可交付成果的大型代码库的需求很敏感.
从长远来看，新的 Gradle 构建系统将成为标准，并且看起来非常好。但是，看起来它还没有准备好用于非平凡的项目。例如，它看起来还不支持 apklib 依赖项。
这是可以理解的，并反映在当前版本为 0.3 的事实中，我期待看到它的发展。
对于今天需要构建的项目，我会使用 Maven。实际上，我现在正在将客户端的构建从 Eclipse-only 转移到 Maven，以便他们可以拥有可重复的构建过程、良好的依赖关系管理和 CI。新的 Gradle 构建看起来会更加灵活，但现在 Maven 可以处理 apklib。由于 Gradle 可以使用 Maven 依赖项，我希望我们将来能够轻松地从 Maven 迁移到 Gradle。
我对巴克一无所知。然而，这本身就是一个危险信号。我会犹豫使用很少有人知道的构建系统。这并不意味着它不好——它可能很棒。但现在使用它可能是一场赌博。
这是一个 gradle 插件OkBuck，它可以让您在当前的 Android Studio + Gradle 构建系统上开始使用 BUCK，只需10行配置。一探究竟。
OkBuck 可以让您同时使用 gradle 和 buck 构建您的项目，具有 gradle 和 buck 的所有优点。
我将添加 Buck 的以下优点：