iOS 崩潰信息收集
最近項目要求收集應用使用過程中的崩潰信息，在網上搜索了一番后，了解目前崩潰信息收集有如下幾種途徑：iTunes Connect導出手機上傳日志、拿到用戶手機使用 Xcode 導出、使用第三方崩潰收集服務（如 Bugly、友盟等）。從及時性和可定制角度來看上面幾種都不符合項目的需求，基于上述需求背景要求必須學習手動收集崩潰信息。
導致崩潰的問題
導致應用崩潰的問題主要有兩種：
- C++語言層面的錯誤，比如野指針、除零、內存非法訪問等；
- 未捕獲異常（Uncaught Exception），在 iOS 中最常見的就是通過 @throw 拋出的 NSException（常見的錯誤，比如數組訪問越界）
對于第一種問題，由于 iOS 和 Android 底層系統都是 Unix 或者類 Unix 系統，可以采用信號機制來捕獲 signal 或 sigaction，通過設置的回調函數來收集信號的上下文信息。
第二種問題可以通過 NSSetUncaughtExceptionHandler 設置異常處理回調函數來收集異常的調用堆棧。
收集崩潰的上下文信息
使用 NSUncaughtExceptionHandler 捕獲 NSException
通過 void NSSetUncaughtExceptionHandler(NSUncaughtExceptionHandler *) 函數設置異常發生時對應的事件處理函數，NSUncaughtExceptionHandler 是一個函數指針 typedef void NSUncaughtExceptionHandler(NSException *exception)，該函數指針的入參是 NSException，包含該異常的調用堆棧：
void InstallUncaughtExceptionHandler(void) {
// Backup original handler
g_previousUncaughtExceptionHandler = NSGetUncaughtExceptionHandler();
NSSetUncaughtExceptionHandler(&HandleException);
}
void MyUncaughtExceptionHandler(NSException *exception) {
// 異常的堆棧信息
NSArray *stackArray = [exception callStackSymbols];
// 出現異常的原因
NSString *reason = [exception reason];
// 異常名稱
NSString *name = [exception name];
NSString *exceptionInfo = [NSString stringWithFormat:@"Exception reason：%@\nException name：%@\nException stack：%@",name, reason, stackArray];
NSLog(@"%@", exceptionInfo);
[UncaughtExceptionHandler saveCreash:exceptionInfo];
if (g_previousUncaughtExceptionHandler != NULL) {
g_previousUncaughtExceptionHandler(exception);
}
}
上面是捕獲異常的簡單示例。
捕獲 Signal 信號
Signal 信號是 Unix 系統中一種用于異步通知的機制。信號傳遞給進程后，在沒有設置處理函數的情況下，程序可以指定三種行為：
- 忽略信號，但 SIGKILL 和 SIGSTOP 信號不可忽略；
- 使用默認的處理函數 SIG_DFL，大多數信號的默認動作是終止進程；
- 捕獲信號，執行用戶定義的函數。
這里有兩個特殊的常量：
- SIG_IGN：向內核表示忽略此信號。對于不能忽略的兩個信號SIGKILL和SIGSTOP，調用時會報錯；
- SIG_DFL：執行該信號的系統默認動作.
常用函數：
-
int kill(pid_t pid, int signo)發送信號到指定的進程 -
int raise(int signo)發送信號給自己
Unix 系統中常見信號有如下幾種：
SIGABRT--程序中止命令中止信號
SIGALRM--程序超時信號
SIGFPE--程序浮點異常信號
SIGILL--程序非法指令信號
SIGHUP--程序終端中止信號
SIGINT--程序鍵盤中斷信號
SIGKILL--程序結束接收中止信號
SIGTERM--程序kill中止信號
SIGSTOP--程序鍵盤中止信號
SIGSEGV--程序無效內存中止信號
SIGBUS--程序內存字節未對齊中止信號
SIGPIPE--程序Socket發送失敗中止信號
會導致程序被殺掉的有下面幾種，我們只需收集這幾種信號的上下文信息，就能找到崩潰發生原因。
SIGABRT,
SIGBUS,
SIGFPE,
SIGILL,
SIGSEGV,
SIGTRAP,
SIGTERM,
SIGKILL,
信號處理流程分三步：
- 注冊信號處理回調函數；
- 在回調函數中收集調用堆棧信息；
- 恢復信號默認處理函數；
1.注冊信號處理回調函數
static int Beacon_errorSignals[] = {
SIGABRT,
SIGBUS,
SIGFPE,
SIGILL,
SIGSEGV,
SIGTRAP,
SIGTERM,
SIGKILL,
};
for (int i = 0; i < Beacon_errorSignalsNum; i++) {
signal(Beacon_errorSignals[i], &SignalExceptionHandler);
}
2.回調函數中收集調用堆棧信息
void SignalExceptionHandler(int sig) {
NSMutableString *mstr = [[NSMutableString alloc] init];
[mstr appendString:@"Stack:\n"];
void *callstack[128];
int i, frames = backtrace(callstack, 128);
char **strs = backtrace_symbols(callstack, frames);
for (i = 0; i <frames; ++i) {
[mstr appendFormat:@"%s\n", strs[i]];
}
[SignalHandler saveCreash:mstr];
free(strs);
}
3.恢復信號默認處理函數
但這里會將信號不斷的發向該處理函數,導致應用無法正常崩潰,因為一般的消息處理會向進程終結,但是這里沒有,所以還會有同樣地信號不斷的發過來并被處理.所以處理函數后要終結該處理函數的處理,并將其由系統默認處理,即:
signal(sig, SIG_DFL);
測試
完成異常和信號處理函數的設置后，我們需要測試設置是否生效，能否正常捕獲到崩潰的堆棧信息。測試需要注意：信號時不能在 debug 環境下進行，系統的 debug 會優先攔截信號。正確的測試姿勢，安裝應用后關閉 debug，直接在模擬器中點擊應用制造信號。Exception 測試可以在 debug 環境下進行。
- (IBAction)buttonClick:(UIButton *)sender {
//1.信號量
Test *pTest = {1,2};
free(pTest); //導致SIGABRT的錯誤，因為內存中根本就沒有這個空間，哪來的free，就在棧中的對象而已
pTest->a = 5;
}
- (IBAction)buttonOCException:(UIButton *)sender {
//2.ios崩潰
NSArray *array= @[@"tom",@"xxx",@"ooo"];
[array objectAtIndex:5];
}
收集后的清理
傳遞 UncaughtExceptionHandler
如果多方通過 NSSetUncaughtExceptionHandler 注冊異常處理程序，后注冊的異常處理程序會覆蓋前一個注冊的 handler，導致之前注冊的日志收集服務收不到相應的 NSException，丟失崩潰堆棧信息。（iOS 系統自帶的 Crash Reporter 不受影響）。
崩潰后友好退出
而對于有些時候,在iOS中,在應用崩潰后,保持運行狀態而不退出：
CFRunLoopRef runLoop = CFRunLoopGetCurrent();
CFArrayRef allModes = CFRunLoopCopyAllModes(runLoop);
while (!dismissed) {
for (NSString *mode in (__bridge NSArray *)allModes) {
CFRunLoopRunInMode((__bridge CFStringRef)mode, 0.001, false);
}
}
CFRelease(allModes);
應用以上代碼,可以做到崩潰時彈框提示應用,以讓用戶還是可以正常操作,讓響應更加友好.
存在的問題
使用上述方式收集到的堆棧信息只包含錯誤線程，其他線程的調用堆棧無法獲取。而在一些 Signal 的出錯信息僅靠崩潰線程的堆棧無法找到原因，需同時根據其他線程調用堆棧來尋找崩潰原因。
目前成熟的開源崩潰日志收集服務有很多，如 KSCrash，PLCrashReporter，CrashKit 等，使用一番后覺得 PLCrashReporter 更符合項目要求。PL 收集崩潰日志信息和蘋果官方日志兼容，擴展性較好，與已有服務銜接較為簡單。
集成 PLCrashReporter
去官網下載最新的 release 包，將iOS Framework/CrashReporter.framework 拖進工程。在 application:didFinishLaunchingWithOptions 方法中調用 initCrashMgr 完成 PLCrashReporter 的初始化。
- (void)initCrashMgr {
PLCrashReporter *crashReporter = [PLCrashReporter sharedReporter];
NSError *error;
// Check if we previously crashed
if ([crashReporter hasPendingCrashReport]) {
[self handleCrashReport];
}
// Enable the Crash Reporter
if (![crashReporter enableCrashReporterAndReturnError: &error]) {
ABLog(@"Warning: Could not enable crash reporter: %@", error);
}
}
- (void)handleCrashReport {
PLCrashReporter *crashReporter = [PLCrashReporter sharedReporter];
NSData *crashData;
NSError *error;
// Try loading the crash report
crashData = [crashReporter loadPendingCrashReportDataAndReturnError:&error];
if (crashData == nil) {
ABLog(@"Could not load crash report: %@", error);
[crashReporter purgePendingCrashReport];
return;
}
// We could send the report from here, but we'll just print out some debugging info instead
PLCrashReport *report = [[PLCrashReport alloc] initWithData:crashData error:&error];
if (report == nil) {
ABLog(@"Could not parse crash report");
[crashReporter purgePendingCrashReport];
return;
}
//TODO:send the report
ABLog(@"Crashed on %@", report.systemInfo.timestamp);
ABLog(@"Crashed with signal %@ (code %@, address=0x%" PRIx64 ")", report.signalInfo.name, report.signalInfo.code, report.signalInfo.address);
NSString *humanReadText = [PLCrashReportTextFormatter stringValueForCrashReport:report withTextFormat:PLCrashReportTextFormatiOS];
// 處理收集到的 crash 信息
[self sendCrashReport:humanReadText];
[crashReporter purgePendingCrashReport];
return;
}
PLCrashReporter 收集的 crash 非常全媲美蘋果的收集的日志，簡單看了下源碼原理和上述思路一致，但一直沒找到它如何解決其他線程的堆棧收集問題，有時間繼續研讀下。
參考文章：
