iOS_Swift函数派发机制_代码007(未授权)

Static dispatch 静态派发，即直接地址调用。这个函数指针在编译、链接完成后就确定了，存放在代码段。
优点：派发速度最快，因为需要调用的指令集少，且编译器还有很大的优化空间（如：函数内敛 inline）。
缺点：局限也是最大的，因为缺乏动态性，所以没法支持继承。

Table dispatch 函数表派发，是编译型语言实现动态行为最常见的实现方式。函数表使用一个数组来存储类声明的每个函数的指针。大部分语言把这个称之为 Virtual Table 虚函数表，Swi ft 里称为 Witness Table 。
每个类维护一个虚函数表，记录着类的所有函数。如果被 override 的话，表里只会保存 override 后的函数。子类新增函数会被插到这个数组的最后，没有位置可以让 extension 安全的插入函数。
优点：可扩展
缺点：速度慢，编译器对某些含有副作用的函数无法优化

基于 Objc RunTi me 实现，沿着实例的 i s a 指针进行查找，找不到最后还有3次拯救机会。详细可见：iOS_Objective-C 消息发送（消息查找及消息转发）过程
优点：最动态的方式，可以实现 KVO、UIAp pe arance 和 Co reData 等功能。可在运行时改变函数行为。不只可以通过 sw izzling 来改变，甚至可以用 i sa-sw izzling 修改对象继承关系，可以在面向对象基础上实现自定义派发
确定：速度最慢

Struct 和 Enum 为值类型，不支持继承，它不需要一个 Table 来记录方法信息。所以它的方法调用（包括协议方法），都是静态派发的。

extension 中的方法和属性无法继承和重写，只属于当前类，所以是静态派发的。

以上都是在没有编译器优化的情况下的派发方式，在有优化的情况下，编译器会尽可能地将方法变成静态派发，有的方法甚至会就地展开，变成 inline 的形式，以便提升性能。

@objc/@nonobjc 只是修改对 objc 的可见性，并不会更改其派发方式。默认依旧是 Table dispatch。
@objc：是将是 swift 中继承自 NSObject 类的函数暴露给 OC。原理：生成两个函数引用，一个给 swift 调用，一个给 objc 调用。
@nonobjc：隐藏对 objc 的可见性，依然使用 Table dispatch。

dynamic 强制使用消息派发，可以动态修改。
修饰属性实现 KVO，否则 setter 会走直接派发，无法触发 KVO。