iOS Crash异常捕获及快速分析

1.前言

• crash认识

• 一套系统、一款app、一个功能、甚至一行代码都可能会出现crash，crash伴随着我们的日常生活，如果我们正在玩游戏，LOL打团时，游戏闪退、电脑死机，那就想要跳起来砸键盘了。质量太差的产品，会导致产品负面评价越来越多，用户流失越来越严重，如果在关键环节出现了crash，比如下单、支付等，那就会造成直接损失。作为技术开发，我们对于这种问题要抱有零容忍的态度，虽然我们不可能做到 0 crash,但是我们要尽量避免项目中存在的crash

• 为什么没有0 crash

• crash的原因有很多，在工作中我们也有很多方法去避免造成crash，比如自定义一个安全处理方法，做好异常crash因素判断。但是为什么没有一个0crash的系统呢，就不能提供给我们绝对稳定可靠的API吗？
• 个人认为，每个API的设计都有其作用价值。比如iOS系统提供的[NSAarray objectAtIndex:]方法，如果出现越界就会crash，在项目中也有[NSArray safetyObjctAtIndex:]这样的自定义安全处理方法，越界时返回nil，但是返回nil，就一定是安全的吗？一定是符合所有场景需求的吗？比如某一个代码异常时，后面的代码是否应该执行，执行是否会带来其他的负面影响

2.异常指标

当开发阶段出现crash时，我们可以直接通过xcode定位crash堆栈，在测试阶段crash时，我们勉强还可以直接拿到测试机连接xcode查看日志，但是线上用户或者拿不到crash测试机的情况下，我们需要自己收集crash日志

造成crash的异常主要类型

• Objective-C uncaughtException异常
  • 这类异常通常可以手动捕获，处理@try...@catch...@finallly，在项目中有很多地方使用

NSArray *arr = @[@1,@2];
@try {
  [arr objectAtIndex:3];
} @catch （NSException *exp）{

} @finally {

}

• NSInvalidArgumentException，非法参数
  • nil参数
    • unrecognized selector sendt to instance
    • ...
  • NSRangeException，越界异常
• 数组，字符串获取下标
• NSGenericException，通用异常
• for ...in 循环中对可遍数组进行增加或者删除，在for( ; ; )中不会造成crash，但是容易造成逻辑上的错误，需要注意
• NSMallocException，内存分配异常

NSMutableData *mData = [[NSMutableData alloc] initWithCapacity:1];
NSUInteger len = 1844674407370955161;
[mData increaseLengthBy:len];


*** Terminating app due to uncaught exception 'NSMallocException', 
reason: 'Failed to grow buffer'

• Mach异常

  • 先看下OSX和ｉＯＳ的系统结构，了解几个基本概念

    
    
    
    

• Mach的职责主要是进程和线程抽象、虚拟内存管理、任务调度、进程间通信和消息传递机制等
• BSD层则在Mach之上，提供一套可靠且更现代的API，提供了POSIX（可移植操作系统接口）兼容性。
• Mach异常是指最底层的内核级异常,

• Mach异常处理流程

  
  

• BSD Signals

  • Mach已经通过异常机制提供了底层的陷阱处理，而BSD则在异常机制之上构建了信号处理机制。硬件产生的信号被Mach捕捉，然后转换为对应的UNIX信号。为了维护一个统一的机制，操作系统和用户尝试的信号首先被转换为Mach异常，然后再转换为信号(Signals)，如下图所示：

    
    
• 信号可以看做是对硬件异常跟软件异常的封装,需要处理的signals

static const int g_fatalSignals[] =
{
 SIGABRT,//调用abort生成的信号，有可能是NSException也有可能是Mach
 SIGBUS,//非法地址
 SIGFPE,//算术运算错误
 SIGILL,//执行非法指令
 SIGPIPE,//进程间通信产生，通信管道破裂
 SIGSEGV,//非法访问地址，比如野指针，通常是对象的异常释放，指针未清空
 SIGSYS,//非法的系统调用
 SIGTRAP,//断点指令，一般出现在debug调试时
};

• Mach exception和Signal转换关系

  
  

3.crash收集

• Objective-C uncaughtException可以通过NSSetUncaughtExceptionHandler系统回调进行捕获
• Mach异常，BSD将mach异常最终都转换为信号异常，所以我们只需要捕捉那些fatal signals，如果开发者没有捕获Mach异常，则会被host层的方法ux_exception()将异常转换为对应的UNIX信号，并通过方法threadsignal()将信号投递到出错线程。可以通过方法signal(x, SignalHandler)来捕获single。
• C++ exceptions使用系统封装好的函数std::set_terminate(CPPExceptionTerminate)来设置回调
• 未被try catch的NSException会发出kill或pthread_kill信号-> Mach异常-> Unix信号（SIGABRT）,但是SIGABRT在处理收集信息时，获取当前堆栈时获取不到，所以采用NSSetUncaughtExceptionHandler,可以参考KSCrash 源码
  

4.Crash快速分析

• 当我们拿到crash日志时，应首先从crash Type，crash thread 快速定位到造成crash的代码段。之所以首先要看这两个，是因为type能大致知道crash的类型，如果是OC类型的异常，那基本上处理起来比较简单，如果是mach signals类型的，通过查看造成crash的线程堆栈，也能快速定位到方法，举个实际项目中的例子：

线上有个偶现的crash，crash Type为SIGSEGV，且thread不定，子线程，主线程都会存在，但是代码段相同，由于SIGSEGV是野指针异常类型，且由于在多线程中都会触发，说明问题基本上是多线程的对象读写安全问题

5.参考资料

• kCrash源码分析

• Dokit支持iOS本地化

• 浅谈Mach Exception