1.自己先寫一個 Demo 演示一下利用bugly測試崩潰的具體情況。
在ViewController里面實現崩潰代碼如下： 
運行后 毫無疑問程序報錯了!
2.使用到第三方的框架Bugly，官方下載bugly
3.進入后利用qq注冊一下，完整一下相應的個人信息。
4.進入后注冊一下你要測試的app，我創建的app demo叫CocoaPodText如下。
5.利用CocoaPods集成 Bugly框架，詳情見本人博客關於CocoaPods的配置使用，只需要pod Bugly如圖。 
6.接下來回到項目中，在 AppDelegate.m 中引入Bugly/Bugly.h，和代理BuglyDelegate，初始化 Bugly等。
appid獲取處： 
7.完成代理方法： 
8.接下來運行，點擊button崩潰后可以打印出出錯信息。刷新bugly上你的app異常日志上報界面如圖（此截圖我是測試了兩處bug后的異常情況截圖）： 
點擊進去詳情： 
到這里你會發現這個日志中的崩潰點雖然定位到具體某一個文件中的某一個方法，但是具體到某一行似乎並沒有實現。不着急慢慢來。。。
這需要另外一個概念：符號表。點擊進去你的崩潰詳情中回發現有那么一個東西如下： 
符號表：
沒有符號表，我們就無法定位崩潰中的符號對應的代碼所在的類以及類中的行數位置。我們在每次構建版本、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比友盟統計中的異常調試更方便全面。