最近在做 Crash 分析方面的工作，發(fā)現(xiàn) iOS 的崩潰捕獲和堆棧符號化雖然已經(jīng)有很多資料可以參考，但是沒有比較完善的成套解決方案，導(dǎo)致操作起來還是要踩很多坑，耽誤了很多時間。所以想做一個總結(jié)，闡述 Crash 收集分析的整體思路和出坑指南，具體細節(jié)實現(xiàn)會給出相關(guān)參考資料。有了思路，實現(xiàn)也就 So Easy 啦。
崩潰捕獲
對于崩潰捕獲，以前在 移動端監(jiān)控體系之技術(shù)原理剖析 中詳細闡述過，并且給出了相應(yīng)的 Demo，崩潰主要是由于 Mach 異常、Objective-C 異常（NSException）引起的，同時對于 Mach 異常，到了 BSD 層會轉(zhuǎn)換為對應(yīng)的 Signal 信號，那么我們也可以通過捕獲信號，來捕獲 Crash 事件。針對 NSException 可以通過注冊 NSUncaughtExceptionHandler 捕獲異常信息。下圖摘自阿里百川，簡潔明了的展現(xiàn)了客戶端崩潰分析架構(gòu)。
沖突
在我們自己研發(fā) Crash 收集框架之前，最早肯定都會接入網(wǎng)易云捕、騰訊 Bugly、Fabric 等第三方日志框架來進行崩潰的收集和分析。如果多個 Crash 收集框架存在時，往往會存在沖突。
不管是對于 Signal 捕獲還是 NSException 捕獲都會存在 handler 覆蓋的問題，正確的做法應(yīng)該是先判斷是否有前者已經(jīng)注冊了 handler，如果有則應(yīng)該把這個 handler 保存下來，在自己處理完自己的 handler 之后，再把這個 handler 拋出去，供前面的注冊者處理。這里給出相應(yīng)的 Demo，Demo 由@zerygao提供。
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 的處理思路，兩者大同小異。
static NSUncaughtExceptionHandler *previousUncaughtExceptionHandler;
static void LDAPMUncaughtExceptionHandler(NSException *exception) {
// 獲取堆棧，收集堆棧
// ......
// 處理前者注冊的 handler
if (previousUncaughtExceptionHandler) {
previousUncaughtExceptionHandler(exception);
}
}
+ (void)installExceptionHandler {
previousUncaughtExceptionHandler = NSGetUncaughtExceptionHandler();
NSSetUncaughtExceptionHandler(&LDAPMUncaughtExceptionHandler);
}
堆棧收集
你可以直接用系統(tǒng)的方法獲取當前線程堆棧，也可以使用 PLCrashRepoter 獲取所有線程堆棧，也可以參考 BSBacktraceLogger 自己寫一套輕量級的堆棧采集框架。
堆棧符號解析
堆棧符號化還原有四種常見的方法：
- symbolicatecrash
- mac 下的 atos 工具
- linux 下的 atos 的替代品 atosl
- 通過 dSYM 文件提取地址和符號的對應(yīng)關(guān)系，進行符號還原
以上方案都有對應(yīng)的應(yīng)用場景，對于線上的 Crash 堆棧符號還原，主要采用的還是后三種方案。atos 和 atosl 的使用方法很類似，以下是 atos 的一個示例。
atos -o MonitorExample 0x0000000100062ac4 ARM-64 -l 0x100058000
// 還原結(jié)果
-[GYRootViewController tableView:cellForRowAtIndexPath:] (in GYMonitorExample) (GYRootViewController.m:41)
但是 atos 是Mac上一個工具，需要使用 Mac 或者黑蘋果來進行解析工作，如果由后臺來做解析工作，往往需要一套基于 Linux 的解析方案，這個時候可以選擇 atosl，但是這個庫已經(jīng)有多年沒有更新了，同時基于我司的嘗試， atosl 好像不太支持 arm64 架構(gòu)，所以我們放棄了該方案。
最終使用了第四個方案，提取 dSYM 的符號表，可以自己研發(fā)工具，也可以直接使用 bugly 和 網(wǎng)易云捕提供的工具，下面是提取出來的符號表。第一列是起始內(nèi)存地址，第二列是結(jié)束地址，第三列是對應(yīng)的函數(shù)名、文件名以及行號。
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
因為程序每次啟動基地址都會變化，所以上面提到的地址是相對偏移地址，在我們獲取到崩潰堆棧地址后，可以根據(jù)堆棧中的偏移地址來與符號表中的地址來做匹配，進而找到堆棧所對應(yīng)的函數(shù)符號。比如下面的第四行，偏移為 43072 轉(zhuǎn)換為十六進制就是 a840，用 a840 去上面的符號表中找對應(yīng)關(guān)系，會發(fā)現(xiàn)對應(yīng)著 -[GYRootViewController tableView:cellForRowAtIndexPath:]，基于這種方式，就可以將堆棧地址完全還原為函數(shù)符號啦。
0 libsystem_kernel.dylib 0x0000000186cfd314 0x186cde000 + 127764
1 Foundation 0x00000001887f5590 0x1886ec000 + 1086864
2 GYMonitorExample 0x00000001000da4ac 0x1000d0000 + 42156
3 GYMonitorExample 0x00000001000da840 0x1000d0000 + 43072
UUID
我們的應(yīng)用存在多個版本，并且支持多種不同的架構(gòu)，那么如何找到與崩潰日志對應(yīng)的符號表呢？就是依靠 UUID，只有當崩潰日志的 UUID 與 dSYM 的 UUID 一致時，才能得到正確的解析結(jié)果。
dSYM 的 UUID 獲取方法：
xcrun dwarfdump --uuid <dSYM文件>
應(yīng)用內(nèi)獲取 UUID 的方法：
#import <mach-o/ldsyms.h>
NSString *executableUUID()
{
const uint8_t *command = (const uint8_t *)(&_mh_execute_header + 1);
for (uint32_t idx = 0; idx < _mh_execute_header.ncmds; ++idx) {
if (((const struct load_command *)command)->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;
}
系統(tǒng)庫符號化
上面只是提取到了我們應(yīng)用中 dSYM 中的符號表，對于系統(tǒng)庫還是無能為力的，比如 UIKit 就沒有辦法將其地址符號化，想要將動態(tài)庫符號化，需要先獲取系統(tǒng)庫的符號文件。提取系統(tǒng)符號文件可以從 iOS 固件中獲取，也可以從 Github 上開源項目中找到對應(yīng)系統(tǒng)的符號文件。
剛才只是講了一個思路，具體的細節(jié)可以參考下面的資料：
