專案開發過程中，使用了友盟統計，就能在友盟給出的錯誤資訊統計中，能比較方便的找出客戶端異常的資訊，但是很多像陣列越界卻只給出了 *** -[__NSArrayM objectAtIndex:]: index 50 beyond bounds [0 .. 39]' 這類錯誤資訊，如下圖所示：

        遇到這種問題的話，如果通過 objectAtIndex 去檢索錯誤的地方，那將會是一個巨大的工作量，那麼怎麼辦才能減輕工作量呢，那就是下面要介紹的情況了。

一、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 檔案了。

三、如何把檔案一一對應

       每一個 xxx.app 和 xxx.app.dSYM 檔案都有對應的 UUID，crash檔案也有自己的UUID，只要這三個檔案的UUID一致，我們就可以通過它們解析出正確的錯誤函式資訊了。
       1.檢視 xxx.app 檔案的 UUID，terminal 中輸入命令 ：dwarfdump --uuid xxx.app/xxx (xxx是你的專案名稱)
       2.檢視 xxx.app.dSYM 檔案的 UUID ，在terminal中輸入命令：dwarfdump --uuid xxx.app.dSYM 
       3.crash 檔案內第一行 Incident Identifier 就是該crash檔案的 UUID。

四、dSYM檔案分析工具的使用

       1.將打包釋出程式時的xcarchive檔案，拖入到軟體視窗內的任意位置(這裡支援多個檔案同時拖入，特別注意：檔名不要包含空格)
       2.選中任意一個版本的xcarchive檔案，右邊會列出該xcarchive檔案支援的CPU型別，選中錯誤對應的CPU型別。
       3.對比錯誤給出的UUID和工具介面中給出的UUID是否一致。
       4.將錯誤地址輸入工具的文字框中，點選分析。

       尤其是上架應用的時候，有些時候蘋果反饋的資訊裡面也會給具體的錯誤日誌，你可以通過dSYM工具直接可以找到具體報錯位置，百試百靈。如果你覺得我寫的內容對你有幫助請點贊，如果想和我更進一步交流探討，也可以關注我的微信公眾號，那裡面同樣有更多使用的方法技巧等著你！