前言：一種愉快的開發方式，輕松快速定位BUG，跟開發中的BUG說再見！（公司里開展技術分享會，我就這對Bugly的使用做了個整理）
Bugly 使用分析
作者：tangjianfeng
時間：2018/10/23
騰訊Bugly簡介：
- Bugly是騰訊公司為移動開發者開發的服務之一，是面向移動開發者提供專業的Crash監控，崩潰分析等質量跟蹤服務。
- Bugly能幫助移動互聯網開發者更及時地發現掌控異常，更全面的了解定位異常，更高效的修復解決異常。
- 針對移動應用，騰訊Bugly提供了專業的Crash、Android ANR(application not response)、iOS 卡頓監控和解決方案。移動開發者(Android / iOS )可以通過監控，快速發現用戶在使用過程中出現的Crash (崩潰)、Android ANR和iOS卡頓，並根據上報的信息快速定位和解決問題。
【圖文簡介】：網址鏈接：https://bugly.qq.com/v2/workbench/apps
一：崩潰信息查看
【1】設備和版本信息查看：
【2】時間查看：
二：崩潰代碼對象定位：
【說明】：先需要先確定下BUG項目版本，定位到Bugly出現crash記錄下的版本。
【案例】：Bugly上面的crash信息我們可以看到如下：
【修正】：崩潰更改分析：
1: 這里我們就可以快速定位到出現crash的調用處：[ResendEmailView keyboardWillShow] 是系統導致崩潰的代碼。
2: 出現錯誤的是一個ResendEmailView類的調用：keyboardWillShow的類方法的crash，報錯是ResendEmailView未初始化的錯誤，也就是對象未實例化。
3: 通過代碼對象的定位，並且調試數據，相信問題就能迎刃而解。
三：Bugly符號化需求
【1】什么是符號表？
答： 符號表是內存地址與函數名、文件名、行號的映射表。符號表元素如下所示：
<起始地址> <結束地址> <函數> [<文件名:行號>]。
【2】為什么要配置符號表？
答：為了能快速並准確地定位用戶APP發生Crash的代碼位置，
Bugly使用符號表對APP發生Crash的程序堆棧進行解析和還原。
【3】:BuglyiOS符號表配置官方文檔入口：
https://bugly.qq.com/docs/user-guide/symbol-configuration-ios/?v=1492997248592
【4】結合項目分析
說明：當Bugly上無顯示代碼類信息和方法調用，只顯示地址信息的情況，如下圖：
分析：如上，面板信息沒有具體的對象或者方法調用信息，我們確定不了出錯代碼定位的時候，就需要應用到Bugly 符號化。
四：安裝Bugly符號化
【第一步】：給Mac安裝Java運行環境，先需要安裝Java環境，連接地址：
http://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-2133151.html
-------選擇MAC版本Java：如下圖
說明：打開鏈接，選擇上圖中紅色圈出部分，下載Mac下的.dmg文件即可。
下載完成之后雙擊便可一鍵式安裝完畢。
【第二步】：驗證安裝是否成功和查看Java版本
—————終端指令輸入：java -version
—————結果如下：安裝1.8的JavaJDK成功
【第三步】：下載Bugly iOS符號表工具：
下載Bugly iOS符號表工具連接地址 —> Bugly iOS符號表工具
【第四步】：關聯項目同名的.dSYM文件
———在確定了BUG版本的情況下，路徑操作如下：
show in finder -> 顯示包內容-> dSYMs文件夾-> 找到和項目同名的.dSYM文件，即(項目名.app.dSYM)。
【第五步】：准備整理文件：
桌面新建一個文件夾，將找到的這個xx.app.dSYM文件和第一步下載的符號表工具包中“buglySymboliOS.jar”文件，放到新建的文件夾中，方便后續通過終端生成符號表.zip文件（我這里放在Desktop）。
【第六步】：終端生成自己項目的符號表.zip文件
------終端指令: java -jar /Users/a/Desktop/saicBugly_dSYM/buglySymboliOS.jar -i /Users/a/Desktop/saicBugly_dSYM/SaicCarPlatform.app.dSYM
------注意：路徑需要改成自己文件的路徑，上面是我本機的文件路徑
需要上傳的zip文件已經生成：
五：上傳當前版本Bugly符號化文件
【第一步】：確定Bugly的崩潰所對應的唯一標識符：UUID
【第二步】：zip文件UUID驗證：
—————查看dSYM文件的UUID
—————終端輸入：xcrun dwarfdump --uuid <dSYM文件路徑>
案例輸出：
UUID: E0242B60-058C-39CF-ADAC-8C28979E469A (armv7) /Users/a/Desktop/saicBugly_dSYM/SaicCarPlatform.app.dSYM/Contents/Resources/DWARF/SaicCarPlatform
UUID: D245BAE0-C338-3275-8CF1-6B6741BDB49B(arm64) /Users/a/Desktop/saicBugly_dSYM/SaicCarPlatform.app.dSYM/Contents/Resources/DWARF/SaicCarPlatform
驗證結果：版本確定是一致的。
【第三步】：Bugly符號表管理
-------打開符號表管理
————為目標的BUG版本，上傳先前合成的指定版本的壓縮包:
找到BUG對應UUID：D245BAE0-C338-3275-8CF1-6B6741BDB49B
————上傳成功需要等一會：
【等四步】：成果果實收獲
這里已經符號化成功了。
總結建議：在測試或者開發構建版本完成，保留構建版本文件，因為在應用符號化定位BUG時，需要Bugly上BUG的UUID對應構建版本文件dSYM的UUID，這樣才能通過地址查找並確定崩潰原因。
結尾語：Bugly的使用分析基本上就這些，最后希望大家加班少寫點BUG。如有問題，歡迎交流，QQ：497609288