App崩溃监控

常见马虎导致崩溃

1 数组越界；
2 多线程问题，在子线程刷新UI；
3 主线程无响应，主线程超过系统规定的时间没有响应，就会被watchdog杀掉；
4 野指针；

崩溃信息的收集却并没有那么简单。因为，有些崩溃日志是可以通过信号捕获到的，而很多崩溃日志却是通过信号捕获不到的。
第三方崩溃监控工具：

PLCrashReporter
Fabric或者Bugly

这些都是通过信号捕获崩溃日志，还有写通过信号捕捉不到的场景：
1 backgroud Task模式，App退到后台，如果在后台执行时间太长，就会被系统杀死。（一般为3分钟）；

解决方法：在进入后台时设置一个定时器，在接近3分钟是看程序是否还在运行，如果还在运行，可以判断该程序即将在后台崩溃，进行上报记录，达到监控效果。

2 内存打爆

解决方法：采用内存映射（mmap）的方式来保存现场

3 主线程卡顿时间超过阈值被 watchdog 杀掉

解决方法：收集当前线程的堆栈信息

采集到崩溃信息后如何分析并解决崩溃问题呢

采集到的崩溃日志，主要包含的信息为：进程信息、基本信息、异常信息、线程回溯

• 进程信息：崩溃进程的相关信息，比如崩溃报告唯一标识符、唯一键值、设备标识；
• 基本信息：崩溃发生的日期、iOS 版本；
• 异常信息：异常类型、异常编码、异常的线程；
• 线程回溯：崩溃时的方法调用栈。

通常情况下，我们分析崩溃日志时先看异常信息，分析问题是哪个线程，在线程回溯中找到对应的线程；然后分析方法调用栈，符号话的方法调用栈可以完整的看到方法调用过程，从而知道问题出在哪个方法调用上。

一些被系统杀掉的情况，我们可以通过异常编码来分析。可以在维基百科上看完整的异常编码。常见的有如下三种：

• 0x8badf00d，表示 App 在一定时间内无响应而被watchdog 杀掉的情况
• 0xdeadfa11，表示 App 被用户强制退出
• 0xc00010ff，表示 App 因为运行造成设备温度太高而被杀掉

0xdeadfa11,这种用户的行为不用关注，0xc00010ff 这种情况，就要对每个线程CPU 进行针对性的检查和优化