如何获取iOS应用崩溃的错误信息或堆栈轨迹 含Crashlytics等方案

一、Crashlytics原生实现方案 #

Crashlytics官方提供了本地未上报崩溃数据的读取接口，可直接复用现有集成能力：

• 应用冷启动完成后，先调用Crashlytics.crashlytics().didCrashDuringPreviousExecution()判断上一次运行是否发生崩溃
• 确认有崩溃后，调用Crashlytics.crashlytics().downloadAndProcessExistingUnsentReports(completion:)接口，在回调中获取FIRCrashlyticsReport实例，实例内可直接读取崩溃时间、错误类型、全线程堆栈轨迹、设备系统信息、应用版本等所有需要的字段
• 将读取到的崩溃数据和用户反馈内容拼接后，调用自有业务服务的上报接口即可
• 上报完成后调用Crashlytics.crashlytics().deleteUnsentReports()清理本地缓存的崩溃数据，避免重复读取上报

二、第三方开源工具方案 #

如果不想依赖Firebase服务，可使用独立的崩溃采集开源库：

• 首选PLCrashReporter，该库是绝大多数商业化崩溃采集工具的底层依赖，经过海量生产环境验证，稳定性有保障
• 该库支持捕获所有类型的iOS应用崩溃，可生成标准格式的崩溃报告，也可直接解析为可读的文本堆栈信息
• 你可以完全控制崩溃数据的存储、读取、上报全流程，不需要将数据上传到任何第三方平台

三、iOS原生自研方案 #

如果不想引入任何第三方依赖，可自己实现基础的崩溃捕获逻辑：

• 分别注册NSUncaughtExceptionHandler捕获上层业务抛出的异常崩溃，注册对应signal回调捕获内存访问错误、野指针等底层信号类型崩溃
• 崩溃触发时，通过NSThread.callStackSymbols获取当前线程的堆栈信息，同时采集设备型号、系统版本、应用版本等上下文信息，写入本地存储
• 下一次应用启动时读取本地存储的崩溃数据，随同用户反馈上报即可

注意：原生自研方案的采集能力有限，默认无法获取子线程堆栈、动态库偏移地址等深度信息，后续堆栈符号化需要自行处理，仅适合对崩溃采集要求较低的场景
额外提醒：所有崩溃采集逻辑的回调中不要执行耗时操作或可能触发新崩溃的逻辑，崩溃数据的上报操作统一放在下一次应用启动后执行，避免崩溃采集逻辑本身导致应用稳定性下降

内容的提问来源于stack exchange，提问作者RUBEN OMAR CAMPOS VAZQUEZ