開發程序的過程中不管我們已經如何小心，總是會在不經意間遇到程序閃退。腦補一下當你在一群人面前自信的拿著你的App做功能預演的時候，流暢的操作被無情地Crash打斷。聯想起老羅在發布Smartisan OS的時候說了，他准備了10個手機，如果一台有問題，就換一台，如果10台後掛了他就不做手機了。好了不閒扯了，今天就跟大家一起聊聊iOSCrash文件的組成以及常用的分析工具。   　　有一個WWDC 2010的視頻推薦大家抽空看看，視頻名稱“Understanding Crash Reports on iPhone OS”，該視頻詳細講解了Crash文件的結構。當然如果你沒時間看的話，不妨閱讀以下這篇文章。       一、Crash文件結構   當程序運行Crash的時候，系統會把運行的最後時刻的運行信息記錄下來，存儲到一個文件中，也就是我們所說的Crash文件。iOS的Crash日志通常由以下6各部分組成。   1、Process Information(進程信息)       Incident Idnetifier 崩潰報告的唯一標識符，不同的Crash CrashReporter Key 設備標識相對應的唯一鍵值(並非真正的設備的UDID，蘋果為了保護用戶隱私iOS6以後已經無法獲取)。通常同一個設備上同一版本的App發生Crash時，該值都是一樣的。 Hardware Model 代表發生Crash的設備類型，上圖中的“iPad4,4”代表iPad Air Process 代表Crash的進程名稱，通常都是我們的App的名字, []裡面是當時進程的ID Path 可執行程序在手機上的存儲位置，注意路徑時到XXX.app/XXX，XXX.app其實是作為一個Bundle的，真正的可執行文件其實是Bundle裡面的XXX，感興趣的可以自己查一下相關資料，有機會我後面也會介紹到 Identifier 你的App的Indentifier，通常為“com.xxx.yyy”，xxx代表你們公司的域名，yyy代表某一個App Version 當前App的版本號，由Info.plist中的兩個字段組成，CFBundleShortVersionString and CFBundleVersion Code Type 當前App的CPU架構 Parent Process 當前進程的父進程，由於iOS中App通常都是單進程的，一般父進程都是launchd     2、Basic Information       Date/Time Crash發生的時間，可讀的字符串 OS Version 系統版本，（）內的數字代表的時Bulid號 Report Version Crash日志的格式，目前基本上都是104，不同的version裡面包含的字段可能有不同             3、Exception（非常重要）       Exception Type 異常類型 Exception Subtype: 異常子類型 Crashed Thread 發生異常的線程號             4、Thread Backtrace       發生Crash的線程的Crash調用棧，從上到下分別代表調用順序，最上面的一個表示拋出異常的位置，依次往下可以看到API的調用順序。上圖的信息表明本次Crash出現xxxViewController的323行，出錯的函數調用為orderCountLoadFailed。   5、Thread State       Crash時發生時刻，線程的狀態，通常我們根據Crash棧即可獲取到相關信息，這部分一般不用關心。   6、Binary Images       Crash時刻App加載的所有的庫，其中第一行是Crash發生時我們App可執行文件的信息，可以看出為armv7，可執行文件的包得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，我們應該去審視自己App初始化時做的事情是否正確，是否在主線程請求了網絡，或者其他耗時的事情卡住了正常初始化流程。   通常系統允許一個App從啟動到可以相應用戶事件的時間最多為5S，如果超過了5S，App就會被系統終止掉。在Launch，resume，suspend，quit時都會有相應的時間要求。在Highlight Thread裡面我們可以看到被終止時調用到的位置，xxxAppDelegate加上行號。    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。   App在運行過程中，系統內存緊張時通常會先發警告，同時把後台掛起的程序終止掉，最終如果還是內存不夠的話就會終止掉當前前台的進程。   當接受到內存警告的事後，我們應該釋放盡可能多的內存，Crash其實也可以看做是對App的一種保護。   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等。   四、附錄   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發生時刻，函數的調用棧，以及線程等信息寫入文件。一般都是直接寫的16進制地址，如果不經過符號化的話，基本上很難獲取到有用信息，下一篇我們將聊一聊Crash日志的符號化，通俗點講就是讓Crash日志變成我們可讀的格式。