swift 选中长按项_Swift编译- 优化编译速度

找出编译耗时过长的文件
要优化项目的编译速度，首先需要把耗时过长的文件找出来，然后进行重点优化。这里会用到Xcode build的两个OTHER_SWIFT_FLAGS：

• -Xfrontend: 如果编译或类型检查时耗时多长，则在Xcode中输出警告。
• -debug-time-function-bodies：输出每个函数的编译时长。

添加这些flag的方法为：

1. 选中Target
2. 选中Build Settings
3. 搜索“Other Swift Flags”
4. 添加”-Xfrontend -debug-time-function-bodies“

image
基于这两个flag，有3个方法可以找到耗时过长的文件，这三个方法的本质是一样，只不过是手动操作的多少而已，推荐使用第一种。

ps；如果你也对性能优化感兴趣，不如加入iOS技术交流大家一起互相交流学习。

1.（推荐）使用BuildTimeAnalyzer

BuildTimeAnalyzer是一个macOS app，用于辅助分析Xcode的编译log。

从github下载这个app的源码后，在Xcode打开项目，点击Product >> Archive >> Export，就可以生成BuildTimeAnalyzer。双击运行看到如下的页面，

按照使用说明一步步操作之后，就可以看到类似于下图的界面，点击任意一行，Xcode就会跳转到对应的函数中。

2. 命令行方式

命令行方式不需要修改Xcode的项目设置，将下面命令行中的SwiftCompileTime替换为你的项目名，在项目所在目录下直接运行即可，它会将每个文件的编译时间都输出到culprits.txt中。这个命令执行的时间可能会非常长！一定要耐心等待。
项目后缀名为.xcworkspace时使用:

xcodebuild -workspace SwiftCompileTime.xcworkspace -scheme SwiftCompileTime clean build OTHER_SWIFT_FLAGS="-Xfrontend -debug-time-function-bodies" | grep .[0-9]ms | grep -v ^0.[0-9]ms | sort -nr > culprits.txt

项目后缀名为.xcodeproj时使用：

xcodebuild -project SwiftCompileTime.xcodeproj -scheme SwiftCompileTime clean build OTHER_SWIFT_FLAGS="-Xfrontend -debug-time-function-bodies" | grep .[0-9]ms | grep -v ^0.[0-9]ms | sort -nr > culprits.txt

输出文件的内容的样式如下：

 210.61ms    /Users/xxx/Documents/Workspace/SwiftCompileTime/SwiftCompileTime/TVGuor/String+TVGuor.swift:34:34 get {} 196.79ms    /Users/xxx/Documents/Workspace/SwiftCompileTime/SwiftCompileTime/TVGuor/String+TVGuor.swift:34:34 get {} 128.94ms    /Users/xxx/Documents/Workspace/SwiftCompileTime/SwiftCompileTime/TVGuor/Optional+Extension.swift:23:28 get {} 123.50ms    /Users/xxx/Documents/Workspace/SwiftCompileTime/SwiftCompileTime/TVGuor/Optional+Extension.swift:23:28 get {} 119.40ms    /Users/xxx/Documents/Workspace/SwiftCompileTime/SwiftCompileTime/TVGuor/VideoAlbum.swift:565:17 @objc public dynamic func formatVideoCount(by type: TVGVideoAlubmType) -> String 117.80ms    /Users/xxx/Documents/Workspace/SwiftCompileTime/SwiftCompileTime/TVGuor/String+Extension.swift:109:23 get {} 114.67ms    /Users/xxx/Documents/Workspace/SwiftCompileTime/SwiftCompileTime/TVGuor/NSObject+Extension.swift:13:32 get {} 112.09ms    /Users/xxx/Documents/Workspace/SwiftCompileTime/SwiftCompileTime/TVGuor/String+Extension.swift:109:23 get {} 110.23ms    /Users/xxx/Documents/Workspace/SwiftCompileTime/SwiftCompileTime/TVGuor/NSObject+Extension.swift:13:32 get {} 108.80ms    /Users/xxx/Documents/Workspace/SwiftCompileTime/SwiftCompileTime/TVGuor/Constants+Enum.swift:61:17 static func channelNo(fromChannelString channel: String?) -> Int? 103.16ms    /Users/xxx/Documents/Workspace/SwiftCompileTime/SwiftCompileTime/TVGuor/String+Extension.swift:26:10 func urlQueryEncoded() -> String 102.63ms    /Users/xxx/Documents/Workspace/SwiftCompileTime/SwiftCompileTime/TVGuor/Constants+Enum.swift:61:17 static func channelNo(fromChannelString channel: String?) -> 

