最近在做 Crash 分析方面的工作追城，發(fā)現(xiàn) iOS 的崩潰捕獲和堆棧符號化雖然已經(jīng)有很多資料可以參考魄懂，但是沒有比較完善的成套解決方案只盹，導致操作起來還是要踩很多坑，耽誤了很多時間。所以想做一個總結权埠，闡述 Crash 收集分析的整體思路和出坑指南榨了，具體細節(jié)實現(xiàn)會給出相關參考資料。有了思路攘蔽，實現(xiàn)也就 So Easy 啦龙屉。
崩潰捕獲
對于崩潰捕獲，以前在 移動端監(jiān)控體系之技術原理剖析 中詳細闡述過满俗，并且給出了相應的 Demo转捕，崩潰主要是由于 Mach 異常、Objective-C 異常（NSException）引起的唆垃，同時對于 Mach 異常五芝，到了 BSD 層會轉換為對應的 Signal 信號，那么我們也可以通過捕獲信號辕万，來捕獲 Crash 事件枢步。針對 NSException 可以通過注冊 NSUncaughtExceptionHandler 捕獲異常信息。下圖摘自阿里百川渐尿，簡潔明了的展現(xiàn)了客戶端崩潰分析架構醉途。
沖突
在我們自己研發(fā) Crash 收集框架之前，最早肯定都會接入網(wǎng)易云捕砖茸、騰訊 Bugly隘擎、Fabric 等第三方日志框架來進行崩潰的收集和分析。如果多個 Crash 收集框架存在時凉夯，往往會存在沖突货葬。
不管是對于 Signal 捕獲還是 NSException 捕獲都會存在 handler 覆蓋的問題，正確的做法應該是先判斷是否有前者已經(jīng)注冊了 handler劲够，如果有則應該把這個 handler 保存下來宝惰，在自己處理完自己的 handler 之后，再把這個 handler 拋出去再沧，供前面的注冊者處理尼夺。這里給出相應的 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 文件提取地址和符號的對應關系，進行符號還原
以上方案都有對應的應用場景东臀，對于線上的 Crash 堆棧符號還原着饥，主要采用的還是后三種方案。atos 和 atosl 的使用方法很類似惰赋，以下是 atos 的一個示例宰掉。
atos -o MonitorExample 0x0000000100062ac4 ARM-64 -l 0x100058000
// 還原結果
-[GYRootViewController tableView:cellForRowAtIndexPath:] (in GYMonitorExample) (GYRootViewController.m:41)
但是 atos 是Mac上一個工具，需要使用 Mac 或者黑蘋果來進行解析工作赁濒，如果由后臺來做解析工作轨奄，往往需要一套基于 Linux 的解析方案，這個時候可以選擇 atosl拒炎，但是這個庫已經(jīng)有多年沒有更新了挪拟，同時基于我司的嘗試， atosl 好像不太支持 arm64 架構击你，所以我們放棄了該方案舞丛。
最終使用了第四個方案，提取 dSYM 的符號表果漾，可以自己研發(fā)工具球切，也可以直接使用 bugly 和 網(wǎ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ù)堆棧中的偏移地址來與符號表中的地址來做匹配，進而找到堆棧所對應的函數(shù)符號必逆。比如下面的第四行怠堪，偏移為 43072 轉換為十六進制就是 a840，用 a840 去上面的符號表中找對應關系名眉，會發(fā)現(xiàn)對應著 -[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
我們的應用存在多個版本陌粹，并且支持多種不同的架構，那么如何找到與崩潰日志對應的符號表呢福压？就是依靠 UUID掏秩，只有當崩潰日志的 UUID 與 dSYM 的 UUID 一致時或舞，才能得到正確的解析結果。
dSYM 的 UUID 獲取方法：
xcrun dwarfdump --uuid <dSYM文件>
應用內獲取 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)庫符號化
上面只是提取到了我們應用中 dSYM 中的符號表蒙幻，對于系統(tǒng)庫還是無能為力的映凳，比如 UIKit 就沒有辦法將其地址符號化，想要將動態(tài)庫符號化杆煞，需要先獲取系統(tǒng)庫的符號文件魏宽。提取系統(tǒng)符號文件可以從 iOS 固件中獲取腐泻，也可以從 Github 上開源項目中找到對應系統(tǒng)的符號文件决乎。
剛才只是講了一個思路，具體的細節(jié)可以參考下面的資料：
