在移动开发的江湖里没有什么比凌晨三点被报警

一、 消息转发机制：Unrecognized Selector 的Zui后一道防线

Objective-C 的动态特性是我们手中的双刃剑。用得好，代码行云流水；用不好，`-: unrecognized selector sent to instance` 这种报错Neng让你怀疑人生。当 `objc_msgSend` 找不到 IMP时系统并不会立刻判死刑，而是给了我们三次机会。

1.1 动态方法决议

这是第一次机会。Runtime 会问类：`+resolveInstanceMethod:` 或 `+resolveClassMethod:`。这时候，我们Ke以通过 `class_addMethod` 动态地给类添加一个方法实现。这就像是给对象临时塞了一本说明书，告诉它：“虽然你没学过这个技Neng，但现在赶紧现学现卖一下。”

1.2 快速转发

Ru果动态决议返回了 `NO`，Runtime 会进入快速转发阶段，调用 `-forwardingTargetForSelector:`。这里的设计非常巧妙，它允许我们将消息转发给另一个对象。这就好比你自己搞不定这件事，但你认识一个Neng搞定的朋友，于是你把活儿甩给了他。在这个阶段进行拦截，性Neng开销是Zui小的。

1.3 完整转发与常规 Crash 防护

Ru果快速转发也行不通，那就只Neng动用大招——完整转发。系统会调用 `-methodSignatureForSelector:` 和 `-forwardInvocation:`。这时候，我们Ke以构造一个 `NSInvocation` 对象，把消息的所有细节dou打包好，随便扔给谁处理dou行。

但是Ru果我们没Zuo任何处理，Zui终就会走到 `-doesNotRecognizeSelector:`，抛出 `NSException`，然后 App 闪退。为了防止这种悲剧，我们通常会在第二步就进行 Hook 拦截。

- safe_forwardingTargetForSelector:selector {
    // 先判断一下自己Neng不Neng处理，或者有没有现成的签名
    // 避免误伤了一些正在使用消息转发机制的黑魔法框架
    BOOL aBool = ;
    NSMethodSignature *signature = ;
    if  {
        return ;
    } else {
        // 到了这一步，基本就是没救了准备后事吧
        // 记录异常信息，告诉后台出事了
        reportBug;
        // 关键点：返回一个“桩对象”
        // 这个对象动态添加了 selector 的空实现，拦截消息，防止 Crash
        SafeGuardStub *stub =  init];
        ;
        return stub;
    }
}

这里有个细节需要注意：桩对象必须通过 `class_addMethod` 动态添加方法，否则它自己也会因为无法识别 selector 而陷入死循环，直到堆栈溢出。而且，这种防护方案必须考虑到兼容性，像 JSPatch 或 Aspects 这种依赖完整消息转发的框架，Ru果我们提前拦截了它们就会失效。所以判断 `methodSignatureForSelector` 是否返回非 nil 是至关重要的。

二、 容器类与多线程：kan不见的雷区

hen多时候，Crash 并不是因为逻辑错误，而是因为多线程并发访问。iOS 的容器类，比如 `NSArray` 和 `NSMutableArray`，它们不是线程安全的。当你在子线程疯狂写入数据，而在主线程读取时`EXC_BAD_ACCESS` 可Neng就在下一个路口等着你。

2.1 越界与插 nil 的防护

数组越界是Zui低级的错误，但也是Zui高发的。直接 Swizzle `NSArray` 的方法？没用的。因为 `NSArray` 只是一个对外发布的抽象接口，真正运行时的对象可Neng是 `__NSArrayI`或者 `__NSArrayM`。我们必须通过 `NSClassFromString` 获取这些私有类，然后对它们进行 Method Swizzling。

+ load {
    static dispatch_once_t onceToken;
    dispatch_once(&onceToken, ^{
        // 必须 Hook 真实的类
        Class class = NSClassFromString;
        safe_swizzleSelector, self, @selector);
    });
}
- safe_objectAtIndex:index {
    if  {
        // 别 Crash，先记下来
        reportException;
        return nil; // 返回 nil 可Neng会导致后续逻辑问题，但至少 App 不会死
    }
    return ;
}

同样的逻辑也适用于 `NSDictionary` 插入 `nil` 键值对，或者 `NSString` 的 `substringWithRange:` 越界。这种“防御性编程”虽然kan起来笨拙，但它Neng救你一命。

2.2 多线程竞态条件

除了容器，属性的原子访问也是个坑。Ru果你把一个属性声明为 `nonatomic`，那么在多线程读写时你可Neng会读到“半成品”的指针。这是因为 64 位的指针赋值在某些架构下不是原子操作，可Neng只写了一半就被另一个线程读走了。这种野指针问题极其难复现，因为它充满了随机性。

解决之道？要么加锁，要么使用 GCD 的串行队列，或者geng高级的读写锁。对于简单的数据结构，使用 `dispatch_barrier_async` 配合并发队列是个不错的选择，既Neng保证读的并发性，又Neng保证写的独占性。

三、 KVO 与野指针：那些年我们踩过的坑

KVO是 iOS 开发中观察者模式的实现，但它也是著名的“Crash 制造机”。

3.1 KVO 的重复注册与移除

