今天搗鼓了一天的crash日志終于順利的把16進(jìn)制的堆棧信息還原了，特地來(lái)寫個(gè)簡(jiǎn)書(shū)。每個(gè)iOS肯定都很羨慕Android的崩潰日志，直接定位到錯(cuò)誤代碼的位置，讓你快速定位BUG，iOS一出現(xiàn)bug就會(huì)出現(xiàn)一堆的16進(jìn)制地址，讓人類無(wú)法閱讀,今天索性研究了一天，來(lái)跟大家分享下如何把這些16進(jìn)制還原成對(duì)應(yīng)的代碼位置，像java一樣定位bug。

首先來(lái)普及下幾個(gè)小知識(shí)：

1.什么是符號(hào)表

符號(hào)表就是指在Xcode項(xiàng)目編譯后，在編譯生成的二進(jìn)制文件.app的同級(jí)目錄下生成的同名的.dSYM文件.dSYM文件其實(shí)是一個(gè)目錄，在子目錄中包含了一個(gè)16進(jìn)制的保存函數(shù)地址映射信息的中轉(zhuǎn)文件，所有Debug的symbols都在這個(gè)文件中(包括文件名、函數(shù)名、行號(hào)等)，所以也稱之為調(diào)試符號(hào)信息文件。

2.符號(hào)表有什么用

符號(hào)表就是用來(lái)符號(hào)化 crash log（崩潰日志）。crash log中有一些方法16進(jìn)制的內(nèi)存地址等，通過(guò)符號(hào)表就能找到對(duì)應(yīng)的能夠直觀看到的方法名之類。

3.如何得到.dsYM文件

我們?cè)贏rchive的時(shí)候會(huì)生成.xcarchive文件，然后顯示包內(nèi)容就能夠在里面找到.dsYM文件和.app文件。

下圖是線上收集的bug崩潰信息

花紅圈的地方就我的APP報(bào)錯(cuò)的位置信息,在你們的日志里tcrrdios應(yīng)該是你們對(duì)應(yīng)的appname，后面緊跟的是2個(gè)16進(jìn)制地址。

解析上面這點(diǎn)信息首先獲取APP編譯時(shí)的.xcarchive

OK,以上步驟就可以得到你的.xcarchive。什么？你沒(méi)有？編譯后就刪除了？那你就只能等下次了，這個(gè)文件沒(méi)發(fā)布一次版本最好保存起來(lái)防止日后出現(xiàn)問(wèn)題找到問(wèn)題的代碼。

找到了你的.xcarchive右擊“顯示包內(nèi)容”---“dSYMs”-----“[你的appname].app.dSYM”---右擊"顯示包內(nèi)容"---"Contents"-----"Resources"----"DWARF"。這時(shí)你會(huì)看到和你APPNAME一樣的文件，打開(kāi)命令行輸入atos -o [拖動(dòng)地址到這里] -l [16進(jìn)制地址] -arch arm64 [16進(jìn)制地址]。

以我的文件為例最終命令為：

atos -o /Users/lr_ios1/Desktop/a/tcrrdios.app.dSYM/Contents/Resources/DWARF/tcrrdios-l 0x0000000100030000 -arch arm64 0x00000001000507f4

注意空格！??！注意空格?。?！注意空格！??！重要的事情要說(shuō)三遍

arm64是根據(jù)你實(shí)際CPU類型，這個(gè)現(xiàn)在基本都是64位的了，5以下的機(jī)型就是armv7。

執(zhí)行完上面的命令得到的結(jié)果是：

-[MainViewController viewDidLoad] (in tcrrdios) (MainViewController.m:31)

這個(gè)返回值的意思大家應(yīng)該都能看得懂了，發(fā)生崩潰的位置就是MainViewController.m這個(gè)文件的31行，也就是MainViewController這個(gè)類的viewDidLoad函數(shù)中。

來(lái)張圖吧。。。。

到這里我相信小白也能看得懂了。其實(shí)我也是小白o(hù)(>﹏<)o。。。

什么？還是太難？好吧，介紹你們一種圖形界面的方法，炒雞簡(jiǎn)單，我就不詳細(xì)介紹了，

https://github.com/answer-huang/dSYMTools

對(duì)就是上面的地址，作者已經(jīng)把源碼開(kāi)源了，圖形化定位代碼位置夠簡(jiǎn)單了吧，上面有操作方法。

順便提供下下載地址：

https://pan.baidu.com/s/1mg01Qha