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

遇到這種問題如果通過 objectAtIndex 去檢索錯誤的地方那將會是一個巨大的工作量。

dSYM 檔案

什麼是 dSYM 檔案

Xcode編譯專案後，我們會看到一個同名的 dSYM 檔案，dSYM 是儲存 16 進位制函式地址對映資訊的中轉檔案，我們除錯的 symbols 都會包含在這個檔案中，並且每次編譯專案的時候都會生成一個新的 dSYM 檔案，位於 /Users/<使用者名稱>/Library/Developer/Xcode/Archives 目錄下，對於每一個釋出版本我們都很有必要儲存對應的 Archives 檔案 ( 

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下載地址  專案原始碼地址