命令行工具解析Crash文件,dSYM文件進行符號化

備份

 

文／愛掏蜂窩的熊（簡書做者）
原文連接：http://www.jianshu.com/p/0b6f5148dab8
著做權歸做者全部，轉載請聯繫做者得到受權，並標註「簡書做者」。

序

在平常開發中，app不免會發生崩潰。簡單的崩潰還好說，複雜的崩潰就須要咱們經過解析Crash文件來分析了，解析Crash文件在iOS開發中是比較常見的。

獲取崩潰信息方式

在iOS中獲取崩潰信息的方式有不少，比較常見的是使用友盟、雲測、百度等第三方分析工具，或者本身收集崩潰信息並上傳公司服務器。
下面列舉一些咱們經常使用的崩潰分析方式：

• 使用友盟、雲測、百度等第三方崩潰統計工具。
• 本身實現應用內崩潰收集，並上傳服務器。
• Xcode-Devices中直接查看某個設備的崩潰信息。
• 使用蘋果提供的Crash崩潰收集服務。（少用）

收集崩潰信息

蘋果給咱們提供了異常處理的類，NSException類。這個類能夠建立一個異常對象，也能夠經過這個類獲取一個異常對象。

這個類中咱們最經常使用的仍是一個獲取崩潰信息的C函數，咱們能夠經過這個函數在程序發生異常的時候收集這個異常。

// 將系統提供的獲取崩潰信息函數寫在這個方法中，以保證在程序開始運行就具備獲取崩潰信息的功能 - (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions { // 將下面C函數的函數地址當作參數 NSSetUncaughtExceptionHandler(&UncaughtExceptionHandler); return YES; } // 設置一個C函數，用來接收崩潰信息 void UncaughtExceptionHandler(NSException *exception){ // 能夠經過exception對象獲取一些崩潰信息，咱們就是經過這些崩潰信息來進行解析的，例以下面的symbols數組就是咱們的崩潰堆棧。 NSArray *symbols = [exception callStackSymbols]; NSString *reason = [exception reason]; NSString *name = [exception name]; }

咱們也能夠經過下面方法獲取崩潰統計的函數指針：

NSUncaughtExceptionHandler *handler = NSGetUncaughtExceptionHandler();

dSYM 符號集

• 符號集是咱們對ipa文件進行打包以後，和.app文件同級的後綴名爲.dSYM的文件，這個文件必須使用Xcode進行打包纔有。
• 每個.dSYM文件都有一個UUID，和.app文件中的UUID對應，表明着是一個應用。而.dSYM文件中每一條崩潰信息也有一個單獨的UUID，用來和程序的UUID進行校對。
• 咱們若是不使用.dSYM文件獲取到的崩潰信息都是不許確的。
• 符號集中存儲着文件名、方法名、行號的信息，是和可執行文件的16進制函數地址對應的，經過分析崩潰的.Crash文件能夠準確知道具體的崩潰信息。

咱們每次Archive一個包以後，都會隨之生成一個dSYM文件。每次發佈一個版本，咱們都須要備份這個文件，以方便之後的調試。進行崩潰信息符號化的時候，必須使用當前應用打包的電腦所生成的dSYM文件，其餘電腦生成的文件可能會致使分析不許確的問題。

Archive.png

當程序崩潰的時候，咱們能夠得到到崩潰的錯誤堆棧，可是這個錯誤堆棧都是0x開頭的16進制地址，須要咱們使用Xcode自帶的symbolicatecrash工具來將.Crash和.dSYM文件進行符號化，就能夠獲得詳細崩潰的信息。

崩潰分析

• 命令行解析Crash文件

經過Mac自帶的命令行工具解析Crash文件須要具有三個文件

• symbolicatecrash，Xcode自帶的崩潰分析工具，使用這個工具能夠更精確的定位崩潰所在的位置，將0x開頭的地址替換爲響應的代碼和具體行數。
• 咱們打包時產生的dSYM文件。
• 崩潰時產生的Crash文件,例如：*.crash。

我在解析崩潰信息的時候，首先在桌面上創建一個Crash文件夾，而後將.Crash、.dSYM、symbolicatecrash放在這個文件夾中，這樣進入這個文件夾下，直接一行命令就解決了。

symbolicatecrash咱們能夠在下面路徑下能夠找到，我用的是Xcode7，其餘版本Xcode路徑不同，請自行Google。

/Applications/Xcode.app/Contents/SharedFrameworks/DTDeviceKitBase.framework/Versions/A/Resources/symbolicatecrash

選中archive的版本右擊，選擇Show in Finder就能夠選中archived 文件而後顯示包內容，就能夠找到dSYM文件了。

dsym文件位置.png

將.Crash、.dSYM、symbolicatecrash三個文件都放在咱們在桌面創建的Crash文件夾中。

crash.png

進行解析的工做

開啓命令行工具，進入崩潰文件夾crash中

cd /Users/本身MacPro上的名字/Desktop/崩潰文件夾crash

使用命令解析Crash文件，*號指的是具體的文件名

./symbolicatecrash ./*.crash ./*.app.dSYM > symbol.crash

若是上面命令不成功，使用命令檢查一下環境變量

xcode-select -print-path

返回結果：

/Applications/Xcode.app/Contents/Developer/

若是不是上面的結果，須要使用下面命令設置一下導出的環境變量，而後重複上面解析的操做。（這一步很重要）

export DEVELOPER_DIR=/Applications/XCode.app/Contents/Developer

解析完成後會生成一個新的.Crash文件，這個文件中就是崩潰詳細信息。圖中紅色標註的部分就是咱們代碼崩潰的部分。

result.png

注意，如下狀況不會有崩潰信息產生：

• 內存訪問錯誤(不是野指針錯誤)
• 低內存，當程序內存使用過多會形成系統低內存的問題，系統會將程序內存回收
• 由於某種緣由觸發看門狗機制

經過Xcode查看設備崩潰信息

除了上面的系統分析工具來進行分析，若是是咱們本身直接使用手機鏈接崩潰或者崩潰以後鏈接手機，選擇window－> devices －> 選擇本身的手機 -> view device logs 就能夠查看咱們的崩潰信息了。

deviceLog.png

只要手機上的應用是這臺電腦安裝打包的，這樣的崩潰信息系統已經爲咱們符號化好了，咱們只須要進去以後等一會就行(不要相信這裏面的進度刷新，並不許確)，若是仍是沒有符號化完畢 ，咱們選擇文件，而後右擊選擇Re-Sysbomlicate就能夠。

若是是使用其餘電腦進行的打包，咱們能夠在這裏面將Crash文件導出，本身經過命令行的方式進行解析。