1.前言
- crash认识
- 一套系统、一款app、一个功能、甚至一行代码都可能会出现crash，crash伴随着我们的日常生活，如果我们正在玩游戏，LOL打团时，游戏闪退、电脑死机，那就想要跳起来砸键盘了。质量太差的产品，会导致产品负面评价越来越多，用户流失越来越严重，如果在关键环节出现了crash，比如下单、支付等，那就会造成直接损失。作为技术开发，我们对于这种问题要抱有零容忍的态度，虽然我们不可能做到
0crash,但是我们要尽量避免项目中存在的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，越界异常
- nil参数
- 数组，字符串获取下标
- 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是野指针异常类型，且由于在多线程中都会触发，说明问题基本上是多线程的对象读写安全问题
