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

a2ab95979864ea7579e49eebea7b7d66.png

找出编译耗时过长的文件
要优化项目的编译速度,首先需要把耗时过长的文件找出来,然后进行重点优化。这里会用到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“

1a863a700c43f50e1d192f59e2e97256.png


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

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

1.(推荐)使用BuildTimeAnalyzer


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


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

6375ef13bee58a72268f1f98fc8ec02b.png


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

280c1fc2654dbe8708c33b6f5933a876.png

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了

156ff270934e23db8e63e2f94d121bf4.png

5bfdd91da0b21d431121272ce5b01b2d.png


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

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

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

6f67cba3c67f32cd62c6f6f2422bceda.png

避免使用简洁表达式
这是一个让人很纠结的优化。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
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值