快速的构建时间优化-第2部分

自从我撰写有关该主题的第一篇文章以来已经过去了两个月。那篇文章介绍了Xcode的构建时间分析器，该分析器旨在帮助确定Swift编译器难以解决的地方。

从那时起，该插件就遍及整个Swift社区，并且在WWDC实验室期间，看到了很多人在使用它。因此，发生了一些非常有趣的事情。 Apple与我联系并提出了增强请求（请参阅新的“发生次数”列）。

可以通过插件识别导致构建时间缓慢的两种原因。第一个是单个例程花费太长时间来编译的地方。这是我以前的文章的重点，我在那里列出了一些示例和解决方法。另一个是对闭包和惰性属性进行类型检查的次数过多。这将是这篇文章的重点。

我最近在插件窗口中添加了一个名为Occurrences的新列。目的是使人们更容易理解为什么相对简单的代码有时会减慢构建过程。

如上所示，在我的Xcode构建日志中，有几次惰性获取器发生了159次。实际上，我可以在日志中打开任何文件并查看对其的引用。下面是从3个单独的文件中摘录的一些示例，这些文件均未在代码中引用CMGridView。

  5.7ms /CMGridView.swift:63:27 @objc get {} 
  16.5ms /CMGridView.swift:63:27 @objc get {} 
  15.5ms /CMGridView.swift:63:27 @objc get {}

因此，事实证明编译器正在为目标中的每个.swift文件类型检查我的lazy属性，从而使累积生成时间总计为1905.5ms（使用Swift 2.2）。对于Swift 3.0，问题仍然存在，但是构建时间几乎减少了一半。

如果您在项目中使用的是惰性属性，我真的建议您注意这一点。在上面的示例中重构代码之前，我曾经有很多这样的代码。

让我们看一下代码。

代码：

为了缩短这些代码的构建时间，只需将代码尽可能移至私有方法即可。

上面的lazy属性仍将接受重复的类型检查，但是随着代码的移出，构建时间现在减少了96.7％ 。

随着Xcode 8.0的出现，Xcode插件的时代结束了，Xcode扩展的新时代开始了。鉴于扩展的局限性，我正在努力使该插件成为一个独立的应用程序。（希望）在Xcode 8.0脱离beta版本之前就可以了。同时，这是根据我之前的文章中列出的示例进行的一些比较。

尽管上述内容看起来很有希望，但我确实注意到了Swift 3.0中的几个新问题。但公平地说，Xcode 8仍处于测试阶段，我没有对总体构建时间进行基准测试。时间会告诉我是否需要撰写有关该主题的第三篇文章……