自从Swift诞生以后,苹果就一直在努力让它变得更好,更快。相比更加灵活的Objective-C,Swift显得更加老实本分。但是,如果你真的对它了解之后,你会觉得原来有如此之大的威力。
开发语言离不开编译器的支持,苹果的编译器团队一直在优化他们。但是在开发过程当中,我们往往没有把编译器的作用发挥到极致,主要原因就是我们并不是太明白编译器是如何为我们工作的。
这是一个我们应该好好利用的特性,使用很简单,如下图开启:
whole module optimization
有了whole module optimization这一特性,编译器对你的代码进行分析的时候,再也不会局限于一个文件当中了,而是整个module。有什么用呢,有了这一特性,编译器可以对你的代码了解得更多,能更好的做好编译工作。比如下面这个例子:
1.swift:
func foo() {
let x: Int = ...
let y: Int = ...
let r = min(x, y)
...
}
2.swift:
func min<T : Comparable>(x: T, y: T) -> T {
return y < x ? y : x
}
这是一个比较简单的泛型例子,目的在于比较x和y的大小,然而由于分别位于不同的源文件中,如果没有Whole Modulw Optimization的话,编译器会生成如下的代码。
func min<T : Comparable>(x: T, y: T, FTable: FunctionTable) -> T {
let xCopy = FTable.copy(x)
let yCopy = FTable.copy(y)
let m = FTable.lessThan(yCopy, xCopy) ? y : x
FTable.release(x)
FTable.release(y)
return m
}
为什么会这样呢,因为编译器没有办法得到足够的信息去推断参数的类型,x和y可能是一个Int、Float等等Value Type从而不需要考虑引用计数,但是它又或者是引用类型需要考虑引用计数呢?
所以,当有了这一特性之后,编译器的“视野”再也不受限于单个文件了,它能得到足够的信息,知道x和y是一个Int,那么最终优化出来的代码便会是下面这个样子:
func min<Int>(x: Int, y: Int) -> Int {
return y < x ? y : x
}
除了在泛型当中进行类型推断,还有Dynamic Dispatch我们也可以给编译器足够的信息,让它为我们生成最优的代码, 比如下面的例子:
父类Pet:
public class Pet {
func noise() ...
var name: String
func noiseImpl() ...
}
子类Dog:
class Dog {
...
override func noise() ...
}
然后有下面一个function:
func makeNoise(p: Pet) {
print("My name is \(p.name)")
p.noise()
}
编译器会生成这样的代码:
func makeNoise(p: Pet) {
let nameGetter = Pet.nameGetter(p)
print("My name is \(nameGetter(p))")
let noiseMethod = Pet.noiseMethod(p)
noiseMethod(p)
}
原因在于编译器并不知道父类中的属性等有没有被子类重载,所以需要去动态的查找它的getter。如果我们在开发的之后已经知道子类不需要去修改name,那么编译器会生成下面这样的代码:
...
print("My name is \(p.name)")
...
你所需要做的就是给name前面加上一个final关键字。 对于不会被子类重载的function,你也应该加上private,这样子编译器也不会去进行一些无谓的检查工作,这都将加让你的代码运行得更加迅速。
同时,为什么说Swift会比OC快,从这儿我想大家也能明白了吧。在OC当中,每个函数调用,最终都会变成objc_msgSend
的形式,依靠runtime进行消息派发。这里会存在两个主要的问题,一个是数据的类型只能在运行的时候才能真正的确定下来,这样带来了安全隐患;同时,由于动态派发,速度也将会大打折扣,所以还在使用OC的朋友,是不是可以考虑下使用Swift了呢?