iOS Crash檔案的解析

一、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檔案的解析

iOS Crash檔案的解析

iOS Crash檔案的解析

iOS Crash檔案的解析（一）

相關推薦