在 iOS 开发的江湖里Objective-C 一直是个特立独行的存在。它不像 C++ 那样在编译期就把一切敲定，也不像 Java 那样完全依赖虚拟机。OC 的灵魂，在于那个kan不见、摸不着，却无处不在的系统——Runtime。hen多开发者初入行时只把它当作底层的 API，但当你真正深入进去，会发现这其实是一套精妙绝伦的动态机制。今天我们就来扒开 Runtime 的外衣，kankan它到底是如何让代码“活”起来的。

一、 动态性的基石：消息发送机制

我们要聊的第一个核心概念，就是“消息”。在 OC 里当你写下 这行代码时编译器并不会像 C 语言那样直接跳转到函数地址。相反，它会把它转化为一条 C 语言的函数调用：

objc_msgSend, arg1, arg2, ...);

这不仅仅是一个语法糖，这是 OC 动态特性的入口。Runtime 就像一个尽职尽责的调度中心，当它收到这条指令时一场紧张的查找之旅就开始了。

1.1 查找链路：从缓存到继承树

当 objc_msgSend 被触发后Runtime 并不会漫无目的地乱找。它有一套极其高效的流程，我们Ke以把它想象成一场接力赛：

空值检查它会kan一眼 receiver 是不是 nil。在 OC 里向 nil 发送消息是安全的，直接返回，不会像 C 那样直接 Crash。

ISA 指针寻址Ru果对象存在Runtime 就通过对象的 isa 指针找到它所属的类对象。

缓存速查现代程序里方法调用往往非常频繁。为了速度，类对象里有一个 cache_t。Runtime 先去这里找，Ru果运气好找到了对应的 IMP，直接执行，耗时极低。

方法列表遍历Ru果缓存没命中，那就得去翻“账本”了。Runtime 会去 class_rw_t 的方法列表里找。这里通常采用二分查找或者线性遍历。

父类链查找Ru果当前类没找到，别急，还有 superclass。Runtime 会沿着继承链一层层往上找，每层dou先查缓存，再查列表。直到找到根类为止。

Ru果这一圈跑下来还是找不到，那就说明这个对象真的“无Neng为力”了。这时候，Runtime 并不会立刻让程序崩溃，它还有Zui后的大招——消息转发。

二、 挽救崩溃的三次机会：消息转发

Runtime 的设计非常人性化，它给了对象三次“补救”的机会。这就像你在工作中遇到了解决不了的问题，你Ke以尝试自学、找同事帮忙，或者Zui后把问题打包上报。我们来kankan这三次机会是如何运作的。

2.1 第一次机会：动态方法解析

这是第一道防线。Runtime 会先问对象：“虽然你现在没这个方法，但你要不要现在动态加一个？”

这对应的方法是 resolveInstanceMethod: 或 resolveClassMethod:。在这里我们Ke以利用 class_addMethod 函数，把某个函数指针强行塞进类的方法列表里。

+ resolveInstanceMethod:sel {
    if ) {
        // 动态添加实现，"v@:" 是类型编码
        class_addMethoddynamicIMP, "v@:");
        return YES; // 告诉系统，我Yi经搞定了
    }
    return ;
}

2.2 第二次机会：快速转发

Ru果第一阶段你返回了 NO，或者没Zuo处理，Runtime 会进入第二阶段。这时候它会问：“你自己不行，那你有没有备用的对象Neng处理这个消息？”

这就是 forwardingTargetForSelector: 的用武之地。这个机制非常轻量级，适合把消息转给备选对象。

- forwardingTargetForSelector:aSelector {
    if ) {
        // 直接把活儿甩给 backupObject
        return self.backupObject;
    }
    return ;
}

2.3 第三次机会：完整消息转发

Ru果连备用对象dou没有，Runtime 就会启动Zui复杂的“完整消息转发”机制。这时候，系统会生成一个 NSInvocation 对象，里面封装了消息的所有细节。

你需要实现两个方法：methodSignatureForSelector:和 forwardInvocation:。

// 1. 先返回方法签名，告诉系统这个方法长什么样
- methodSignatureForSelector:aSelector {
    if ) {
        return ;
    }
    return ;
}
// 2. 处理具体的转发逻辑
- forwardInvocation:anInvocation {
    if  {
        // 转发给备用对象
        ;
    } else {
        // 实在没办法了Zuo个日志记录，防止 Crash
        NSLog);
    }
}

这里有个高频面试题：消息转发和继承有什么区别？ 简单说继承是编译期就定死的静态关系，而转发是运行时的动态决策。转发Ke以把消息发给任何你想要的对象，甚至是你临时创建的对象，灵活性极高，但调试起来也geng头疼。

三、 底层架构：类与对象的内存布局

理解了消息怎么跑，我们再来kankan路是怎么铺的。Runtime 之所以Neng动态查找，全靠底层精巧的数据结构设计。

3.1 ISA 指针的进化

在 OC 的世界里万物皆对象。一个对象的结构体里Zui重要的就是 isa 指针。

struct objc_object {
    isa_t isa; // 指向类对象
};

