前言
前两天在优化项目性能的时候，突然想起一个很有意思的问题：为什么有些方法调用快得飞起，有些却慢得要命？这个问题其实跟 Swift 的方法分发机制有关，今天来讲讲这个看似复杂，实则很有趣的话题。说实话，刚开始听到"方法分发"这个词，我还以为是什么高深莫测的概念。但其实这玩意儿每天都在我们的代码里默默工作着，影响着 App 的性能表现。如果你也经常被性能问题困扰，或者单纯想了解 Swift 底层是怎么运行的，那这篇文章绝对值得一看！

方法分发到底是啥？
简单来说，方法分发就是程序决定调用哪个方法实现的过程。听起来很抽象对吧？我来举个生活中的例子。假设你要叫外卖（最近外卖大战，就举这个例子吧），你对着手机说"我要点餐"。这时候手机需要决定：你是要用美团、饿了么，还是其他 App？这个"决定过程"就类似于方法分发。在 Swift 中，当你写下 animal.makeSound() 的时候，系统需要决定调用的是狗的叫声、猫的叫声，还是其他动物的叫声。这个决定可能在编译时就确定了（静态分发），也可能要等到运行时才知道（动态分发）。

Swift 的三种分发机制
Swift 主要有三种方法分发机制，按性能从快到慢排序：
静态分发（Static Dispatch） - 最快
动态分发（Dynamic Dispatch） - 中等

消息分发（Message Dispatch） - 最慢

1. 静态分发：编译时就定好了
静态分发是最简单也是最快的方式。编译器在编译时就能确定要调用哪个方法，所以运行时直接跳转到对应的内存地址即可。什么时候会用静态分发呢？

// 1. 结构体的方法（没有继承，所以确定）
struct Dog {
    func bark() {
        print("汪汪汪")
    }
}

// 2. final 类或方法（不能被重写）
finalclass Cat {
    func meow() {
        print("喵喵喵")
    }
}

class Animal {
    finalfunc breathe() {
        print("呼吸中...")
    }
}

// 3. private 方法（外部看不到，不能重写）
class Bird {
    privatefunc fly() {
        print("飞行中...")
    }
}

// 4. 协议扩展中的方法（默认实现）
protocol Walkable {
    func walk()
}

extension Walkable {
    func walk() {  // 这个是静态分发
        print("走路中...")
    }
}

我之前就踩过一个坑。写了个协议，然后在扩展里提供了默认实现，以为子类重写后就能生效。结果发现通过协议类型调用时，永远走的是扩展里的实现。后来才知道，协议扩展中的方法用的是静态分发！

2. 动态分发：运行时查表决定
动态分发是 Swift 的默认方式，主要用于支持多态。它通过虚表（V-Table）来实现，每个类都有一个虚表，记录着方法的实际实现地址。

class Vehicle {
    func startEngine() {
        print("Vehicle engine started")
    }
}

class Car: Vehicle {
    overridefunc startEngine() {
        print("Car engine started")
    }
}

class Truck: Vehicle {
    overridefunc startEngine() {
        print("Truck engine started")
    }
}

let vehicles: [Vehicle] = [Car(), Truck()]
for vehicle in vehicles {
    // 这里用的是动态分发
    // 运行时查询每个对象的虚表，决定调用哪个实现
    vehicle.startEngine()
}

虽然动态分发比静态分发慢一些，但也只是多了两个步骤：读取虚表 + 跳转。对于现代处理器来说，这点开销其实可以忽略不计。

3. 消息分发：最灵活也最慢
消息分发来自 Objective-C，提供了最强的运行时动态性。它需要 @objc dynamic 修饰符：

class LegacySystem: NSObject {
    @objc dynamic func processData() {
        print("Processing data in legacy system")
    }
}

// 可以在运行时修改方法实现（Method Swizzling）
// 这在静态分发和动态分发中都是不可能的

消息分发的查找过程比较复杂：先从当前类开始查找，找不到就往父类找，一直找到 NSObject 为止。好在有缓存机制，所以实际性能影响没有想象中那么大。

实际开发中的性能考虑
说实话，在日常开发中，你很少需要为了那点性能差异而专门优化方法分发。但了解这些机制能帮你写出更好的代码：
1. 合理使用 final
如果你确定某个类或方法不需要被重写，加上 final 可以让编译器进行更多优化：

// 堆代码 duidaima.com
final class NetworkManager {
    final func request() {
        // 这个方法用静态分发，性能最优
    }
}

2. 避免不必要的 @objc dynamic
除非你真的需要运行时动态性（比如 Method Swizzling），否则别随便加 @objc dynamic。

3. 协议设计要小心

protocol Drawable {
    func draw()// 这是协议要求，用动态分发
}

extension Drawable {
    func draw() {  // 这是默认实现，用静态分发
        print("Drawing...")
    }
    
    func erase() {  // 这也是静态分发
        print("Erasing...")
    }
}

struct Circle: Drawable {
    func draw() {  // 重写协议要求
        print("Drawing circle")
    }
    
    func erase() {  // 这个重写是"无效"的！
        print("Erasing circle")
    }
}
let shape: Drawable = Circle()
shape.draw()   // 输出 "Drawing circle"（动态分发）
shape.erase()  // 输出 "Erasing..."（静态分发，走的是扩展实现）

这个例子告诉我们：协议中声明的方法用动态分发，扩展中的方法用静态分发。

编译器的黑魔法：优化
最有意思的是，Swift 编译器非常聪明，会尽可能地把动态分发优化成静态分发。这个过程叫做"去虚化"（Devirtualization）。
比如这段代码：

class Animal {
    func makeSound() {
        print("Some animal sound")
    }
}
let dog = Animal()  // 编译器知道这肯定是 Animal 类型
dog.makeSound()     // 可能被优化成静态分发

即使 makeSound 理论上应该用动态分发，但编译器知道 dog 肯定是 Animal 类型，所以可能直接优化成静态调用。开启 Whole Module Optimization 后，这种优化会更加激进。

实战建议
根据我的开发经验，给大家几个建议：
别过度优化：除非你的 App 真的有性能瓶颈，否则可读性比那点微小的性能差异更重要。
优先考虑 final：如果类或方法确实不需要被重写，加 final 是个好习惯。
小心协议扩展：记住扩展中的方法是静态分发的，别指望重写能生效。
用 Instruments 验证：真要优化性能，用工具测量，别凭感觉。
理解业务需求：有些场景确实需要运行时动态性，别为了性能放弃灵活性。

写在最后
方法分发这个话题看似复杂，其实理解了原理后会发现挺有意思的。它就像是程序运行时的"导航系统"，指引着代码找到正确的目的地。我觉得最重要的不是记住每种分发机制的细节，而是要理解什么时候该用什么，以及为什么要这样设计。Swift 的设计哲学就是在性能和灵活性之间找到最佳平衡点。下次写代码的时候，不妨想想你的方法调用走的是哪种分发机制。说不定你会发现一些有趣的优化机会呢！

你在开发中遇到过因为方法分发引起的性能问题吗？欢迎在评论区分享你的经验！