桥接头中导入的文件数量是否会影响编译时间？

Question

我有一个理论，但我不知道如何检验它。我们有一个相当大的iOS项目，大约有200个Swift文件和240个obj-C文件(以及等量的头文件)。我们仍然使用Swift 1.2，这意味着整个项目都会得到重建。

我注意到，每个.swift文件的编译时间大约为4-6秒；在其他项目中，最多只需要2秒钟。

现在，我注意到在构建输出中，每个.swift文件都会重复头文件中生成的警告，这使我相信快速编译器将重新解析桥接头中包含的所有头。因为我们在桥接头中有~160条导入语句，这就有点累加了。

因此，基本问题：

• 桥接头的大小会影响构建时间吗？
• 有任何方法来优化这一点，所以它只解析一次头？
• Swift 2也有同样的问题吗？
• 还有其他的技巧来优化这个吗？除了用Swift重写所有东西外，这对我们来说是一个劳动密集的项目，在这个时候我们无法承担。

Answer 1

桥接头的大小会影响构建时间吗？

绝对一点儿没错。桥接头中包含的文件越多，编译器解析它们的时间就越长。这就是预编译头试图修复的地方。PCH文件已被逐步淘汰，以支持模块。

有任何方法来优化这一点，所以它只解析一次头？

老实说，我不知道，这取决于源文件和依赖关系。

Swift 2也有同样的问题吗？

是的，但是编译器优化在新版本的Xcode和Swift中要好得多。同样，在这里强调模块而不是预编译头文件。我应该注意，可以将pch文件直接传递到clang，但这很少是一个好主意。

如果可以的话，我会尝试在混合项目中使用pch头。我还会考虑创建预编译库或静态框架，以防止类的不断重构。有一个伟大的WWDC视频从2013年介绍模块，我强烈建议观看它。

参考文献：

• 模块和预编译头
• WWDC 2014会议404 -目标C的进展
• 为什么没有在Xcode 6中自动创建ProjectName-Prefix.pch . Why？

Answer 2

我只能从我以前工作的经历中说出来，这意味着有些事情可能已经改变了。此外，我不确定这是否有助于你的具体情况，因为你混合了目标C和Swift，我从来没有做过，但理论仍然是健全的。

简而言之，是的，桥接头的大小会影响编译时间，而且正确的是，它会对每个文件/包含进行一次分析。

对此进行优化的正确方法似乎是将项目分成模块(在某个时候也称为“框架”)，因为每个模块都是单独编译的，因此如果没有任何变化，就不会重新编译。