Swift 函数派发机制

原文: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的基石,同时也催生了KVOUIAppearanceCoreData等技术。这种派发机制的关键在于,开发者可以在运行时修改函数的调用。例如 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中的函数,使用直接派发
  • NSObjectextension中的函数使用消息机制派发

引用类型(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包,里面包括了NSObjectObjective-CRuntimedynamic可以用在所有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的话,而这个属性的gettersetter会被优化为直接派发,代码依旧可以通过编译,不过动态生成的 KVO函数就不会被触发。

派发总结