iOS Crash文件的解析（一）

螢火與皓月 2015-01-26

展開全文

發(fā)程序的過程中不管我們已經(jīng)如何小心，總是會在不經(jīng)意間遇到程序閃退。腦補一下當(dāng)你在一群人面前自信的拿著你的App做功能預(yù)演的時候，流暢的操作被無情地Crash打斷。聯(lián)想起老羅在發(fā)布Smartisan OS的時候說了，他準(zhǔn)備了10個手機，如果一臺有問題，就換一臺，如果10臺后掛了他就不做手機了。好了不閑扯了，今天就跟大家一起聊聊iOS Crash文件的組成以及常用的分析工具。

有一個WWDC 2010的視頻推薦大家抽空看看，視頻名稱“Understanding Crash Reports on iPhone OS”，該視頻詳細(xì)講解了Crash文件的結(jié)構(gòu)。當(dāng)然如果你沒時間看的話，不妨閱讀以下這篇文章。

一、Crash文件結(jié)構(gòu)

當(dāng)程序運行Crash的時候，系統(tǒng)會把運行的最后時刻的運行信息記錄下來，存儲到一個文件中，也就是我們所說的Crash文件。iOS的Crash日志通常由以下6各部分組成。

1、Process Information(進程信息)

Incident Idnetifier-崩潰報告的唯一標(biāo)識符，不同的Crash

CrashReporter Key-設(shè)備標(biāo)識相對應(yīng)的唯一鍵值(并非真正的設(shè)備的UDID，蘋果為了保護用戶隱私iOS6以后已經(jīng)無法獲取)。通常同一個設(shè)備上同一版本的App發(fā)生Crash時，該值都是一樣的。

Hardware Model-代表發(fā)生Crash的設(shè)備類型，上圖中的“iPad4,4”代表iPad Air

Process-代表Crash的進程名稱，通常都是我們的App的名字, []里面是當(dāng)時進程的ID

Path-可執(zhí)行程序在手機上的存儲位置，注意路徑時到XXX.app/XXX，XXX.app其實是作為一個Bundle的，真正的可執(zhí)行文件其實是Bundle里面的XXX，感興趣的可以自己查一下相關(guān)資料，有機會我后面也會介紹到

Identifier-你的App的Indentifier，通常為“com.xxx.yyy”，xxx代表你們公司的域名，yyy代表某一個App

Version-當(dāng)前App的版本號，由Info.plist中的兩個字段組成，CFBundleShortVersionString and CFBundleVersion

Code Type-當(dāng)前App的CPU架構(gòu)

Parent Process-當(dāng)前進程的父進程，由于iOS中App通常都是單進程的，一般父進程都是launchd

2、Basic Information

Date/Time-Crash發(fā)生的時間，可讀的字符串

OS Version-系統(tǒng)版本，（）內(nèi)的數(shù)字代表的時Bulid號

Report Version-Crash日志的格式，目前基本上都是104，不同的version里面包含的字段可能有不同

3、Exception（非常重要）

Exception Type-異常類型

Exception Subtype-異常子類型

Crashed Thread-發(fā)生異常的線程號

4、Thread Backtrace

發(fā)生Crash的線程的Crash調(diào)用棧，從上到下分別代表調(diào)用順序，最上面的一個表示拋出異常的位置，依次往下可以看到API的調(diào)用順序。上圖的信息表明本次Crash出現(xiàn)xxxViewController的323行，出錯的函數(shù)調(diào)用為orderCountLoadFailed。

5、Thread State

Crash時發(fā)生時刻，線程的狀態(tài)，通常我們根據(jù)Crash棧即可獲取到相關(guān)信息，這部分一般不用關(guān)心。

6、Binary Images

Crash時刻App加載的所有的庫，其中第一行是Crash發(fā)生時我們App可執(zhí)行文件的信息，可以看出為armv7，可執(zhí)行文件的包得uuid位c0f……cd65，解析Crash的時候dsym文件的uuid必須和這個一樣才能完成Crash的符號化解析。

