为大型游戏项目改进 XCode 4.5 的构建时间答案

【问题标题】：Improving build time on XCode 4.5 for a huge game project为大型游戏项目改进 XCode 4.5 的构建时间
【发布时间】：2012-12-30 15:26:46
【问题描述】：

场景： 我们有一个用于 iOS 游戏的 XCode 项目，其中包含大约 7000 多个文件。

只有 1000 多个文件是代码。其余的是图像、声音、关卡数据、XIB、plist、配置文件等。

它是一个通用应用程序，因此，我们为旧 iPhone、Retina iPhone、iPad 等提供了单独的资源集。我们还为 BG 图像等少量内容提供了 PNG 和 PVRTC，以充分利用不同的硬件。

问题：

目前该项目大约需要

42 秒清除（Cmd - Shift - K）

8.3 分钟完全重建 (Cmd - B)（重建时，进度条的一半在 1 分钟内填满）

aaaand... 5 分钟 36 仅用于运行 (Cmd - R) ??

在那之后，我按下“停止”并再次单击“运行”，没有做任何其他事情。 “再次运行”需要 2 分 40 秒

我还看到资源再次被复制，一些文件被再次构建，如进度条上方的 XCode 所示。

高度赞赏任何减少这些阶段时间的解决方案。请问？

附言该项目是在 XCode 3 天内启动的，每次有新的 XCode 出来时，我们都会自动更新 xcodeproj 文件。

【问题讨论】：

我不是在寻找一个神奇的按钮。但由于 XCode 在编译/构建阶段没有给我任何信息，我正在寻找解决方案，比如 - 是否有可以打开的详细模式？命令行构建是否可以帮助我解决为什么需要这么长时间？等等
您对我们有任何更新吗，根据构建日志，哪些构建阶段是最昂贵的？
@Mecki 非常感谢您的指导！我确实设法想出一些步骤来将构建/运行时间减少一半或 1/3。 1) 验证产品需要很长时间。有人在目标设置中将验证构建产品设置为“开启”。我把它关掉了。（至少现在是“调试”） 2）发现 dSYM 文件的生成也需要一段时间。所以跟着这个问题 - stackoverflow.com/q/8454937/121067 3）由于粗心的编码实践，整个项目中也有太多警告（1000+）。只是手动关闭了其中的许多。
只有在我每次运行时，Codesign 阶段都需要一段时间（不是在完全重建期间）。但我猜如果我必须在设备上测试它，没有办法将其关闭。
我知道我在这里很贪心，但是有什么方法可以减少“代码设计”的时间吗？ :D

标签： xcode compiler-construction compilation xcode4.5 compiler-optimization

【解决方案1】：

您正在寻找的是改进调试的编译和启动时间，对吗？那么为每个平台创建不同的目标呢？因此，您保留相同的代码，但仅根据您的调试设备打包一部分资源用于调试目的。

要做到这一点，继续你的实际目标，右键单击并复制。保持你的实际目标不变，它是胖的！对于新目标，假设它是 iPad Retina，转到“构建阶段”->“复制捆绑资源”并删除所有与 iPad Retina 无关的资源。对每个平台都这样做。

然后在 Xcode 的左上角，为特定设备选择好的目标。也许，您可以定义目标接受哪个设备。

如果你使用持续集成，让你的构建机器在晚上编译胖目标。

【讨论】：

为什么每个平台都需要不同的目标？在调试器中启动目标时，您可以告诉 Xcode 仅为您当前的平台构建（这是默认的 BTW），因此除非您进行部署构建，否则 Xcode 不会真正为所有平台构建。此外，您的建议只会影响编译时间，提问者说编译只是这 8 分钟以上的 1 分钟。即使你可以立即编译，他仍然需要等待 7 分钟。
不，对于不同的目标，您可以说您不希望将应用程序中的 iPhone Retina 资源发送到您的 iPad Retina 设备。 ipa 会更小，因此上传到 iPad 的速度会更快。这里的关键是资源
只有这种情况，如果视网膜和非视网膜设备有不同的资源，可能不是这样。例如。为了节省空间，所有图像可能仅以视网膜质量存在，并在加载时甚至在绘制时缩小。特别是对于大多数资源作为纹理加载的 OpenGL 游戏，两种设备都只有一组纹理并不少见（视网膜纹理通常几乎什么都没有，进一步的 OpenGL 可用于缩小 GPU 上的纹理几乎没时间）。
我同意 Mecki，但根据 QuakeBoy 的说法：“它是一个通用应用程序，因此，我们为旧 iPhone、视网膜 iPhone、iPad 等提供了单独的资源集。我们还为 BG 等少数东西提供了 PNG 和 PVRTC图像等，以充分利用不同的硬件。”这就是我试图解决的问题
也许实现并不完美，但值得只发送特定调试设备所需的资源。

【解决方案2】：

如果问题的原因未知，则无法解决问题。 “我的车不再启动了，有没有办法让它重新启动？”；最有可能，但前提是它当前拒绝启动的原因是已知的。这听起来有点像您希望 Xcode 中有一个名为“Build fast”的魔法开关，通过启用它，一切都会变得更快。如果有这样的开关，你不觉得它会默认启用吗？你不认为它实际上会一直启用吗？

我也想知道你为什么用“编译器”和“编译器优化”标记这个问题。根据您自己的说法，编译只需要 8.3 分钟的构建时间，那么如何进一步减少编译时间使整个过程更快？即使编译时间减少到零，这仍然会给您留下 7.3 分钟的构建时间。不要在错误的地方进行优化。

这就像优化代码。如果您的代码太慢，那么如果您没有将大部分时间花在代码中，那么所有优化都是毫无意义的。如果只有 0.1% 的时间花在这段代码上，那么优化一段代码以使其运行速度提高 10 倍对整体性能毫无帮助。代码优化的第一步是分析代码并找出在哪段代码上花费了多少时间。

因此，为了让您的构建过程更快，第一步也是最重要的一步是找出究竟为什么构建时间现在很慢。如果没有这些知识，人们可以在这里给出的所有答案都只是猜测。一旦您确切地知道问题出在哪里，您就可以回来并准确地询问如何使这一步更快。首先优化最慢的一步，然后是第二慢的，以此类推。

查看 Xcode 中的构建日志

确保选择“所有消息”，否则您只会看到警告和错误，或者只会看到错误。现在开始一个干净的构建，选择左侧弹出的新日志并继续监视该日志。您将准确地看到 Xcode 何时开始操作以及何时接近下一个操作。这应该会给您一个第一印象，哪些任务需要相当长的时间才能完成。一旦您告诉我们这些是哪些任务，我们就可以开始提出建议，您如何才能更快地完成这项任务。

【讨论】：

酷，感谢编译日志。事实上，我一直在寻找能够找出编译器在哪些阶段需要更多时间的方法。我会运行它并让你知道。
-1。最后两段很有用，其余的在我看来是粗鲁和屈尊的。
@TarkaDaal 是的，如果我刚刚关闭这个问题当然会不那么粗鲁，就像大多数人在问题不包含足够的信息甚至无法解决时所做的那样。我宁愿教育人们在未来提出好的问题，因为这将帮助他们获得更好的答案并更快地得到答案。 OP 认为这并不粗鲁，我认为您的评论非常粗鲁。