在早期的 32 位系统上，isa 就是个普通的指针。但在现在的 64 位架构下为了节省内存和提高性Neng，Apple 采用了非指针 isa。这意味着 isa 不再仅仅是一个地址，它利用了 64 位里空闲的位，存储了引用计数、是否被 weak 引用、是否有关联对象等额外信息。这就像把一个人的身份证号，顺便当成了会员卡积分卡来用，一举多得。

3.2 类与元类

OC 里的类本身也是一个对象，因为它继承自 objc_object。这就引出了一个经典的概念：元类。

实例对象的 isa 指向 类对象。

类对象的 isa 指向 元类。

元类的 isa 指向 根元类，根元类的 isa 指向它自己，形成了一个闭环。

这种设计保证了 这种类方法调用，也Neng通过 objc_msgSend 的机制查找到对应的 IMP。

3.3 class_rw_t 与 class_ro_t

这是 Runtime 内存管理中Zui精妙的一对搭档。类对象里的 bits 字段，通过位运算指向了这两个结构体。

class_ro_t 这是在编译期就确定的。它包含了类的基本信息：实例大小、成员变量、属性列表，以及编译期确定的基础方法列表。这些数据是从 Mach-O 文件的 __DATA,__objc_data 段直接加载进内存的，一旦加载就不Neng修改。

class_rw_t 这是在运行期创建的。当类第一次被“ realize ”时Runtime 会分配 class_rw_t。它 引用 class_ro_t 的内容，然后预留了空间来存放 Category添加的方法，以及运行时动态修改的方法。

为什么要这么麻烦？因为 App 启动时内存是宝贵的。hen多类根本不需要动态修改。从 iOS 15 开始，Apple 甚至引入了 class_rw_ext_t 的延迟分配优化——Ru果一个类既没有 Category，也没被运行时修改过它甚至不需要分配完整的可写数组，Neng节省大量内存。

四、 实战应用：Method Swizzling

聊了这么多理论，终于到了大家Zui爱的“黑魔法”环节。Method Swizzling 允许我们在运行时把两个方法的实现进行交换。这在 APM、无侵入埋点等场景下简直是神器。

但是Swizzling 也是一把双刃剑，用不好hen容易把自己砍伤。下面我们来kan一个安全的 Swizzle 实现方案。

4.1 常见的坑

hen多人写 Swizzle 时直接调用 method_exchangeImplementations。这有几个隐患：

方法不存在Ru果 SEL 写错了或者类里根本没这个方法，直接交换会导致 Crash。

重复交换Ru果 +load 在多个 Category 里被调用，或者被手动调用多次方法会被换回来导致逻辑失效。

4.2 安全封装方案

我们需要一个健壮的工具方法，不仅要交换，还要处理各种边界情况。

+ swizzleInstanceMethod:original withMethod:swizzled error:error {
    Class cls = ;
    Method origMethod = class_getInstanceMethod;
    Method newMethod = class_getInstanceMethod;
    // 防护1：检查方法是否存在
    if  {
        if  {
            *error = ;
        }
        return NO;
    }
    // 防护2：处理父类继承的情况
    // Ru果 original 方法只在父类里class_addMethod 会成功把 newMethod 的 IMP 加到本类
    BOOL didAdd = class_addMethod(cls, original,
                                  method_getImplementation,
                                  method_getTypeEncoding);
    if  {
        // 既然加进去了那就把 swizzled 的实现换成父类的 original 实现
        class_replaceMethod(cls, swizzled,
                            method_getImplementation,
                            method_getTypeEncoding);
    } else {
        // Ru果本类就有 original，直接交换
        method_exchangeImplementations;
    }
    return YES;
}

这段代码的逻辑非常严密：它利用 class_addMethod 的特性，区分了“本类实现”和“父类继承”两种情况，确保无论方法在哪里定义，交换行为dou是符合预期的。

五、 边界：关联对象与动态属性

我们知道，Category是不Neng直接添加成员变量的。但 Runtime 提供了“关联对象”这个机制，让我们Neng绕过这个限制。

其原理是：Runtime 维护了一个全局的哈希表，以对象地址为 Key，存储了一个或多个关联值。当我们给对象添加关联属性时其实是在这个全局表里存了一份数据。

// 在分类中实现 setter
- setCustomProperty:value {
    // OBJC_ASSOCIATION_RETAIN_NONATOMIC 是内存管理策略
    objc_setAssociatedObject, value, OBJC_ASSOCIATION_RETAIN_NONATOMIC);
}
// 在分类中实现 getter
- customProperty {
    return objc_getAssociatedObject);
}

这个技巧常用于给系统类添加业务数据，避免了繁琐的子类化。

Objective-C Runtime 绝不仅仅是一堆枯燥的 C 函数。它构建了一个灵活、动态、甚至带有一点“叛逆”的运行时世界。从消息发送的精妙流程，到消息转发的三次补救机会，再到类结构的内存优化，每一个细节dou体现了系统设计的哲学。

掌握 Runtime，意味着你不再被语言的语法所束缚，而是拥有了在底层操控程序行为的Neng力。当然Neng力越大责任越大。在享受 Swizzling 和动态方法带来的便利时一定要注意代码的安全性和可维护性。毕竟没人希望在生产环境里去调试一个“幽灵”般的方法调用。

---