APP崩溃以及为什么会出现崩溃

一、APP崩溃的几种情况：

1. APP启动闪退
2. 切换到后台再次打开时APP重新启动
3. 无响应
4. 打开某一个界面时突然退出

二、为什么会出现崩溃：

1. 操作系统异常和中断

• 崩溃是CPU对发生异常的一种显式反应，CPU的异常处理是基于中断来完成的。中断是CPU暂停正在执行的程序，保留现场后转去执行相应的处理程序，处理完该事件后再返回断点继续执行被“打断”的程序。
• 在操作系统相关资料中介绍：中断(interrupt)和异常(exception)在不同的CPU架构里有不同的含义。
  比如在Intel架构中，中断处理的入口由操作系统内核中的中断分配表定义(interrupt dispatch table, IDT)，IDT中有255个中断向量，其中前20个定义为异常(exception)的处理入口，即中断包含异常。
  而在ARM架构中，中断处理的入口则是在异常向量(exception vector)中，8个异常向量里边有3个是中断相关的，即异常包含中断。
  不管如何界定中断和异常，CPU发生异常时，都会将控制权从异常前的程序交给异常处理程序，而且CPU将获得 不会更低 的执行权利，比如执行用户态的应用程序发生异常，CPU将切换到内核态，并执行对应的异常处理程序。经典的CPU五级流水线中一条指令的生命周期为[取指、译码、执行、访存、写回]，每个阶段都可能出现CPU异常，比如在ARM架构下：
  在“执行”阶段产生的“数据中止”异常：若处理器 数据访问指令 的地址不存在，或该地址不允许当前指令访问时，产生数据中止异常。
  在“取指”阶段产生的”预取中止“异常：若处理器 预取指令 的地址不存在，或该地址不允许当前指令访问，存储器会向处理器发出中止信号，但当预取的指令被执行时，才会产生指令预取中止异常。
  两种异常对应的处理程序会直接或者间接调用 Mach 内核的 exception_triage() 函数，并将 EXC_BAD_ACCESS 作为入参传进去，exception_triage() 将会利用Mach消息传递机制投递异常。

三、崩溃有哪些典型场景

1. watchdog，
   ①如果App在执行某个任务(启动、终止或响应系统事件)时花费时间较长，操作系统会终止当前进程。看门狗机制触发的崩溃最明显的标识就是错误码：0x8badf00d
   ②当App的启动时间超过最大允许值(一般为20s),在ios系统中就会触发看门狗机制立即终止进程。值得注意的是：由看门狗触发的崩溃并不会收集在自己开发的错误监控里，可以在崩溃设备中获取崩溃日志。苹果在使用模拟器时关闭了看门狗机制，并且在Debug模式下也不会触发看门狗机制。所以在开发中我们对App启动流程务必做到简洁、按需加载
2. 野指针
   ①野指针即指针指向一个不确定的内存地址，通过野指针访问这个内存地址时可能会发生各种不确定的情况。如果这块内存地址未被覆盖并不一定会出现问题，如果已经被覆盖或者分配成不可访问空间则程序直接崩溃。如果判断是野指针造成的崩溃，那么当前的崩溃代码很大可能并不是导致崩溃的原因，需要通过分析调用关系找到真正的崩溃原因
3. 多线程操作
4. 死锁
   ①主线程死锁：一般情况下我们想执行一个同步任务经常会使用dispatch_sync方法，如果因为某些复杂业务逻辑场景导致任务运行在主线程，则会导致应用crash。
5. 方法调用异常