iOS專案崩潰日誌採集與分析

先看乙個下demo**：

nsstring *str = nil;
nsarray *arr = @[@"hello",str];

**很簡單，因為陣列裡面有nil元素，所以執行的時候一定會崩潰，執行的崩潰畫面分析：

先看乙個oc的ddemo工程：

nsstring *str = nil;
nsarray *arr = @[@"hello",str];

**很簡單，因為陣列裡面有nil元素，所以執行的時候一定會崩潰，執行的崩潰畫面分析：

螢幕快照 2016-11-02 下午9.52.17.png

如圖所示，在我們工作中，在打了全域性斷點的情況下，在一些情況下，還是不能崩潰在指定的問題**位置，而在main函式的入口處，我們有時候就會很茫然，不知所謂，這時候，我們就要一步一步來分析，問題道理在**，首先肯定會先看崩潰原因：

attempt to insert nil object from objects[1]

我們就知道，奧。。。原來是陣列裡面插入了一盒nil 的元素，導致崩潰的，這時候，就會去想，是**呢，**插入nil物件了呢？？？

這很明顯，不是乙個正確的解決問題的思路，在看完原因後，我們應該，看一下執行緒下呼叫堆疊的資訊，堆疊資訊我們應該從下往上看（看圖中的箭頭方向）,一行一行的看，可以看到我們熟悉的方法，我們最終可以得到以下資訊：

在控制器viewcontroller載入viewdidload方法的中，初始化乙個陣列，由於嘗試插入乙個nil元素，引起了崩潰。所以是不是很直觀的就知道了問題的具體資訊了

螢幕快照 2016-11-02 下午10.36.03.png

return yes;

}swift

return true

}看看，bugly的崩潰資訊：

螢幕快照 2016-11-02 下午10.56.42.png

螢幕快照 2016-11-02 下午10.56.55.png

螢幕快照 2016-11-02 下午10.57.11.png

可以看到，bugly可以幫助我們做一些崩潰資料的統計與分析。

螢幕快照 2016-11-02 下午10.57.28.png

當我們進入崩潰的詳情頁面，可以清楚的看到在哪乙個控制器，哪乙個方法，什麼原因引起的崩潰。

在日常工作中，看崩潰日誌，使我們程式設計師每天必需要做工作，怎樣是不是很方便啊，友盟的使用和這個很類似，打擊有興趣可以自己嘗試哦。

**：