如何在Xcode中减少构建时间/加快编译时间？

Question

通常可以使用哪些策略来减少任何Xcode项目的构建时间？我最感兴趣的是Xcode特定策略。

我正在使用Xcode进行iPhone开发，我的项目正逐渐变得越来越大。我发现编译/链接阶段开始花费比我想要的更多时间。

目前，我是：

• 使用静态库来实现它 我的大多数代码都不需要 我每次清理和构建时编译 我的主要项目

• 已删除了我的大部分资源 应用，并用硬测试 iPhone中的编码文件系统路径 尽可能的模拟器，所以我的 资源不一定是 在我对它们进行更改时打包。

我注意到“检查依赖关系”阶段似乎比我想要的时间更长。任何减少这一点的提示都将受到赞赏！

Answer 1

通常，您可以做的最大的事情就是控制包含头文件。

在源代码中包含“额外”头文件会大大减慢编译速度。这也会增加依赖性检查所需的时间。

此外，使用forward declaration而不是包含其他标头的标头可以大大减少依赖项的数量，并帮助您完成所有时间。

Answer 2

我写了一篇关于如何改进Spotify的iOS开发周期的博文：

Shaving off 50% waiting time from the iOS Edit-Build-Test cycle

归结为：

1）停止生成dSYM捆绑包。

2）如果使用Clang，请避免使用-O4进行编译。

Answer 3

我个人将编译器切换到LLVM-Clang用于我的Mac开发项目，并且看到构建时间大幅减少。还有LLVM-GCC编译器，但我不确定这会对构建时间有所帮助，如果LLVM-Clang不能用于iPhone应用程序编译，那么你也可以尝试。

我不是百分之百确定在Linux上开发支持LLVM，但我想我记得在新闻源中阅读它。这不是您可以在代码中实现的优化，但值得一试！

Answer 4

如果您没有使用8GB内存，请立即升级。

我刚刚将我的macbook pro从4GB升级到8GB。我的项目构建时间从2:10到0:45。我对改进感到震惊。它还可以在编制索引等时进行网页浏览，以获得研究速度和一般Xcode性能

Answer 5

简单回答：在本地网络上添加另一台运行Xcode的计算机。 Xcode结合了distcc来做分布式编译。它甚至可以使用Bonjour查找其他构建主机，这极大地简化了配置过程。对于大型构建，分发可以使您的速度增加几乎与构建机器的数量成比例（2台机器占用一半时间，3台占用三分之一，依此类推）。

要了解如何进行此设置，您可以咨询this development doc。它还具有其他有用的构建时间改进策略，例如使用预编译头和预测构建。

编辑：可悲的是，从Xcode 4.3开始Apple似乎已删除此功能：http://lists.apple.com/archives/xcode-users/2012/Mar/msg00048.html

Xcode 5有一个可以执行CI的服务器版本，但我怀疑这会给临时开发人员构建带来任何好处。但是，有一些未公布的功能可以大大加快构建时间。

Answer 6

Xcode用于执行任务的线程数默认为CPU所具有的核心数。例如，具有Intel Core i7的Mac有两个内核，因此默认情况下Xcode最多使用两个线程。由于编译时间通常是I / O绑定而不是CPU绑定，因此增加Xcode使用的线程数可以为编译提供显着的性能提升。

尝试将Xcode配置为使用3,4或8个线程，并查看哪个线程为您的用例提供了最佳性能。

您可以按如下方式设置Xcode从终端使用的进程数：

defaults write com.apple.Xcode PBXNumberOfParallelBuildSubtasks 4

有关详细信息，请参阅Xcode User Defaults。

Answer 7

将编译时间缩短一半（至少针对iOS项目）的一个重要提示是将构建设置/架构/仅构建活动架构设置为是。

这样做（特别是64位iPad / 64位编译器的出现）是不构建您当前未使用的体系结构的二进制文件。

请务必在提交到应用商店时重新启用此设置，否则您的二进制文件将无法验证。

Answer 8

我使用脚本来使用RAM驱动器，以及一些“前向声明”优化项目 clean 构建时间从53秒到20秒。

我很想在AppStore上获得Gui，但我选择了 去命令行。我把脚本作为git存储库的一部分。

要查看构建时间，请在终端中输入： “defaults write com.apple.dt.Xcode ShowBuildOperationDuration YES”

重新启动Xcode以注意工具栏中的构建时间。 （这是我使用objective-c的非干净构建时间）

