自从Swift诞生以后，苹果就一直在努力让它变得更好，更快。相比更加灵活的Objective-C，Swift显得更加老实本分。但是，如果你真的对它了解之后，你会觉得原来有如此之大的威力。
开发语言离不开编译器的支持，苹果的编译器团队一直在优化他们。但是在开发过程当中，我们往往没有把编译器的作用发挥到极致，主要原因就是我们并不是太明白编译器是如何为我们工作的。
Whole Module Optimizations
这是一个我们应该好好利用的特性，使用很简单，如下图开启：
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了呢？
网友评论