- 背景
最近遇到一个启动的crash，这个启动是app的通知拉起来的，每次都会crash，而正常的启动则不会发生，所以不好断点调试，也是费了几番周折才定位到原因，最后发现是个很常见的错误导致的，主要运用swizzle定位到了问题，大体路径如下。
1. 尝试查看手机Crash Logs
-
一般crash都会在设备上留下crash的日志，可以通过在Xcode的Devices And Simulators中查看。
连上xcode，打开手机的Device Logs，然后查看当天的crash，如下：
Xcode上的crash.png
查看源码，发现APMAnalytics是第三服务方的库，工程中都搜不到这个类名，这下麻烦了，不能从代码上分析原因，继续查看调用栈,发现了如下调用+[NSJSonSerialization dataWithJSONObject:options:error:]
当时就觉得应该是传入的参数不合法导致的，然后写了一个NSJSonSerialization的category，覆盖掉dataWithJSONObject，每次返回nil，发现就不crash了，定位到确实是这个方法导致。
1. 尝试hook造成crash的系统方法
- 从上面的步骤看来，应该是调用这个方法的参数不对导致的，得采用swizzle的方式，保留dataWithJSONObject的原本逻辑，同时对参数的输入做下安全判断，这样应该就可以。
@implementation NSJSONSerialization (ABSExtension)
+ (BOOL)lh_swizzleClassMethod:(SEL)origSel withMethod:(SEL)altSel {
return [object_getClass((id)self) lh_swizzleMethod:origSel withMethod:altSel];
}
+ (BOOL)lh_swizzleMethod:(SEL)origSel withMethod:(SEL)altSel {
Method origMethod = class_getInstanceMethod(self, origSel);
Method altMethod = class_getInstanceMethod(self, altSel);
if (!origMethod || !altMethod) {
return NO;
}
class_addMethod(self,
origSel,
class_getMethodImplementation(self, origSel),
method_getTypeEncoding(origMethod));
class_addMethod(self,
altSel,
class_getMethodImplementation(self, altSel),
method_getTypeEncoding(altMethod));
method_exchangeImplementations(class_getInstanceMethod(self, origSel),
class_getInstanceMethod(self, altSel));
return YES;
}
+ (void)load {
static dispatch_once_t onceToken;
dispatch_once(&onceToken, ^{
[self lh_swizzleClassMethod:@selector(dataWithJSONObject:options:error:) withMethod:@selector(lh_dataWithJSONObject:options:error:)];
});
}
+ (NSData *)lh_dataWithJSONObject:(id)obj options:(NSJSONWritingOptions)opt error:(NSError * _Nullable __autoreleasing *)error{
if (obj && ([obj isKindOfClass:[NSArray class]]||
[obj isKindOfClass:[NSDictionary class]]||
[obj isKindOfClass:[NSString class]])) {
return [self lh_dataWithJSONObject:obj options:opt error:error];
}else{
return nil;
}
}
@end
添加了以上代码后，发现还是发生crash，所以传入的参数应该是合法的，问题还是没有定位到,接着添加NSLog打印所有启动的参数传入，在Devices And Simulators中点击Open Console，发现启动过程的所有调用传入的参数都是合法的，而且数量很多，不知道是哪一条的问题。
3. 添加try catch代码块
- try catch 可以抓到iOS系统方法执行的异常，并打印出异常信息
修改代码如下：
+ (NSData *)lh_dataWithJSONObject:(id)obj options:(NSJSONWritingOptions)opt error:(NSError * _Nullable __autoreleasing *)error{
NSData *res = nil;
@try {
res = [self lh_dataWithJSONObject:obj options:opt error:error];
} @catch (NSException *exception) {
NSLog(@"lh -- exception is %@,%@",exception,obj);
} @finally {
return res;
}
}
既然上面步骤已经跟踪到是这个系统方法的问题，就想到加上try catch，这样应该可以抓到异常，同时也可以避免crash，运行了一遍，发现确实走到catch代码块里面，也打印了异常信息和对应传入的参数,最后发现传入的参数是个字典，但是某个key对应的value是个NSNumber，由于通知拉起的跳转逻辑，导致它是NAN，所以不能解析就crash了，然后找到对应的位置，修复了这个问题，最后决定保留这块代码记录一个数据点，上传今后类似异常信息
4.总结
- 遇到启动crash的时候，常用Xcode自带的console去打日志定位代码问题，同时结合设备生成的.crash文件可以快速定位到业务代码上的问题，如果崩在是非开源库中，就可以看看调用栈是否崩在系统方法里面，然后通过swizzle的方式找出对应的输入参数，最后加上try catch去找到异常信息一般就可以定位到问题了
- try catch能抓到的异常还是挺多的，如解档失败，集合类插入nil数据等系统方法，使用的好可以避免很多crash
