chu*_*bra 9 xcode build swift xcode10
修改单行代码并在大项目中执行Xcode 10.1增量构建后，Xcode在完成所有列出的任务（编译更改的文件和合并swiftmodule都完成）后，大部分构建时间都花在“编译swift源文件”阶段，任务列表截图: https://imgur.com/a/JoVI0zB
虽然编译和合并 swift 模块只需要不到一秒钟，但在我的项目 (300k LOC) 中，整个阶段最多可能需要 2 分钟。
Xcode在这个时候做了什么？有没有办法加快这个过程？
用 Obj-C 编写的类似项目在更改 1 行代码后只需几秒钟即可启动。
Hel*_*lam 10
我有同样的问题，经过大量调查后，我确定无论它在做什么，它都是基于您拥有的 swift 源文件的数量。
在2018 年的 wwdc 演讲中，演示者说Xcode 构建系统（可在视频抄本中搜索）：
这意味着与 Clang 不同，当编译一个 Swift 文件时，编译器将解析目标中的所有其他 Swift 文件。
因此，即使/尽管增量构建只需要重新编译单个文件，它仍然会解析所有其他swift 文件。
我们的项目有超过 2000 个 swift 源文件，我们看到重新编译单个独立文件的构建时间增加了 3 分钟以上。
因为在 WWDC 演讲中听到它是不够的，我做了以下自己的测试：
在我的测试中，附加 swift 文件内容的复杂性似乎并不重要，只是文件数量。
将您的应用程序分成更小的框架，以减少每个目标中 swift 源文件的数量。
这是一个不错的指南，如果您还不知道如何进行，则显示了如何进行此操作的步骤。
在我上面的测试用例中，我创建了一个新框架并将 2,000 个 swift 文件移动到框架中，然后在原始项目中测试增量构建时间（导入框架），构建时间回到 < 1-2 秒。当然，在框架内进行增量构建仍然会很慢，但理想情况下，您会将项目拆分为许多更小的框架，以便每个框架都有更快的增量构建时间。
如果问题是文件数量，为什么不合并一堆文件来减少数量？因为它可能会导致增量构建变慢。
根据2018 年 WWDC 在 Xcode 中的 Building Faster：
Swift 的依赖模型基于文件
这与我们当前的问题有关，因为这意味着对文件的任何更改（仅对函数体内容的更改除外）都将导致任何依赖于已更改文件中的任何内容的文件的重新编译。
如果将多种类型合并到一个文件中，如果任何更改涉及大文件或其任何依赖项，则会导致在增量构建中重新编译更多代码。它还将增加大文件所具有的依赖项的数量，因此如果修改了大文件中的任何类型，所有依赖项都将被重新编译。