Other Swift Flags
在build setting的Other Swift Flags中添加如下flag，就可在building log中看到详细的编译时长:
-Xfrontend -debug-time-compilation：输出文件的编译时长
-Xfrontend -debug-time-function-bodies:输出function编译时长
-Xfrontend -debug-time-expression-type-checking：输出function内每一行代码的编译时长
-Xfrontend -warn-long-function-bodies=100：编译时间超过100ms的function报警告
-Xfrontend -warn-long-expression-type-checking=100：编译时间超过100ms的代码报警告
日志一般都有数十万行，可阅读性极差。GitHub上有个工具可以方便的统计展示这些日志信息，链接如下：
github.com/fastred/Opt…
使用flag和对应的工具可以定位到具体编译时间特长的代码的位置，相应的进行修改就能解决代码层面的编码时间长的问题。
build setting
- Optimization Level：优化等级，Debug设为None
- Debug Information Format：在Debug模式下移除dsym文件
- Build Active Architecture：Debug模式下设为YES，只编译当前的Architecture，可以加快编译速度 这三个是常见的优化编译速度的设置。
代码规范
- Dictionary和数组之类的容器对象需要变量声明类型。不声明类型的容器对象会导致编译时长增加一秒左右
- String和array等对象不要用”+“拼接串联，String用“+”拼接会大幅增加编译速度
- 在if等逻辑判断语句中不要进行“+-/”计算操作
以上三点规范对编译时长影响比较大，建议严格遵守。
能缩短编译时长的代码规范的有很多，但是大多都不具备可操作性。比如：复杂的“+-/”和频繁嵌套类型转换也会导致编译时间长，通过将长的计算式拆分为多个短计算式等方式可以缩减编译时间，但是没有什么实际的意义，所以可以不用在意。
参考文档
参考文档比我写的详细，我只是将这些文档实践，然后总结一下有用的东西。
koke.me/2017/03/24/…
hackernoon.com/speed-up-sw…
github.com/fastred/Opt…
工具链接：
github.com/RobertGumme…
