iOS中Crash文件崩潰捕獲分析及符號(hào)化思路

最近在做 Crash 分析方面的工作，發(fā)現(xiàn) iOS 的崩潰捕獲和堆棧符號(hào)化雖然已經(jīng)有很多資料可以參考，但是沒(méi)有比較完善的成套解決方案，導(dǎo)致操作起來(lái)還是要踩很多坑，耽誤了很多時(shí)間。所以想做一個(gè)總結(jié)，闡述 Crash 收集分析的整體思路和出坑指南，具體細(xì)節(jié)實(shí)現(xiàn)會(huì)給出相關(guān)參考資料。有了思路，實(shí)現(xiàn)也就 So Easy 啦。

崩潰捕獲

對(duì)于崩潰捕獲，以前在 移動(dòng)端監(jiān)控體系之技術(shù)原理剖析 中詳細(xì)闡述過(guò)，并且給出了相應(yīng)的 Demo，崩潰主要是由于 Mach 異常、Objective-C 異常（NSException）引起的，同時(shí)對(duì)于 Mach 異常，到了 BSD 層會(huì)轉(zhuǎn)換為對(duì)應(yīng)的 Signal 信號(hào)，那么我們也可以通過(guò)捕獲信號(hào)，來(lái)捕獲 Crash 事件。針對(duì) NSException 可以通過(guò)注冊(cè) NSUncaughtExceptionHandler 捕獲異常信息。下圖摘自阿里百川，簡(jiǎn)潔明了的展現(xiàn)了客戶(hù)端崩潰分析架構(gòu)。

?

沖突

在我們自己研發(fā) Crash 收集框架之前，最早肯定都會(huì)接入網(wǎng)易云捕、騰訊 Bugly、Fabric 等第三方日志框架來(lái)進(jìn)行崩潰的收集和分析。如果多個(gè) Crash 收集框架存在時(shí)，往往會(huì)存在沖突。

不管是對(duì)于 Signal 捕獲還是 NSException 捕獲都會(huì)存在 handler 覆蓋的問(wèn)題，正確的做法應(yīng)該是先判斷是否有前者已經(jīng)注冊(cè)了 handler，如果有則應(yīng)該把這個(gè) handler 保存下來(lái)，在自己處理完自己的 handler 之后，再把這個(gè) handler 拋出去，供前面的注冊(cè)者處理。這里給出相應(yīng)的 Demo，Demo 由@zerygao提供。