二、常見的Crash類型

1、Watchdog timeout

Exception Code：0x8badf00d，不太直觀，可以讀成“eat bad food”，意思是don‘t block main thread

緊接著下面會有一段描述：

1 2	`Application Specific Information：` `com.xxx.yyy　　 failed to resume` `in` `time`

對于此類Crash，我們應(yīng)該去審視自己App初始化時做的事情是否正確，是否在主線程請求了網(wǎng)絡(luò)，或者其他耗時的事情卡住了正常初始化流程。

通常系統(tǒng)允許一個App從啟動到可以相應(yīng)用戶事件的時間最多為5S，如果超過了5S，App就會被系統(tǒng)終止掉。在Launch，resume，suspend，quit時都會有相應(yīng)的時間要求。在Highlight Thread里面我們可以看到被終止時調(diào)用到的位置，xxxAppDelegate加上行號。

PS. 在連接Xcode調(diào)試時為了便于調(diào)試，系統(tǒng)會暫時禁用掉Watchdog，所以此類問題的發(fā)現(xiàn)需要使用正常的啟動模式。

2、User force-quit

1	`Exception Codes: 0xdeadfa11, deadfall`

這個強制退出跟我們平時所說的kill掉后臺任務(wù)操作還不太一樣，通常在程序bug造成系統(tǒng)無法響應(yīng)時可以采用長按電源鍵，當(dāng)屏幕出現(xiàn)關(guān)機確認(rèn)畫面時按下Home鍵即可關(guān)閉當(dāng)前程序。

3、Low Memory termination

跟一般的Crash結(jié)構(gòu)不太一樣，通常有Free pages，Wired Pages，Purgeable pages，largest process 組成，同事會列出當(dāng)前時刻系統(tǒng)運行所有進程的信息。

關(guān)于Memory warning可以參看我之前寫的一篇文章IOS 內(nèi)存警告 Memory warning level。

App在運行過程中，系統(tǒng)內(nèi)存緊張時通常會先發(fā)警告，同時把后臺掛起的程序終止掉，最終如果還是內(nèi)存不夠的話就會終止掉當(dāng)前前臺的進程。

當(dāng)接受到內(nèi)存警告的事后，我們應(yīng)該釋放盡可能多的內(nèi)存，Crash其實也可以看做是對App的一種保護。

4、Crash due to bugs

因為程序bug導(dǎo)致的Crash通常千奇百怪，很難一概而論。大部分情況通過Crash日志就可以定位出問題，當(dāng)然也不排除部分疑難雜癥看半天都不值問題出在哪兒。這個就只能看功底了，一點點找，總是能發(fā)現(xiàn)蛛絲馬跡。是在看不出來時還可以求助于Google大神，總有人遇到和你一樣的Bug

三、常見的Exception Type & Exception Code

1、Exception Type

1）EXC_BAD_ACCESS

此類型的Excpetion是我們最長碰到的Crash，通常用于訪問了不改訪問的內(nèi)存導(dǎo)致。一般EXC_BAD_ACCESS后面的"()"還會帶有補充信息。

SIGSEGV: 通常由于重復(fù)釋放對象導(dǎo)致，這種類型在切換了ARC以后應(yīng)該已經(jīng)很少見到了。

SIGABRT: 收到Abort信號退出，通常Foundation庫中的容器為了保護狀態(tài)正常會做一些檢測，例如插入nil到數(shù)組中等會遇到此類錯誤。

SEGV:（Segmentation Violation），代表無效內(nèi)存地址，比如空指針，未初始化指針，棧溢出等；

SIGBUS：總線錯誤，與 SIGSEGV 不同的是，SIGSEGV 訪問的是無效地址，而 SIGBUS 訪問的是有效地址，但總線訪問異常(如地址對齊問題)

SIGILL：嘗試執(zhí)行非法的指令，可能不被識別或者沒有權(quán)限

2）EXC_BAD_INSTRUCTION

此類異常通常由于線程執(zhí)行非法指令導(dǎo)致

3）EXC_ARITHMETIC