苹果工程师不想让你知道的性能优化黑科技
这里每天分享一个 iOS 的新知识，快来关注我吧
前言
前两天在优化项目性能的时候，突然想起一个很有意思的问题：为什么有些方法调用快得飞起，有些却慢得要命？这个问题其实跟 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 可以让编译器进行更多优化：
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 的设计哲学就是在性能和灵活性之间找到最佳平衡点。
下次写代码的时候，不妨想想你的方法调用走的是哪种分发机制。说不定你会发现一些有趣的优化机会呢！
你在开发中遇到过因为方法分发引起的性能问题吗？欢迎在评论区分享你的经验！
这里每天分享一个 iOS 的新知识，快来关注我吧
