收集crash日誌方式
1.裝置上直接檢視
路徑：設定 -> 隱私 -> 分析 -> 分析資料
2.xcode獲取裝置上資訊
路徑：xcode選單欄window -> devices and simulators -> 選中裝置 -> view device logs
3.xcode獲取發布版本崩潰資訊
路徑：xcode選單欄window -> organizer -> 選擇專案 -> tab選擇crashes
下圖中：
1為崩潰資訊列表；
2可選擇發布版本；
3為具體崩潰堆疊資訊；
4可選擇源**，跟蹤具體崩潰位置。
image.png
4.**捕捉崩潰資訊
1.第三方平台：bugly、友盟;
2.**捕獲crash，監聽nssetuncaughtexceptionhandler和signal事件，可借助第三方工具kscrash、plcrashreporter等。
**捕獲crash
crash的型別
crash的捕獲的方式
mach 異常捕獲。基於mach核心程式設計，需要對核心有一定了解.
unix 訊號捕獲。對於mach 異常，作業系統會將其轉換為對應的 unix訊號，可以通過註冊signalhandler的方式來做訊號異常。
signal(sigabrt, signalexceptionhandler)
n***ception 捕獲。應用層，通過 nsuncaughtexceptionhandler 捕獲，因為堆疊中不會有出錯**，所以需要獲取n***ception物件中的reason,name,callstacksymbols。然後把細節寫入crash日誌，上傳到後台做資料分析.
nssetuncaughtexceptionhandler(uncaughtexceptionhandler)
debug模式下，signal監聽無效問題
在debug模式下，如果你觸發了signal崩潰，那麼應用會直接崩潰到主函式，斷點都沒用，此時沒有任何log資訊顯示出來，如果你想看log資訊的話，你需要在會crash的那行**上打斷點，然後在console中輸入pro hand -p true -s false sigabrt命令(sigabrt只是示例，應輸對應的訊號錯誤)，然後下一步，不然你啥也看不到。
image.png
image.png
衝突當專案中存在多個crash收集框架時往往會存在衝突。
因為不管是對於 signal 捕獲還是 n***ception 捕獲都會存在 handler 覆蓋的問題，應該先判斷handler是否存在，如果存在剛 儲存handler，處理完自己的 handler 後，再把這個 handler 丟擲去，供前面的註冊者處理，詳情見demo。
堆疊收集
無論unix 訊號捕獲，還是n***ception 捕獲，都只能獲取到當前執行緒的堆疊，如果想獲取所有執行緒的堆疊，可以考慮用這個框架：
堆疊符號解析
無論是採用何種方式收集到的崩潰資訊，都會面臨同乙個問題，堆疊大概率是沒有被符號化過的，對於開發者來說，是根本看不懂的，那就無從談起問題的定位了。這個時候就需要進行堆疊符號化了。
堆疊符號化還原有三種常見的方法：
1.symbolicatecrash
2.mac 下的 atos 工具
3.通過 dsym 檔案提取位址和符號的對應關係，進行符號還原
獲取dsym檔案：xcode選單欄window -> organizer -> 選擇專案 -> tab選擇crashes -> achieve包 -> show in finder -> 右鍵顯示包內容 -> 開啟dsyms資料夾
// 未符號化前
thread 0 crashed:
0 libobjc.a.dylib 0x000000018b816f30 0x18b7fc000 + 110384 (objc_msgsend + 16)
1 uikit 0x0000000192e0a79c 0x192c05000 + 2119580 ( + 72)
2 uikit 0x0000000192c4db48 0x192c05000 + 297800 ( + 312)
3 uikit 0x0000000192c4d988 0x192c05000 + 297352 ( + 160)
4 quartzcore 0x00000001900d6404 0x18ffc5000 + 1119236 ( + 260)
// 符號化後
thread 0 crashed:
0 libobjc.a.dylib 0x000000018b816f30 objc_msgsend + 16
1 uikit 0x0000000192e0a79c -[uisearchdisplaycontroller _senddelegatedidbegindidendsearch] + 72
2 uikit 0x0000000192c4db48 -[uiviewanimationstate senddelegateanimationdidstop:finished:] + 312
3 uikit 0x0000000192c4d988 -[uiviewanimationstate animationdidstop:finished:] + 160
4 quartzcore 0x00000001900d6404 ca::layer::run_animation_callbacks(void*) + 260
注：xcode的organizer內建了symbolicatecrash，所以我們才可以直接看到符號化的崩潰堆疊日誌。
資料：實戰ios崩潰堆疊的符號化解析
crash防護
crash型別
1.unrecognized selector crash
2.kvo crash
3.nsnotification crash
4.nstimer crash
5.container crash(陣列越界，插nil等)
6.nsstring crash (字串操作的crash)
7.ui not on main thread crash (非主線程刷ui(機制待改善))
防護
IOS崩潰日誌
1.普通崩潰日誌 參考 1 程序資訊 incident identifier 30e46451 53fd 4965 896a 457fc11ad05f 崩潰報告的唯一識別符號 是與裝置標識相對應的唯一鍵值。雖然它不是真正的裝置識別符號，但也是乙個非常有用的情報 如果你看到100個崩潰日誌的crash...
iOS應用崩潰（三） 崩潰日誌
當我們在模擬器上除錯時，可能經常遇到下面的記憶體訪問錯誤 該錯誤是對乙個已經釋放的物件進行操作，定位如下 2 終端輸入 info malloc history 命令，即可得到堆疊資訊，從而分析具體問題所在 gdb info malloc history 0x12e4b0 3 也可輸入如下資訊 gdb...
iOS程式崩潰日誌
void uncaughtexceptionhandler n ception exception 當然你還要在以下方法中新增呼叫 nssetuncaughtexceptionhandler uncaughtexceptionhandler 錯誤日誌收集 下面時陣列越界時返回的錯誤日誌 arr 0 ...