3.（不推荐）手动查看Xcode log方式
这个方式需要大量的手动操作，效率很低，不推荐，列出来仅做参考。步骤如下：

• 按照上面的教程，在Xcode中添加”-Xfrontend -debug-time-function-bodies“的flags
• 编译
• 点击⌘-9(Xcode 8上是⌘-8)跳转到Build Report
• 右击build log >> Expand All Transcripts 就可以看到编译时长的log了

通过修改项目配置实现优化优先级：高
在修改代码之前，可以先通过修改Xcode的配置实现编译速度的优化

• Optimization Level。
  • Build Settings -> Optimization Level -> Debug模式下设置为None。
  • Build Settings -> User-Defined -> 添加 SWIFT_WHOLE_MODULE_OPTIMIZATION = YES

• Debug模式下不生成dSYM文件。
  • dSYM(debug symbols file)是一个存储debug信息的文件，每次编译时都会生成。但在Debu模式下我们并不需要它，所以可以将Debug的值设为"DWARF"，仅在Release使用"DWARF with dSYM File".

避免使用简洁表达式
这是一个让人很纠结的优化。Swift提供了很多简洁的表达方式，比如定义变量时可以不用声明变量的类型，使用??为optional提供默认值等，这些功能为Swift开发者提供了不少便利，也构成了Swift简洁的编程风格。不过它们在提供便利的同时，也增加了不少编译的时间。如何抉择，是令开发者头疼的一个问题。我个人的观点是，对于那些并没有提供太多便利的表达式，一定要替换为编译更快的写法；其他简洁表达式，只要没有显著的增加编译时长，继续使用。 一定要避免使用String1 + String2优先级：高
一定要避免使用加好将两个字符串合并起来，可以改用"(string1)(string2)"。
将"123" + string1 + "456"
替换为"123(string1)456" 一定要避免使用Array1 + Array2优先级：高
一定要避免使用加好将两个数组合并起来，可以改用array1.append(contentsOf: array2)。
将array1 + array2
替换为array1.append(contentsOf: array2)
对于复杂变量的定义，添加类型声明优先级：高
在Swift中定义变量时可以不带类型声明，编译器会根据初始化的值去猜测变量类型，比如let str = "123"就定义了一个String。这为Swift开发者提供了很大的便利，但编译器分析变量类型是需要时间的。从减少编译时间的角度考虑，肯定是要给每个变量定义都加上类型声明，但这样就完全不是在写Swift的代码了！
其实对于简单的变量定义，比如let str = "123"和let str: String = "123"，添不添加类型声明，编译时间都差不多，但对于下面两个复杂的类型，最好还是加上type。

 let myCompany = [    "employees": [         "employee 1": ["attribute": "value"],         "employee 2": ["attribute": "value"],         "employee 3": ["attribute": "value"],         "employee 4": ["attribute": "value"],         "employee 5": ["attribute": "value"],         "employee 6": ["attribute": "value"],         "employee 7": ["attribute": "value"],         "employee 8": ["attribute": "value"],         "employee 9": ["attribute": "value"],         "employee 10": ["attribute": "value"],         "employee 11": ["attribute": "value"],         "employee 12": ["attribute": "value"],         "employee 13": ["attribute": "value"],         "employee 14": ["attribute": "value"],         "employee 15": ["attribute": "value"],         "employee 16": ["attribute": "value"],         "employee 17": ["attribute": "value"],         "employee 18": ["attribute": "value"],         "employee 19": ["attribute": "value"],         "employee 20": ["attribute": "value"],     ] ]  

 // build time: 330ms let tm1 = ceil(abs(PlayerWaitingStartInterval - timer.fireDate.timeIntervalSinceNow) * 1000) // build time: 79ms // Add type annotation let tm1: Double = ceil(abs(PlayerWaitingStartInterval - timer.fireDate.timeIntervalSinceNow) * 1000) // build time: 26ms // Add type annotation & separate into two parts let interval: Double = abs(PlayerWaitingStartInterval - timer.fireDate.timeIntervalSinceNow) let tm1: Double = ceil(interval * 1000) 

避免使用Nil-Coalescing operator ?? 优先级：低??同样会增加编译时长。但我觉得这个优化的优先级并不高，仅在编译时长真的非常长时才考虑使用。
将let name = string ?? ""
替换为

 if let name = string { /* string has value */ } else { /* string is nil*/ } 

