前言：本文旨在介绍iOS性能优化中有关崩溃的介绍和采集。
一、APP常见的崩溃
- 野指针，即EXC_BAD_ACCESS
- 非法参数异常，比如参数传为nil
- 数组越界
- 除0，即被除数为0
- 方法未找到，即unrecognized selector
- 旧设备老系统的崩溃
- OOM（低内存崩溃）
- 崩溃到main函数
二、iOS中的崩溃类型
1、EXC_BAD_ACCESS
野指针引起的崩溃，访问了一个已经释放的内存而导致，向已经释放的对象或向它发送消息时，EXC_BAD_ACCESS就会出现。造成EXC_BAD_ACCESS最常见的原因是，在初始化方法中初始化变量时用错了所有权修饰符，这会导致对象过早地被释放。
2、SIGSEGV
段错误信息（SIGSEGV）是操作系统产生的一个更严重的问题。
3、SIGBUS
总线错误信号（SIGBUG）代表无效内存访问，即访问的内存是一个无效的内存地址。也就是说，那个地址指向的位置根本不是物理内存地址（它可能是某个硬件芯片的地址）。
4、SIGTRAP
SIGTRAP代表陷阱信号。它并不是一个真正的崩溃信号。它会在处理器执行trap指令发送。LLDB调试器通常会处理此信号，并在指定的断点处停止运行。如果你收到了原因不明的SIGTRAP，先清除上次的输出，然后重新进行构建通常能解决这个问题。
5、EXC_ARITHETIC
当要除零时，应用会收到EXC_ARITHMETIC信号。这个错误应该很容易解决。
6、SIGILL
SIGILL代表signal illegal instruction(非法指令信号)。当在处理器上执行非法指令时，它就会发生。执行非法指令是指，将函数指针会给另外一个函数时，该函数指针由于某种原因是坏的，指向了一段已经释放的内存或是一个数据段。
7、SIGABRT
SIGABRT代表SIGNAL ABORT（中止信号）。当操作系统发现不安全的情况时，它能够对这种情况进行更多的控制；必要的话，它能要求进程进行清理工作。
8、超时
这种崩溃通常比较容易分辨，因为错误码是固定的0x8badf00d。在iOS上，它经常出现在执行一个同步网络调用而阻塞主线程的情况。因此，永远不要进行同步网络调用。
9、一些被系统杀掉的情况，我们可以通过异常编码来分析：
0x8badf00d，表示app在一段时间内无响应而被watchdog杀掉的情况
0xdeadfa11，表示app被用户强制推出。
0xc00010ff，表示app因为运行造成设备温度太高而被杀掉。
三、崩溃信息：
我们采集到的崩溃信息，主要包含的信息为：进程信息、基本信息、异常、线程回溯。
- 进程信息：崩溃进程的相关信息，比如崩溃报告唯一标识符、唯一键值、设备标识。
- 基本信息：崩溃发生的日期、iOS版本。
- 异常信息：异常类型、异常编码、异常的线程。
- 线程回溯：崩溃时的方法调用栈。
四、崩溃信息采集原理
1、捕获异常
iOS中引发崩溃的代码本质上就两类，一个是c++语言层面的错误，属于比较底层的错误，比如野指针，除零，内存访问异常等等，这一类的错误可以通过信号机制来捕获（signal或者是sigaction），即任何系统错误都会抛出一个错误信号，我们可以通过设定一个回调函数，然后在回调函数里面进行自己的处理；另一类是未捕获异常（Uncaught Exception），iOS下面最常见的就是objective-c的NSException，比如，数组访问元素越界。这些异常如果没有在最上层try住，那么程序就崩溃了。
针对NSException的捕获，通过调用NSSetUncaughtExceptionHandler来捕获，系统错误通过注册signal来捕获，一般产生一个NSException的异常的时候，同时也会抛出一个signal的信号。
2、获取堆栈信息
但捕获到程序的异常后，我们需要解析app崩溃时的环境，即崩溃堆栈。
NSException的异常比较简单，直接获取崩溃name，reason和callstack；signal的堆栈的处理就比较麻烦些；另外，还就是需要分析APP的当前线程信息以及所有的线程信息或者更加深一步的寄存器信息。不过这个时候拿到的堆栈是地址的形式，还需要第三步的符号表还原功能才能定位到代码行号。
五、怎么排查崩到main函数的崩溃
-
设置异常崩溃-Xcode-Exception BreakPoint
-
设置-隐私-数据和分析-分析数据，就可以导出崩溃日志
-
Xcode自带Zombie检测的开关，选择edit scheme - Run- Diagnostics - 勾选 Zombie Objects
-
Xcode-Window-Organizer-选择你的APP-Crashes
Xcode自带的bug分析工具--Crashes Origanizer，它可以报告在app上架期间的崩溃情况。
左侧列出了App Store收集的崩溃列表，右侧有详细的崩溃原因。最有用的一个功能莫过于点击"Open in Project"按钮，它能直接将错误定位到当前项目的崩溃点上。
六、深入了解iOS中的OOM（低内存崩溃）
在iOS开发过程或者用户反馈中，可能会经常看到这样的情况，用着用着就崩溃了，而在后台查看崩溃栈的时候，找不到崩溃日志。其实这大多数的可能是系统产生了低内存崩溃，也就是OOM(还有一种可能是主线程卡死，导致watchdog杀掉了应用)，而低内存崩溃的日志，往往都是以JetsamEvent开头的（下图中展示），日志中有内存页大小(pageSize)，CPU时间(cpuTime)等字段。
1、什么是OOM？
什么是OOM呢，它是out-of-memory的缩写，字面意思就是内存超过了限制。它是由于 iOS 的 Jetsam机制造成的一种“另类” Crash，它不同于常规的Crash，通过Signal捕获等Crash监控方案无法捕获到OOM事件。
当然还会有FOOM这样的词，代表的是Foreground-out-of-memory，是指App在前台因消耗内存过多引起系统强杀。这也就是本文要讨论的。后台出现OOM不一定都是app本身造成的，大多数是因为当前在前台的App占用内存过大，系统为了保证前台应用正常运行，把后台应用清理掉了。
2、什么是Jetsam机制?
Jetsam机制可以理解为操作系统为了控制内存资源过度使用而采用的一种管理机制。Jetsam是一个独立运行的进程，每一个进程都有一个内存阈值，一旦超过这个阈值Jetsam就会立刻杀掉这个进程。
3、为什么要设计Jetsam机制?
首先设备的内存是有限制的，并不是无限大的，所以内存资源非常重要。系统进程及用户使用的其他app的进程都会争抢这个资源。由于iOS不支持交换空间，一旦触发低内存事件，Jetsam就会尽可能多的释放应用占用的内存，这样在iOS系统上出现系统内存不足时，应用就会被系统终止。
从设置-隐私-数据和分析-分析数据中导出的数据可以看出：以JetsamEvent开头的则为OOM的信息
4、检测OOM工具：
- 腾讯 OOMDetector
- 微信 matrix
网友评论