最近分析了一波上傳的crash日志骏掀，方法和iOS的幾乎一模一樣鸠澈，畢竟都是蘋(píng)果的東西。這里對(duì)于一些基礎(chǔ)的crash日志里面的信息不作解釋?zhuān)唤榻B如何符號(hào)化crashlog獲取具體的崩潰代碼位置,方便以后自己查閱截驮。第一次寫(xiě)文章水平有限笑陈，有不對(duì)的地方希望大家指出，共同學(xué)習(xí)葵袭，共同進(jìn)步涵妥！
首先需要獲取你發(fā)布產(chǎn)品的dSYM文件，如果你上線(xiàn)的產(chǎn)品是在本地打包的話(huà)坡锡，最好保存一份Xcode生成的.dSYM文件蓬网。如果是統(tǒng)一用服務(wù)器打包的話(huà)窒所，應(yīng)該會(huì)保存有一份.dSYM文件，例如上傳到192.../** 文件夾下帆锋，如果沒(méi)有吵取，建議錘死搭建環(huán)境的人。
接下來(lái)锯厢，打開(kāi)crash文件皮官，查看是否已經(jīng)符號(hào)化。crash文件大體分為3種：Unsymbolicated（未符號(hào)化）实辑、Partially Symbolicated（半符號(hào)化）和 Fully Symbolicated（符號(hào)化）臣疑。
一般我們拿到的.crash都是Unsymbolicated。在符號(hào)化之前徙菠，首先確保.crash文件相關(guān)崩潰模塊的uuid和相關(guān)崩潰模塊的.dSYM的uuid一致讯沈，這樣得到的結(jié)果才是準(zhǔn)確的。這里為什么說(shuō)相關(guān)崩潰模塊呢婿奔，稍后再做解析缺狠。
dwarfdump獲取uuid
通過(guò)dwarfdump --uuid <Path to dSYM file>得到.dSYM的uuid(<>不需要)。例如得到的uuid：17D96A43-531E-3E3C-9399-A7D1FCCD015F萍摊。這個(gè)和.crash上的uuid：17d96a43531e3e3c9399a7d1fccd015f一致挤茄，所以我們可以獲得正確的偏移結(jié)果。
那么怎么看.crash 文件崩潰模塊的uuid呢冰木？如下圖：
其中TheElements即為崩潰的模塊穷劈，app可能由多個(gè)framework，多個(gè)bundle組成踊沸，所以TheElements有可能就是你的app名字歇终，也有可能是某個(gè)bundle或者某個(gè)framework的名字。所以剛才說(shuō)：相關(guān)崩潰模塊的uuid和相關(guān)崩潰模塊的.dSYM的uuid逼龟。
dwarfdump獲取具體崩潰代碼信息
a.獲取符號(hào)表中的TEXT段起始地址
$otool -l <Path to dSYM file>/Contents/Resources/DWARF/<binary image name>
找到如下的運(yùn)行結(jié)果：
Load command 2
cmd LC_SEGMENT_64
cmdsize 1032
segname __TEXT
vmaddr 0x0000000000000000
vmsize 0x0000000000023000
fileoff 0
filesize 0
maxprot 0x00000007
initprot 0x00000005
nsects 12
flags 0x0
其中vmaddr 0x0000000000000000即為起始地址评凝。
b.崩潰信息還原
首先找到崩潰的地址。例如：
7 TheElements 0x0000000109ae552a 0x109ae3000 + 9514
其中9514（0x252A）就是偏移量腺律，實(shí)際堆棧地址可由下面公式來(lái)計(jì)算：
實(shí)際堆棧地址 = TEXT段起始地址 + 偏移量
所以計(jì)算的出結(jié)果為：0x252A奕短。
在終端輸入如下命令：
dwarfdump --arch <Binary Architecture> <Path to dSYM file> --lookup 0x252a
<Binary Architecture>，可以通過(guò).crash文件信息得到匀钧。比如Mac OS的應(yīng)用程式為：x86_64翎碑，iOS的為:arm64等。
得到結(jié)果：
Line table file: 'TSDownloadObj.m' line 164, column 13 with start address 0x0000000000002522
Looking up address: 0x000000000000252a in .debug_frame... not found.
所以崩潰的代碼所在文件為T(mén)SDownloadObj.m之斯，行號(hào)為164日杈。
通過(guò)atos符號(hào)化Crash Report
通過(guò)上面的步驟確認(rèn)uuid一致后，輸入如下命令：
atos -arch <Binary Architecture> -o <Path to dSYM file>/Contents/Resources/DWARF/<binary image name> -l <load address> <address to symbolicate>
例如：
atos -arch x86_64 -o <Path to dSYM file>/Contents/Resources/DWARF/<binary image name> -l 0x109ae3000 0x0000000109ae552a
得到如下結(jié)果：
-[TSDownloadObj URLSession:task:didCompleteWithError:] (in TheElements) (TSDownloadObj.m:164)
這樣得到的結(jié)果和dwarfdump的結(jié)果一模一樣。
蘋(píng)果官方文獻(xiàn)
如果沒(méi)有.dSYM文件达椰，那么就比較麻煩了翰蠢，需要符號(hào)化.crash的話(huà)项乒，必須保證本地或者服務(wù)器上路徑：~/Library/Developer/Xcode/DerivedData/YOUR_PROJECT_CONFIGFILE存在啰劲，即可通過(guò)dsymutil命令提取.dSYM文件。
dsymutil appName.app/Contents/MacOS/appName
如果上述路徑不存在的話(huà)檀何，雖然能提取出.dSYM文件蝇裤，但是這個(gè)文件是不能用來(lái)符號(hào)化的。路徑不存在的話(huà)運(yùn)行上述命令會(huì)得到一堆類(lèi)似如下的警告：
warning: (x86_64) /***/***/Library/Developer/Xcode/DerivedData/***-bivwwbqnjqxnlrcoeospkrentncw/Build/Intermediates.noindex/***.build/Release/***.build/Objects-normal/x86_64/TUILinkTextField.o unable to open object file: No such file or directory
***-bivwwbqnjqxnlrcoeospkrentncw即為YOUR_PROJECT_CONFIGFILE频鉴。