在日常開發中,App難免會發生爆炸??...哦不...崩潰...對于那些簡單的崩潰,看看大概??看一眼心里就有數了,但是對于復雜的崩潰呢,就要通過我們解析Crash文件來分析一下了
利用第三方統計功能符號化iOS應用崩潰日志
在iOS中獲取崩潰信息的方式有很多，比較常見的是使用友盟、騰訊、百度等第三方分析工具，或者自己收集崩潰信息并上傳公司服務器。
注意，以下情況不會有崩潰信息產生：
1.內存訪問錯誤(不是野指針錯誤)
2.低內存，當程序內存使用過多會造成系統低內存的問題，系統會將程序內存回收
3.因為某種原因觸發看門狗機制
什么是dSYM文件
Xcode編譯項目后，我們會看到一個同名的 dSYM 文件，dSYM 是保存 16 進制函數地址映射信息的中轉文件，我們調試的 symbols 都會包含在這個文件中，并且每次編譯項目的時候都會生成一個新的 dSYM 文件，位于 /Users/<用戶名>/Library/Developer/Xcode/Archives 目錄下，對于每一個發布版本我們都很有必要保存對應的 Archives 文件 ( AUTOMATICALLY SAVE THE DSYM FILES ,通過腳本每次編譯后都自動保存 dSYM 文件)。
dSYM有什么作用
當我們軟件 release 模式打包或上線后，不會像我們在 Xcode 中那樣直觀的看到用崩潰的錯誤，這個時候我們就需要分析 crash report 文件了，iOS 設備中會有日志文件保存我們每個應用出錯的函數內存地址，通過 Xcode 的 Organizer 可以將 iOS 設備中的 DeviceLog 導出成 crash 文件，這個時候我們就可以通過出錯的函數地址去查詢 dSYM 文件中程序對應的函數名和文件名。大前提是我們需要有軟件版本對應的 dSYM 文件，這也是為什么我們很有必要保存每個發布版本的 Archives 文件了
友盟統計具體的做法
首先將文件一一對應
每一個 xx.app 和 xx.app.dSYM 文件都有對應的 UUID，crash 文件也有自己的 UUID，只要這三個文件的 UUID 一致，我們就可以通過他們解析出正確的錯誤函數信息了。
1.查看 xx.app 文件的 UUID，terminal 中輸入命令 ：
dwarfdump --uuid xx.app/xx (xx代表你的項目名)
2.查看 xx.app.dSYM 文件的 UUID ，在 terminal 中輸入命令：
dwarfdump --uuid xx.app.dSYM
3.crash 文件內第一行 Incident Identifier 就是該 crash 文件的 UUID。
dSYM工具的具體用法
1.將打包發布軟件時的xcarchive文件拖入軟件窗口內的任意位置(支持多個文件同時拖入，注意：文件名不要包含空格)
2.選中任意一個版本的xcarchive文件，右邊會列出該xcarchive文件支持的CPU類型，選中錯誤對應的CPU類型。
3.對比錯誤給出的UUID和工具界面中給出的UUID是否一致。
4.將錯誤地址輸入工具的文本框中，點擊分析。
騰訊Bugly具體的做法
首先要確保Xcode已經做了如下的設置:
Debug為DWARF with dSYM File會有警告，Release為DWARF就不會生成dSYM文件。
在你每次Archive一個版本時，都會相應的生成一個dSYM文件（前提是上面的設置是正確的），按如下操作找到dSYM：
有了dSYM文件后還需要進行如下步驟：
1.在Bugly網站下載iOS對應的"符號表工具"；
2.下載完成后，按照我的方法，你只要把buglySymboliOS.jar文件提取出來，和dSYM文件放在同一個目錄下就OK了；
3.打開命令行，進入到這兩個文件所在的目錄，執行如下命令：java -jar buglySymboliOS.jar -i xx.app.dSYM/ （xx代表你的App的名稱）
4.然后在該目錄下就會生成一個.zip文件；
5.去bugly網站中，找到你的App版本控制，選擇對應的版本，上傳上面生成的.zip文件；
6.完成，日后的崩潰日志就都會被符號化。
