<译> Optimizing Swift Build Times

Silver Bullet

2017-10-24

原文地址

函数和表达式的类型检查

Swift 的构建时间如此之长主要是因为需要做复杂的类型检查。Xcode 默认不会告诉你哪些代码需要很长时间来编译。你可以通过在 Build Settings 中的 Other Swift Flags 添加以下参数来查看：

-Xfrontend -warn-long-function-bodies=100 （100 指 100 ms，你也可以根据需要调整这个值）
-Xfrontend -warn-long-expression-type-checking=100

现在，重新构建你的项目，然后你就会看见像这样的错误警告：

下一步就是如何定位那些编译很慢的代码。John Sundell 和 Robert Gummesson 的文章可以帮上你的忙。

更多资源：

关注那些编译很慢的文件

上一章介绍了如何在函数及表达式层面改善编译时间，但有时候你也想知道某一个单独文件的总编译时间是多少。

现在，打开命令行，通过以下命令来收集项目文件的编译时间：

xcodebuild -destination 'platform=iOS Simulator,name=iPhone 8' \
  -sdk iphonesimulator -project YourProject.xcodeproj \
  -scheme YourScheme -configuration Debug \
  clean build \
  OTHER_SWIFT_FLAGS="-driver-time-compilation \
    -Xfrontend -debug-time-function-bodies \
    -Xfrontend -debug-time-compilation" | \
tee profile.log

(如果你使用的是 workspace，请自行把 -project YourProject.xcodeproj 替换成 -workspace YourProject.xcworkspace)

然后我们就可以把有用的编译时间信息提取出来：

2.7288 (  0.3%)  {compile: Account.o <= Account.swift }
2.7221 (  0.3%)  {compile: MessageTag.o <= MessageTag.swift }
2.7089 (  0.3%)  {compile: EdgeShadowLayer.o <= EdgeShadowLayer.swift }
2.4605 (  0.3%)  {compile: SlideInPresentationAnimator.o <= SlideInPresentationAnimator.swift }

更多资源：

Diving into Swift compiler performance

只构建你需要的架构

Xcode 默认会帮你设置好这个编译器参数，但是你应该检查一下以确保万无一失。你的项目在 Debug 模式下应该只构建那些需要的架构。

更多资源：

What is Build Active Architecture Only

dSYM 的生成

在新的项目中，dSYM 文件默认不会在 Debug 模式下自动生成。但是，我们有的时候需要在真机调试中生成这个文件来分析程序的崩溃和闪退原因。

因此，推荐设置如下：

更多资源：

Speeding up Development Build Times With Conditional dSYM Generation

编译器优化等级

另一个常见的技巧是：

Debug 模式下，将 Optimization Level 设置成 Fast, Whole Module Optimization
只在 Debug 模式下，在 Other Swift Flags 中添加 -Onone

这样能使编译器：

It runs one compiler job with all source files in a module instead of one job per source file

Less parallelism but also less duplicated work

It’s a bug that it’s faster; we need to do less duplicated work. Improving this is a goal going forward

更多资源：

针对 CocoaPods 的编译器优化

如果你的项目使用 CocoaPods，你也该考虑把 Pod 项目的编译器优化打开。你可以通过在 Podfile 文件中添加一个 post_install 的 hook 来实现：

post_install do |installer|
  installer.pods_project.targets.each do |target|
    target.build_configurations.each do |config|
      if config.name == 'Debug'
        config.build_settings['OTHER_SWIFT_FLAGS'] = ['$(inherited)', '-Onone']
        config.build_settings['SWIFT_OPTIMIZATION_LEVEL'] = '-Owholemodule'
      end
    end
  end
end

然后运行 $ pod install。别忘了对比一下添加这个 hook 前后的编译速度，来确认这个是否有效。

第三方依赖

现在有两种方式可以对项目安装第三方依赖：

1.源代码方式，当你 clean build 的时候，第三方依赖的源代码也会被重新编译一次。（例如：CocoaPods, git submodules, copy-pasted code, internal libraries in subprojects that the app target depends on）
2.预构建好的 framework 或者 library （例如：Carthage, static library distributed by a vendor that doesn’t want to provide the source code）

CocoaPods 作为 iOS 开发中最著名的依赖管理器，会在你每次 clean build 的时候将第三方依赖的源代码重新编译一次，从而使项目的编译时间更长。通常情况下，你不会经常地 clean build 项目。但实际情况是：你经常地不得不需要 clean build。（如需要切换分支，或者由于 Xcode 的 bugs 或其他奇怪的原因）

尽管 Carthage 比 CocoaPods 更加难用，但是它确实能加快项目的编译速度。因为 Carthage 的操作大多数都是修改声明依赖的文件 Podfile，（如添加或删除一个依赖，或者将依赖更新到一个新版本）。这些操作可能需要 5-15 分钟来完成，但是你进行这些操作的频率远远比 CocoaPods 重新把源代码编译一遍要少得多。

更多资源：

time spent waiting for Xcode to finish builds

模块化

Swift 的 Incremental compilation 并不是很完美。有时也许仅仅是修改了一个字符串，就会导致整个项目重新编译。

为了避免这个问题，你可以考虑将 app 拆分为几个模块。这里有 2 种方案：动态库和静态库（Xcode 9 Beta4 版本开始支持 Swift 静态库）。

假设你的 app 依赖一个叫做 DatabaseKit 的内部 framework。这种方法能够保证在你对 app 项目做了一些修改时，DatabaseKit 不会因为 Incremental compilation 而重新编译。

更多资源：

XIBs

XIBs/storyboards 和纯代码之间的抉择一直是一个热门的讨论话题，我们在这里不再过多地讨论。但是，有趣的是，如果你修改了 Interface Builder 里面的内容，只有那个修改的文件会被重新编译（成 NIB 格式），另外，如果你在 UIView 的某个子类里修改一个公开的方法，Swift 编译器可能会把继承自这个类的所有类都重新编译。

更多资源：