如何去衡量一款应用的质量好坏？为了回答这一问题，APM这一目的性极强的工具向开发顺应而生。最早的APM开发只关注于crash、cpu这类的硬性指标。而随着移动开发市场的成熟，越来越多的数据指标也被加入到了APM的采集范畴中，包括感官体验相关的数据和使用习惯等。

然而，无论APM最终如何发展，其最核心的采集指标一定是crash数据。一套完善的crash监控方案可以快速的发现并协助完成问题定位，从而能够及时止损，避免更多的损失。而反过来说，如果crash不能及时被发现，又或者因为采集链中出现异常导致了数据丢失，对于开发者和公司来说，这都会是一个噩梦。

crash采集

细分之下，crash分别存在mach exception、signal以及NSException三种类型，每一种类型表示不同分层上的crash，也拥有各自的捕获方式。

• mach exception

  mach异常由处理器陷阱引发，在异常发生后会被异常处理程序转换成Mach消息，接着依次投递到thread、task和host端口。如果没有一个端口处理这个异常并返回KERN_SUCCESS，那么应用将被终止。每个端口拥有一个异常端口数组，系统暴露了后缀为_set_exception_ports的多个API让我们注册对应的异常处理到端口中。

  mach异常即便注册了对应的处理，也不会导致影响原有的投递流程。此外，即便不去注册mach异常的处理，最终经过一系列的处理，mach异常会被转换成对应的UNIX信号，一种mach异常对应了一个或者多个信号类型。因此在捕获crash要提防二次采集的可能。

• NSException

  NSException发生在CoreFoundation以及更高抽象层，在CoreFoundation层操作发生异常时，会通过__cxa_throw函数抛出异常。在通过NSSetUncaughtExceptionHandler注册NSException的捕获函数之后，崩溃发生时会调用这个捕获函数。但如果没有任何函数去捕获这个异常 如果在捕获函数中没有进行操作终止应用，最终异常会通过abort()来抛出一个SIGABRT信号。

  由于NSException的抽象层次足够高，相比较其他的crash类型，NSException是可以被人为的阻止crash的。比如@try-catch机制能够捕获块中发生的异常，避免应用被杀死。但由于try-catch的开销和回报不成正比，往往不会使用这种机制。其二是crash防护，这一手段通过hook掉上层接口来规避crash风险，但是只建议用于线上防护，而且hook未必不会导致其他的问题。

• signal

  signa会导致crash，这是多数iOS开发者对于信号的印象。传递crash信息其实只是信号的一部分功能，信号是一套基于POSIX标准开发的通信机制，具体可以阅读。在signal.h中声明了32种异常信号，下面列出一部分的信号异常对：

  信号	异常
  SIGILL	执行了非法指令，一般是可执行文件出现了错误
  SIGTRAP	断点指令或者其他trap指令产生
  SIGABRT	调用abort产生
  SIGBUS	非法地址。比如错误的内存类型访问、内存地址对齐等
  SIGSEGV	非法地址。访问未分配内存、写入没有写权限的内存等
  SIGFPE	致命的算术运算。比如数值溢出、NaN数值等

  虽然存在三种crash，但由于mach exception会在BSD层被转换成UNIX信号，NSException在未被捕获的情况下会调用abort抛出信号，因此即便是我们只注册了signal的处理，只要注册的signal足够多，理论上也是能捕获到全部的crash。

采集冲突

由于crash的捕获机制只会保存最后一个注册的handle，因此如果项目中残留或者存在另外的第三方框架采集crash信息时，经常性的会存在冲突。解决冲突的做法是在注册自己的handle之前保存已注册的处理函数，便于发生崩溃后能将crash信息连续的传递下去。

struct sigaction my_action;static struct sigaction registered_action;static NSUncaughtExceptionHandler *previousHandle;    void signal_handler(int signal) {    ......}void exception_handler(NSException *exception) {    ......}    void registerCrashHandle() {    previousHandle = NSGetUncaughtExceptionHandler();    NSSetUncaughtExceptionHandler(&exception_handler);        myAction.sa_handler = &signal_handler;    sigemptyset(&my_action.sa_mask);    sigaction(SIGABRT, &my_action, &registered_action);}复制代码

一般来说，一个经验丰富的开发者在注册crash回调时都会主动的去保存其他函数，避免因为冲突导致别人的数据丢失。但是即便按照这样的方式来注册你的回调，也不代表我们的处理函数是安全的。最重要的原因在于完成回调的注册之后，我们无法保证后续会不会有其他人继续注册，如果有就会存在被替换掉的风险

解决方案

按照正常方式的做法，能保证先于我们注册的crash回调不会被我们拦截导致失败，但如果在我们后方存在另外的注册，我们需要一个有效的机制来保护我们的采集数据。解决问题的收益是不变的，所以解决方案理当尽可能的低开销和低风险。

如何去判断我们的handle是否安全？这要求我们对已注册的handle进行检测。首先检测时机要选择在哪？由于crash是可能发生在应用启动阶段的，因此crash采集一般也是发生在didLaunch这个时间，下图是我绘制的应用启动到完全启动的几个重要阶段：

applicationActive这个阶段基本上是能保证crash相关的注册都完成的，因此冲突检测可以放到这个阶段进行。

周期性检测

利用已有的周期性机制或者使用定时器来进行handle冲突检测。可以分别使用通知和定时器两个机制来完成周期性检测方案

