一、前言：
作為一個合格的iOS開發者，除了具有規范強悍的編碼能力外，還應該具有過硬的查錯糾錯能力。在項目運行時，程序崩潰是不可避免的，遇到這個問題，有時會出現一大堆的crash日志，艹，貌似看不懂呀。其實沒有那么可怕，我們可以將這些日志格式化，通過它來快速定位問題的所在，以便迅速搞定它。
二、分析：
首先我們來看一個crash日志，大略的介紹其中的幾個重要的關鍵詞：
關鍵詞解釋：
2.1、 進程信息
第一部分是閃退進程的相關信息：
Incident Identifier ： 是崩潰報告的唯一標識符。
CrashReporter Key： 是與設備標識相對應的唯一鍵值。雖然它不是真正的設備標識符，但也是一個非常有用的情報:如果你看到100個崩潰日志的CrashReporter Key值都是相同的，或者只有少數幾個不同的CrashReport值，說明這不是一個普遍的問題，只發生在一個或少數幾個設備上。
Hardware Model ：標識設備類型。 如果很多崩潰日志都是來自相同的設備類型，說明應用只在某特定類型的設備上有問題。上面的日志里，崩潰日志產生的設備是iPhone 4s。
Process：對項目的操作權限，上面的是可讀可寫
Path:崩潰文件的路徑
Identifier:項目標識符，就是Bundle Id
Version:版本號
.....等等.......
2.2、基本信息
這部分給出了一些基本信息，包括閃退發生的日期Date/Time和時間Launch Time，設備的iOS版本OS Version等。
2.3、異常信息
Exception Type:異常的類型。
Exception Codes ：異常錯誤碼
Termination Reason：閃退的原因，比如常見的數組越界啊，什么的。
Triggered by Thread：出現問題在哪個線程，這個比較重要，首先確定在哪個線程中出了問題，然后再去定位。
2.4、線程回溯
這部分提供應用中所有線程的回溯日志。 線程調用的一些，堆棧信息，壓根看不懂，所有需要進行符號化處理。
三、解析崩潰日志
用Xcode自帶的 symbolicatecrash 工具來解析的.crash文件
3.1、獲取crash文件：
a.直接從設備中獲取方法如下圖
b.如果產品在上架過程中發生崩潰，蘋果那邊的測試人員給我們直接發送過來已經整理好的崩潰日志文件，只需要根據其解決問題就行。
3.2、找到app包所對應的.dSYM文件。
強調要對應.dSYM 是保存 16 進制函數地址映射信息的中轉文件，我們調試的 symbols 都會包含在這個文件中，並且每次編譯項目的時候都會生成一個新的 dSYM 文件。測試給過來的.crash文件中，關於崩潰的確切語句和函數部分只有16進制地址符號，並不是我們在xcode調試時看到的xxx.cpp(xxfunction xx行)這樣的。一般發布一個版本需要保存好對應的.dSYM和.app包，方便分析crash。如圖所示：
3.3、就是找到Xcode中的symbolicatecrash工具咯，本人用的Xcode8，路徑為：
/Applications/Xcode.app/Contents/SharedFrameworks/DVTFoundation.framework/Versions/A/Resources/symbolicatecrash
其他版本的xcode，自己百度咯，反正都差不多。把我們需要的工具直接復制到桌面上來（方便用）。
3.4、.crash文件的分析
a.配置環境變量DEVELOPER_DIR，（配置好了就不再需要）
export DEVELOPER_DIR=/Applications/Xcode.app/Contents/Developer
b.新建一個文件夾，將第二步中獲取的兩個文件放在同一個文件夾中
注意：上面指的是其所在的路徑。經過上面的簡單幾步我們就能得到格式化好的crash日志，這樣就方便我們定位bug的位置了。