工作中難免或碰到crash，如果是開發(fā)環(huán)境，碰到簡單的crash還能重現(xiàn)下，如果不能重現(xiàn)的話，我們只能去分crash文件了。
首先看下面的crash問題，說句實(shí)話一看這個(gè)我是拒絕的，這怎么找原因啊，頭都大了。
68BFD825-BB35-4106-B030-772B9884FB82.png
1、 進(jìn)程信息
第一部分是閃退進(jìn)程的相關(guān)信息。
Incident Identifier ： 是崩潰報(bào)告的唯一標(biāo)識(shí)符。
CrashReporter Key： 是與設(shè)備標(biāo)識(shí)相對(duì)應(yīng)的唯一鍵值。雖然它不是真正的設(shè)備標(biāo)識(shí)符，但也是一個(gè)非常有用的情報(bào):如果你看到100個(gè)崩潰日志的CrashReporter Key值都是相同的，或者只有少數(shù)幾個(gè)不同的CrashReport值，說明這不是一個(gè)普遍的問題，只發(fā)生在一個(gè)或少數(shù)幾個(gè)設(shè)備上。
Hardware Model ：標(biāo)識(shí)設(shè)備類型。 如果很多崩潰日志都是來自相同的設(shè)備類型，說明應(yīng)用只在某特定類型的設(shè)備上有問題。上面的日志里，崩潰日志產(chǎn)生的設(shè)備是iPhone 4s。
接下來幾行不言自明，無需贅述。
(2) 基本信息
這部分給出了一些基本信息，包括閃退發(fā)生的日期和時(shí)間，設(shè)備的iOS版本。
(3) 異常
Exception Type:異常的類型。
Exception Codes ：異常錯(cuò)誤碼
Termination Reason：閃退的原因，比如常見的數(shù)組越界啊，什么的。
Triggered by Thread：出現(xiàn)問題在哪個(gè)線程，這個(gè)比較重要，首先確定在哪個(gè)線程中出了問題，然后再去定位。
(4) 線程回溯
這部分提供應(yīng)用中所有線程的回溯日志。 線程調(diào)用的一些，堆棧信息，壓根看不懂，所有需要進(jìn)行符號(hào)化處理。
用Xcode自帶的 symbolicatecrash 工具來解析的.crash文件
1、獲取crash文件：
a、直接從設(shè)備中獲取方法如下圖
屏幕快照 2016-09-21 下午9.16.49.png
b、蘋果審核那邊發(fā)給你的（我的就是）
2、找到app包所對(duì)應(yīng)的.dSYM文件，強(qiáng)調(diào)要對(duì)應(yīng)
.dSYM 是保存 16 進(jìn)制函數(shù)地址映射信息的中轉(zhuǎn)文件，我們調(diào)試的 symbols 都會(huì)包含在這個(gè)文件中，并且每次編譯項(xiàng)目的時(shí)候都會(huì)生成一個(gè)新的 dSYM 文件。測試給過來的.crash文件中，關(guān)于崩潰的確切語句和函數(shù)部分只有16進(jìn)制地址符號(hào)，并不是我們?cè)趚code調(diào)試時(shí)看到的xxx.cpp(xxfunction xx行)這樣的。一般發(fā)布一個(gè)版本需要保存好對(duì)應(yīng)的.dSYM和.app包，方便分析crash
屏幕快照 2016-09-21 下午9.21.56.png
3、就是找到Xcode中的symbolicatecrash工具咯，
我用的Xcode8，路徑為
/Applications/Xcode.app/Contents/SharedFrameworks/DVTFoundation.framework/Versions/A/Resources/symbolicatecrash
其他版本的xcode，自己百度咯，反正都差不多。把我們需要的工具直接復(fù)制到桌面上來（方便用）。
4、.crash文件的分析
a、.配置環(huán)境變量DEVELOPER_DIR，（配置好了就不再需要）
exportDEVELOPER_DIR=/Applications/Xcode.app/Contents/Developer
b、新建一個(gè)文件夾，將第二步中獲取的兩個(gè)文件放在同一個(gè)文件夾中
注意：上面指的是其所在的路徑。
經(jīng)過上面的簡單幾步我們就能得到格式化好的crash日志，這樣就方便我們定位bug的位置了。
