1.本身先寫一個 Demo 演示一下利用bugly測試崩潰的具體狀況。
在ViewController裏面實現崩潰代碼以下： 
ios
運行後 毫無疑問程序報錯了!數組
2.使用到第三方的框架Bugly，官方下載bugly
3.進入後利用qq註冊一下，完整一下相應的我的信息。app
4.進入後註冊一下你要測試的app，我建立的app demo叫CocoaPodText以下。框架
5.利用CocoaPods集成 Bugly框架，詳情見本人博客關於CocoaPods的配置使用，只須要pod Bugly如圖。 ide
6.接下來回到項目中，在 AppDelegate.m 中引入Bugly/Bugly.h，和代理BuglyDelegate，初始化 Bugly等。工具
appid獲取處： 測試
7.完成代理方法： ui
8.接下來運行，點擊button崩潰後能夠打印出出錯信息。刷新bugly上你的app異常日誌上報界面如圖（此截圖我是測試了兩處bug後的異常狀況截圖）： .net
點擊進去詳情： debug
到這裏你會發現這個日誌中的崩潰點雖然定位到具體某一個文件中的某一個方法，可是具體到某一行彷佛並無實現。不着急慢慢來。。。
這須要另一個概念：符號表。點擊進去你的崩潰詳情中回發現有那麼一個東西以下：
符號表：
沒有符號表，咱們就沒法定位崩潰中的符號對應的代碼所在的類以及類中的行數位置。咱們在每次構建版本、debug的時候，都會生成dSYM後綴名的符號表文件，而咱們App在手機上運行的時候，崩潰後產生的崩潰信息，不可能定位到代碼的多少多少行，由於這些信息對於App運行是沒有意義的，存儲在App中勢必會增大安裝包的體積，因此App的崩潰信息都是存儲爲各類符號，具體符號表明什麼，須要去符號表中查找對應的含義。
咱們每次debug、構建版本，都會生成dSYM文件，都對應了一個UUID（像咱們的手機同樣，都有一個惟一標誌），按下圖指示，咱們就能找到咱們所使用的App版本對應的dSYM文件的UUID，經過這個UUID，咱們就能找到存儲在咱們電腦中的dSYM文件，將這個文件上傳到bugly，bugly會自動幫咱們找到崩潰符號的含義。
1)接下來 你能夠根據官方給的如何上傳符號表來完成。我也是根據文檔中關於自動配置自動配置：XCode + sh腳本來實現的，下載好配置文件以下：
2)配置Xcode編譯執行腳本在Xcode工程對應Target的Build Phases中新增Run Scrpit Phase
3)打開工具包中的dSYM_upload.sh，複製全部內容，在新增的Run Scrpit Phase中粘貼
4)修改新增的Run Scrpit中的App ID,App Key，App的Bundle Id等。
5）腳本默認在Debug模式及模擬器編譯狀況下不會上傳符號表，在須要上傳的時候，請修改下列選項
Debug模式編譯是否上傳，1＝上傳 0＝不上傳，默認不上傳
UPLOAD_DEBUG_SYMBOLS=0
模擬器編譯是否上傳，1＝上傳 0＝不上傳，默認不上傳
UPLOAD_SIMULATOR_SYMBOLS=0
以下：
至此，自動上傳符號表腳本配置完畢，Bugly 會在每次 Xcode 工程編譯後自動完成符號表配置工做。
當你再次刷新你的bugly界面時，閃崩的行號自動變動爲正常在項目中對應的行號：
一下是我配置的另外一個項目中的結果展現：
第一個圖中代碼部分501行明確能夠看出來數組越界的問題，輸出部分標號3也定位到是tableView的點擊方法裏面，可是後面的352缺並非表明行號。因此經過符號表腳本配置，咱們能夠看到第二張圖中明確的閃崩行號501.
發現裏面的異常狀況說得很詳細，主要還根據異常狀況給出了相應的解決方案，這一點很棒。
本人以爲這個bugly比友盟統計中的異常調試更方便全面。