开发中不可避免的会遇到很多bug,利用崩溃日志,可以快速有效的帮助我们定位bug
接下来模拟一个崩溃的Bug:
数组中添加了一个为nil的字符串
#import "ViewController.h"
@interface ViewController ()
@end
@implementation ViewController
- (void)viewDidLoad {
[super viewDidLoad];
[self demoCrash];
}
- (void)demoCrash{
NSString *nilString = nil;
NSArray *array = @[@"hello",@"world",nilString];
}
@end
Command +R 运行后崩溃:
程序停在Main函数位置,通常我们会将目光放在控制台的报错信息,一般只会留意上面的部分:
Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '*** -[__NSPlaceholderArray initWithObjects:count:]: attempt to insert nil object from objects[2]'
可以怕段崩溃原因是在某个数组中试图添加一个空对象
如果是刚刚修改代码出现的bug,或许还可以快速分析出bug位置,但如果维护项目中,并且类文件比较多,只是通过报错原因并不能快速有效定位bug
所以我们必须要充分利用控制台的下面的部分: 调用堆栈
调用堆栈中先执行的在下面,后执行的在上面,通过这样的一个详细调用过程可以看到,bug大概就是在ViewController中,当调用demoCrash方法的时候,添加了一个空对象导致的
7 --> [UIViewController view]
5 --> [ViewController viewDidLoad]
4 --> [ViewController demoCrash]
这样就快速定位到bug所在位置了
需要注意的是:这是在模拟器上运行的情况,当程序崩溃,控制台会给出错误信息和调用堆栈,但如果在真机运行,只会给出错误信息,并不会显示调用堆栈
真机模拟或项目上线后的bug收集,可以借助第三方框架
如腾讯的Bugly,使用很简单,可以参考腾讯API:https://bugly.qq.com/iosfast
需要注意的是:当连接真机运行崩溃时,程序(断点)会停在main函数,后面不会执行,报错信息就不会提交,需要使用真机运行应用,出现崩溃闪退后,过一会,刷新Bugly崩溃分析页面,除了可以看到设备基本信息,在下面还会显示调用堆栈信息
另外需要注意的是,初始化Bugly的时候,代码一定要放在最前面,这样才能保证后面的代码被监听到:
- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
[Bugly startWithAppId:@"此处替换为你的AppId"];
/*
其他代码
*/
return YES;
}