轉至
一、crash檔案結構
當程式執行crash的時候，系統會把執行的最後時刻的執行資訊記錄下來，儲存到乙個檔案中，也就是我們所說的crash檔案。ios的crash日誌通常由以下6各部分組成。
1、process information(程序資訊)
崩潰報告的唯一識別符號，不同的crash
crashreporter key
hardware model
代表發生crash的裝置型別，上圖中的「ipad4,4」代表ipad air
crash發生的時間，可讀的字串
os version
系統版本，（）內的數字代表的時bulid號
report version
crash日誌的格式，目前基本上都是104，不同的version裡面包含的字段可能有不同
3、exception（非常重要）
異常型別
exception subtype:
異常子型別
crashed thread
發生異常的執行緒號
發生crash的執行緒的crash呼叫棧，從上到下分別代表呼叫順序，最上面的乙個表示丟擲異常的位置，依次往下可以看到api的呼叫順序。上圖的資訊表明本次crash出現***viewcontroller的323行，出錯的函式呼叫為ordercountloadfailed。
crash時發生時刻，執行緒的狀態，通常我們根據crash棧即可獲取到相關資訊，這部分一般不用關心。
二、常見的crash型別
1、watchdog timeout
exception code：0x8badf00d， 不太直觀，可以讀成「eat bad food」，意思是don『t block main thread
緊接著下面會有一段描述：
com.***.yyy failed to resume in time
ps. 在連線xcode除錯時為了便於除錯，系統會暫時禁用掉watchdog，所以此類問題的發現需要使用正常的啟動模式。
2、user force-quit
exception codes: 0xdeadfa11, deadfall
這個強制退出跟我們平時所說的kill掉後台任務操作還不太一樣，通常在程式bug造成系統無法響應時可以採用長按電源鍵，當螢幕出現關機確認畫面時按下home鍵即可關閉當前程式。
3、low memory termination
跟一般的crash結構不太一樣，通常有free pages，wired pages，purgeable pages，largest process 組成，同事會列出當前時刻系統執行所有程序的資訊。
關於memory warning可以參看我之前寫的一篇文章ios 記憶體警告 memory warning level。
4、crash due to bugs
因為程式bug導致的crash通常千奇百怪，很難一概而論。大部分情況通過crash日誌就可以定位出問題，當然也不排除部分疑難雜症看半天都不值問題出在哪兒。這個就只能看功底了，一點點找，總是能發現蛛絲馬跡。是在看不出來時還可以求助於google大神，總有人遇到和你一樣的bug
三、常見的exception type & exception code
1、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
此類異常通常由於執行緒執行非法指令導致
3）exc_arithmetic
除零錯誤會丟擲此類異常
2、exception code
0xbaaaaaad
此種型別的log意味著該crash log並非乙個真正的crash，它僅僅只是包含了整個系統某一時刻的執行狀態。通常可以通過同時按home鍵和音量鍵，可能由於使用者不小心觸發
0xbad22222
當voip程式在後台太過頻繁的啟用時，系統可能會終止此類程式
0x8badf00d
這個前面已經介紹了，程式啟動或者恢復時間過長被watch dog終止
0xc00010ff
程式執行大量耗費cpu和gpu的運算，導致裝置過熱，觸發系統過熱保護被系統終止
0xdead10cc
程式退到後台時還占用系統資源，如通訊錄被系統終止
0xdeadfa11
前面也提到過，程式無響應使用者強制關閉
三、獲取crash的途徑
1、本機
通過xcode連線測試機器，直接在device中即可讀取到該機器上發生的所有crash log。
2、itunes connect
通過itunes connect後台獲取到使用者上報的crash日誌。
3、第三方的crash收集系統
有很多優秀的第三方crash收集系統大大的方便了我們收集crash，甚至還帶了符號化crash日誌的功能。比較常用的有crashlytics，flurry等。
四、附錄
iOS Crash檔案的解析
一 crash檔案結構 當程式執行crash的時候，系統會把執行的最後時刻的執行資訊記錄下來，儲存到乙個檔案中，也就是我們所說的crash檔案。ios的crash日誌通常由以下6各部分組成。1 process information 程序資訊 incident idnetifier 崩潰報告的唯一識...
iOS Crash檔案的解析
一 crash檔案結構 當程式執行crash的時候，系統會把執行的最後時刻的執行資訊記錄下來，儲存到乙個檔案中，也就是我們所說的crash檔案。ios的crash日誌通常由以下6各部分組成。1 process information 程序資訊 incident idnetifier 崩潰報告的唯一識...
iOS Crash檔案的解析
一 crash檔案結構 當程式執行crash的時候，系統會把執行的最後時刻的執行資訊記錄下來，儲存到乙個檔案中，也就是我們所說的crash檔案。ios的crash日誌通常由以下6各部分組成。1 process information 程序資訊 崩潰報告的唯一識別符號，不同的crash crashre...