- iOS Crash 流程化：概覽
- 崩潰捕獲
- Mach 異常捕獲
- Unix 信號捕獲
- NSException 捕獲
- 沖突
- 堆棧收集
- 堆棧符號解析
- UUID
- 系統庫符號化
- 崩潰捕獲
一、崩潰捕獲
對于崩潰的情況，一般是由 Mach異常或 Objective-C 異常（NSException）引起的。可以針對這兩種情況抓取對應的 Crash 事件。
對于 Mach 異常，到了 BSD 層會轉換為對應的 Signal 信號，那么我們也可以通過捕獲信號，來捕獲 Crash 事件。
針對 NSException 可以通過注冊 NSUncaughtExceptionHandler 捕獲異常信息。
Mach 異常捕獲
如果想要做 Mach 異常捕獲，需要注冊一個異常端口，這個異常端口會對當前任務的所有線程有效，如果想要針對單個線程，可以通過 thread_set_exception_ports注冊自己的異常端口，發生異常時，首先會將異常拋給線程的異常端口，然后嘗試拋給任務的異常端口，當我們捕獲異常時，就可以做一些自己的工作，比如，當前堆棧收集等。
對于如何注冊一個異常端口，這里有示意圖和 PLCrashReporter 可以參考
Unix 信號捕獲
對于 Mach 異常，操作系統會將其轉換為對應的 Unix 信號，所以如果你對Mach不熟悉的話，也可以通過注冊signalHandler的方式來做信號異常。對于實例，你可以參考這里
signal(SIGHUP, signalHandler);
signal(SIGINT, signalHandler);
signal(SIGQUIT, signalHandler);
signal(SIGABRT, signalHandler);
signal(SIGILL, signalHandler);
signal(SIGSEGV, signalHandler);
signal(SIGFPE, signalHandler);
signal(SIGBUS, signalHandler);
signal(SIGPIPE, signalHandler);
NSException 捕獲
對于NSException異常，也比較容易處理，通過注冊NSUncaughtExceptionHandler捕獲異常信息即可，將拿到的NSException細節寫入Crash日志，上傳到后臺做數據分析
// register the uncaught exception handler
NSSetUncaughtExceptionHandler(&handler);
沖突
在我們自己研發 Crash 收集框架之前，最早肯定都會接入網易云捕、騰訊 Bugly、Fabric 等第三方日志框架來進行崩潰的收集和分析。如果多個 Crash 收集框架存在時，往往會存在沖突。
不管是對于 Signal 捕獲還是 NSException 捕獲都會存在 handler 覆蓋的問題，正確的做法應該是先判斷是否有前者已經注冊了 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);
}
SignalHandler不要在debug環境下測試。因為系統的debug會優先去攔截。我們要運行一次后，關閉debug狀態。應該直接在模擬器上點擊我們build上去的App去運行。而UncaughtExceptionHandler可以在調試狀態下捕捉
堆棧收集
你可以直接用系統的方法獲取當前線程堆棧，也可以使用 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，但是這個庫已經有多年沒有更新了，同時基于我司的嘗試， atosl 好像不太支持 arm64 架構，所以我們放棄了該方案。
最終使用了第四個方案，提取 dSYM 的符號表，可以自己研發工具，也可以直接使用 bugly 和 網易云捕提供的工具，下面是提取出來的符號表。第一列是起始內存地址，第二列是結束地址，第三列是對應的函數名、文件名以及行號。
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:]，基于這種方式，就可以將堆棧地址完全還原為函數符號啦。
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;
}
系統庫符號化
上面只是提取到了我們應用中 dSYM 中的符號表，對于系統庫還是無能為力的，比如 UIKit 就沒有辦法將其地址符號化，想要將動態庫符號化，需要先獲取系統庫的符號文件。提取系統符號文件可以從 iOS 固件中獲取，也可以從 Github 上開源項目中找到對應系統的符號文件。
搜集系統符號化文件非常困難，國內有一個非常敬業的iOS同行，搜集總結了iOS7 - iOS10的很多符號化文件，而且作者對文件做了優化，下載下來的文件也不會很大，非常感謝他！
網盤??
密碼: 79m8
