更改单行代码并在大型项目中执行Xcode 10.1增量构建后，Xcode在完成所有列出的任务（编译更改的文件和合并swiftmodule都完成）之后，将大部分构建时间花费在“编译swift源文件”阶段。 屏幕快照，显示任务列表：User Info API
虽然编译和合并swift模块花费的时间不到第二秒，但是在我的项目中，整个阶段最多可能需要2分钟（300k LOC）。
此时Xcode做什么？有什么办法可以加快这个过程？
用Obj-C编写的类似项目在更改1行代码后只需几秒钟即可启动。
答案 0 :(得分：2)
我遇到了同样的问题，经过大量调查，我确定它所做的一切都是基于您拥有的快速源文件数量。
演示者在2018 wwdc talk about the Xcode build system中说（可以在视频的抄本中搜索）：
这意味着，与Clang不同，当编译一个Swift文件时，编译器将解析目标中的所有其他Swift文件。
因此，即使/虽然增量构建仅需要重新编译单个文件，它仍会解析其他快速文件。
我们的项目有2000多个快速的源文件，并且看到重新编译单个独立文件的构建时间增加了3分钟以上。
由于在WWDC演讲中听到它是不够的，所以我做了以下自我测试：
在我的测试中，其他快速文件内容的复杂性似乎并不重要，而只是文件数量。
将您的应用程序分成较小的框架，以减少每个目标中快速源文件的数量。
This is a decent guide显示了有关如何解决此问题的步骤。
在上面的测试案例中，我创建了一个新框架并将2,000个swift文件移入该框架，然后在原始项目（导入框架）中测试了递增的构建时间，并且构建时间回到了1-2秒。当然，在框架内进行增量构建仍然会很慢，但是理想情况下，您可以将项目拆分为许多较小的框架，以使每个框架都有更快的增量构建时间。
如果问题出在文件数量上，为什么不合并一堆文件以减少数量呢？因为这可能会导致增量构建速度变慢。
根据2018 WWDC's Building Faster in Xcode：
Swift的依赖关系模型基于文件
这与我们当前的问题有关，因为这意味着对文件的任何更改（仅对函数主体内容的更改除外）都将导致依赖于更改后文件中任何内容的任何文件的重新编译。
如果将多种类型合并到一个文件中，则任何更改都会影响大文件或其任何依赖项，这将导致更多代码在增量版本上重新编译。还会增加大文件所具有的依赖性，如果修改了大文件中的任何类型，它们都将重新编译。