Swift编译慢-优化 - 优化编译速度

找出编译耗时过长的文件

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

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

添加这些flag的方法为：

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

image

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

1.（推荐）使用BuildTimeAnalyzer

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

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

image

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

image

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了

image

image

通过修改项目配置实现优化

优先级：高

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

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

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

image

避免使用简洁表达式

这是一个让人很纠结的优化。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

References

Profiling your Swift compilation times

Uber: Swift with a hundred engineers

Speed up Swift compile time

Regarding Swift build time optimizations

Swift build time optimizations — Part 2

Improving Swift Compilation Times from 12 to 2 Minutes

作者：mobilefellow
链接：https://www.jianshu.com/p/89e9df02e244
來源：
著作权归作者所有，任何形式的转载都请联系作者获得授权并注明出处。

Swift编译慢-优化 - 优化编译速度

找出编译耗时过长的文件

1.（推荐）使用BuildTimeAnalyzer

2. 命令行方式

3.（不推荐）手动查看Xcode log方式

通过修改项目配置实现优化

避免使用简洁表达式

一定要避免使用String1 + String2

一定要避免使用Array1 + Array2

对于复杂变量的定义，添加类型声明

避免使用Nil-Coalescing operator ??

避免使用条件运算符?:

预计算

Closures and lazy properties

奇怪的优化

CGFloat转化为CGFloat

Round()

References

你可能感兴趣的:(Swift编译慢-优化 - 优化编译速度)

避免使用Nil-Coalescing operator `??`

避免使用条件运算符`?:`