以下為文章正文，如果覺得有用，歡迎給她打賞。
為了能夠第一時間發(fā)現(xiàn)程序問題，應用程序需要實現(xiàn)自己的崩潰日志收集服務，成熟的開源項目很多，如KSCrash，plcrashreporter，CrashKit等。追求方便省心，對于保密性要求不高的程序來說，也可以選擇各種一條龍 Crash 統(tǒng)計產(chǎn)品，如Crashlytics，Hockeyapp，友盟，Bugly等等。
是否集成越多的 Crash 日志收集服務就越保險？
自己收集的 Crash 日志和系統(tǒng)生成的 Crash 日志有分歧，應該相信誰？
為什么有大量 Crash 日志顯示崩在 main 函數(shù)里，但函數(shù)棧中卻沒有一行自己的代碼？
野指針類的 Crash 難定位，有何妙招來應對？
想解釋清這些問題，必須從 Mach 異常說起。
Mach 異常與 Unix 信號
iOS 系統(tǒng)自帶的 Apple’s Crash Reporter 記錄在設備中的 Crash 日志，Exception Type 項通常會包含兩個元素： Mach 異常 和 Unix 信號。
Exception Type:? ? ? ? EXC_BAD_ACCESS (SIGSEGV)
Exception Subtype:? ? ? KERN_INVALID_ADDRESS at 0x041a6f3
Mach 異常是什么？它又是如何與 Unix 信號建立聯(lián)系的？
Mach 是一個 XNU 的微內(nèi)核核心，Mach 異常是指最底層的內(nèi)核級異常，被定義在下 。每個 thread，task，host 都有一個異常端口數(shù)組，Mach 的部分 API 暴露給了用戶態(tài)，用戶態(tài)的開發(fā)者可以直接通過 Mach API 設置 thread，task，host 的異常端口，來捕獲 Mach 異常，抓取 Crash 事件。
所有 Mach 異常都在 host 層被ux_exception轉換為相應的 Unix 信號，并通過threadsignal將信號投遞到出錯的線程。iOS 中的 POSIX API 就是通過 Mach 之上的 BSD 層實現(xiàn)的。
因此，EXC_BAD_ACCESS (SIGSEGV)表示的意思是：Mach 層的EXC_BAD_ACCESS異常，在 host 層被轉換成 SIGSEGV 信號投遞到出錯的線程。既然最終以信號的方式投遞到出錯的線程，那么就可以通過注冊 signalHandler 來捕獲信號:
signal(SIGSEGV,signalHandler);
捕獲 Mach 異常或者 Unix 信號都可以抓到 crash 事件，這兩種方式哪個更好呢？優(yōu)選 Mach 異常，因為 Mach 異常處理會先于 Unix 信號處理發(fā)生，如果 Mach 異常的 handler 讓程序 exit 了，那么 Unix 信號就永遠不會到達這個進程了。轉換 Unix 信號是為了兼容更為流行的 POSIX 標準 (SUS 規(guī)范)，這樣不必了解 Mach 內(nèi)核也可以通過 Unix 信號的方式來兼容開發(fā)。
小貼士:
因為硬件產(chǎn)生的信號 (通過 CPU 陷阱) 被 Mach 層捕獲，然后才轉換為對應的 Unix 信號；蘋果為了統(tǒng)一機制，于是操作系統(tǒng)和用戶產(chǎn)生的信號 (通過調(diào)用kill和pthread_kill) 也首先沉下來被轉換為 Mach 異常，再轉換為 Unix 信號。
Crash 收集的實現(xiàn)思路
正如上述所說，可以通過捕獲 Mach 異常、或 Unix 信號兩種方式來抓取 crash 事件，于是總結起來實現(xiàn)方案就一共有 3 種。
1）Mach 異常方式
2）Unix 信號方式
signal(SIGSEGV,signalHandler);
3）Mach 異常 +Unix 信號方式
Github 上多數(shù)開源項目都采用的這種方式，即使在優(yōu)選捕獲 Mach 異常的情況下，也放棄捕獲EXC_CRASH異常，而選擇捕獲與之對應的 SIGABRT 信號。著名開源項目plcrashreporter在代碼注釋中給出了詳細的解釋：
We still need to use signal handlers to catch SIGABRT in-process. The kernel sends anEXC_CRASHmach 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 forEXC_CRASH.
另外，需要重點說明的是：對于應用級異常 NSException，還需要特殊處理。
你是否見過崩潰在 main 函數(shù)的 crash 日志，但是函數(shù)棧里面沒有你的代碼：
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 細節(jié)寫入 Crash 日志，精準的定位出錯程序位置：
Application Specific Information:
*** Terminating app due to uncaught exception 'NSUnknownKeyException', reason: '[<__NSDictionaryI 0x14554d00> 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 函數(shù)卻沒有 NSException 信息的日志，就代表自己集成的 Crash 日志收集服務沒有注冊 NSUncaughtExceptionHandler 呢？不一定，還有另外一種可能，就是被同時存在的其他 Crash 日志收集服務給坑了。
多個 Crash 日志收集服務共存的坑
是的，在自己的程序里集成多個 Crash 日志收集服務實在不是明智之舉。通常情況下，第三方功能性 SDK 都會集成一個 Crash 收集服務，以及時發(fā)現(xiàn)自己 SDK 的問題。當各家的服務都以保證自己的 Crash 統(tǒng)計正確完整為目的時，難免出現(xiàn)時序手腳，強行覆蓋等等的惡意競爭，總會有人默默被坑。
1）拒絕傳遞 UncaughtExceptionHandler
如果同時有多方通過 NSSetUncaughtExceptionHandler 注冊異常處理程序，和平的作法是：后注冊者通過 NSGetUncaughtExceptionHandler 將先前別人注冊的 handler 取出并備份，在自己 handler 處理完后自覺把別人的 handler 注冊回去，規(guī)規(guī)矩矩的傳遞。不傳遞強行覆蓋的后果是，在其之前注冊過的日志收集服務寫出的 Crash 日志就會因為取不到 NSException 而丟失Last Exception Backtrace等信息。（P.S. iOS 系統(tǒng)自帶的 Crash Reporter 不受影響）
在開發(fā)測試階段，可以利用fishhook框架去 hookNSSetUncaughtExceptionHandler方法，這樣就可以清晰的看到 handler 的傳遞流程斷在哪里，快速定位污染環(huán)境者。不推薦利用調(diào)試器添加符號斷點來檢查，原因是一些 Crash 收集框架在調(diào)試狀態(tài)下是不工作的。
檢測代碼示例：
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);
}
對于越獄插件注入應用進程內(nèi)部，惡意覆蓋 NSSetUncaughtExceptionHandler 的情況，應用程序本身處理起來比較弱勢，因為越獄環(huán)境下操作時序的玩法比較多權利比較大。
2）Mach 異常端口換出 + 信號處理 Handler 覆蓋
和 NSSetUncaughtExceptionHandler 的情況類似，設置過的 Mach 異常端口和信號處理程序也有可能被干掉，導致無法捕獲 Crash 事件。
3）影響系統(tǒng)崩潰日志準確性
應用層參與收集 Crash 日志的服務方越多，越有可能影響 iOS 系統(tǒng)自帶的 Crash Reporter。由于進程內(nèi)線程數(shù)組的變動，可能會導致系統(tǒng)日志中線程的Crashed標簽標記錯位，可以搜索abort()等關鍵字來復查系統(tǒng)日志的準確性。
若程序因 NSException 而 Crash，系統(tǒng)日志中的Last Exception Backtrace信息是完整準確的，不會受應用層的胡來而影響，可作為排查問題的參考線索。
ObjC 野指針類的 Crash
收集 Crash 日志這個步驟沒有問題的情況下，還是有很多全系統(tǒng)棧的日志的情況，沒有自己一行代碼，分析起來十分棘手，ObjC 野指針類的 Crash 正是如此，這里推薦幾篇好文章：
如何定位 Obj-C 野指針隨機 Crash(一)：先提高野指針 Crash 率
http://bugly.qq.com/blog/?p=200
如何定位 Obj-C 野指針隨機 Crash(二)：讓非必現(xiàn) Crash 變成必現(xiàn)
http://bugly.qq.com/blog/?p=308
如何定位 Obj-C 野指針隨機 Crash(三)：加點黑科技讓 Crash 自報家門
http://bugly.qq.com/blog/?p=335
分析 objc_msgSend() 處崩潰的小技巧
除此之外，在 Crash 日志中補充記錄一些額外信息可以輔助定位，如切面標記線程出處、隊列出處，記錄用戶操作軌跡等等……
