Facebook Buck和xctool：针对Android和iOS的开源构建工具
本文包含了最新发布的Buck和xctool的细节，这是两种Facebook内部用于本地Android和iOS应用程序的构建工具。
Buck
Facebook最近开源了他们用于构建本地Android应用程序的工具Buck。Buck受到了Google Blaze的启发，创建它是为了处理与多个Android库有复杂关联的应用程序，从而减少构建时间。引入Buck之后，Facebook开发的四种本地Android应用程序中使用了单一的代码树和构建工具，这让开发更简单、更流畅，错误更少。最初的38个库在四种应用程序之间共享了500个模块。使用Buck替换了最初基于Ant的系统之后，第一次针对代码树运行时，构建时间就从3分40秒降到1分30秒。
Buck是用Java编写的，而构建规则最初是用Python定义的，后来为了更快的规则评估而采用了Jython。工具现在被用于构建Android Java代码，但是团队正在努力使其支持构建纯粹的Java代码，而与Android无关，它可能会扩展到构建Python项目，可能还会支持其他类型的项目。
Facebook的Android代码是以树的形式组织的，其中独立的子树构成了有向无环图，支持与各种不同子树相关的构建规则的并行执行，从而减少了构建时间。包含规则的构建文件分布在代码树中，每个文件针对一个已存在的Android模块。只有模块中的文件有变化时，构建文件才会执行，而这些构建可以并行执行。据Buck的创造者Michael Bolin所说，把并行能力设置为八个线程，会把单元测试的时间从20分钟降低到4分钟。他在DevCon New York 2013的话题中详细描述了构建系统。
Buck知道如何处理文件的多个版本，正如Bolin在G+的一个话题中说明的：
在构建Android应用时，另一个困难的问题是生成R.java文件。如果不探究太多细节，你可能会构建多个Android应用，它们的Java文件依赖于同一个名为R的类。对于普通的Java类，你可能会编译一次，然后任意数量的其他Java类都可以依赖它。然而，在Android中，你需要编译的R的版本依赖于Android应用，其中编译的Java代码最终会被包含在内。为你构建的每种Android应用都编译Java代码的不同版本，效率会很低，所以Buck使用了一些聪明的技巧（为编译时而不是运行时创建不同的R.java文件），从而减少重复编译。
在不久的将来，团队准备增加一个后台程序，它会监控文件的编辑情况，一旦发现就会立即开始构建。
Buck运行在Mac OS和Linux平台上，团队正在考虑把它也移植到Windows上。
Gerrit的创建者Shawn Pearce建议使用Buck替换Maven，他提到了速度以及其他几种原因：
buck: clean: 0.452s, full 1m21.083s [*], no-op: 7.145s,
maven: clean: 4.596s, full 2m53.776s, no-op: 59.108s,[*] 完整构建包括下载所有依赖，时间可能会因为远程服务器的性能差别而不同。
Pearce还指出Buck的一些缺点：
-不支持Windows
-没有本地的Maven Central支持（通过宏）
- 没有本地的GWT、Prolog和WAR支持（通过宏）
- Buck的引导程序需要Ant
xctool
xctool是Facebook最近开源的另一种构建工具，它用于构建iOS应用程序。xctool替换了xcodebuild，具有以下特性：
- 能够作为Xcode.app运行相同的测试
- 构建输出和测试结果都是JSON格式的，使得我们不需要解析输出
- xctool只有在发现错误的时候才打印消息，而xcodebuild对每个源文件都会打印。
我们想要知道为什么Facebook基于xcodebuild构建了另一种工具，所以采访了xctool的提交者Fred Potter，询问他为什么这个工具更好一些：
xctool的最大好处在于，它可以从命令行构建和运行单元测试，这和Xcode.app从图形化界面上达到一样的效果。如果你为iOS设置了持续集成系统，那么这就非常重要了。你想要能够自动化运行测试，那些测试与你的开发人员在本地计算机上运行的完全相同，而xcodebuild不会用和Xcode.app相同的方式来构建和运行测试。在Xcode 4中，苹果把单元测试集成到了Xcode中——与“构建”和“运行”一起，有一个新的“测试”动作；使用Xcode scheme，你可以选择启用或者禁用哪些单元测试；如果你依赖于iOS模拟器（也就是应用程序测试）来编写测试，那么Xcode会自动载入模拟器并运行测试。这些都是很大的改进，但看起来苹果并没有把这些改进融入到xcodebuild中，那使得自动化构建和测试非常困难。
另一个重大的问题是构建和测试失败的报告。使用xcodebuild，你会得到大量文本输出，其中包含编译命令、编译错误和警告以及OCUnit的测试输出。如果你想要自动确定哪个组件编译失败，或者哪个单元测试失败，那么你就需要编写自己的正则表达式解析器，那也是我们和其他iOS社区中的人一直在做的工作。那会有效果，但实在很麻烦。有了xctool，我们会让xcodebuild和OCUnit测试运行器把构建输出和测试结果作为JSON对象的结构化流输出。 这让我们可以很容易地以需要的形式来显示构建和测试结果。例如，我们创建了一个报表，以吸引人的、带有颜色的输出形式来显示结果（https://fpotter_public.s3.amazonaws.com/xctool-uicatalog.gif）。 还有人使用这来把测试结果输出为JUnit XML，那在流行的Jenkins构建系统中会显示得很好。
所以，我们最初创建xctool只是为了持续集成系统，但很多开发者最后都在本地计算机上使用它。如果你想要为运行测试拥有命令行的工作流，它会非常方便。
查看英文原文：Facebook Buck and xctool: Open Source Build Tools for Android and iOS