问Xcode 10 iOS应用程序构建，“隐藏”任务花费了大部分构建时间。

EN

我也有同样的问题，经过大量的调查，我确定不管它在做什么，它都是基于你拥有的快速源文件的数量。

根本原因

在2018年wwdc谈Xcode构建系统中，主持人说(可在视频记录中搜索)：

这意味着，与Clang不同，在编译一个Swift文件时，编译器将解析目标中的所有其他Swift文件。

因此，即使/尽管增量构建只需要重新编译一个单个文件，它仍然会解析每一个其他快捷文件。

我们的项目有2000多个快速源文件，我们正在看到3+分钟的增量构建时间来重新编译一个独立的文件。

测试以证明根本原因

因为在WWDC的演讲中听到它是不够的，所以我自己做了以下测试：

1. 创建了一个新项目
2. 测试几乎为空项目的增量构建时间，更改单个文件
   • 增量构建几乎立即完成(< 1-2秒)

​

1. 使用脚本生成2,000个快速文件，每个文件包含一个具有唯一名称的简单结构、2个变量和一个简单的函数。任何文件之间都不存在依赖关系。
2. 将包含2,000个新的快速文件的目录添加到项目中，并完成完整的构建。
3. 再次测试单个文件的增量构建时间
   • 增量构建时间超过1分钟。

​

在我的测试中，附加的快速文件的内容的复杂性似乎并不显着，只是文件的数量。

解决方案-模块化/框架

将您的应用程序分离到更小的框架中，以减少每个目标中快速源文件的数量。

如果你还不知道怎么做的话，这是一本不错的指南。给出了如何做这件事的步骤。

在上面的测试用例中，我创建了一个新的框架，并将2,000个快速文件移动到框架中，然后在原始项目中测试增量构建时间(导入框架)，构建时间回到< 1-2秒。当然，在框架内进行增量构建仍然很慢，但理想情况下，您可以将项目分解为多个和更小的框架，以便每个框架都有更快的增量构建时间。

不是解决方案-合并文件

如果问题是文件的数量，为什么不合并一堆文件来减少数量呢？因为它可能会导致缓慢的增量构建。

根据2018年WWDC的Xcode建筑速度更快

Swift的依赖模型基于文件

这与我们当前的问题有关，因为这意味着对文件的任何更改(仅对函数体内容的更改除外)将导致对任何依赖于已更改文件中的任何内容的文件重新编译。

如果将多个类型合并到单个文件中，如果任何更改都涉及到大文件或其依赖项，则将导致更多的代码在增量构建上重新编译。它还将增加大文件的数量依赖性，因此如果修改了大文件中的任何类型，那么所有这些类型都会被重新编译。