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

遇到這種問題如果通過 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.將錯誤地址輸入工具的文本框中，點擊分析。
Mac app下載地址  項目源碼地址