一、日常開發(fā)崩潰分析
先看一個下Demo代碼：
NSString *str = nil;
NSArray *arr = @[@"hello",str];
代碼很簡單，因為數(shù)組里面有nil元素，所以運行的時候一定會崩潰，運行的崩潰畫面分析：
先看一個OC的DDemo工程：
NSString *str = nil;
NSArray *arr = @[@"hello",str];
如圖所示，在我們工作中，在打了全局?jǐn)帱c的情況下，在一些情況下，還是不能崩潰在指定的問題代碼位置，而在main函數(shù)的入口處，我們有時候就會很茫然，不知所謂，這時候，我們就要一步一步來分析，問題道理在哪里，首先肯定會先看崩潰原因：
attempt to insert nil object from objects[1]
我們就知道，奧。。。原來是數(shù)組里面插入了一盒nil 的元素，導(dǎo)致崩潰的，這時候，就會去想，是哪里呢，哪里插入nil對象了呢？？？
這很明顯，不是一個正確的解決問題的思路，在看完原因后，我們應(yīng)該，看一下線程下調(diào)用堆棧的信息，堆棧信息我們應(yīng)該從下往上看（看圖中的箭頭方向）,一行一行的看，可以看到我們熟悉的方法，我們最終可以得到以下信息：
在控制器viewController加載ViewDidLoad方法的中，初始化一個數(shù)組，由于嘗試插入一個nil元素，引起了崩潰。所以是不是很直觀的就知道了問題的具體信息了
二、上線應(yīng)用崩潰采集
那么，問題來了，在我們開發(fā)的環(huán)境中，我們可以通過看調(diào)用堆棧的信息，和崩潰信息來確定問題所在，那么當(dāng)我們的App上線后，不可計的用戶可以能由于各種環(huán)境和操作，發(fā)生崩潰，我們怎么知道問題在哪里，怎么優(yōu)化呢，
這時候，我想說，我剛學(xué)編程的時候，老師常說的一句話：凡是剛需的、經(jīng)常用的，但是又比較復(fù)雜的，都有大牛們做好的解決方案，不需要我們這種菜菜來考慮怎么解決 ，事實證明這句話是有道理的，現(xiàn)在有許多第三方提供了現(xiàn)成的解決方法，例如友盟、Bugly等，使用起來都很簡單方便，我就介紹下Bugly的使用方法：
- 登錄Bugly，注冊應(yīng)用：
-
選擇異常上報
屏幕快照 2016-11-02 下午10.36.55.png 可以選著SDK集成，也可以使用Pod，我當(dāng)然選著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函數(shù)，那么上傳崩潰信息就走運行不了了。
看看，Bugly的崩潰信息：
可以看到，Bugly可以幫助我們做一些崩潰數(shù)據(jù)的統(tǒng)計與分析。
當(dāng)我們進(jìn)入崩潰的詳情頁面，可以清楚的看到在哪一個控制器，哪一個方法，什么原因引起的崩潰。
在日常工作中，看崩潰日志，使我們程序員每天必需要做工作，怎樣是不是很方便啊，友盟的使用和這個很類似，打擊有興趣可以自己嘗試哦。
