在分析一份crash日志之前，如果開發人員對于常見的錯誤類型有所了解，那定是極好的。crash日志的產生來源于兩種問題：違反iOS策略被干掉，以及自身的代碼bug。
1.違反iOS策略
-
內存報警閃退
當iOS檢測到內存過低時，它的VM系統會發出低內存警告通知，嘗試回收一些內存；如果情況沒有得到足夠的改善，iOS會終止后臺應用以回收更多內存；最后，如果內存還是不足，那么正在運行的應用可能會被終止掉。在Debug模式下，可以主動將客戶端執行的動作邏輯寫入一個log文件中，這樣程序童鞋可以將內存預警的邏輯寫入該log文件，當發生如下截圖中的內存報警時，就是提醒當前客戶端性能內存吃緊，可以通過Instruments工具中的Allocations 和 Leaks模塊庫來發現內存分配問題和內存泄漏問題。
我們使用Xcode 5和iOS 7的設備模擬一次低內存閃退，然后通過Organizer查看產生的crash日志，可以發現Process和Type都為Unknown：
第一部分是崩潰信息，包括識別標識、軟硬件信息和時間信息等。
第二部分是內存頁分配信息，以及當前占用內存最多的進程，上圖中為crashTypeDemo。
第三部分是具體的進程列表，描述著每個進程使用內存的情況以及當前狀態。在較早的版本中可以在某些進程后面看到“jettisoned”字樣，表明這些進程使用過多內存被終止了，而現在我們看到的是“vm-pageshortage”字樣。
-
Watchdog響應超時
當應用程序對一些特定的事件（比如啟動、掛起、恢復、結束）響應不及時，蘋果的Watchdog機制會把應用程序干掉，并生成一份相應的crash日志。這些事件與下列UIApplicationDelegate方法相對應，當遇到Watchdog日志時，可以檢查上圖中的幾個方法是否有比較重的阻塞UI的動作。
-
用戶強制退出
一看到“用戶強制退出”，首先可能想到的雙擊Home鍵，然后關閉應用程序。不過這種場景一般是不會產生crash日志的，因為雙擊Home鍵后，所有的應用程序都處于后臺狀態，而iOS隨時都有可能關閉后臺進程，當應用阻塞界面并停止響應時這種場景才會產生crash日志。這里指的“用戶強制退出”場景，是稍微比較復雜點的操作：先按住電源鍵，直到出現“滑動關機”的界面時，再按住Home鍵，這時候當前應用程序會被終止掉，并且產生一份相應事件的crash日志。
2.應用邏輯的Bug
大多數閃退崩潰日志的產生都是因為應用中的Bug，這種Bug的錯誤種類有很多，比如
SEGV：（Segmentation Violation，段違例），無效內存地址，比如空指針，未初始化指針，棧溢出等；
SIGABRT：收到Abort信號，可能自身調用abort()或者收到外部發送過來的信號；
SIGBUS：總線錯誤。與SIGSEGV不同的是，SIGSEGV訪問的是無效地址（比如虛存映射不到物理內存），而SIGBUS訪問的是有效地址，但總線訪問異常（比如地址對齊問題）；
SIGILL：嘗試執行非法的指令，可能不被識別或者沒有權限； SIGFPE：Floating Point Error，數學計算相關問題（可能不限于浮點計算），比如除零操作；
SIGPIPE：管道另一端沒有進程接手數據；
常見的崩潰原因基本都是代碼邏輯問題或資源問題，比如數組越界，訪問野指針或者資源不存在，或資源大小寫錯誤等。需要稍微注意點的是多線程問題，當一時找不到解決思路時，不妨往多線程方面考慮下。
3. 常見錯誤標識** Exception codes**
- 0x8badf00d錯誤碼：Watchdog超時，意為“ate bad food”。
- 0xdeadfa11錯誤碼：用戶強制退出，意為“dead fall”。
- 0xbaaaaaad錯誤碼：用戶按住Home鍵和音量鍵，獲取當前內存狀態，不代表崩潰。
- 0xbad22222錯誤碼：VoIP應用（因為太頻繁？）被iOS干掉。
- 0xc00010ff錯誤碼：因為太燙了被干掉，意為“cool off”。
- 0xdead10cc錯誤碼：因為在后臺時仍然占據系統資源（比如通訊錄）被干掉，意為“dead lock”。