• 监听应用状态

  监听UIApplicationDidBecomeActiveNotification在应用进入活跃状态时做检测：

  - (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {      ......      [[NSNotificationCenter defaultCenter] addObserver: [SignalHandler sharedHandler] selector: @selector(checkRegisterCrashHandler) name: UIApplicationDidBecomeActiveNotification object: nil];      ......     }    static struct sigaction existActions[32];  static int fatal_signals[] = {      SIGILL,      SIGBUS,      SIGABRT,      SIGPIPE,  };    - (void)checkRegisterCrashHandler {      struct sigaction oldAction;      for (int idx = 0; idx < sizeof(fatal_signals) / sizeof(int); idx++) {          sigaction(fatal_signals[idx], NULL, &oldAction);          if (oldAction.sa_handler != &signal_handler) {              existActions[fatal_signals[idx]] = oldAction;                            struct sigaction myAction;              myAction.sa_handler = &signal_handler;              sigemptyset(&myAction.sa_mask);              sigaction(SIGABRT, &myAction, NULL);          }      }  }复制代码

• 定时器检测

  创建定时器来进行周期性的检测，相比通知的机制，可以控制检测间隔：

  - (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {      ......      NSTimer *timer = [[NSTimer alloc] initWithFireDate: [NSDate date] interval: 30 target: [SignalHandler sharedHandler] selector: @selector(checkRegisterCrashHandler) userInfo: nil repeats: YES];      [[NSRunLoop currentRunLoop] addTimer: timer forMode: NSRunLoopCommonModes];      [timer fire];      ......     }复制代码

hook注册函数

通过hook调用注册handle的对应函数，建立一个回调数组来保存非exception_handle的所有回调，后续处理完我们的采集，再逐个调起。由于捕获函数都是基于C接口的，因此我们需要来提供相应的hook功能。

struct SignalHandler {    void (*signal_handler)(int);    struct SignalHandler *next;}struct SignalHandler *previousHandlers[32];void append(struct SignalHandler *handlers, struct SignalHandler *node) {     ......}static int (*origin_sigaction)(int, const struct sigaction *__restrict, struct sigaction * __restrict) = NULL;int custom_sigaction(int signal, const struct sigaction *__restrict new_action, struct sigaction * __restrict old_action) {    if (new_action.sa_handler != signal_handler) {        append(previousHandlers[signal], new_action);        return origin_sigaction(signal, NULL, old_action);    } else {        return origin_sigaction(signal, new_action, old_action);    }}复制代码

风险

在周期性检测的方案下，假设存在handle注册链（依次从左到右）：

previous <- exception_handle <- other

在检测时发现当前回调是other，于是重新注册我们的回调，保存other。但是假如other也保存了我们的回调，这样可能会导致崩溃发生的时候，调用顺序变成一个死循环。

hook方案则是因为在调用origin_sigaction时会传入old_action，可能导致另外的注册者保存了我们的exception_handle，并在最后处理的时候出现同样的循环调用问题。对于hook方案来说，解决方法要简单很多，只需要在非我们的注册调用origin_sigaction时不传入old_action就能保证其他注册者无法获取到我们的回调：

int custom_sigaction(int signal, const struct sigaction *__restrict new_action, struct sigaction * __restrict old_action) {    if (new_action.sa_handler != signal_handler) {        append(previousHandlers[signal], new_action);        return origin_sigaction(signal, NULL, NULL);    } else {        return origin_sigaction(signal, new_action, old_action);    }}复制代码

而使用周期性监测，就需要考虑是否放弃other的回调，最终只保证exception_handle和previous和更早之前的注册能够被顺利调起。

另外，hook还存在一个风险是假如第三方同样做了hook掉注册函数的处理，并且做了筛选处理，最终导致的结果是没办法完成任何一个注册。两害相较取其轻，个人的建议是使用周期性检测方案。

最简单的方式

上述的两套方案都存在风险点，而且这些风险点对于应用来说都算是致命的。那么有没有几乎没有风险又能解决问题的办法呢？答案是肯定的，那就是不要用有潜在风险的第三方，或者和第三方开发者商量提供一个无需crash采集的版本。

在应用发生崩溃的时候，此时的崩溃所在线程是极不稳定的，不稳定性包括几点：

• 内存不稳定

  如果是内存相关错误引发的crash，比如内存过载、野指针等，此时线程的内存是危险状态。如果这时候在handle中再次分配内存，极有可能导致二次crash

• 死锁

  大多数底层的的核心API会涉及到加锁处理，这一情况在signal错误中出现的较多。而作为上层调用方的我们是不自知的，此时错误的操作可能导致线程陷入死锁状态

理论上当我们拦截了一个signal的时候，此时的应用会陷入内核并停止工作，应用页面卡死，这时候我们可执行时长是无限的。如果处理链过长，耗时过多或者陷入某种循环，会造成一种应用卡死而非崩溃的错觉，而经过我厂大量的统计，应用卡死要比应用崩溃更让人难以接受。此外，过多的处理链会增加回调流程上的风险点。如果链条上的某个点发生了二次崩溃，会导致后续的处理都无法执行。因此，不用第三方或者让第三方去除crash采集，是一种可行且高效的手段。

其他

文中提到过一次现在比较流行的crash防护手段，这里还是想说两句。在开发中，crash防护会造成依赖心理，降低对风险的敏感。而在线上，这种方案可能屏蔽了大量的低级错误，也是让我不能容忍的，当然循环引用的防护属于例外。最后安利一波寒神的，除了容器类的防crash都值得学习，尤其是正确的method swizzling姿势。

参考