一貌矿、符號(hào)表
1示括、概念：debugger Symbols 的簡(jiǎn)稱秘通。符號(hào)表就是指在Xcode項(xiàng)目編譯后为严，在編譯生成的.app的同級(jí)目錄下生成的同名的.dSYM文件。
符號(hào)表是內(nèi)存地址與函數(shù)名肺稀，文件名第股，行號(hào)的映射表。 符號(hào)表元素如下所示:
<起始地址> <結(jié)束地址> <函數(shù)> [<文件名:行號(hào)>]
.dSYM文件其實(shí)是一個(gè)目錄话原，在子目錄中包含了一個(gè)16進(jìn)制的保存函數(shù)地址映射信息的中轉(zhuǎn)文件夕吻，所有Debug的symbols都在這個(gè)文件中(包括文件名、函數(shù)名繁仁、行號(hào)等)涉馅，所以也稱之為調(diào)試符號(hào)信息文件。
2黄虱、作用：符號(hào)表就是用來(lái)符號(hào)化 crash log（崩潰日志）稚矿。crash log中有一些方法16進(jìn)制的內(nèi)存地址等，通過(guò)符號(hào)表就能找到對(duì)應(yīng)的能夠直觀看到的方法名之類捻浦。
3晤揣、獲取途徑：在Archive的時(shí)候會(huì)生成.xcarchive文件，然后顯示包內(nèi)容就能夠在里面找到.dsYM文件和.app文件朱灿。
- 一般Xcode項(xiàng)目每次編譯后, 都會(huì)產(chǎn)生一個(gè)新的.dSYM文件和.app文件, 這兩者有一個(gè)共同的UUID.
- 注:項(xiàng)目編譯完dSYM文件和app文件在同一個(gè)目錄昧识，Xcode Debug 編譯默認(rèn)不會(huì)生成.dSYM文件, Release 編譯才會(huì)生成
- 注:為了方便找回Crash對(duì)應(yīng)的dSYM文件和還原堆棧，建議每次構(gòu)建或者發(fā)布APP版本的時(shí)候盗扒，備份好dSYM文件跪楞。
二缀去、符號(hào)化文件
1、 Xcode分析
1>甸祭、要使用Xcode符號(hào)化 crash log朵耕，你需要下面所列的3個(gè)文件：
①crash報(bào)告（.crash文件）
②符號(hào)文件 (.dsymb文件)
③應(yīng)用程序文件 (.app文件）
2>、把這3個(gè)文件放到同一個(gè)目錄下淋叶，打開Xcode的Window菜單下的organizer，然后點(diǎn)擊Devices tab伪阶，然后選中左邊的Device Logs煞檩。
然后把.crash文件拖到Device Logs或者選擇下面的import導(dǎo)入.crash文件。
這樣你就可以看到crash的詳細(xì)log了栅贴。
2斟湃、使用命令行工具symbolicatecrash
1>、將“.app“, “.dSYM”和 ".crash"文件放到同一個(gè)目錄./Crash 下檐薯。
2>凝赛、在Xcode中找到 symbolicatecrash 工具
使用命令
find /Applications/Xcode.app -name symbolicatecrash -type f
可以輕松找到。找到后你會(huì)發(fā)現(xiàn)有多個(gè)其中
/Applications/Xcode.app/Contents/SharedFrameworks/DVTFoundation.framework/Versions/A/Resources/symbolicatecrash
對(duì)應(yīng)的是真機(jī), 找到后將 symbolicatecrash 拷貝到 ./Crash 目錄下
3>坛缕、切換到 ./Crash目錄下墓猎。 打開終端(Terminal)然后輸入如下的命令：
export DEVELOPER_DIR=/Applications/Xcode.app/Contents/Developer
然后輸入命令：
./symbolicatecrash appName.crash appName.app > appName.log
現(xiàn)在，符號(hào)化的crash log就保存在appName.log中了赚楚。
如果報(bào)No such file or directory : at ./symbolicatecrash line 909.錯(cuò)誤毙沾，嘗試執(zhí)行
./symbolicatecrash ./*.crash ./*.app.dSYM>Symbol_Crash.crash
3、atos
- atos 是一個(gè)可以把地址轉(zhuǎn)換為函數(shù)名（包括行號(hào)）的工具, 它和dwarfdump 為mac os自帶工具.
我們使用atos命令來(lái)完成符號(hào)化宠页，具體命令如下：
$ atos -arch <Binary Architecture> -o <Path to dSYM file>/Contents/Resources/DWARF/<binary image name> -l <load address> <address to symbolicate>
其中:
- Binary Architecture: arm64左胞、armv6、armv7 armv7s 根據(jù)自己的情況來(lái)寫举户。
- Path to dSYM file: dSYM文件的路徑烤宙。
- binary image name: 你工程的名字。
- load address: 是運(yùn)行時(shí)起始地址（基地址）俭嘁，如果我們的崩潰日志中沒(méi)有這個(gè)信息(比如上面的Crash信息中就沒(méi)有包含)躺枕，就需要我們手動(dòng)去計(jì)算這個(gè)load * address:laod address = address to symbolicate - offset,比如：0x0000000102838119轉(zhuǎn)化為十進(jìn)制為4337139993,再減去偏移量265,為4337139728,在轉(zhuǎn)化為十六進(jìn)制0x0000000102838010
- address to symbolicate:運(yùn)行時(shí)堆棧地址，當(dāng)前方法的內(nèi)存地址兄淫。
具體示例：
atos -arch arm64 -o CrashDemo.app.dSYM/Contents/Resources/DWARF/CrashDemo -l 0x0000000102838010 0x0000000102838119
這樣crash文件就被符號(hào)化完成了屯远，打開符號(hào)化如下圖：
三、Crash分析
以上圖為例捕虽，大部分字段都是不言而喻的慨丐，下面列舉一些有用處的。（在官方文檔都有解釋泄私，這里做歸納與翻譯）
Incident Identifier： 報(bào)告的唯一標(biāo)識(shí)符房揭，兩份報(bào)告決不會(huì)共享同一個(gè)事件標(biāo)識(shí)符备闲。
CrashReporter Key：每個(gè)設(shè)備的匿名標(biāo)識(shí)符，來(lái)自同一設(shè)備的兩個(gè)報(bào)告將包含相同的值捅暴。
Process：很明顯是我們的進(jìn)程名稱恬砂。
Date/Time 與 Launch Time：報(bào)告生成時(shí)間與程序開始運(yùn)行時(shí)間
Exception Type：異常類型
Exception Note：不屬于異常類型的附加信息，如果這個(gè)字段包含SIMULATED(不是崩潰)蓬痒，那這個(gè)進(jìn)程不是崩潰的泻骤，而是在系統(tǒng)的請(qǐng)求下被殺死，通常是看門狗機(jī)制起了作用（APP內(nèi)一段時(shí)間內(nèi)無(wú)法響應(yīng)用戶的操作梧奢，會(huì)被系統(tǒng)kill）狱掂。
Termination Reason：閃退的原因，比如常見(jiàn)的數(shù)組越界啊亲轨，什么的趋惨。
Triggered by Thread：出現(xiàn)問(wèn)題在哪個(gè)線程，這個(gè)比較重要惦蚊，首先確定在哪個(gè)線程中出了問(wèn)題器虾，然后再去定位。
接著是最重要的堆棧信息蹦锋，由下到上為最后調(diào)用的順序：
可以很明顯的看到兆沙，一個(gè)名為ViewController的對(duì)象在viewDidLoad方法中調(diào)用了第35行的testMethodTwo方法，并執(zhí)行testMethodTwo方法中的61行時(shí)代碼莉掂，在Backtrace第2行可以發(fā)現(xiàn)調(diào)用了未識(shí)別的方法導(dǎo)致崩潰挤悉，我們來(lái)看下代碼。
最終我們找到了崩潰的原因：一個(gè)NSArray調(diào)用了addObject方法巫湘，so easy!
一些較常見(jiàn)的異常類型（如果翻譯錯(cuò)誤請(qǐng)指正）：
內(nèi)存訪問(wèn)不良[EXC_BAD_ACCESS // SIGSEGV // SIGBUS]
通常用于訪問(wèn)了不該訪問(wèn)的內(nèi)存導(dǎo)致或者嘗試以不允許的方式訪問(wèn)內(nèi)存（例如只讀屬性装悲，比如在上一篇我們提到的通過(guò)KVO更改只讀屬性），并且" Exception SubType"字段會(huì)包含kern_return_t來(lái)描述錯(cuò)誤和未正確訪問(wèn)的內(nèi)存地址尚氛。
下面是官方給出的建議：
- 如果
objc_msgSend或objc_release接近崩潰線程的Backtraces(堆棧信息回溯)的頂部诀诊，則該進(jìn)程可能試圖向釋放的對(duì)象發(fā)送消息，可以使用Zombie Instrument來(lái)分析應(yīng)用程序阅嘶，以更好地了解此次崩潰的情況属瓣。- 如果
gpus_ReturnNotPermittedKillClient接近崩潰線程的Backtraces的頂部，則該進(jìn)程被終止讯柔，因?yàn)樗鼑L試在后臺(tái)使用OpenGL ES或Metal進(jìn)行渲染抡蛙。
異常退出[EXC_CRASH // SIGABRT]
該進(jìn)程異常退出，此異常類型崩潰的最常見(jiàn)原因是向?qū)ο蟀l(fā)送了無(wú)法識(shí)別的消息魂迄，比如上文中向NSArray發(fā)送了addObject消息粗截。
另外如果App Extensions需要太多時(shí)間來(lái)初始化（看門狗機(jī)制），那么App Extensions將終止于此異常類型捣炬，如果擴(kuò)展因啟動(dòng)時(shí)掛起而死亡熊昌，則生成的崩潰報(bào)告的Exception Subtype將會(huì)是LAUNCH_HANG绽榛，由于擴(kuò)展沒(méi)有main函數(shù)，任何花在初始化上的時(shí)間都會(huì)在+load擴(kuò)展庫(kù)和相關(guān)庫(kù)中的靜態(tài)構(gòu)造函數(shù)和方法中婿屹，你應(yīng)該盡可能多地推遲這項(xiàng)工作灭美。
資源限制[EXC_RESOURCE]
該過(guò)程超出了資源消耗限制，這是來(lái)自操作系統(tǒng)的通知昂利，該進(jìn)程正在使用太多的資源,確切的資源列在Exception SubType字段中届腐。如果Exception Note字段包含
NON-FATAL CONDITION，則即使生成崩潰報(bào)告蜂奸，該進(jìn)程也不會(huì)被終止梯捕。
- 異常子類型
MEMORY表示該進(jìn)程已超過(guò)系統(tǒng)施加的內(nèi)存限制。- 異常子類型
WAKEUPS表示進(jìn)程中的線程每秒被喚醒的次數(shù)過(guò)多窝撵，這迫使CPU醒來(lái)的頻率很高，并且消耗電池壽命襟铭。
四碌奉、符號(hào)化dSYM常見(jiàn)問(wèn)題
如何查看dsYM文件的UUID?
方法一： 通過(guò)命令行查看dSYM文件的UUID
xcrun dwarfdump --uuid <dSYM文件>
方法二：通過(guò)符號(hào)表文件查看UUID
符號(hào)表文件的UUID與dSYM文件的UUID是一致的，因此可以通過(guò)符號(hào)表工具生成的符號(hào)表文件來(lái)查看dSYM文件的UUID：
生成符號(hào)表文件(.zip) ---> 解壓符號(hào)表文件(.symbol) ---> 使用文本編輯器打開符號(hào)表文件
其中符號(hào)表文件的“UUID”信息即Debug SO文件的UUID寒砖，亦是符號(hào)表文件的UUID赐劣，如果文件較大，建議使用“Sublime Text”等文本編輯器來(lái)打開符號(hào)表文件哩都。
如何定位dSYM文件魁兼？
一般情況下，項(xiàng)目編譯完dSYM文件跟app文件在同一個(gè)目錄下漠嵌，下面以XCode作為IDE詳細(xì)說(shuō)明定位dSYM文件咐汞。
-> 進(jìn)入XCode；
-> 打開工程（已編譯過(guò)）儒鹿；
-> 在左欄找到“Product”項(xiàng)化撕；
-> 鼠標(biāo)右鍵點(diǎn)擊編譯生成的“xxx.app”；
-> 點(diǎn)擊“Show in Finder”约炎；
如下圖所示：
如果有多個(gè)dSYM文件植阴，可以在使用工具時(shí)指定輸入為dSYM文件所在的目錄或者工程目錄。
Xcode編譯后沒(méi)有生成dSYM文件圾浅？
XCode Release編譯默認(rèn)會(huì)生成dSYM文件掠手，而Debug編譯默認(rèn)不會(huì)生成，對(duì)應(yīng)的Xcode配置如下：
XCode -> Build Settings -> Code Generation -> Generate Debug Symbols -> Yes
XCode -> Build Settings -> Build Option -> Debug Information Format -> DWARF with dSYM File
開啟Bitcode之后需要注意哪些問(wèn)題狸捕？
-
在點(diǎn)“Upload to App Store”上傳到App Store服務(wù)器的時(shí)候需要聲明符號(hào)文件（dSYM文件）的生成：
在配置符號(hào)表文件之前喷鸽，需要從App Store中把該版本對(duì)應(yīng)的dSYM文件下載回本地（參考“如何找回已發(fā)布到App Store的App對(duì)應(yīng)的dSYM文件？”）灸拍，然后用符號(hào)表工具生成和上傳符號(hào)表文件魁衙。
不需要配置自動(dòng)生成符號(hào)表的腳本了报腔，也不要用本地生成的dSYM文件來(lái)生成符號(hào)表文件，因?yàn)楸镜鼐幾g生成的dSYM文件的符號(hào)表信息都被隱藏了剖淀。如果用本地編譯生成的dSYM文件生成符號(hào)表文件并配置到Bugly平臺(tái)之后纯蛾，還原出來(lái)的結(jié)果將是類似于“__hiden#XXX”這樣的符號(hào)。
如何判斷dSYM文件是否與Crash的UUID匹配纵隔？
Bugly還原Crash堆棧時(shí)翻诉，需要根據(jù)UUID來(lái)匹配符號(hào)表文件，因此只有上傳的符號(hào)表文件的UUID與Crash對(duì)應(yīng)APP的UUID一致時(shí)捌刮，才能準(zhǔn)確地對(duì)堆棧進(jìn)行還原碰煌。
查看符號(hào)表文件的UUID（“如何查看dSYM文件的UUID？”）
查看Crash對(duì)應(yīng)的APP的UUID
如何找回已發(fā)布到App Store的App對(duì)應(yīng)的dSYM文件绅作？
1> 通過(guò)Xcode找回
- 打開 Xcode 頂部菜單欄 -> Window -> Organizer 窗口：
- 打開 Xcode 頂部菜單欄芦圾，選擇 Archive 標(biāo)簽：
-
找到發(fā)布的歸檔包，右鍵點(diǎn)擊對(duì)應(yīng)歸檔包俄认，選擇Show in Finder操作：
右鍵選擇定位到的歸檔文件个少，選擇顯示包內(nèi)容操作：
- 選擇dSYMs目錄，目錄內(nèi)即為下載到的 dSYM 文件：
2>通過(guò)mdfind工具找回
在Bugly的issue頁(yè)面查詢到crash對(duì)應(yīng)的UUID：
然后在Mac的Shell中眯杏，用mdfind命令定位dSYM文件：
mdfind "com_apple_xcode_dsym_uuids == <UUID>"
注意夜焦，使用mdfind時(shí)，UUID需要格式轉(zhuǎn)換（增加“-”）： 12345678-1234-1234-1234-xxxxxxxxxxxx
例如岂贩，要定位的dSYM的UUID為：E30FC309DF7B3C9F8AC57F0F6047D65F 則定位dSYM文件的命令如下：
mdfind "com_apple_xcode_dsym_uuids == E30FC309-DF7B-3C9F-8AC5-7F0F6047D65F"
|12345678-1234-1234-1234-xxxxxxxxxxxx|
建議每次構(gòu)建或者發(fā)布APP版本的時(shí)候茫经，備份App對(duì)應(yīng)的dSYM文件！
參考:
iOS開發(fā)符號(hào)表(dSYM)知識(shí)總結(jié)
bugly文檔
iOS Crash收集與分析詳解（基礎(chǔ)篇）
iOS Crash監(jiān)測(cè)及處理上傳
