一、日常开发崩溃分析
先看一个下Demo代码:
NSString *str = nil;
NSArray *arr = @[@"hello",str];
代码很简单,因为数组里面有nil元素,所以运行的时候一定会崩溃,运行的崩溃画面分析:
先看一个OC的DDemo工程:
NSString *str = nil;
NSArray *arr = @[@"hello",str];
代码很简单,因为数组里面有nil元素,所以运行的时候一定会崩溃,运行的崩溃画面分析:
如图所示,在我们工作中,在打了全局断点的情况下,在一些情况下,还是不能崩溃在指定的问题代码位置,而在main函数的入口处,我们有时候就会很茫然,不知所谓,这时候,我们就要一步一步来分析,问题道理在哪里,首先肯定会先看崩溃原因:
attempt to insert nil object from objects[1]
我们就知道,奥。。。原来是数组里面插入了一盒nil 的元素,导致崩溃的,这时候,就会去想,是哪里呢,哪里插入nil对象了呢???
这很明显,不是一个正确的解决问题的思路,在看完原因后,我们应该,看一下线程下调用堆栈的信息,堆栈信息我们应该从下往上看(看图中的箭头方向),一行一行的看,可以看到我们熟悉的方法,我们最终可以得到以下信息:
在控制器viewController加载ViewDidLoad方法的中,初始化一个数组,由于尝试插入一个nil元素,引起了崩溃。所以是不是很直观的就知道了问题的具体信息了
二、上线应用崩溃采集
那么,问题来了,在我们开发的环境中,我们可以通过看调用堆栈的信息,和崩溃信息来确定问题所在,那么当我们的App上线后,不可计的用户可以能由于各种环境和操作,发生崩溃,我们怎么知道问题在哪里,怎么优化呢,
这时候,我想说,我刚学编程的时候,老师常说的一句话:凡是刚需的、经常用的,但是又比较复杂的,都有大牛们做好的解决方案,不需要我们这种菜菜来考虑怎么解决 ,事实证明这句话是有道理的,现在有许多第三方提供了现成的解决方法,例如友盟、Bugly等,使用起来都很简单方便,我就介绍下Bugly的使用方法:
- 登录Bugly,注册应用:
-
选择异常上报
-
可以选着SDK集成,也可以使用Pod,我当然选着Pod了,这么方便:
通过CocoaPods集成,在工程的Podfile
里面添加以下代码:pod 'Bugly'
初始化Bugly,在工程AppDelegate.m
的application:didFinishLaunchingWithOptions:
方法中初始化Bugly:
Objective-C
- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
[Bugly startWithAppId:@"此处替换为你的AppId"];
return YES;
}
Swift
func application(application: UIApplication, didFinishLaunchingWithOptions launchOptions: [NSObject: AnyObject]?) -> Bool {
Bugly.startWithAppId("此处替换为你的AppId")
return true
}
友情提醒:使用Bugly采集崩溃信息,要使用真机,不能使用模拟器,不可以Xcode启动真机App,因为,崩溃后,程序会停止在mian函数,那么上传崩溃信息就走运行不了了。
看看,Bugly的崩溃信息:
可以看到,Bugly可以帮助我们做一些崩溃数据的统计与分析。
当我们进入崩溃的详情页面,可以清楚的看到在哪一个控制器,哪一个方法,什么原因引起的崩溃。
在日常工作中,看崩溃日志,使我们程序员每天必需要做工作,怎样是不是很方便啊,友盟的使用和这个很类似,打击有兴趣可以自己尝试哦。
转自:http://www.jianshu.com/p/76804c6c2e16