dSYM 檔案分析工具，dsym分析工具

dSYM 檔案分析工具，dsym分析工具

前不久 項目 終於成功發布上線了，最近就在給項目做最佳化，並排除一些線上軟體的 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  項目源碼地址

 

 

原文連結:http://www.cocoachina.com/ios/20141219/10694.html

參考連結: http://blog.csdn.net/openglnewbee/article/details/38824139