ChatGPT生成的复古电脑

如果你开发 iOS 应用，你肯定经历过 Xcode 构建时间过长的痛苦。你只是小小修改了一下代码，按下 ⌘ + B 后…… 再等待着。甚至会看看手机。终于构建完成了，终于可以继续手头的工作了——直到下一次循环再次开始。

有一段时间，我并没有太在意。在我开发我的最新应用Okla时，当我的构建时间开始逐渐增加时，我知道我有麻烦了。我越想这件事，就越觉得糟糕。每天我花在等待Xcode上的时间到底有多少？我有多少Xcode Cloud分钟是在无谓地浪费呢？

所以我就像一个好的工程师一样开始调查。深入查看构建日志，分析过程，并测试不同的优化后，我将构建时间从129秒减少到了20秒。这相当于减少了大约六倍的时间。这些优化大大节省了我的时间和减轻了我的压力，如果你的构建时间很长，这些优化也会为你节省不少时间。

当遇到构建缓慢时，通常的直觉反应是立即开始优化——清理构建文件夹、删除派生数据、调整编译器选项，甚至在极端情况下升级硬件设备。但在没有首先找出减速的具体原因之前，这些努力无异于在黑暗中乱猜。

美国工程师兼发明家查尔斯·凯特林（Charles Kettering）曾说：“表述清楚的问题就解决了一半。”他完美地捕捉到了找出实际瓶颈的重要性。与其假设低效的地方，关键是要收集数据，找出真正的原因。在深入解决之前找到关键瓶颈，而不是假设低效所在，是至关重要的。

首先，我使用了Xcode的构建时间线来分析哪些步骤耗时最长。这是一个非常有用的工具，但我发现很多人甚至都不知道如何找到它。从报告导航器（⌘ + 9）中，选择一个构建报告文件。在打开的构建日志上右键点击并选择显示在时间线上。

我最初的 Xcode 构建时间表

我要指出，对于所有的构建，我使用了一个冷启动构建，以确保我面对的是最糟糕的情况。你可以看到在我上面的时间轴中，两个编译资源目录的任务是最长的，每个大约耗时60秒。多亏了Xcode构建时间轴，我知道是什么在拖慢我的构建时间。

先说个背景，Okla 是一个用来识别 Occlupanids 的应用，用来识别那些封住面包袋的小塑料夹子。你可能觉得难以置信，有一个社区（我也是其中一员）把它们当作真正的生物一样对待，还有它们自己的分类系统。社区里有几十人呢！

这款应用程序让收藏者可以过滤、排序和浏览分类系统，其中包含每个物种的手绘炭笔素描。该应用包含超过250个物种，每个物种需要三种不同的尺寸，以及用于小部件的小尺寸版本，我管理的高分辨率PNG文件超过1,500个——总计接近200MB。你可能会觉得屏幕上的这些图片有些臃肿。

嗯，奥克拉州的资产清单

最初，所有图像资源都存储在一个资源目录中。这意味着Xcode需要一次性编译所有资产，这大大拖慢了构建过程。

为了优化这个过程，我将图片资产按各自所属的类别分组，并分到了不同的资产目录中——与应用程序中现有的分类方式一致。一般的经验法则是，每个目录大约包含~100MB，约50个文件左右。

为每个家庭设定单独的资产清单

这有利于整理，但并没有显著减少构建时长——每个文件仍然需要同样长的时间来整理。

在拆分资产目录后，Xcode的构建时间线

步骤二: 切换到单个资产

默认情况下，Xcode 支持 @1x、@2x 和 @3x 图像缩放以优化不同设备。然而，由于 Okla 只针对 iOS 17 及更高版本，我移除了 1x 和 2x 资源，并在Attributes Inspector > Scales中进行切换。这将图像资源数量减少了 66%，从原来的数量来看，并将构建时间减少到 55 秒。这导致 iPhone SE 内存使用略有增加，但还不足以引起明显的性能问题。

使用单一尺度资产后 Xcode 的构建的时间线

最初，所有图片对所有目标都是可用的——这意味着在每次构建时，所有的 iOS 应用和小部件扩展都会编译所有的图片。为了解决这个问题，我将较大的图片移到了 iOS 目标，将较小的图片移到了小部件目标。现在，Xcode 只编译每个构建所需的内容，从而减少了不必要的处理。这使构建时间略有减少，现在只需要 43 秒。

Xcode构建过程中拆分图片到各自目标后的时机线

在这个阶段，图片仍然占用了应用包大约200 MB的空间，每张图片平均约为500 KB。使用Crunch，我将每张图片压缩到了约77 KB。这将图片资源的总大小减少到大约80 MB。再进行一次构建，构建时间就缩短到了不到20秒。

最后的构建成果

图像目录的编撰仍然是构建的主要工作，但要短许多。并行构建还让我受益，进一步节省了我们的时间。

优化构建时间并不是一劳永逸的解决方案，而是关于做出渐进式改进，这些改进累积起来会产生巨大的差异。通过分析Xcode耗时的地方，我发现可以拆分资产目录，减少冗余的图像比例，按目标分离资产，并压缩图像。每个步骤单独看可能并不显眼，但结合起来，它们把我的构建时间从超过两分钟缩短到了不到20秒。

这些更改让开发感觉更快了，我的迭代也快多了。等待构建的时间少了，就能花更多时间来完善Okla——这才是真正的进步。

感谢您花时间读到这里。在您离开前，谢谢。

• 点赞 并 关注 以阅读更多精彩内容！
• 查看我的月度通讯 Kernel Extension (内核扩展) 获取更多 iOS 开发信息。
• 在 BlueSky (蓝天社交) 上关注我。
• 在 Twitter (推特) 上关注我。
• 加入我们在 Discord (语音聊天软件) 的社区。
• 在 Ko-Fi (支持创作者的小额捐赠平台) 上支持我的工作。