漫談iOS Crash收集框架
為了能夠第一時間發現程序問題，應用程序需要實現自己的崩潰日志收集服務，成熟的開源項目很多，如 KSCrash，plcrashreporter，CrashKit 等。追求方便省心，對於保密性要求不高的程序來說，也可以選擇各種一條龍Crash統計產品，如 Crashlytics，Hockeyapp ，友盟，Bugly 等等。
是否集成越多的Crash日志收集服務就越保險？
自己收集的Crash日志和系統生成的Crash日志有分歧，應該相信誰？
為什麼有大量Crash日志顯示崩在main函數裡,但函數棧中卻沒有一行自己的代碼？
野指針類的Crash難定位，有何妙招來應對？
想解釋清這些問題，必須從Mach異常說起
Mach異常與Unix信號
iOS系統自帶的 Apple’s Crash Reporter 記錄在設備中的Crash日志，Exception Type項通常會包含兩個元素： Mach異常 和 Unix信號。
Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Subtype: KERN_INVALID_ADDRESS at 0x041a6f3
Mach異常是什麼？它又是如何與Unix信號建立聯系的？ Mach是一個XNU的微內核核心，Mach異常是指最底層的內核級異常，被定義在
所有Mach異常都在host層被ux_exception轉換為相應的Unix信號，並通過threadsignal將信號投遞到出錯的線程。iOS中的 POSIX API 就是通過 Mach 之上的 BSD 層實現的。
因此，EXC_BAD_ACCESS (SIGSEGV)表示的意思是：Mach層的EXC_BAD_ACCESS異常，在host層被轉換成SIGSEGV信號投遞到出錯的線程。既然最終以信號的方式投遞到出錯的線程，那麼就可以通過注冊signalHandler來捕獲信號:
signal(SIGSEGV,signalHandler);
捕獲Mach異常或者Unix信號都可以抓到crash事件，這兩種方式哪個更好呢？ 優選Mach異常，因為Mach異常處理會先於Unix信號處理發生，如果Mach異常的handler讓程序exit了，那麼Unix信號就永遠不會到達這個進程了。轉換Unix信號是為了兼容更為流行的POSIX標准(SUS規范)，這樣不必了解Mach內核也可以通過Unix信號的方式來兼容開發。
因為硬件產生的信號(通過CPU陷阱)被Mach層捕獲，然後才轉換為對應的Unix信號；蘋果為了統一機制，於是操作系統和用戶產生的信號(通過調用kill和pthread_kill)也首先沉下來被轉換為Mach異常，再轉換為Unix信號。
Crash收集的實現思路
正如上述所說，可以通過捕獲Mach異常、或Unix信號兩種方式來抓取crash事件，於是總結起來實現方案就一共有3種。
1）Mach異常方式
2）Unix信號方式
signal(SIGSEGV,signalHandler);
3）Mach異常+Unix信號方式
Github上多數開源項目都采用的這種方式，即使在優選捕獲Mach異常的情況下，也放棄捕獲EXC_CRASH異常，而選擇捕獲與之對應的SIGABRT信號。著名開源項目plcrashreporter在代碼注釋中給出了詳細的解釋：
We still need to use signal handlers to catch SIGABRT in-process. The kernel sends an EXC_CRASH mach exception to denote SIGABRT termination. In that case, catching the Mach exception in-process leads to process deadlock in an uninterruptable wait. Thus, we fall back on BSD signal handlers for SIGABRT, and do not register for EXC_CRASH.
另外，需要重點說明的是：對於應用級異常NSException，還需要特殊處理。 你是否見過崩潰在main函數的crash日志，但是函數棧裡面沒有你的代碼：
Thread 0 Crashed:
0 libsystem_kernel.dylib 0x3a61757c __semwait_signal_nocancel + 0x18
1 libsystem_c.dylib 0x3a592a7c nanosleep$NOCANCEL + 0xa0
2 libsystem_c.dylib 0x3a5adede usleep$NOCANCEL + 0x2e
3 libsystem_c.dylib 0x3a5c7fe0 abort + 0x50
4 libc++abi.dylib 0x398f6cd2 abort_message + 0x46
5 libc++abi.dylib 0x3990f6e0 default_terminate_handler() + 0xf8
6 libobjc.A.dylib 0x3a054f62 _objc_terminate() + 0xbe
7 libc++abi.dylib 0x3990d1c4 std::__terminate(void (*)()) + 0x4c
8 libc++abi.dylib 0x3990cd28 __cxa_rethrow + 0x60
9 libobjc.A.dylib 0x3a054e12 objc_exception_rethrow + 0x26
10 CoreFoundation 0x2f7d7f30 CFRunLoopRunSpecific + 0x27c
11 CoreFoundation 0x2f7d7c9e CFRunLoopRunInMode + 0x66
12 GraphicsServices 0x346dd65e GSEventRunModal + 0x86
13 UIKit 0x32124148 UIApplicationMain + 0x46c
14 XXXXXX 0x0003b1f2 main + 0x1f2
15 libdyld.dylib 0x3a561ab4 start + 0x0
可以看出是因為某個NSException導致程序Crash的，只有拿到這個NSException，獲取它的reason，name，callStackSymbols信息才能確定出問題的程序位置。
/* NSException Class Reference */
@property(readonly, copy) NSString *name;
@property(readonly, copy) NSString *reason;
@property(readonly, copy) NSArray *callStackSymbols;
@property(readonly, copy) NSArray *callStackReturnAddresses;
方法很簡單，可通過注冊NSUncaughtExceptionHandler捕獲異常信息:
static void my_uncaught_exception_handler (NSException *exception) {
//這裡可以取到 NSException 信息
}
NSSetUncaughtExceptionHandler(&my_uncaught_exception_handler);將拿到的NSException細節寫入Crash日志，精准的定位出錯程序位置：
Application Specific Information: *** Terminating app due to uncaught exception 'NSUnknownKeyException', reason: '[ setValue:forUndefinedKey:]: this class is not key value coding-compliant for the key key.' Last Exception Backtrace: 0 CoreFoundation 0x2f8a3f7e __exceptionPreprocess + 0x7e 1 libobjc.A.dylib 0x3a054cc objc_exception_throw + 0x22 2 CoreFoundation 0x2f8a3c94 -[NSException raise] + 0x4 3 Foundation 0x301e8f1e -[NSObject(NSKeyValueCoding) setValue:forKey:] + 0xc6 4 DemoCrash 0x00085306 -[ViewController crashMethod] + 0x6e 5 DemoCrash 0x00084ecc main + 0x1cc 6 DemoCrash 0x00084cf8 start + 0x24
那麼，是不是收到了大量crash在main函數卻沒有NSException信息的日志，就代表自己集成的Crash日志收集服務沒有注冊NSUncaughtExceptionHandler呢？不一定，還有另外一種可能，就是被同時存在的其他Crash日志收集服務給坑了。
多個Crash日志收集服務共存的坑
是的，在自己的程序裡集成多個Crash日志收集服務實在不是明智之舉。通常情況下，第三方功能性SDK都會集成一個Crash收集服務，以及時發現自己SDK的問題。當各家的服務都以保證自己的Crash統計正確完整為目的時，難免出現時序手腳，強行覆蓋等等的惡意競爭，總會有人默默被坑。
1）拒絕傳遞 UncaughtExceptionHandler
如果同時有多方通過NSSetUncaughtExceptionHandler注冊異常處理程序，和平的作法是：後注冊者通過NSGetUncaughtExceptionHandler將先前別人注冊的handler取出並備份，在自己handler處理完後自覺把別人的handler注冊回去，規規矩矩的傳遞。不傳遞強行覆蓋的後果是，在其之前注冊過的日志收集服務寫出的Crash日志就會因為取不到NSException而丟失Last Exception Backtrace等信息。（P.S. iOS系統自帶的Crash Reporter不受影響）
在開發測試階段，可以利用 fishhook 框架去hookNSSetUncaughtExceptionHandler方法，這樣就可以清晰的看到handler的傳遞流程斷在哪裡，快速定位污染環境者。不推薦利用調試器添加符號斷點來檢查，原因是一些Crash收集框架在調試狀態下是不工作的。
檢測代碼示例：
static NSUncaughtExceptionHandler *g_vaildUncaughtExceptionHandler;
static void (*ori_NSSetUncaughtExceptionHandler)( NSUncaughtExceptionHandler * );
void my_NSSetUncaughtExceptionHandler( NSUncaughtExceptionHandler * handler)
{
g_vaildUncaughtExceptionHandler = NSGetUncaughtExceptionHandler();
if (g_vaildUncaughtExceptionHandler != NULL) {
NSLog(@"UncaughtExceptionHandler=%p",g_vaildUncaughtExceptionHandler);
}
ori_NSSetUncaughtExceptionHandler(handler);
NSLog(@"%@",[NSThread callStackSymbols]);
g_vaildUncaughtExceptionHandler = NSGetUncaughtExceptionHandler();
NSLog(@"UncaughtExceptionHandler=%p",g_vaildUncaughtExceptionHandler);
}對於越獄插件注入應用進程內部，惡意覆蓋NSSetUncaughtExceptionHandler的情況，應用程序本身處理起來比較弱勢，因為越獄環境下操作時序的玩法比較多權利比較大。
2）Mach異常端口換出+信號處理Handler覆蓋
和NSSetUncaughtExceptionHandler的情況類似，設置過的Mach異常端口和信號處理程序也有可能被干掉，導致無法捕獲Crash事件。
3）影響系統崩潰日志准確性
應用層參與收集Crash日志的服務方越多，越有可能影響iOS系統自帶的Crash Reporter。由於進程內線程數組的變動，可能會導致系統日志中線程的Crashed 標簽標記錯位，可以搜索abort()等關鍵字來復查系統日志的准確性。 若程序因NSException而Crash，系統日志中的Last Exception Backtrace信息是完整准確的，不會受應用層的胡來而影響，可作為排查問題的參考線索。
ObjC野指針類的Crash
收集Crash日志這個步驟沒有問題的情況下，還是有很多全系統棧的日志的情況，沒有自己一行代碼，分析起來十分棘手，ObjC野指針類的Crash正是如此，這裡推薦幾篇好文章：
如何定位Obj-C野指針隨機Crash(一)：先提高野指針Crash率
如何定位Obj-C野指針隨機Crash(二)：讓非必現Crash變成必現
如何定位Obj-C野指針隨機Crash(三)：加點黑科技讓Crash自報家門
分析objc_msgSend()處崩潰的小技巧
除此之外，在Crash日志中補充記錄一些額外信息可以輔助定位，如切面標記線程出處、隊列出處，記錄用戶操作軌跡等等……
