原文：Method Dispatch in Swift
作者：Brian King

派发机制是程序判断如何去调用函数或方法的机制，每次调用方法时都会触发，但一般我们都不会注意到。了解派发机制的工作原理，对于写出高性能的代码来说非常重要，派发机制也能解释一些Swift中的奇妙现象，和Objective-C中所谓的。

编译型编程语言主要有三种派发方式：直接派发(Direct Dispatch)， 函数表派发(Table Dispatch) 和 消息机制派发(Message Dispatch)。

Java默认使用函数表派发机制，但是我们可以通过final关键字来将其转换为直接派发。C++默认使用直接派发，但可以通过virtual关键字转化为消息机制派发。Objective-C总是使用消息机制派发，但允许开发者使用C进行直接派发来提高性能。Swift已经实现了三种派发机制的全部支持，但是也给开发者带来了很多困扰。

派发方式

派发机制的目的是为了让程序告诉CPU，当调用一个具体方法的时候要去内存的哪个地方找到可执行代码。在了解Swift之前，先来了解一下三种派发方式，以及它们如何在性能和动态性之间的取舍。

直接派发（Direct Dispatch）

直接派发是速度最快的派发机制，它生成的汇编指令最少，编译器也有很大的优化空间，例如函数内联等等，但这不在本文的讨论范围内。因为在编译时就能确定方法的调用位置，直接派发也被称为静态派发（Static Dispatch）。

但是，对于编程来说直接派发也是最局限的，因为它缺乏动态性，而无法支持继承。

函数表派发（Table Dispatch）

函数表派发是编译型编程语言动态性的最常见的实现，函数表维护了一个指针数组，每个指针都指向类中声明的函数，每个声明的函数也确保有指针指向它。大部分语言把这个表称为虚函数表（Virtual Table），但在Swift里称为（Witness Table）。

每个类都维护一张属于自己的函数表，里面记录着所有函数；子类会复制一张父类的表，在重写时修改指针，指向覆盖的新函数，子类添加的新函数会被插入表的最后。每当调用函数时，根据函数表的指针来确定具体调用哪个函数。

举个栗子，有下面两个类：

class ParentClass {
    func method1() {}
    func method2() {}
}

class ChildClass: ParentClass {
    override func method2() {}
    func method3() {}
}

这时，编译器会创建两个函数表，一个是ParentClass的，一个是ChildClass的：

函数表

let obj = ChildClass()
obj.method2()

当一个method2函数被调用时，会经历以下过程：

1. 读取0xB00的函数表。
2. 读取函数指针索引，在这里method2的偏移量是1，所以得到地址0xB00 + 1。
3. 跳转到地址0x222并读取内容。

查表是一种简单、易实现而且性能可预知的方式，但是，这种派发方式比起直接派发还是慢了一点。从字节码角度来看，查表时首先要读取方法表指针，然后根据偏移量跳转到函数指针，再读取函数指针，所以查表多了两次读操作和一次跳转操作，导致了性能损耗。另外一个原因就是编译器无法进行任何优化。

查表法的缺陷在于，基于数组实现的函数表无法为extension提供扩展。子类添加的新函数会插入函数表的尾部，所以没有位置可以让extension安全地插入函数。这篇文章详细描述了这种局限性。

消息机制派发 （Message Dispatch)

消息机制是动态性最高的调用方式，也是Cocoa的基石，同时也催生了KVO，UIAppearance，CoreData等技术。这种派发机制的关键在于，开发者可以在运行时修改函数的调用。例如 Method Swizzling 可以在运行时修改函数的实现和调用，甚至可以通过 ISA Swizzling 在运行时修改对象的继承关系，由此可以在面向对象的基础上实现自定义分发。

Method Swizzling

同样举一个栗子：

class ParentClass {
    dynamic func method1() {}
    dynamic func method2() {}
}

class ChildClass: ParentClass {
    override func method2() {}
    dynamic func method3() {}
}

Swift会通过树来简历继承关系：

当一个消息被派发，Runtime会顺着继承关系向上查找应该被调用的函数，这样做的效率非常低。但是，这个查找操作会建立一个散列表用于缓存，一旦这个缓存被建立起来，消息机制派发就会像函数表派发一样快，这篇文章详细探讨了性能测试，这篇文章深入介绍了消息派发机制的技术细节。

Swift的派发机制

