轉關於iOS--Crash日誌的分析

工做中不免或碰到crash，若是是開發環境，碰到簡單的crash還能重現下，若是不能重現的話，咱們只能去分crash文件了。

首先看下面的crash問題，說句實話一看這個我是拒絕的，這怎麼找緣由啊，頭都大了。

68BFD825-BB35-4106-B030-772B9884FB82.png

一、 進程信息
第一部分是閃退進程的相關信息。

Incident Identifier ： 是崩潰報告的惟一標識符。

CrashReporter Key： 是與設備標識相對應的惟一鍵值。雖然它不是真正的設備標識符，但也是一個很是有用的情報:若是你看到100個崩潰日誌的CrashReporter Key值都是相同的，或者只有少數幾個不一樣的CrashReport值，說明這不是一個廣泛的問題，只發生在一個或少數幾個設備上。

Hardware Model ：標識設備類型。 若是不少崩潰日誌都是來自相同的設備類型，說明應用只在某特定類型的設備上有問題。上面的日誌裏，崩潰日誌產生的設備是iPhone 4s。

接下來幾行不言自明，無需贅述。

(2) 基本信息
這部分給出了一些基本信息，包括閃退發生的日期和時間，設備的iOS版本。
(3) 異常
Exception Type:異常的類型。
Exception Codes ：異常錯誤碼
Termination Reason：閃退的緣由，好比常見的數組越界啊，什麼的。
Triggered by Thread：出現問題在哪一個線程，這個比較重要，首先肯定在哪一個線程中出了問題，而後再去定位。

(4) 線程回溯

這部分提供應用中全部線程的回溯日誌。 回溯是閃退發生時全部活動幀清單。它包含閃退發生時調用函數的清單。看下面這行日誌:

2 XYZLib 0x34648e88 0x83000 + 8740

它包括四列:

1. 幀編號—— 此處是2。
2. 二進制庫的名稱 ——此處是 XYZLib.
3. 調用方法的地址 ——此處是 0x34648e88.
4. 第四列分爲兩個子列，一個基本地址和一個偏移量。此處是0×83000 + 8740, 第一個數字指向文件，第二個數字指向文件中的代碼行。

 

 

用Xcode自帶的 symbolicatecrash 工具來解析的.crash文件

一、獲取crash文件：
a、直接從設備中獲取方法以下圖

屏幕快照 2016-09-21 下午9.16.49.png

 

b、蘋果審覈那邊發給你的（個人就是）

二、找到app包所對應的.dSYM文件，強調要對應
.dSYM 是保存 16 進制函數地址映射信息的中轉文件，咱們調試的 symbols 都會包含在這個文件中，而且每次編譯項目的時候都會生成一個新的 dSYM 文件。測試給過來的.crash文件中，關於崩潰的確切語句和函數部分只有16進制地址符號，並非咱們在xcode調試時看到的xxx.cpp(xxfunction xx行)這樣的。通常發佈一個版本須要保存好對應的.dSYM和.app包，方便分析crash

屏幕快照 2016-09-21 下午9.21.56.png

 

三、就是找到Xcode中的symbolicatecrash工具咯，

我用的Xcode8，路徑爲

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

其餘版本的xcode，本身百度咯，反正都差很少。把咱們須要的工具直接複製到桌面上來（方便用）。

四、.crash文件的分析
a、.配置環境變量DEVELOPER_DIR，（配置好了就再也不須要）

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

b、新建一個文件夾，將第二步中獲取的兩個文件放在同一個文件夾中

QQ20160921-0.png

QQ20160921-1.png

注意：上面指的是其所在的路徑。

通過上面的簡單幾步咱們就能獲得格式化好的crash日誌，這樣就方便咱們定位bug的位置了。

原文連接：http://www.jianshu.com/p/e616d094cf65