一井厌、dSYM符號(hào)表分析崩潰
在能夠獲取到dSYM符號(hào)表文件的情況下蚓庭，分析崩潰詳情請(qǐng)移步iOS crash 解析定位，shell腳本查找crash仅仆，
或者使用可視化工具分析崩潰 CJCrashTools
二器赞、無(wú)dSYM符號(hào)表文件崩潰分析
下面來(lái)講一下本文的重點(diǎn)：無(wú)dSYM符號(hào)表文件下的崩潰分析。
要是很不幸缺失了dSYM文件墓拜，但如果能夠獲取到崩潰日志以及對(duì)應(yīng)的.app文件的情況下港柜，那么我們同樣可以對(duì)崩潰詳情進(jìn)行分析。
獲取crash log崩潰日志
將iOS設(shè)備連接到電腦上咳榜，打開(kāi) Xcode -> Window -> Devices and Simulators -> Devices夏醉，找到該臺(tái)設(shè)備，點(diǎn)擊View Device Logs涌韩，在 This Device的崩潰日志列表中中找到對(duì)應(yīng)app的崩潰日志即可畔柔；也可以點(diǎn)擊右鍵，Export Log將日志導(dǎo)出（后綴為 .crash 的 log 文件）臣樱。
如果你的應(yīng)用已經(jīng)上架App Store靶擦，那么開(kāi)發(fā)者可以通過(guò)iTunes Connect（Manage Your Applications - View Details - Crash Reports）獲取用戶(hù)的crash log腮考。不過(guò)這并不是100%有效的，而且大多數(shù)開(kāi)發(fā)者并不依賴(lài)于此玄捕，因?yàn)檫@需要用戶(hù)設(shè)備同意上傳相關(guān)信息踩蔚，詳情可參見(jiàn)iOS: Providing Apple with diagnostics and usage information摘要。
第三方crash收集系統(tǒng)桩盲，甚至還帶了符號(hào)化crash日志的功能寂纪。比較常用的有Crashlytics，Flurry等赌结。
獲取.app文件
如果是Xcode debug模式下崩潰獲取.app文件：打開(kāi)Xcode捞蛋，找到項(xiàng)目工程Products文件夾下的編譯產(chǎn)物，右鍵Show in Finder柬姚，即可找到 CJTest.app (本文示例.app名為CJTest.app拟杉，后同)。
如果是導(dǎo)出ipa安裝之后的崩潰：修改.ipa后綴名為.zip量承，解壓之后進(jìn)入Payload文件夾搬设，同樣可以找到 CJTest.app 文件。注意如果是從App Store渠道獲取的ipa文件撕捍，那么必須先經(jīng)過(guò)砸殼處理拿穴！
.app文件瘦身（非必要步驟）
首先判斷崩潰日志是來(lái)自arm64還是其他機(jī)器，以及得到的.app是否集成多架構(gòu)忧风。
查看.app架構(gòu)默色，終端執(zhí)行：
lipo -info CJTest.app/CJTest
如果結(jié)果提示本身就只包含arm64，那么可以跳過(guò)本步驟了狮腿。
否則執(zhí)行以下指令進(jìn)行瘦身：
lipo -thin arm64 CJTest.app/CJTest -output CJTest_arm64
符號(hào)恢復(fù)工具restore-symbol
下載后修改權(quán)限
chmod a+x restore-symbol
恢復(fù)符號(hào)
./restore-symbol CJTest -o CJTest_symbol
# 如果是.app有經(jīng)過(guò)瘦身腿宰，則執(zhí)行
./restore-symbol CJTest_arm64 -o CJTest_arm64_symbol
最終得到恢復(fù)了符號(hào)表的二時(shí)制文件 CJTest_symbol。
另外如果運(yùn)行restore-symbol指令的過(guò)程中系統(tǒng)提示"無(wú)法打開(kāi)restore-symbol缘厢，因?yàn)闊o(wú)法驗(yàn)證開(kāi)發(fā)者“吃度，可通過(guò)以下步驟解決：打開(kāi)系統(tǒng)偏好設(shè)置選項(xiàng) — 點(diǎn)擊打開(kāi)安全性與隱私選項(xiàng) — 點(diǎn)擊上方的通用選項(xiàng) — 點(diǎn)擊選中下方的任何來(lái)源選項(xiàng)即可。
Bug位置定位
最后執(zhí)行指令贴硫，定位到最終的崩潰代碼椿每。
atos -arch arm64 -o CJTest_arm64_symbol -l 0x1045e8000 0x0000000105b8b738 0x0000000105b8b724
atos指令說(shuō)明：
# atos -arch ”CPU架構(gòu)“ -o “二進(jìn)制文件” -l “起始地址” “一系列內(nèi)存地址。夜畴。拖刃。”
-l 后面跟的是模塊的起始地址贪绘，然后后面可以羅列很多內(nèi)存地址，執(zhí)行命令后會(huì)依次解析出央碟，所羅列的內(nèi)存地址對(duì)應(yīng)的所有函數(shù)税灌。
對(duì)應(yīng)的崩潰日志快照說(shuō)明：
Binary Images表示的是app崩潰時(shí)程序加載的所有庫(kù)的快照均函，找到CJTest所在行，開(kāi)始的地址區(qū)間0x1045e8000 - 0x10658ffff代表的是程序崩潰時(shí)的內(nèi)存區(qū)間菱涤，其中起始地址為0x1045e8000苞也。其后是對(duì)應(yīng)的app二進(jìn)制文件名，架構(gòu)類(lèi)型arm64粘秆，再后面的尖括號(hào)里對(duì)應(yīng)的是uuid說(shuō)明如迟。
查看.app文件uuid指令：
dwarfdump —uuid xxx.app/xxx