Swift的派发机制没有一个固定答案，但是影响派发方式的因素有四个：

• 声明的位置
• 引用类型
• 指定派发方式
• 显式优化

Swift没有在文档中写明什么时候会用什么派发机制，唯一说明的是：使用dynamic修饰的函数，会用过OC Runtime进行消息机制派发。

声明的位置（Location Matters）

Swift中，一个函数有两种声明位置可以选择：类的声明和extension，根据声明位置不同，派发方式也不同。

class MyClass {
    func mainMethod() {}
}
extension MyClass {
    func extensionMethod() {}
}

在这个例子中，mainMethod会使用函数表派发，而extensionMethod会使用直接派发。具体根据不同声明位置，不同的派发方式如下表格：

总结起来有这么几点规律：

• 值类型总是直接派发
• 协议和类的声明作用域中的函数，使用函数表派发
• 协议和类的extension中的函数，使用直接派发
• NSObject 的extension中的函数使用消息机制派发

引用类型（Reference Type Matters）

声明的引用类型决定了派发方式，一个常见的例子就是，协议拓展和对象拓展同时实现一个函数的时候：

protocol MyProtocol {
}

struct MyStruct: MyProtocol {
}

extension MyStruct {
    func extensionMethod() {
        print("In Struct")
    }
}

extension MyProtocol {
    func extensionMethod() {
        print("In Protocol")
    }
}
 
let myStruct = MyStruct()
let proto: MyProtocol = myStruct
 
myStruct.extensionMethod() // -> “In Struct”
proto.extensionMethod() // -> “In Protocol”

可以看到，在这种情况下因为proto的声明引用类型为MyProtocol，所以proto.extensionMethod()直接调用了协议拓展中的函数，Kotlin的扩展也遵循这个规律。但是如果把extensionMethod的声明移动到协议声明中，则会使用函数表派发，最终调用结构体里的实现。

由此我们得出结论，如果两种声明方式都使用了直接派发，那么我们不能完成预想的函数覆盖。

指定派发方式（Specifying Dispatch Behavior）

Swift有一些修饰符可以指定派发方式：

final

final允许类里面的函数使用直接派发， 这个修饰符会让函数失去动态性。任何函数都可以使用这个修饰符，就算是extension里本来就是直接派发的函数， 这也会让Objective-C Runtime获取不到这个函数, 不会生成相应的selector。

dynamic

dynamic可以让类里面所有的函数使用消息机制派发，使用时必须导入Foundation包，里面包括了NSObject和Objective-C的Runtime。dynamic可以用在所有NSObject的子类和所有Swift原生类，也可以让extension中的函数能够被继承。

@objc & @nonobjc

@objc和@nonobjc显式地声明了一个函数能否被Objective-C Runtime捕捉到。使用@objc的典型例子就是给selector一个命名空间，让这个函数可以在运行时被调用。@nonobjc表示不让这个函数注册到Runtime中，由此禁止消息机制来派发这个函数，和final非常相似。

final @objc

可以同时使用final和@objc来修饰函数，这样做的结果就是，调用函数时会直接派发，但可以将函数注册到Objective-C Runtime中，来让函数可以响应perform(selector:)或者其他特性。

@inline

可以通过@inline来使用直接派发，但是同时使用dynamic @inline修饰时，会使用消息机制派发。

修饰符总结

显式优化

Swift会尽可能优化函数派发方式，例如，一个函数从来没有继承或被继承过，Swift就会检测到并且在可能的情况下使用直接派发，在大多数情况下这样的优化效果非常好，但是对于Cocoa开发者就不太友好了：

override func viewDidLoad() {
    super.viewDidLoad()
    navigationItem.rightBarButtonItem = UIBarButtonItem(
        title: "Sign In", style: .plain, target: nil,
        action: #selector(ViewController.signInAction)
    )
}
private func signInAction() {}

这时编译器会报错：

Argument of '#selector' refers to a method that is not exposed to Objective-C
（Objective-C无法获取 #selector指定的函数）

这里Swift将signInAction优化为直接派发，所以没有注册到Runtime中，#selector 自然无法获取。

另一个需要注意的是， 如果你没有使用dynamic修饰的话，这个优化会默认让KVO失效。如果一个属性绑定了KVO的话，而这个属性的getter和setter会被优化为直接派发，代码依旧可以通过编译，不过动态生成的 KVO函数就不会被触发。

派发总结