一、日常开发崩溃分析
先看一个下Demo代码：
NSString *str = nil;
NSArray *arr = @[@"hello",str];
代码很简单，因为数组里面有nil元素，所以运行的时候一定会崩溃，运行的崩溃画面分析：
先看一个OC的DDemo工程：
NSString *str = nil;
NSArray *arr = @[@"hello",str];
如图所示，在我们工作中，在打了全局断点的情况下，在一些情况下，还是不能崩溃在指定的问题代码位置，而在main函数的入口处，我们有时候就会很茫然，不知所谓，这时候，我们就要一步一步来分析，问题道理在哪里，首先肯定会先看崩溃原因：
attempt to insert nil object from objects[1]
我们就知道，奥。。。原来是数组里面插入了一盒nil 的元素，导致崩溃的，这时候，就会去想，是哪里呢，哪里插入nil对象了呢？？？
这很明显，不是一个正确的解决问题的思路，在看完原因后，我们应该，看一下线程下调用堆栈的信息，堆栈信息我们应该从下往上看（看图中的箭头方向）,一行一行的看，可以看到我们熟悉的方法，我们最终可以得到以下信息：
在控制器viewController加载ViewDidLoad方法的中，初始化一个数组，由于尝试插入一个nil元素，引起了崩溃。所以是不是很直观的就知道了问题的具体信息了
二、上线应用崩溃采集
那么，问题来了，在我们开发的环境中，我们可以通过看调用堆栈的信息，和崩溃信息来确定问题所在，那么当我们的App上线后，不可计的用户可以能由于各种环境和操作，发生崩溃，我们怎么知道问题在哪里，怎么优化呢，
这时候，我想说，我刚学编程的时候，老师常说的一句话：凡是刚需的、经常用的，但是又比较复杂的，都有大牛们做好的解决方案，不需要我们这种菜菜来考虑怎么解决 ，事实证明这句话是有道理的，现在有许多第三方提供了现成的解决方法，例如友盟、Bugly等，使用起来都很简单方便，我就介绍下Bugly的使用方法：
- 登录Bugly，注册应用：
-
选择异常上报
屏幕快照 2016-11-02 下午10.36.55.png 可以选着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可以帮助我们做一些崩溃数据的统计与分析。
当我们进入崩溃的详情页面，可以清楚的看到在哪一个控制器，哪一个方法，什么原因引起的崩溃。
在日常工作中，看崩溃日志，使我们程序员每天必需要做工作，怎样是不是很方便啊，友盟的使用和这个很类似，打击有兴趣可以自己尝试哦。
