原文链接：iOS 崩溃千奇百怪，如何全面监控？
一、编码常见崩溃
1 数组越界
2 多线程问题
3 程序无响应
4 野指针
二、捕获崩溃问题
1 可捕获的崩溃信号
KVO、Notification线程问题、数组越界、野指针
收集这些崩溃日志的常用方法：
1 Xcode -> Archive
2 PLCrashReporter 获取崩溃日志，上传到自己的服务器查看
3 Fabric
4 Bugly
捕获原理：
程序发生崩溃时，我们经常会看到这段代码：
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
它表示，EXC_BAD_ACCESS这个异常会通过SIGSEGV信号发现问题。
可以通过 signalHandler 来捕获不同种类的信号，代码如下：
void registerSignalHandler(void) {
signal(SIGSEGV, handleSignalException);
signal(SIGFPE, handleSignalException);
signal(SIGBUS, handleSignalException);
signal(SIGPIPE, handleSignalException);
signal(SIGHUP, handleSignalException);
signal(SIGINT, handleSignalException);
signal(SIGQUIT, handleSignalException);
signal(SIGABRT, handleSignalException);
signal(SIGILL, handleSignalException);
}
void handleSignalException(int signal) {
NSMutableString *crashString = [[NSMutableString alloc]init];
void* callstack[128];
int i, frames = backtrace(callstack, 128);
char** traceChar = backtrace_symbols(callstack, frames);
for (i = 0; i <frames; ++i) {
[crashString appendFormat:@"%s\n", traceChar[i]];
}
NSLog(crashString);
}
上面这段代码对各种信号都进行了注册，捕获到异常信号后，在处理方法 handleSignalException 里通过 backtrace_symbols 方法就能获取到当前的堆栈信息。
在程序崩溃前，将错误的堆栈信息保存在本地磁盘中，下次启动时再上传到服务器。
2 不可捕获的崩溃信号
后台任务超时、内存打爆、主线程卡顿超阈值
App 退到后台中，即使代码逻辑没有问题也很容易出现崩溃，这些崩溃往往是因为系统强制杀掉了某些进程导致的，导致强杀的信号还由于系统限制无法被捕获到。
后台容易崩溃的原因是什么？
iOS后台保活的方式有5种：Background Mode、Background Fetch、Silent Push、PushKit、Background Task。
每种方式都有不同的使用场景，这里就不一一介绍了，感兴趣的朋友可以自己去了解一下。
这5种方式中，Background Task最为常用，App退到后台后，默认都会使用这种方式。
通过UIApplication的beginBackgroundTaskWithExpirationHandler:保持程序在后台运行
我们必须知道的是，App进入后台后，你的任务最终执行的时间是有限的。（这个时间具体是多少没有被考证，戴老师原文中说是3分钟，上面提供的截图中说的是10分钟，截图来自《iOS高级编程》）
总之，在有限的时间内没有执行完任务，系统也会强制杀掉进程。而后台处理的任务分门别类，所以很容易出现崩溃。尤其是要控制后台读写操作。
如何监控内存打爆、主线程卡顿超阈值？
内存打爆和主线程卡顿超过阈值被 watchdog 杀掉这两种情况也会造成程序崩溃。
监控他们的思路和监控后台崩溃类似，我们要先找到它们的阈值，然后在临近阈值时还在执行的后台程序判断为将要崩溃，收集信息并上报。（关于内存和卡顿阈值怎么获取和RunLoop有关，后面会介绍）
三、分析和解决崩溃问题
对于捕获的系统的崩溃日志，主要包含的信息为：进程信息、基本信息、异常信息、线程回溯。
- 进程信息：崩溃进程的相关信息，比如崩溃报告唯一标识符、唯一键值、设备标识
- 基本信息：崩溃发生的日期、iOS版本
- 异常信息：异常类型、异常编码、异常的线程
- 线程回溯：崩溃时的方法调用栈
方法1: 查看方法调用栈
先通过异常信息分析出发生异常的线程，然后分析方法调用栈，符号化后的方法调用栈可以完整的看到方法调用的过程，从而知道问题发生在哪个方法的调用上。
栈顶的方法就是最后导致崩溃的方法调用。
方法2: 分析异常编码
一些被系统杀掉的情况，我们可以通过异常编码来分析。
这里举例3种常见的异常编码：
- 0x8badf00d，表示 App 在一定时间内无响应二倍 watchdog 杀掉
- 0xdeadfa11，表示 App 被用户强制退出
- 0xc00010ff，表示 App 因为运行造成设备温度太高而被杀掉
方法3: 分析第三方平台采集的崩溃信息
之前我们提到的向 Bugly 平台，在监控到崩溃信息后，它们会提供可视化的信息来辅助我们追溯问题。
最后
解决线上崩溃问题是一个非常复杂且繁琐的工作，由于我个人在这方面也没有很丰富的经验，所以此篇文章仅做学习和了解。
虽说现在可以使用的第三方监控平台很多，但是有些错误发生后难以定位和复现。解决崩溃问题涉及的知识也远不止这些，除了上文的内容，可能还涉及 RunLoop 的相关知识、App对设备性能及电量的影响、App 的全量日志信息等知识。
太多内容导致我无法去一一实践和测试，做技术就是要不断的学习，希望自己能坚持。