避免使用条件运算符?: 优先级：低?:与??一样会增加编译时长，但优化的优先级也不高。
将let letter = isFirst ? "a" : "b"
替换为

 var letter = "" if isFirst {    letter = "a" } else {   letter = "b" } 

预计算优先级：中
不要直接在if-else的condition中做计算，会大大的增加编译时长。可以先在外部创建一个变量保存计算好的值，再将这个变量作为condition。
将if number == 60 * 60 {}
替换为

 let number: Double = 60 * 60 if number == 3600 { } 

Closures and lazy properties

优先级：高
Lazy Property和Closures也可能导致编译时长的增加。下面这个代码是一个很普通的lazy Property定义，但它却有可能导致过长的编译时间。

 // Lazy property private(set) lazy var chartViewColors: [UIColor] = [ self.chartColor, UIColor(red: 86/255, green: 84/255, blue: 124/255, alpha: 1), UIColor(red: 80/255, green: 88/255, blue: 92/255, alpha: 1), UIColor(red: 126/255, green: 191/255, blue: 189/255, alpha: 1), UIColor(red: 161/255, green: 77/255, blue: 63/255, alpha: 1), UIColor(red: 235/255, green: 185/255, blue: 120/255, alpha: 1), UIColor(red: 100/255, green: 126/255, blue: 159/255, alpha: 1), UIColor(red: 160/255, green: 209/255, blue: 109/255, alpha: 1), self.backgroundGradientView.upperColor ] 

如果将它改为下面的closure后，编译时间会更长。

 private let createChartViewColors = { () -> [UIColor] in     let colors = [ UIColor(red: 86/255, green: 84/255, blue: 124/255, alpha: 1), UIColor(red: 80/255, green: 88/255, blue: 92/255, alpha: 1), UIColor(red: 126/255, green: 191/255, blue: 189/255, alpha: 1), UIColor(red: 161/255, green: 77/255, blue: 63/255, alpha: 1), UIColor(red: 235/255, green: 185/255, blue: 120/255, alpha: 1), UIColor(red: 100/255, green: 126/255, blue: 159/255, alpha: 1), UIColor(red: 160/255, green: 209/255, blue: 109/255, alpha: 1), ] return colors } 

解决方案是将初始化代码移到一个单独的函数中。从代码风格的角度考虑，将过长的初始化代码移到单独的函数中也是一个好习惯，查看代码时可以更加清晰地看出一个class定义了哪些property。

 // Cumulative build time: 56.3ms private(set) lazy var chartViewColors: [UIColor] = self.createChartViewColors() // Build time: 6.2ms private func createChartViewColors() -> [UIColor] { return [         chartColor, UIColor(red: 86/255, green: 84/255, blue: 124/255, alpha: 1), UIColor(red: 80/255, green: 88/255, blue: 92/255, alpha: 1), UIColor(red: 126/255, green: 191/255, blue: 189/255, alpha: 1), UIColor(red: 161/255, green: 77/255, blue: 63/255, alpha: 1), UIColor(red: 235/255, green: 185/255, blue: 120/255, alpha: 1), UIColor(red: 100/255, green: 126/255, blue: 159/255, alpha: 1), UIColor(red: 160/255, green: 209/255, blue: 109/255, alpha: 1),         backgroundGradientView.upperColor     ] } 

奇怪的优化

这里列出的是Swift编译优化中的一些奇怪现象，感觉更像是编译器的一些bug，不必花太多时间在这方便。

CGFloat转化为CGFloat

优先级：低
下面的代码，将一个值为CGFloat的转化为CGFloat时反而会导致编译时长的大大增加。这是一个很奇怪的现象，估计是编译器的bug。

 // Build time: 3431.7ms return CGFloat(M_PI) * (CGFloat((hour + hourDelta + CGFloat(minute + minuteDelta) / 60) * 5) - 15) * unit / 180 // Build time: 3.0ms return CGFloat(M_PI) * ((hour + hourDelta + (minute + minuteDelta) / 60) * 5 - 15) * unit / 180 

Round()优先级：低
下面的代码只是调用了round()就增加了97%的编译时长，很奇怪。

 // Build time: 1433.7ms let expansion = a — b — c + round(d * 0.66) + e // Build time: 34.7ms let expansion = a — b — c + d * 0.66 + e