最近一段時間，在iOS開發調試過程中以及上線之後，程序經常會出現崩潰的問題。簡單的崩潰還好說，復雜的崩潰就需要我們通過解析Crash文件來分析了，解析Crash文件在iOS開發中是比較常見的。但在跟開發者溝通過程中，雲捕小編發覺大家對iOS的應用符號表還不是很清楚。



現在網上有很多關於解析崩潰堆棧信息的符號化的博客，但是大多質量參差不齊，或者有些細節沒有注意到。今天總結一下對iOS崩潰符號化的使用和技巧：

一．場景

當我們收集iOS的崩潰信息時，獲取到的崩潰堆棧一般是如下的形式，全是十六進制的內存地址形式：



這樣的格式我們很難看出實際含義，無法定位問題代碼，只有將它們轉化為可讀的形式才有意義：



如上所示，我們一眼就能看明白，這次崩潰發生在ViewController.m文件的68行，對應的方法是rangeException。那麼這樣的符號化又是如何實現的呢？

我們知道，開發者在使用Xcode開發調試App時，一旦遇到崩潰問題，開發者可以直接使用Xcode的調試器定位分析崩潰堆棧。但如果App發布上線，用戶的手機發生了崩潰，我們就只能通過分析系統記錄的崩潰日志來定位問題，在這份崩潰日志文件中，會指出App出錯的函數內存地址，關鍵的問題，崩潰日志中只有地址，類似 0x2312e92f這種，這看起來豈不是相當頭疼，那怎麼辦呢？

幸好有dSYM文件的存在，它是幫助苦逼的碼農有效定位bug問題的重要途徑。崩潰堆棧裡的函數地址可以借助dSYM文件來找到具體的文件名、函數名和行號信息的。實際上，在使用Xcode的Organizer查看崩潰日志時，就是根據本地存儲的.dSYM文件進行了符號化的操作。

二．Xcode符號化工具

Xcode本身也提供了幾個工具來幫助開發者執行函數地址符號化的操作

1、symbolicatecrash

symbolicatecrash是一個將堆棧地址符號化的腳本，輸入參數是蘋果官方格式的崩潰日志及本地的.dSYM文件，
執行方式如下：
Symbolicatecrash + 崩潰日志 + APP對應的.dSYM文件 + > + 輸出到的文件，
但使用symbolicatecrash工具有很大的限制
(1)只能分析官方格式的崩潰日志，需要從具體的設備中導出，獲取和操作都不是很方便
(2)符號化的結果也是沒有具體的行號信息的，也經常會出現符號化失敗的情況。
實際上, Xcode的Organizer內置了symbolicatecrash工具，所以開發者才可以直接看到符號化的崩潰堆棧日志。

2、atos

更普遍的情況是，開發者能獲取到錯誤堆棧信息，而使用atos工具就是把地址對應的具體符號信息找到。它是一個可以把地址轉換為函數名（包括行號）的工具，
執行方式如下：
atos -o executable -arch architecture -l loadAddress address
說明：
loadAddress 表示函數的動態加載地址，對應崩潰地址堆棧中 + 號前面的地址，即0x00048000
address 表示運行時地址、對應崩潰地址堆棧中第一個地址，即0x0004fbed ，實際上，崩潰地址堆棧中+號前後的地址相加即是運行時地址，即0x00048000+ 31720= 0x0004fbed
執行命令查詢地址的符號，可以看到如下結果：
-[ViewController rangeException:] (in xx)(ViewController.m:68)

三．堆棧符號化原理

那麼，如果我們自己來符號化堆棧，又該怎麼實現呢？這裡需要處理兩種符號，包括用戶符號和系統符號。

1、用戶堆棧的符號化

符號化的依據來自dSYM文件， dSYM文件也是Mach-o格式，我們按照Mach-o格式一步一步解析即可。



從圖上我們可以大概的看出Mach-O可以分為3個部分
(1)Header
(2)Segment
(3)section
如圖所示，header後面是segment，然後再跟著section，而一個segment是可以包含多個section的。
我們把dSYM文件放入可視化工具:



該dSYM文件包含armv7和arm64兩種架構的符號表，我們只看armv7(arm64同理)，它偏移64，直接定位到64(0x00000040),這裡就是上面的Mach Header信息



跟我們符號表有關的兩個地方，一是”LC_SYMTAB”, 二是“LC_SEGMENT(__DWARF)” -> “Section Header(__debug_line)”。

LC_SYMTAB信息



定位地址: 偏移4096 + 64(0x1040),得到函數符號信息模塊”Symbols”,把函數符號解析出來，比如第一個函數: “-[DKDLicenseAgreeementModel isAuthorize]”對應的內存地址:模塊地址+43856



“__debug_line”模塊

這個模塊裡包含有代碼文件行號信息，根據dwarf格式去一個一個解析
首先定位到SEGMENT：LC_SEGMENT(__DWARF)，再定位到Section:__debug_line



它的偏移值:4248608, 4248608+ 64 = 0x40D460，定位到“Section(__DWARF,__debug_line)”
這裡面就是具體的行號信息，根據dwarf格式去解析



解析出來的結果如下:



第一列是起始內存地址，第二列是結束內存地址，第三列是對應的函數名、文件名、行號信息，這樣我們捕獲到任意的崩潰信息後，都可以很輕松的還原了。

上面解析出來的Object-C符號倒沒什麼問題，但如果是C++或者Swift的符號就還需要特殊處理

Swift符號:

Swift函數會進行命名重整(name mangling),所以從dSYM中解析出來的原始符號是不太直觀的



我們使用”swift-demangle”來還原:swift-demangle –simplified originName，結果如下:



C++符號:

C++函數也會進行命名重整(name mangling),所以從dSYM中解析出來的原始符號如下:



我們使用”c++filt ”來還原: c++filt originName，結果如下:



2、系統堆棧的符號化

未解析形式:


解析後:


Apple沒有提供系統庫符號表的下載功能，我們可以通過真機來獲取
當把開發機連到MAC時，會首先把該機型的符號拷貝到電腦上。



“Processing symbol files”做的事情就是把系統符號拷貝到電腦，拷貝地址:
~/Library/Developer/Xcode/iOS DeviceSupport



但這樣有個缺陷，那就是你真機的iOS版本不會足夠多，包含所有版本，所以系統符號會有缺失，另一個辦法就是下載各種iOS固件，從固件中去解析。

四．結語

在實際的項目開發中，崩潰問題的分析定位都不是采用這種方式，因為它依賴於系統記錄的崩潰日志或錯誤堆棧，在本地開發調試階段，是沒有問題的。
如果在發布的線上版本出現崩潰問題，開發者是無法即時准確的取得錯誤堆棧。一般地，開發者都是接入第三方的崩潰監控服務（如網易雲捕），實現線上版本崩潰問題的記錄和跟蹤。