Zui常见的场景就是：观察者注册了两次或者移除的时候没有注册过。这会直接导致 Crash。为了解决这个问题，我们Ke以维护一个映射表，记录所有的观察关系。

我们Ke以 Hook `addObserver:forKeyPath:options:context:` 和 `removeObserver:forKeyPath:`。在添加之前，先检查映射表里有没有；在移除的时候，Ru果映射表里没有，就直接 return，不要调用原生的移除方法。这就好比你要出门，先检查一下钥匙是不是在口袋里没带钥匙就别瞎锁门。

3.2 野指针：幽灵般的杀手

野指针是所有 C/C++/OC 开发者的噩梦。对象被释放了指针还在指向的那块内存可NengYi经被分配给了别的对象。当你 通过这个指针发消息时结果完全不可预测。有时候运气好，什么dou没发生；有时候运气不好，直接 Crash；Zui惨的是数据被悄悄篡改了导致逻辑错误。

在开发阶段，我们Ke以开启 `NSZombieEnabled`。这个开关非常强大，它让对象释放后不真正回收内存，而是变成一个“僵尸对象”。任何对僵尸对象的访问dou会立刻报错并打印日志。虽然这会导致内存泄漏，但在调试阶段，它是定位野指针的神器。

在线上环境，我们没法用 Zombie。这时候，Facebook 的 `FBAllocationTracker` 或者一些基于 `malloc_zone` 监控的方案就派上用场了。虽然hen难完全杜绝野指针，但我们Ke以通过监控大内存分配、使用 Address Sanitizer等工具来尽量减少它的发生。

四、 系统杀手：OOM 与 Watchdog

有时候，你的代码写得再好，也挡不住系统的“铁拳”。

4.1 OOM

iOS 没有内存交换机制，物理内存一旦耗尽，系统就会杀进程。这就是 Jetsam 机制。App 被 Jetsam 杀死时不会产生标准的 Crash 日志，这让我们排查起来非常困难。

怎么判断是不是 OOM？Facebook 给出了一个思路：排除法。Ru果用户上次退出不是因为 Crash、不是因为 Watchdog、也不是用户自己杀的，那大概率就是 OOM。

治理 OOM 的核心在于“节流”。图片要降采样，不要无脑缓存，收到内存警告时要果断释放非核心资源。我们Ke以监控 App 的物理内存占用，当水位线过高时主动清理缓存，甚至弹窗提示用户重启 App。

4.2 Watchdog

这个十六进制代码读起来就像 "ate bad food"。主线程Ru果在规定时间内没有完成特定的任务，系统的kan门狗线程就会直接终止进程。

这通常是因为我们在主线程Zuo了耗时的 I/O 操作或者复杂的计算。解决方法hen简单：主线程只负责 UI 刷新，所有脏活累活dou扔到子线程去。为了监控主线程的卡顿，我们Ke以使用 RunLoop Observer。监听 RunLoop 的状态切换，Ru果在 `kCFRunLoopBeforeSources` 和 `kCFRunLoopAfterWaiting` 之间停留太久，说明主线程卡住了。

五、 Crash 监控体系：从捕获到符号化

有了防护，还得有监控。我们需要知道哪里出了问题，才Neng去修复。

5.1 异常捕获的三层防线

iOS 的异常捕获主要分三层：

OC 层异常通过 `NSSetUncaughtExceptionHandler` 捕获。这是Zui上层的，比如数组越界抛出的异常。

Mach 异常这是内核态的异常，比如非法指令访问。我们需要通过 `task_set_exception_ports` 来注册端口监听。

Unix SignalRu果 Mach 异常没被处理，内核会把它转换成 Signal。我们Ke以通过 `sigaction` 来捕获。

一个完善的 Crash 捕获框架，通常会同时注册这三层 handler，确保没有漏网之鱼。

5.2 堆栈回溯与符号化

拿到 Crash 堆栈后你kan到的是一堆内存地址，这对开发者来说毫无意义。我们需要把这些地址还原成人类可读的函数名和行号，这就是符号化。

这需要用到 Xcode Archive 时生成的 dSYM 文件。dSYM 文件里保存了地址到源码位置的映射表。我们Ke以使用 `atos` 命令行工具，或者 `symbolicatecrash` 脚本来进行符号化。

# 使用 atos 符号化某个地址
atos -arch arm64 -o MyApp.app.dSYM/Contents/Resources/DWARF/MyApp -l 0x100000000 0x1000abcde

这里有个坑：dSYM 文件的 UUID 必须和线上二进制文件的 UUID 完全一致，否则符号化会失败。所以每次发版，务必把 dSYM 文件归档好，别弄丢了。

六、 ：稳定性是一场持久战

构建低 Crash 率的 App，没有银弹。它需要我们对底层原理有深刻的理解，对代码细节有极致的追求。从 Method Swizzling 的黑魔法，到多线程同步的严谨逻辑，再到内存管理的精打细算，每一个环节dou不Neng掉以轻心。

我们不仅要写代码，还要像侦探一样去分析 Crash 日志，像医生一样去诊断 App 的病症。当你的 App Crash 率降到千分之一以下当你不再害怕用户的差评，那种成就感，是对我们无数个熬夜加班的Zui好回报。希望这篇分享Neng给大家带来一些启发，让我们一起写出geng健壮、geng稳定的 iOS 应用。

---