Swift中的分发机制

2019-03-05 本文已影响0人小宇pod

介绍

方法分发是指程序确定哪个操作应该被执行的机制。有时候，我们只希望在运行时才确定一个方法决定执行什么行为。这就产生了多种不同的分发方法的机制，而他们也各有各的有缺点。

静态分发

也叫做直接分发。
如果一个方法是静态分发的，在编译过程中，编译器是能标记到方法所在的位置。所以，静态分发时，当方法被调用是，系统可以直接跳到方法所对应的内存地址然后执行相应操作。这样的结果就是：静态分发的执行速度会非常快，并且也允许编译器执行各种优化，例如内联。事实上，由于巨大的性能提升，如果允许的话，在预编译的时候编译器会使方法静态化。这种优化就是去虚拟化。

动态分发

使用这种方式，程序知道运行时才知道执行哪种操作。
虽然静态分发是非常轻量级的，但是它限制了程序的灵活性，尤其是涉及到多态的时候。这也就是动态分发广泛应用于面对对象的语言的原因。
每个语言都有自己的机制来支持动态分发。Swift提供了两种方式来实现动态：表分发和消息分发。

表分发

这是一种在编译语言里最普遍使用的方式。通过表分发，类与一个所谓的虚表相关联，其中虚表包含一个保存函数指针的数组，而这些函数指针指向执行与这个类相关的实际实现。
注意：虚表是在编译时就已经构建的，相比于静态分发，只多了两个指令--读取和跳转。所以，这也是一种理论上来说很快的分发方式。

消息分发

OC就提供了这种机制，当然有时也被叫做消息发送。Swift只有在使用OC的Runtime库的时候才能使用这种机制。每次当OC的方法被调用的时候，这个请求就会被发送给objc_msgSend去处理查找。这个过程开始于给定的类，然后逐层寻找这个具体的实现。
与表分发不同的是，消息分发的字典在运行时是可以改变的，使我们能够在运行时调整程序的具体执行。方法交换就是利用这一特性最常见的使用之一。
消息分发是在这三种分发方式中最具动态性的一种。作为交换的是，尽管查询性能的表现属于内存机制，但是在具体实现过程中对于性能还是比上两种要稍差。
这一机制是Cocoa的基础。通过看Swift的源码，你就会知道其中的KVO就是使用isa-swizzling实现的。

Swift

区别分发机制的方法

对于分发策略的合理解释，在SIL document有一段简短的描述：
（1）如果一个函数使用表分发，他将会出现在vtable(或者witness_table协议)中。

sil_vtable Animal {
    #Animal.makeSound!1: (Animal) -> () -> () : main.Animal.makeSound() -> ()   // Animal.makeSound()
  ......
}

（2）如果一个函数通过消息分发，关键词volatile就会出现在调用中。而且，你将会发现两个标记foreign和objc_method，说明这个函数是在OC运行时调用的。

%14 = class_method [volatile] %13 : $Dog, #Dog.beWild!1.foreign : (Dog) -> () -> (), $@convention(objc_method) (Dog) -> () // user: %15

（3）如果没有以上两个关键词，那么就是静态调用。

一般情况

首先，结构体或者值类型的函数一定是静态调用的。因为他们永远不会被重写。
显示执行：
- 函数是final关键词修饰的是静态调用。
- dynamic关键字修饰的函数是通过消息发送被调用的。在Swift4中，dynamic修饰的函数对OC是隐性可见的。同时，Swift4要求你显示的用@objc修饰。
- 一般的延展（没有final,dynamic,@objc关键字修饰的）是静态分发的。回想一下你曾经历过的编译错误，在延展里的声明同样是不能重写的。你也许会问，那什么样的延展是动态的。如果延展是动态的，那么他就可以被重写。

extension Animal {
    func eat() { }
    @objc dynamic func getWild() { }
}
class Dog: Animal {
    override func eat() { } // Compiled error!
    @objc dynamic override func getWild() { }   // Ok :)
}

其他情况

protocol Noisy {
    func makeNoise() -> Int // TABLE
}
extension Noisy {
    func makeNoise() -> Int { return 0 }    // TABLE
    func isAnnoying() -> Bool { return true }   // STATIC
}
class Animal: Noisy {
    func makeNoise() -> Int { return 1 }    // TABLE
    func isAnnoying() -> Bool { return false } // TABLE
    @objc func sleep() { }  // Still TABLE
}
extension Animal {
    func eat() { }  // STATIC
    @objc func getWild() { }    // MESSAGE
}

Noisy.isAnnoying()，和Animal.getWild()是静态分发，因为他们在延展中。
Noisy.makeNoise()使用表分发尽管他有默认的实现。
考虑下面两个用法。animal2.isAnnoying()选择用协议延展实现，因为它是一个直接方法，不需要查找。以这种方式可能是bug的源头。

let animal1 = Animal()
print(animal1.isAnnoying()) // Value: false
let animal2: Noisy = Animal()
print(animal2.isAnnoying()) // Value: true

另一方面，animal1.makeNoise()和animal2.makeNoise()产生同样的结果，因为协议的实现是通过表查询来查找的。
在@objc func sleep()中的@objc意味着，函数对于OC是可见的。对于系统来说，选择OC的方法执行并不是一定的。从SIL中，我们可以知道，Swift的方法的选择优先级要高于OC的。

%9 = class_method %8 : $Animal, #Animal.sleep!1 : (Animal) -> () -> (), $@convention(method) (@guaranteed Animal) -> () // user: %10

结论

现在，我们已经知道了方法分发是什么和在Swift中选择的分发方式是什么样的。这里提供了一些例子来更方便理解Swift如何解析特定功能。并且，通过阅读SIL，我们也能得到对于分发一个方法应该遵循的假设的证据。

静态分发是在性能上最具优势的。这也就是为什么Swift是Swift。
虽然消息分发是在性能上稍差，但是它提供了更灵活的使用方式。
理解方法分发机制是非常重要的。不仅帮助我们写出更高效的代码同时也会避免一些奇怪的bug。
当然，情况也许会在后续的Swift版本中不同，别忘记验证这篇文章的真实性。