首先上一張Hockey裡的crash記錄
Incident Identifier：崩潰報告的唯一辨別符，不同的Crash日志該标示符也不同。
CrashReporter Key：裝置辨別相對應的唯一鍵值(并非真正的裝置的UDID，蘋果為了保護使用者隐私iOS6以後已經無法擷取)。通常同一個裝置上同一版本的App發生Crash時，該值都是一樣的。
Hardware Model ：代表發生Crash的裝置類型。
Process：代表系統Crash的程序名稱，通常都是我們的App的名字, [ ]裡面是當時程序的ID。
Path：App的所在路徑。
Identifier：我們App的Indentifier，就是你app的bundle Indentifier。
AppVersion：目前App的版本号，由Info.plist中的兩個字段組成，CFBundleShortVersionString and CFBundleVersion。
Code Type：目前App的CPU架構。
Parent Process：目前程序的父程序，由于iOS中App通常都是單程序的，一般父程序都是launchd。
Date/Time：發生crash的時間
Launch Time：啟動App的時間
OS Version：iOS系統固件版本
Report Version：日志版本
Exception Type： 這個資訊非常重要，它就像是這個crash的名字。
Crashed Thread： 問題發生的thread
我一般都直接看最後的thread 然後找到對應的crash的thread
一般這個thread 後都會跟着crash。 然後從下往上是堆棧資訊，這裡左邊數字後跟着你們項目的Target 說明是代碼裡的問題 如果是Foundation 或者 其他的，可以忽略。找到最後你們Target那一條目，然後後邊跟着的方法 以及類裡多少行，友善你去定位錯誤位置。
但是有些問題隻看這裡，是解決不了的！
這時候就需要Exception Type 還有其他的地方來配合看了。
1. 首先有一些常見的Exception code，https://en.wikipedia.org/wiki/Hexspeak 請自行檢視。
2. Exception Type
1）EXC_BAD_ACCESS
此類型的Excpetion是我們最長碰到的Crash，通常用于通路了不改通路的記憶體導緻。一般EXC_BAD_ACCESS後面的"()"還會帶有補充資訊。
SIGSEGV:通常由于重複釋放對象導緻，這種類型在切換了ARC以後應該已經很少見到了。
SIGABRT:收到Abort信号退出，通常Foundation庫中的容器為了保護狀态正常會做一些檢測，例如插入nil到數組中等會遇到此類錯誤。
SEGV:（Segmentation Violation），代表無效記憶體位址，比如空指針，未初始化指針，棧溢出等；
SIGBUS：總線錯誤，與 SIGSEGV 不同的是，SIGSEGV 通路的是無效位址，而 SIGBUS 通路的是有效位址，但總線通路異常(如位址對齊問題)
SIGILL：嘗試執行非法的指令，可能不被識别或者沒有權限
2）EXC_BAD_INSTRUCTION
此類異常通常由于線程執行非法指令導緻。
1.在代碼中修改了storyboard與outlet的對應關系，但是storyboard沒有更新時發生過此crash。
2.與第三方庫中方法沖突時發生過此crash。
3.調用系統方法時傳入了不恰當的指針類型。
3）EXC_ARITHMETIC
代碼中做除法時分母為零了會發生此問題。