在 App 審核時，可能會出現類似下圖這種被拒的情況：
原來出現了閃退唠粥，這對于 App 是個致命的問題疏魏，要馬上修復。那么問題來了晤愧，我測試的時候沒有崩潰的問題呀大莫！我看不到 crash 的信息呀？我并不知道問題出現在哪里呀官份？
這時只厘，我們就要用到崩潰日志了烙丛，這里面包含了我們需要的內容。當你拿到崩潰日志的時候羔味，你看到的是這樣的東西：
頓時一臉懵逼河咽，感覺不會再愛了。
別急赋元，只需要做一些簡單的操作忘蟹，把它符號化之后就變成人看的東西了。
本文將從以下幾部分講述崩潰日志符號化：
- 什么是崩潰日志
- 什么是符號化
- 如何判斷符號化是否完成
- 如何獲取崩潰日志
- 如何符號化
- 使用 symbolicatecrash 符號化
- 使用 Xcode 符號化
什么是崩潰日志
概念部分我們來看一下相關的官方文檔搁凸。
When an application crashes, a crash report is created and stored on the device. Crash reports describe the conditions under which the application terminated, in most cases including a complete backtrace for each executing thread, and are typically very useful for debugging issues in the application. You should look at these crash reports to understand what crashes your application is having, and then try to fix them.
崩潰日志就是在 App 異常終止時媚值，生成的記錄運行環(huán)境、線程护糖、椚烀ⅲ回溯的用于調試的文件。
什么是符號化
Symbolication is the process of resolving backtrace addresses to source code method or function names, known as symbols. Without first symbolicating a crash report it is difficult to determine where the crash occurred.
符號化就是解決把椀樟迹回溯地址轉化為為源碼方法名或函數名的過程锰扶。
如何判斷符號化是否完成
A crash report may be unsymbolicated, fully symbolicated, or partially symbolicated. Unsymbolicated crash reports will not contain the method or function names in the backtrace. Instead, you have hexadecimal addresses of executable code within the loaded binary images. In a fully symbolicated crash report, the hexadecimal addresses in every line of the backtrace are replaced with the corresponding symbol. In a partially symbolicated crash report, only some of the addresses in the backtrace have been replaced with their corresponding symbols.
Obviously, you should try to fully symbolicate any crash report you receive as it will provide the most insight about the crash. A partially symbolicated crash report may contain enough information to understand the crash, depending upon the type of crash and which parts of the backtraces were successfully symbolicated. An unsymbolicated crash report is rarely useful.
符號化分為三個級別：未符號化、半符號化和全符號化：
| 級別 | 特點 | 是否有用 |
|---|---|---|
| 未符號化 | 全是十六進制地址 | 不是人給看的寝受，基本沒用 |
| 半符號化 | 部分十六進制地址少辣、部分方法名函數名 | 部分是給人看的，有點用 |
| 全符號化 | 全是方法名函數名 | 全都是給人看的羡蛾，特別有用 |
由此可見，全符號化才是最終的完成狀態(tài)锨亏。
如何獲取崩潰日志
- 審核時出現的問題痴怨，蘋果官方會把崩潰日志作為回復的附件，直接點擊下載即可器予。
- 從設備中獲取(有時已經是完全符號化狀態(tài)浪藻，可直接查看)
- 目標設備連接電腦 > 打開Xcode > Window > Devices (快捷鍵 shift + ? + 2)
- 選擇 View Devices Logs
- 在列表中選擇文件，右鍵選導出
如何符號化
本文介紹兩種方法乾翔，第一種相對第二種有些復雜爱葵，其實按步驟做也是很簡單的
- 使用 symbolicatecrash 符號化
symbolicatecrash 是蘋果官方提供的符號化工具，需要我們在終端輸入命令執(zhí)行反浓，在此之前還有一些準備工作萌丈。
- 在桌面創(chuàng)建文件夾，把 symbolicatecrash雷则、崩潰日志和 dSYM 文件放進去
首先辆雾，找到 symbolicatecrash，打開終端輸入：
find /Applications/Xcode.app -name symbolicatecrash -type f
會輸出 symbolicatecrash 的路徑位置(可能不一樣)
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/Library/PrivateFrameworks/DVTFoundation.framework/symbolicatecrash
拷貝 symbolicatecrash 文件到創(chuàng)建的文件夾中月劈。
然后度迂，查看崩潰日志文件的拓展名藤乙，如果是 .txt(蘋果審核時返回的是.txt文件)，修改為 .crash惭墓。
最后坛梁，找到崩潰日志對應的 dSYM 文件(dSYM 是保存十六進制函數地址映射信息的中轉文件，符號化過程中的十六進制函數地址對應的方法名函數名就保存在這個文件中)腊凶。
dSYM 文件在打好的包中：
· 打開 Organizer 面板：Xcode > Window > Organizer
· 選擇與崩潰日志版本對應的包划咐，右鍵 Show In Finder
· 選擇 xcarchive 文件，右鍵 顯示包內容
· dSYM 文件就在 dSYMs 文件夾里
Xcode 默認打包時不創(chuàng)建 dSYM 文件吭狡，需要在 Build Settings 設置 Debug Information Format 為 DWARF with sSYM File(如下圖)尖殃，否則 dSYMs 文件夾是空的。
2.查看 dSYM 文件的 uuid划煮，終端輸入下面的命令
dwarfdump --uuid dSYM文件路徑
得到如下輸出：
UUID: CD78BB00-BE55-3FC2-89AC-580437E54D36 (armv7) + 很長的路徑
UUID: AB0EC401-77B7-3FF6-BF99-567FA14A45FC (arm64) + 很長的路徑
3.對比崩潰日志中的 uuid 與 輸出的 uuid 是否一致
下面列出了崩潰日志中 Header 的部分信息：
{
"app_name": "XXXXXX",
"timestamp": "2017-06-03 02:15:01.50 +0800",
"app_version": "1.2.00",
"slice_uuid": "ab0ec401-77b7-3ff6-bf99-567fa14a45fc",
"adam_id": 1128617051,
"build_version": "1.0.1",
"share_with_app_devs": false,
"is_first_party": false,
"bug_type": "109",
"os_version": "iPhone OS 10.3.2 (14F89)",
"incident_id": "1DE9E3EF-D2DF-4A54-992A-1912BF8D285A",
"name": "XXXXXX"
}
Incident Identifier: 1DE9E3EF-D2DF-4A54-992A-1912BF8D285A
CrashReporter Key: 5abb1af3a567bd61ac640b7daf57c472c59d9547
Hardware Model: xxx
Version: 1.0.1 (1.2.00)
Code Type: ARM-64 (Native)
Role: Foreground
Parent Process: launchd [1]
這里我們需要關注兩個字段 "Code Type" 和 "slice_uuid"送丰，"Code Type"的類型為 ARM-64，所以從上一步輸出的 UUID 信息中弛秋，找到 arm64 類型對應的 UUID 為 "AB0EC401-77B7-3FF6-BF99-567FA14A45FC"器躏，對比 Header 信息中的 "slice_uuid"，如果不一致蟹略，說明生成崩潰日志的應用包與當前 dSYM 所在的包不同登失；如果一致，進行下一步挖炬。
4.執(zhí)行 symbolicatecrash 命令
終端 cd 到第1步創(chuàng)建的文件夾揽浙，先定義 DEVELOPER_DIR：
export DEVELOPER_DIR=/Applications/Xcode.app/Contents/Developer
執(zhí)行符號化：
./symbolicatecrash XXXX/XXXX/appName.crash XXXX/XXXX/appName.app.dSYM > customName.crash
命令執(zhí)行完成后，在文件夾中會多出一個 customName.crash 文件意敛，不出意外的話馅巷，這個就是完成符號化的崩潰日志。
PS：這個命令中 .crash 文件的路徑一定要在 .dSYM 文件路徑之前草姻，否則會符號化失數鲡；路徑可以簡化為 ./撩独，生成的文件拓展名也可以為 log敞曹、txt等
./symbolicatecrash ./appName.crash ./appName.app.dSYM > customName.log
5.查資料的時候，有些文章上說用 symbolicatecrash 符號化還需要應用的 .app 文件综膀，我沒有把這個文件放到創(chuàng)建的文件夾中澳迫，符號化也成功了，如果大家在操作的時候出現了什么問題剧劝，可以先試試復制一份 .app 文件到文件夾中纲刀，再執(zhí)行命令。
應用的 .app 文件，在打包后導出的 .ipa 文件里示绊。把 .ipa 文件的拓展名改成 .zip锭部，解壓打開，在 Payload 文件夾中面褐。
- 使用 Xcode 符號化
這種方式比較簡單拌禾，具體操作如下：
首先，處理崩潰日志的拓展名如果不是 .crash 需要改成 .crash展哭。
然后湃窍，設備連接電腦 > 打開Xcode > Window > Devices (快捷鍵 shift + ? + 2)，選擇 View Devices Logs
最后匪傍，把崩潰日志拽到左側的列表中您市，Xcode 就會自動符號化。
當然役衡，這種方式也要滿足一定條件這茵休，如 Mac 中要有應用的二進制文件和 dSYM 文件。
To symbolicate a crash report, Xcode needs to be able to locate the following:
·The crashing application's binary and dSYM file.
·The binaries and dSYM files for all custom frameworks that the application links against. For frameworks that were built from source with the application, their dSYM files are copied into the archive alongside the application's dSYM file. For frameworks that were built by a third-party, you will need to ask the author for the dSYM file.
結果對比分析
完成符號化之后手蝎，我們來對比一下未符號化和全符號化的崩潰日志榕莺，還有 Xcode 控制臺打印的關鍵信息(只截取部分信息)。
由此可見棵介，正如前面所說钉鸯，符號化完成后，崩潰日志中所有的十六進制地址都轉化為了方法名函數名邮辽，而且與控制臺打印的內容基本一致唠雕。
定位崩潰問題主要看 Last Exception Backtrace 部分，如紅框所示吨述，在 NSException 拋出異常之前岩睁，應用正在進行字符串截取，所以可能是字符串為空或 index 越界導致的锐极。
關于崩潰日志符號化的操作就講這么多。
第一次寫東西灵再，寫得不是很好，如有問題歡迎指正亿笤。
**若有轉載翎迁，請注明出處，謝謝~ **
