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