从method swizzling 到crash 分析与解决
引文
之前开发中了解到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,这个维护更新的比较多,可以了解一下