最近在做 Crash 分析方面的工作，發現 iOS 的崩潰捕獲和堆疊符號化雖然已經有很多資料可以參考，但是沒有比較完善的成套解決方案，導致操作起來還是要踩很多坑，耽誤了很多時間。所以想做一個總結，闡述 Crash 收集分析的整體思路和出坑指南，具體細節實現會給出相關參考資料。有了思路，實現也就 So Easy 啦。
崩潰捕獲
對於崩潰捕獲，以前在 移動端監控體系之技術原理剖析 中詳細闡述過，並且給出了相應的 Demo，崩潰主要是由於 Mach 異常、Objective-C 異常（NSException）引起的，同時對於 Mach 異常，到了 BSD 層會轉換為對應的 Signal 訊號，那麼我們也可以通過捕獲訊號，來捕獲 Crash 事件。針對 NSException 可以通過註冊 NSUncaughtExceptionHandler 捕獲異常資訊。下圖摘自阿里百川，簡潔明瞭的展現了客戶端崩潰分析架構。
衝突
在我們自己研發 Crash 收集框架之前，最早肯定都會接入網易雲捕、騰訊 Bugly、Fabric 等第三方日誌框架來進行崩潰的收集和分析。如果多個 Crash 收集框架存在時，往往會存在衝突。
不管是對於 Signal 捕獲還是 NSException 捕獲都會存在 handler 覆蓋的問題，正確的做法應該是先判斷是否有前者已經註冊了 handler，如果有則應該把這個 handler 儲存下來，在自己處理完自己的 handler 之後，再把這個 handler 丟擲去，供前面的註冊者處理。這裡給出相應的 Demo，Demo 由@zerygao提供。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 |
typedef void (*SignalHandler)(int signo, siginfo_t *info, void *context); static SignalHandler previousSignalHandler = NULL; + (void)installSignalHandler { struct sigaction old_action; sigaction(SIGABRT, NULL, &old_action); if (old_action.sa_flags & SA_SIGINFO) { previousSignalHandler = old_action.sa_sigaction; } LDAPMSignalRegister(SIGABRT); // ....... } static void LDAPMSignalRegister(int signal) { struct sigaction action; action.sa_sigaction = LDAPMSignalHandler; action.sa_flags = SA_NODEFER | SA_SIGINFO; sigemptyset(&action.sa_mask); sigaction(signal, &action, 0); } static void LDAPMSignalHandler(int signal, siginfo_t* info, void* context) { // 獲取堆疊，收集堆疊 ........ LDAPMClearSignalRigister(); // 處理前者註冊的 handler if (previousSignalHandler) { previousSignalHandler(signal, info, context); } } |
上面的是一個處理 Signal handler 衝突的大概程式碼思路，下面是 NSException handler 的處理思路，兩者大同小異。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
static NSUncaughtExceptionHandler *previousUncaughtExceptionHandler; static void LDAPMUncaughtExceptionHandler(NSException *exception) { // 獲取堆疊，收集堆疊 // ...... // 處理前者註冊的 handler if (previousUncaughtExceptionHandler) { previousUncaughtExceptionHandler(exception); } } + (void)installExceptionHandler { previousUncaughtExceptionHandler = NSGetUncaughtExceptionHandler(); NSSetUncaughtExceptionHandler(&LDAPMUncaughtExceptionHandler); } |
堆疊收集
你可以直接用系統的方法獲取當前執行緒堆疊，也可以使用 PLCrashRepoter 獲取所有執行緒堆疊，也可以參考 BSBacktraceLogger 自己寫一套輕量級的堆疊採集框架。
堆疊符號解析
堆疊符號化還原有四種常見的方法：
- symbolicatecrash
- mac 下的 atos 工具
- linux 下的 atos 的替代品 atosl
- 通過 dSYM 檔案提取地址和符號的對應關係，進行符號還原
以上方案都有對應的應用場景，對於線上的 Crash 堆疊符號還原，主要採用的還是後三種方案。atos 和 atosl 的使用方法很類似，以下是 atos 的一個示例。
|
1 2 3 4 |
atos -o MonitorExample 0x0000000100062ac4 ARM-64 -l 0x100058000 // 還原結果 -[GYRootViewController tableView:cellForRowAtIndexPath:] (in GYMonitorExample) (GYRootViewController.m:41) |
但是 atos 是Mac上一個工具，需要使用 Mac 或者黑蘋果來進行解析工作，如果由後臺來做解析工作，往往需要一套基於 Linux 的解析方案，這個時候可以選擇 atosl，但是這個庫已經有多年沒有更新了，同時基於我司的嘗試， atosl 好像不太支援 arm64 架構，所以我們放棄了該方案。
最終使用了第四個方案，提取 dSYM 的符號表，可以自己研發工具，也可以直接使用 bugly 和 網易雲捕提供的工具，下面是提取出來的符號表。第一列是起始記憶體地址，第二列是結束地址，第三列是對應的函式名、檔名以及行號。
|
1 2 3 4 5 6 7 8 9 10 |
a840 a854 -[GYRootViewController tableView:cellForRowAtIndexPath:] GYRootViewController.m:41 a854 a858 -[GYRootViewController tableView:cellForRowAtIndexPath:] GYRootViewController.m:42 a858 a87c -[GYRootViewController tableView:cellForRowAtIndexPath:] GYRootViewController.m:42 a87c a894 -[GYRootViewController tableView:cellForRowAtIndexPath:] GYRootViewController.m:42 a894 a8a0 -[GYRootViewController tableView:cellForRowAtIndexPath:] GYRootViewController.m:42 aa3c aa80 -[GYFilePreviewViewController initWithFilePath:] GYRootViewController.m:21 aa80 aaa8 -[GYFilePreviewViewController initWithFilePath:] GYFilePreviewViewController.m:23 aaa8 aab8 -[GYFilePreviewViewController initWithFilePath:] GYFilePreviewViewController.m:23 aab8 aabc -[GYFilePreviewViewController initWithFilePath:] GYFilePreviewViewController.m:24 aabc aac8 -[GYFilePreviewViewController initWithFilePath:] GYFilePreviewViewController.m:24 |
因為程式每次啟動基地址都會變化，所以上面提到的地址是相對偏移地址，在我們獲取到崩潰堆疊地址後，可以根據堆疊中的偏移地址來與符號表中的地址來做匹配，進而找到堆疊所對應的函式符號。比如下面的第四行，偏移為 43072 轉換為十六進位制就是 a840，用 a840 去上面的符號表中找對應關係，會發現對應著 -[GYRootViewController tableView:cellForRowAtIndexPath:]，基於這種方式，就可以將堆疊地址完全還原為函式符號啦。
|
1 2 3 4 |
0 libsystem_kernel.dylib 0x0000000186cfd314 0x186cde000 + 127764 1 Foundation 0x00000001887f5590 0x1886ec000 + 1086864 2 GYMonitorExample 0x00000001000da4ac 0x1000d0000 + 42156 3 GYMonitorExample 0x00000001000da840 0x1000d0000 + 43072 |
UUID
我們的應用存在多個版本，並且支援多種不同的架構，那麼如何找到與崩潰日誌對應的符號表呢？就是依靠 UUID，只有當崩潰日誌的 UUID 與 dSYM 的 UUID 一致時，才能得到正確的解析結果。
dSYM 的 UUID 獲取方法：
|
1 |
xcrun dwarfdump --uuid |
應用內獲取 UUID 的方法：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
#import NSString *executableUUID() { const uint8_t *command = (const uint8_t *)(&_mh_execute_header + 1); for (uint32_t idx = 0; idx cmd == LC_UUID) { command += sizeof(struct load_command); return [NSString stringWithFormat:@"%02X%02X%02X%02X-%02X%02X-%02X%02X-%02X%02X-%02X%02X%02X%02X%02X%02X", command[0], command[1], command[2], command[3], command[4], command[5], command[6], command[7], command[8], command[9], command[10], command[11], command[12], command[13], command[14], command[15]]; } else { command += ((const struct load_command *)command)->cmdsize; } } return nil; } |
系統庫符號化
上面只是提取到了我們應用中 dSYM 中的符號表，對於系統庫還是無能為力的，比如 UIKit 就沒有辦法將其地址符號化，想要將動態庫符號化，需要先獲取系統庫的符號檔案。提取系統符號檔案可以從 iOS 韌體中獲取，也可以從 Github 上開源專案中找到對應系統的符號檔案。
剛才只是講了一個思路，具體的細節可以參考下面的資料：