RUM 赋能 iOS App 稳定：从异常体系到监控方案的全方位解析！
作者：高玉龙（元泊）
背景介绍
App 上线后，作为开发同学，最怕出现的情况就是应用崩溃了。但是，线下测试好好的 App，为什么上线后就发生崩溃了呢？这些崩溃日志信息是怎么采集的？
先看看几个常见的编写代码时的疏忽，是如何让应用崩溃的。
- 数组越界：在取数据索引时越界，App 会发生崩溃。
- 多线程问题：在子线程中进行 UI 更新可能会发生崩溃。多个线程进行数据的读取操作，因为处理时机不一致，比如有一个线程在置空数据的同时另一个线程在读取这个数据，可能会出现崩溃情况。
- 主线程无响应：如果主线程超过系统规定的时间无响应，就会被 Watchdog 杀掉。
- 野指针：指针指向一个已删除的对象访问内存区域时，会出现野指针崩溃。
为了解决这个问题，阿里云可观测研发团队进行了一些 iOS 异常监控方向的探索。
iOS 异常体系介绍
iOS 异常体系采用分层架构，从底层硬件到上层应用，异常在不同层次被捕获和处理。理解异常体系的分层结构，有助于我们更好地设计和实现异常监控方案。iOS 异常体系主要分为以下几个层次：
1. 硬件层异常
- CPU 异常：由硬件直接产生的异常，如非法指令、内存访问错误等
- 这是最底层的异常来源，所有其他异常最终都源于此
2. 系统层异常
- Mach 异常： macOS/iOS 系统最底层的异常机制，源于 Mach 微内核架构
- Unix 信号： Mach 异常会被转换为 Unix 信号，如 SIGSEGV、SIGABRT 等
- 系统层异常是应用层异常监控的主要捕获点
3. 运行时层异常
- NSException： Objective-C 运行时异常，如数组越界、空指针等
- C++ 异常： C++ 代码抛出的异常，通过
std::terminate()处理 - 运行时层异常通常由编程错误引起
4. 应用层异常
- 业务逻辑异常：应用自定义的异常和错误
- 性能异常：主线程死锁、内存泄漏等
- 僵尸对象访问：访问已释放对象导致的异常
异常体系的分层关系如下图所示：
异常捕获的层次关系：
- 硬件异常 → Mach 异常： CPU 异常被 Mach 内核捕获，转换为 Mach 异常消息
- Mach 异常 → Unix 信号： Mach 异常处理机制会将异常转换为对应的 Unix 信号
- 运行时异常： NSException 和 C++ 异常在运行时层被捕获，如果未处理会触发系统层异常
- 应用层异常： 业务异常和性能问题需要应用层主动监控和检测
异常监控策略：
- 系统层监控： 通过 Mach 异常和 Unix 信号捕获，可以捕获所有底层异常
- 运行时层监控： 通过设置异常处理器（NSUncaughtExceptionHandler、terminate handler）捕获运行时异常
- 应用层监控： 通过主动检测机制（死锁检测、僵尸对象检测）发现潜在问题
理解这个分层体系，有助于我们：
- 选择合适的异常捕获机制
- 理解不同异常类型的来源和处理方式
- 设计完整的异常监控方案
主流异常监控方案
在 iOS 端侧异常监控领域，PLCrashReporter 与 KSCrash 是最常用的两个内核库。两者都是开源、生产可用，且被多家平台化产品或 SDK 采用作为底层能力。
基于以上对比分析，KSCrash 相比其他崩溃监控框架的核心优势在于：
- 异常类型监测支持更全面（唯一同时支持 C++ 异常、死锁检测、僵尸对象检测的开源框架）
- 异步安全设计（崩溃处理完全异步安全，双重异常处理线程确保可靠性）
- 技术优势明显（堆栈游标抽象、内存内省、模块化架构等）
基于以上优势，我们选择基于 KSCrash 作为崩溃异常监控的核心方案。
异常监控方案实现
架构设计
异常采集模块，是我们 SDK 数据采集层一个模块的具体实现，如下：
- 监控器管理层：统一管理所有监控器，提供统一的异常处理入口
- 异常捕获层：多种监控器，分别捕获不同类型的异常和状态信息
- 异常处理层：构建崩溃上下文，收集堆栈、符号、内存等信息
- 报告生成层：将崩溃上下文转换为 JSON 格式报告
接下来，我们介绍各种类型异常的捕获原理，以及对应监控器是如何实现的。
系统层异常捕获
系统层异常包括 Mach 异常和 Unix 信号，是应用层异常监控的主要捕获点。我们需要同时捕获这两种异常，确保不遗漏任何底层异常。
Mach 异常捕获
Mach 异常是 macOS/iOS 系统最底层的异常机制，源于 Mach 微内核架构。Mach 是 macOS/iOS 内核的基础，提供了进程间通信（IPC）和异常处理的核心机制。硬件异常（CPU 异常）会被 Mach 内核捕获并转换为 Mach 异常消息。Mach 异常与特定线程关联，可以精确捕获异常发生的线程。Mach 异常通过 Mach 消息异步传递异常信息，需要使用 Mach 端口（Mach Port）作为异常处理的通信通道。
监控 Mach 异常，涉及以下几个核心的步骤：
1. 创建异常端口
// 创建新的异常处理端口
mach_port_allocate(mach_task_self(), MACH_PORT_RIGHT_RECEIVE, &g_exceptionPort);
// 申请端口权限
mach_port_insert_right(mach_task_self(), g_exceptionPort, g_exceptionPort, MACH_MSG_TYPE_MAKE_SEND);
为了与三方 SDK 兼容，在创建新的异常处理端口之前，需要对旧的异常处理端口进行保存，并在异常处理完毕后恢复旧的异常端口。
2. 注册异常处理器
把异常处理端口设置为刚才创建的：
// 设置异常端口，捕获所有异常类型
task_set_exception_ports(
mach_task_self(),
EXC_MASK_ALL,
g_exceptionPort,
EXCEPTION_DEFAULT,
MACHINE_THREAD_STATE
);
3. 创建异常处理线程
为了防止异常处理线程本身崩溃，需要创建两个独立的异常处理线程：
-
主处理线程：正常处理异常
-
备用处理线程：主处理线程崩溃时的后备份方案
// 主异常处理线程 pthread_create(&g_primaryPThread, &attr, handleExceptions, kThreadPrimary); // 备用异常处理线程（防止主线程崩溃） pthread_create(&g_secondaryPThread, &attr, handleExceptions, kThreadSecondary);
主备线程之间的关系如下：
- 备用处理线程在创建后会立即挂起
- 主线程在处理异常之前会通过
thread_resume()函数恢复备用处理线程 - 备用处理线程恢复后，会进入
mach_msg()等待 - 如果主线程在处理异常时发生崩溃，备用处理线程可以继续处理崩溃信息（由于异常端口已恢复，此时备用线程可能也收不到消息）
4. 处理异常消息
异常处理线程通过 mach_msg() 接收异常消息：
mach_msg_return_t kr = mach_msg(
&exceptionMessage.header,
MACH_RCV_MSG | MACH_RCV_LARGE,
0,
sizeof(exceptionMessage),
g_exceptionPort,
MACH_MSG_TIMEOUT_NONE,
MACH_PORT_NULL
);
- 挂起所有线程：确保状态一致性
- 标记已捕获异常：进入异步安全模式
- 激活备用处理线程
- 读取异常线程的机器状态
- 初始化堆栈游标
- 构建异常上下文
- 异常类型
- 机器状态
- 地址信息等
- 堆栈游标
- 统一异常处理：不同异常类型统一处理
- 恢复线程
Unix 信号捕获
作为 Mach 异常捕获的补充，也需要直接捕获 Unix 信号，确保在 Mach 异常处理失败时，仍能捕获到崩溃。Unix 信号的捕获处理涉及：
为了能够通过 Unix 信号捕获到异常，需要先安装信号处理器：
// 获取信号列表
const int* fatal_signals = signal_fatal_signals();
// 配置信号动作
struct sigaction action = {{0}};
action.sa_flags = SA_SIGINFO | SA_ONSTACK;
action.sa_sigaction = &signal_handle_signals;
// 安装信号处理器
sigaction(fatal_signal, &action, &previous_signal_handler);
Unix 信号的产生主要有以下情况：
- 来自 Mach 异常： 如果 Mach 异常未被应用层处理，系统会将其转换为对应的 Unix 信号
- 直接产生： 如调用
abort()直接产生SIGABRT，或 NSException/C++ 异常未捕获时产生的信号
当信号产生后，系统会找到我们安装的信号处理器，并调用我们注册的信号处理函数：
void signal_handle_signals(int sig_num, siginfo_t *signal_info, void* user_context)
{
// sig_num: 信号编码，如 SIGSEGV=11
// signal_info: 信号详细信息
// - si_signo: 信号编码
// - si_code: 信号代码，如 SEGV_MAPERR
// - si_addr: 异常地址
// user_context: CPU 寄存器状态
}
后续对异常的处理，同 Mach 异常处理流程。
注意： 并非所有异常都源于 Mach 异常。例如，NSException 未捕获时通常会调用 abort() 产生 SIGABRT 信号，这个过程不经过 Mach 异常。因此，异常监控需要同时捕获 Mach 异常、Unix 信号和运行时异常处理器。
机器上下文堆栈
在崩溃发生时，堆栈追踪可以帮助开发者定位问题发生的代码位置。在基于 Mach 或 Unix 信号捕获的场景，需要从 CPU 寄存器和堆栈内存中恢复完整的调用栈。核心原理：每个函数调用，都会在堆栈上创建一个堆栈帧，包含：
- 返回地址：函数返回后继续执行的地址
- 帧指针（FP）：指向当前堆栈帧的指针
- 局部变量：函数的局部变量
- 参数：传递给函数的参数
以 ARM64 架构为例，堆栈布局如下：
为了还原崩溃发生时的调用栈，我们需要对堆栈帧进行遍历。堆栈帧遍历的核心原理是通过帧指针链向上遍历：
- 第 1 帧：从 PC 寄存器获取当前崩溃点
- 第 2 帧：从 LR 寄存器获取调用者
- 第 3 帧及以后：通过帧指针链从堆栈内存中读取
堆栈帧遍历的完整流程如下：
在堆栈遍历过程中，有下面几个关键点需要注意：
- 在遍历堆栈时，必须安全地访问内存，防止访问无效内存导致崩溃
- 堆栈溢出检测，防止在堆栈损坏时无限遍历
- 地址规范化，不同 CPU 架构的地址可能有特殊标记，需要规范化处理
运行时异常捕获
运行时异常包括 NSException 和 C++ 异常，通常由编程错误引起。我们需要通过设置异常处理器来捕获这些未处理的异常。
NSException 异常捕获
iOS 需要通过设置 NSUncaughtExceptionHandler 来捕获未捕获的 NSException。
// 在设置exception handler之前，先保存之前的设置
NSUncaughtExceptionHandler *previous_uncaught_exceptionhandler = NSGetUncaughtExceptionHandler();
// 设置我们的exception handler
NSSetUncaughtExceptionHandler(&handle_uncaught_exception);
当 Objective-C 代码抛出异常，且未被 @catch 块捕获时，Objective-C 运行时会调用我们设置的异常处理器。在处理完 NSException 异常后，还需要主动调用 previous_uncaught_exceptionhandler，以便其他异常处理器能够正确处理异常。
注意：在异常监控场景中，通常需要在 handler 中收集完崩溃信息后，主动调用 abort() 来终止程序，确保程序不会在异常状态下继续运行。
在捕获到 NSException 异常之后，一般通过以下方式获取 Objective-C 的调用栈信息。
// NSException 提供了 callStackReturnAddresses
NSArray* addresses = [exception callStackReturnAddresses];
通过 [NSException callStackReturnAddresses] 获取到 return address 之后，还需要进一步处理，如：过滤掉无效地址等。
C++ 异常捕获
通过设置 C++ terminate handler 可以捕获未处理的 C 异常。当 C 异常未被捕获时，C++ 运行时会调用 std::terminate()，我们通过拦截这个调用来捕获异常。
// 保存原始 terminate handler
std::terminate_handler original_terminate_handler = std::get_terminate();
// 设置我们的 terminate handler
std::set_terminate(cpp_exception_terminate_handler);
当 C 代码抛出异常时，throw 语句会调用 __cxa_throw()，C 运行时会查找匹配的 catch 块，如果未找到异常会继续向上传播。当异常未被捕获时：
- C++ 运行时会调用
std::terminate() std::terminate()会调用已注册的 terminate handler- 我们设置的
cpp_exception_terminate_handler会被调用
在我们的 terminate handler 中处理完异常后，还需要调用原始的 terminate handler，以便其他异常处理器能正确处理异常。
应用层异常捕获
应用层异常包括业务逻辑异常和性能问题，需要应用层主动监控和检测。主要包括主线程死锁检测和僵尸对象检测。
主线程死锁检测
主线程死锁（Deadlock）是 iOS 开发中一种严重的运行时问题，会导致 App 界面完全卡死（无响应），最终通常会被系统的看门狗（Watchdog）强制终止。
针对这类问题，一种可行的方式是通过"看门狗"机制检测主线程死锁：
- 监控线程：独立的监控线程，定期检查主线程状态
- 心跳机制：向主线程发送"心跳"任务，检查是否及时响应
- 死锁判定：如果主队列在指定时间内未响应，则判定为死锁
需要注意：
- 误报风险：如果主线程有长时间运行的任务，可能产生误报
- 超时时间：需要根据应用实际情况，调整超时时间，避免误报
僵尸对象检测
iOS 僵尸对象（Zombie Object）是 iOS 开发中导致应用崩溃（Crash）最常见的内存问题之一。僵尸对象是指已经被释放（dealloc）的内存块，但对应的指针仍然指向这块内存，并且代码试图通过这个指针去访问它（发送消息）。访问僵尸对象可能会导致崩溃，通常表现为 EXC_BAD_ACCESS 崩溃。
- 这是一个内存访问错误，意味着你试图访问一块你无法访问或无效的内存。
- 因为这块内存可能已经被系统回收并分配给了其他对象，或者变成了一块杂乱的数据区域，所以访问结果是不可预知的。
产生僵尸对象的原因主要有以下几点：
- unsafe_unretained 或 assign 指针： 如果一个属性被修饰为 assign（修饰对象时）或 unsafe_unretained，当对象被释放后，指针不会自动置为 nil（变成悬垂指针）。此时再次访问就会变成僵尸对象访问
- 多线程竞争： 线程 A 刚刚释放了对象，但线程 B 几乎同时在尝试访问该对象
- CoreFoundation 与 ARC 的桥接不当： 在使用
__bridge，__bridge_transfer等转换时，所有权管理混乱导致对象过早释放 - Block 或 Delegate 循环引用：某些老旧代码中 Delegate 依然使用 assign 修饰
僵尸对象检测的主要思路是：
- hook
NSObject和NSProxy的dealloc方法 - 在对象释放时，计算对象的 hash，然后记录 class 信息
- 检测是否为 NSException，如果是，则保存异常详情
- 各类异常发生时，读取保存的异常详情
- 为了降低 CPU 和内存占用，僵尸对象的记录上限是
0x8000个，即：32768 - 计算哈希时，通过
((uintptr_t)object >> (sizeof(uintptr_t) - 1)) & 0x7FFF计算
这是一种设计权衡的结果。因为这种检测方式并不是非常准确，不能捕获所有僵尸对象。因为 hash 的计算会产生一定的碰撞，导致对象被覆盖，可能会产生误报或错误的类型。
运行时符号化
在异常监控系统中，除了需要检测和记录异常类型（如僵尸对象访问、主线程死锁等），还需要处理异常发生时的堆栈信息。堆栈信息通常以内存地址的形式存在，这些地址对于开发者来说是不可读的。为了能够快速定位问题，我们需要将这些内存地址转换为可读的函数名、文件名和行号信息，这个过程就是符号化（Symbolication）。
符号化一般分为两种：
- 运行时符号化：使用
dladdr()获取符号信息（函数名、镜像名等） - 完整符号化：使用
dSYM文件获取文件名和行号
运行时符号化只能获取公开符号。
我们主要讨论 iOS 平台上如何在运行时符号化。iOS 平台主要通过 dladdr() 进行运行时符号化，通过 dladdr() 可以获取到如下信息：
- imageAddress：image 镜像基址
- imageName：image 镜像路径
- symbolAddress：符号地址
- symbolName：符号名称
由于在符号化时，我们需要的是调用指令的地址，但堆栈上存储的是返回地址，因此需要对地址调整：
函数调用过程：
1. 调用指令：call function_name (地址: 0x1000)
2. 函数执行：function_name() (地址: 0x2000)
3. 返回地址：0x1001 (存储在堆栈上)
堆栈上存储的是返回地址（0x1001），
但我们需要的是调用指令的地址（0x1000），所以需要减 1。
不同 CPU 架构对应的地址调整有所不同，以 ARM64 为例：
uintptr_t address = (return_address &~ 3UL) - 1;
运行时符号化的完整流程如下图所示：
异步安全
除了以上内容外，在处理 iOS 平台异常捕获时，我们还需要关注异步安全。
在 Unix 信号处理函数，或 Mach 异常处理中，只能使用异步安全函数，主要是因为：
- 崩溃时系统状态不稳定
- 可能持有锁，调用非异步安全函数可能导致死锁
- 堆可能已损坏，此时分配内存可能会失败
一般情况下，malloc()、free()、NSLog()、printf()，Objective-C 方法的调用，任何可能分配内存的函数都不允许在处理异常过程中调用。
结语和展望
本文主要介绍了当下主流的 iOS 异常监控方案，和基于 KSCrash 的异常监控实现细节，包括 Mach、Unix 信号、NSException 等异常类型的捕获的处理等。异常监控能力还在持续进化，后续还有不少可以优化和提升的点，如支持实时上传和崩溃回调，支持 App 日志记录，dump 寄存器地址附近内存等。目前这套方案已经应用在阿里云用户体验监控 RUM iOS SDK 中，您可以参考接入文档 [ 1] 体验使用。阿里云 RUM SDK 当前也支持 Android 、 HarmonyOS 、Web 等平台下异常监控能力。相关问题可以加入"RUM用户体验监控支持群"（钉钉群号：67370002064）进行咨询。
相关链接：
[1] 接入文档
https://help.aliyun.com/zh/arms/user-experience-monitoring/monitor-ios-apps/
点击此处查看产品详情。
