dSYM 文件分析工具

來到新公司後，前段時間就一直在忙，前不久 項目 終於成功發佈上線了，最近就在給項目作優化，並排除一些線上軟件的 bug，由於項目中使用了友盟統計，因此在友盟給出的錯誤信息統計中能比較方便的找出客戶端異常的信息，但是不少像數組越界卻只給出了 *** -[__NSArrayM objectAtIndex:]: index 7 beyond bounds [0 .. 6]' 這類錯誤信息，以下圖所示：

遇到這種問題若是經過 objectAtIndex 去檢索錯誤的地方那將會是一個巨大的工做量。

dSYM 文件

---

什麼是 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工具

---

因而我抽了幾個小時的時間將這些命令封裝到一個應用中，也爲之後解決bug提供了便利。

使用步驟:

1.將打包發佈軟件時的xcarchive文件拖入軟件窗口內的任意位置(支持多個文件同時拖入，注意：文件名不要包含空格)

2.選中任意一個版本的xcarchive文件，右邊會列出該xcarchive文件支持的CPU類型，選中錯誤對應的CPU類型。

3.對比錯誤給出的UUID和工具界面中給出的UUID是否一致。

4.將錯誤地址輸入工具的文本框中，點擊分析。

 

終端命令方法，如下兩種

第一種方法：

使用dwarfdump命令

dwarfdump --uuid xx.app.dSYM     用來獲得app的UUID。
dwarfdump --lookup 0x12b45d -arch armv7 xx.app.dSYM  使錯誤的日誌能看懂，把相應的內存地址對應到正確的地方。
若是一開始dwarfdump命令不能用的話，要先裝Command Line Tools,這個在設置裏面能下載（cmd+「，」打開設置）。另外還必須在進入.DSYM所在文件夾。

使用dwarfdump須要安裝Command Line Tools,XCode裏設置下載。並且須要進入.DSYM所在文件夾裏進行操做。

第二種方法：

 

使用xcrun atos命令

atos -o YourApp.app.dSYM/Contents/Resources/DWARF/YourApp 0x00062867