原文：http://www.cnblogs.com/smileEvday/p/Crash1.html
開發(fā)程序的過程中不管我們已經(jīng)如何小心甘晤，總是會在不經(jīng)意間遇到程序閃退洽洁。腦補一下當(dāng)你在一群人面前自信的拿著你的App做功能預(yù)演的時候，流暢的操作被無情地Crash打斷晦譬。聯(lián)想起老羅在發(fā)布Smartisan OS的時候說了叭首，他準(zhǔn)備了10個手機习勤，如果一臺有問題，就換一臺焙格，如果10臺后掛了他就不做手機了图毕。好了不閑扯了，今天就跟大家一起聊聊iOSCrash文件的組成以及常用的分析工具眷唉。
有一個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中的兩個字段組成，CFBundleShortVersionStringandCFBundleVersion
Code Type當(dāng)前App的CPU架構(gòu)
Parent Process當(dāng)前進程的父進程淘衙，由于iOS中App通常都是單進程的传藏，一般父進程都是launchd
2、Basic Information
Date/TimeCrash發(fā)生的時間彤守，可讀的字符串
OS Version系統(tǒng)版本漩氨，（）內(nèi)的數(shù)字代表的時Bulid號
Report VersionCrash日志的格式，目前基本上都是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
緊接著下面會有一段描述：
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
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
除零錯誤會拋出此類異常
2奏篙、Exception Code
0xbaaaaaad此種類型的log意味著該Crash log并非一個真正的Crash柴淘，它僅僅只是包含了整個系統(tǒng)某一時刻的運行狀態(tài)。通趁赝ǎ可以通過同時按Home鍵和音量鍵为严，可能由于用戶不小心觸發(fā)
0xbad22222當(dāng)VOIP程序在后臺太過頻繁的激活時，系統(tǒng)可能會終止此類程序
0x8badf00d這個前面已經(jīng)介紹了肺稀，程序啟動或者恢復(fù)時間過長被watch dog終止
0xc00010ff程序執(zhí)行大量耗費CPU和GPU的運算第股，導(dǎo)致設(shè)備過熱，觸發(fā)系統(tǒng)過熱保護被系統(tǒng)終止
0xdead10cc程序退到后臺時還占用系統(tǒng)資源话原，如通訊錄被系統(tǒng)終止
0xdeadfa11前面也提到過夕吻，程序無響應(yīng)用戶強制關(guān)閉
三、獲取Crash的途徑
1繁仁、本機
通過xCode連接測試機器涉馅，直接在Device中即可讀取到該機器上發(fā)生的所有Crash log黄虱。
2稚矿、itunes connect
通過itunes connect后臺獲取到用戶上報的Crash日志捻浦。
3、第三方的Crash收集系統(tǒng)
有很多優(yōu)秀的第三方Crash收集系統(tǒng)大大的方便了我們收集Crash朱灿，甚至還帶了符號化Crash日志的功能昧识。比較常用的有Crashlytics，Flurry等母剥。
四、附錄
Apple官方文檔：Understanding and Analyzing iOS Application Crash Reports
Technical Note TN2123?CrashReporter
https://developer.apple.com/library/ios/qa/qa1592/_index.html
WWDC視頻：Understanding Crash Reports on iPhone OS
Crash日志記錄的時候是將Crash發(fā)生時刻习霹，函數(shù)的調(diào)用棧，以及線程等信息寫入文件炫隶。一般都是直接寫的16進制地址淋叶，如果不經(jīng)過符號化的話，基本上很難獲取到有用信息伪阶，下一篇我們將聊一聊Crash日志的符號化处嫌，通俗點講就是讓Crash日志變成我們可讀的格式斟湃。