根据自己的喜好调整脚本。 - 请注意脚本清除 派生数据文件夹。

#!/bin/sh

#2 GIG RAM
GIGA_BYTES=$((2*1024*1024*1024))

# a sector is 512 bytes
NUMSECTORS=$((${GIGA_BYTES}/512))

#ram disk
mydev=`hdiutil attach -nomount ram://$NUMSECTORS`
newfs_hfs $mydev

# make mount point
MOUNT_POINT=/Users/your_user_name/Library/Developer/Xcode/DerivedData

# ******************************************* 
# ** WARNING - MOUNT POINT WILL BE DELETED ** 
# *******************************************
rm -rf ${MOUNT_POINT}
mkdir -p ${MOUNT_POINT}

# mount
mount -t hfs $mydev ${MOUNT_POINT}
echo unmount $(MOUNT_POINT)

要查看效果并控制RAM驱动器：

mount                       - see mount points
umount mount_point          - unmount point
diskutil list               - see disks
diskutil eject /dev/diskX   - eject the disk
df -ahl                     - see free space

注意： 我基本上使用macOs提供的hdiutil。 我尝试切换-kernel选项（没有交换到磁盘）但在我的机器上失败，说它没有实现。

也许新操作系统即将推出，我们将看到更多改进，因为新的文件系统复制功能非常快，并且可能使这个脚本变得多余。

Answer 9

您提到为最常用的文件使用静态库来防止编译。您可以通过将标题放在经常使用的代码中而不是在预编译标头中的静态库中来完成类似的操作。至少他们只会被编译一次。

如果项目中有多种编译类型（例如Obj-C，Obj-C ++，C ++），必须注意避免问题。

Answer 10

嘿那里，我建议你优化项目的物理结构。关于这一点有一些很好的解读（至少在C ++世界中），但我做的是客观-C，并且通常适用相同的原则。

这是一篇关于项目物理结构优化的精彩文章，它往往会缩短编译时间 Games From Within: Physical Structure Part 1

祝你好运：）

Answer 11

一个字：TmpDisk

1. 使用TmpDisk创建1.5Gb RAM磁盘
2. 更改Xcode＆gt;偏好＆gt;位置＆gt;派生数据到/Volumes/1.5Gb/xcode数据
3. 享受速度！

Answer 12

快速注释关于“投入更多硬件”方法..

总结：通过进行重大硬件升级，我的速度提升了很快

测试：在克隆的macbooks上构建/运行完全相同的项目（唯一的区别应该是他们的硬件）

旧Macbook Air（1.86GHZ Core 2 Duo仅2GB RAM） VS 全新Macbook Pro（2.3GHZ酷睿i7 8GB内存）

建立IPHONE 3GS
Macbook Air 1:00 - 1:15
Macbook Pro~1：00

=＆GT;速度增加0到0:15

建立IPHONE 4S
Macbook Pro~0：35
Macbook Air~0：50

=＆GT; 〜15秒的速度增加

**部分测试：两台机器之间SIMULATOR的构建时间之间存在显着差异

在我的持续经验中......当你对PHONE硬件做出重大改变时你将获得显着的增长（即在3GS和iphone 5（或者4件）上建立时间）...至少在我的经验，限制因素是手机硬件（不是计算机硬件）。

SO ..以获得最快的构建时间..
选项1）编写代码并在快速计算机上运行模拟器或选项2）使用最新的iphone在设备上构建

Answer 13

如果整个项目在每次运行时都重建了，那可能是XCode 7.0中的错误＆lt; = 8.1给你带来了困难。

将用户定义的构建设置HEADERMAP_USES_VFS创建为YES将macbook编译时间从每次75秒减少到25秒。有关详细信息，请参阅Xcode 8 does full project rebuild。

Answer 14

我用5960x CPU切换到Hackintosh，超频到4.4GHz只是为了降低Xcode的编译时间。这是8个内核和16个线程。压碎所有mac的计算机的总成本为3000美元。然而，我已经花了至少10天的时间来设置它，首先是优胜美地。当我无法更新macOS而Xcode需要更新的操作系统时，我有六个月的停机时间。我只是让它运行了山脉，生活再次好起来。

我的2,8 GHz i7双核16 GB RAM MacBook Pro在75秒内编译我的项目，Hackintosh在20秒内完成。 （项目中的Swift，dlib，opencv c ++）

然而，最大的问题是Xcode在编译swift时似乎没有使用多个线程。这是瓶颈，我希望他们能尽快解决。