引文
之前开发中了解到Android遇到Crash，可以利用框架回退到上一个页面而不是闪退掉，然后在思考如何降低iOS的Crash率，当然最主要方法是从根源抓起，注意代码逻辑完成性，代码规范性，多测试。
后来知道可以通过Runtime的方法交换替换一些方法，那么此时就可以替换掉NSArray、NSDictionary的一些插入方法，进行判断避免插入空值。
通过本文你可以学到什么？
- 简单的方法交换和消息转发降低crash率
- 遇到crash怎么快速定位与解决
1. 简单的方法交换和消息转发降低crash率
先说一些一眼能定位的异常，数组越界、插入空值等，我们可以使用分类进行交换系统方法避免Crash，原理很简单，见代码：
@implementation NSArray (XQAdd)
+ (void)load {
static dispatch_once_t onceToken;
dispatch_once(&onceToken, ^{
[objc_getClass("__NSArrayI") swizzleInstanceMethod:@selector(objectAtIndex:) with:@selector(xq_objectAtIndex:)];
// [@"1"]
}
- (id)xq_objectAtIndex:(NSInteger)index {
if (index >= self.count || index < 0 || !self.count) {
return nil;
}
return [self xq_objectAtIndex:index];
}
同样，我们也可以交换NSMutableArray的插入方法，NSDictionary的插入方法等，可以看我写的一个代码示例
还有在我们获取到网络数据的时候，如果直接当字典取值，并不知道某个key存储的值是NSNumber还是NSString，但是我的习惯性是传值大部分使用NSString来进行，所以遇到NSNumber当NSString使用可能会发生崩溃，那么我们利用消息转发-forwardingTargetForSelector:来实现NSNumber直接当做NSString使用不崩溃。主要代码如下
@implementation NSNumber (avoidCrash)
+ (void)load {
static dispatch_once_t onceToken;
dispatch_once(&onceToken, ^{
[self swizzleInstanceMethod:@selector(respondsToSelector:) with:@selector(swizzle_respondsToSelector:)];
[self swizzleInstanceMethod:@selector(forwardingTargetForSelector:) with:@selector(swizzle_forwardingTargetForSelector:)];
});
}
- (BOOL)swizzle_respondsToSelector:(SEL)aSelector {
if ([self swizzle_respondsToSelector:aSelector]) {
return YES;
}
if ([__checkString respondsToSelector:aSelector]) {
return YES;
}
return [super respondsToSelector:aSelector];
}
- (id)swizzle_forwardingTargetForSelector:(SEL)aSelector {
// whether NSString respondsToSelector
if ([__checkString respondsToSelector:aSelector]) {
return [NSString stringWithFormat:@"%@", self];
}
// Returns the object to which unrecognized messages should first be directed
return [super forwardingTargetForSelector:aSelector];
}
其实Runtime类似于跑酷，玩不好就会摔的很惨，斟酌使用此方法，最好的方式就是写好自己的代码逻辑。
2. 遇到crash怎么快速定位与解决
这里推荐一篇文章@念茜漫谈iOS Crash收集框架, 推荐阅读
补充一些大家常见的EXC_BAD_错误原因
1）EXC_BAD_ACCESS
此类型的Excpetion是我们最长碰到的Crash，通常用于访问了不改访问的内存导致。一般EXC_BAD_ACCESS后面的"()"还会带有补充信息。
SIGSEGV:通常由于重复释放对象导致，这种类型在切换了ARC以后应该已经很少见到了。
SIGABRT:收到Abort信号退出，通常Foundation库中的容器为了保护状态正常会做一些检测，例如插入nil到数组中等会遇到此类错误。
SEGV:（Segmentation Violation），代表无效内存地址，比如空指针，未初始化指针，栈溢出等；
SIGBUS：总线错误，与 SIGSEGV 不同的是，SIGSEGV 访问的是无效地址，而 SIGBUS 访问的是有效地址，但总线访问异常(如地址对齐问题)
SIGILL：尝试执行非法的指令，可能不被识别或者没有权限
2）EXC_BAD_INSTRUCTION
此类异常通常由于线程执行非法指令导致。
1.在代码中修改了storyboard与outlet的对应关系，但是storyboard没有更新时发生过此crash。
2.与第三方库中方法冲突时发生过此crash。
3.调用系统方法时传入了不恰当的指针类型。
3）EXC_ARITHMETIC
代码中做除法时分母为零了会发生此问题。
推荐两个开源的Crash 收集库
plcrashreporter：这是是相对比较早的Crash收集处理库了，支付宝的开源协议上就有此库。使用的话大致流程就是，注册到APP，搜集Crash文件、上传。
更推荐KSCrash，这个维护更新的比较多，可以了解一下
