记录一次启动crash排查记录一次启动crash排查

背景
最近遇到一个启动的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排查】添加了以上代码后，发现还是发生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