源網址：

http://developer.apple.com/library/ios/#technotes/tn2151/_index.html

      當一個應用程序崩潰時，創建一份“崩潰報告”對于理解崩潰是如何引起的非常有用。本文檔包含有關如何識別，了解并解釋崩潰報告的基本信息。

    簡介

      當一個應用程序在一臺iOS 設備上崩潰時，一份“崩潰報告”將在該設備上次創建并存儲起來。崩潰報告描述應用程序是在何種條件下崩潰的，大部分情況下包含一份當前正在運行線程的完整的堆棧跟蹤，通常這在調試問題時非常有用。如果你是一位iOS 開發者，你應該查看這些崩潰報告，了解導致你的應用程序崩潰的原因，然后修復它。

      內存不足報告與其他的崩潰報告的不同之處在于這種類型的報告沒有堆棧跟蹤。當一個內存崩潰發生時，你必須研究一下你的內存使用方式以及你對于內存警告的處理方式。你可能會發現本文檔為你指出幾種內存管理方式是非常有用的。

      包含堆棧跟蹤的崩潰報告需要先進行符號化（symbolicated）才可以進行分析。符號化的過程是將內存地址替換為便于人們閱讀的函數名稱和行號?；偃缒阃ㄟ^Xcode的Organizer窗口獲取崩潰日志，那么該報告將在幾秒鐘后自動進行符號化。否則你需要將.crash文件導入到Xcode的Organizer進行符號化。你可以通過符號化來了解更多細節。

    了解內存不足報告

      當監測到內存不足時，iOS的虛擬內存系統依靠應用程序間的合作來釋放內存。內存不足的通知被發送到所有正在運行的應用程序，并作為內存釋放的請求來進行處理，以期望降低所使用的內存總量。如果內存的壓力始終存在，那么系統可能會終止一些后臺進程來降低內存壓力。如果可以釋放足夠多的內存，那么你的應用程序將繼續運行而不會產生崩潰報告。如果不可以，那么你的程序將被iOS終止，因為此時已沒有足夠的內存來滿足應用程序的需求，一份內存不足的報告將被產生并存儲在設備中。

      內存不足報告與其他崩潰報告的不同之處在于它里面沒有應用程序的堆棧跟蹤。每個進程的內存使用量依據內存頁面的數量進行報告，每個內存頁面量的大小為4KB。你將會看到“拋棄（jettisoned）”緊跟在iOS為了釋放內存而終止的進程名稱后。如果你看到它緊跟在你的應用程序名稱后面，那么可以確定這個應用因為使用了太多的內存而被終止。否則，應該不是內存壓力引起的崩潰。你可以通過查看.crash文件（下一節中進行描述）獲取更多信息。

      當你看到一個內存不足報告時，你更應該研究一下你使用內存的方式和你對內存不足警告的處理方式，而不是去關心在程序終止時你的哪一部分代碼被執行了。內存分配幫助（Memory Allocations Help）列舉了如何使用泄露工具（Leaks Instrument）來發現內存泄露，以及如何使用分配工具（Allocations Instrument's）的標記堆功能來避免被拋棄的內存。內存使用性能指導方案（Memory Usage Performance Guidelines）討論了像其他內存使用秘訣一樣的適當的方案來響應內存不足通知。同時也建議你看一下WWSC2010中的關于使用工具進行高效內存分析的視頻（Advanced Memory Analysis with Instruments）。

      注意

      泄露和分配工具不能跟蹤顯存。你需要使用VM Tracker工具（包含在分配工具模板中）來運行你的應用以便觀察顯存的使用情況。VM Tracker默認是禁用的。為了在你的應用程序使用VM Tracker，請點擊工具，選中“自動快照Automatic Snapshotting”標志或者手工按下“獲取快照（Snapshot Now）”按鈕。

    分析崩潰報告

      和內存不足報告不同，大部分的崩潰報告都包含每一個線程在程序終止時的堆棧跟蹤。本節將討論這類報告。

      符號化

      在崩潰報告中最令人感興趣的部分是在你的應用程序執行終止時的堆棧跟蹤。這個跟蹤和你在調試器中停止執行時的類似，但遺憾的是這里沒有提供被認為是符號的方法或函數的名稱。取而代之的是16位的內存地址和它所指向的你的應用程序或系統框架的可執行代碼。你需要將這些地址映射到符號中。崩潰日志在輸出時并不包含土豪信息，你需要在你分析日志前進行符號化處理。

      符號化——將堆棧跟蹤地址轉化為源代碼方法名稱及行號——需要上次到蘋果應用商店的應用程序的二進制文件以及構建二進制文件時產生的.dSYM文件。這些必須是精確匹配的，否則你的報告將不能完整地符號化?；疽竽惚３置總€分發給用戶（忽略那些分發的細節）的構建和它的.dSYM是一致的。

      注意：

      你必須保存應用程序的二進制文件和.dSYM文件以便于完整地符號化崩潰日志。你應該打包每一個你所提交到iTunes Connect中的構建。.dSYM文件和應用程序的二進制文件應該綁定到一起，不管是基礎版本的構建還是后續版本的構建。即便是相同的源代碼，不同構建的文件也不會弄混。假如你使用“構建并打包”命令，那么它們將會被自動放置到一個合適的位置。雖然任何位置都可以用Spotlight搜索到。

      Xcode的“打包（Archive）”命令使保持二進制文件和.dSYM匹配變得很簡單，當你使用打包命令（通過點擊產品（“PRoduct”）-）打包（Archive）或是按下Shift+Command+B），Xode將會把應用程序的二進制文件及包含符號信息的.dSYM文件收集到一起，并存儲到你的主目錄文件夾下的一個合適位置。你可以在Xcode中的Organizer下的“已打包（Archived）”中知道你所打包的所有應用程序。Xcode在符號化崩潰日志時會自動尋找打包的應用程序，在確認你要的發布應用程序和.dSYM文件匹配的情況下，你可以將它們打包，直接提交到ITunes Connect。

      如果Xcode擁有產生崩潰日志的應用程序的二進制代碼和.dSYM文件，那么它將自動進行符號化。Xcode Organizer符號化所需要提供的是崩潰日志及相應的二進制文件和.dSYM文件。打開Xcode Organizer，選擇“設備（Devices）”選選看，選擇邊欄頂部“文庫（LIBRARY）”下的“設備日志（Device Logs）”，點擊導入按鈕，選擇需要符號化的.crash文件，當這些步驟完成后，Xcode將自動符號化崩潰日志并顯示結果。

異常代碼

在崩潰日志的16行中，你可以看到以一個或多個16進制值開頭一行，這些數字代表的是處理器的特殊代碼，可以為你提供更多的崩潰的本質信息。你可以通過這些代碼辨別應用程序的崩潰是由于程序錯誤（例如，錯誤的內存訪問，發生異常，等等）還是其他的一些原因，例如：

  1）異常代碼0x8badf00d表明應用程序已被iOS終止，原因是watchdog超時引起的。該應用程序花了太長的時間加載，終止或響應系統時間。一個常見的原因是在主線程中進行網絡同步（synchronous networking on the main thread.）。

  2）異常代碼0xbad22222表明一個Voip應用程序因其頻繁重啟而被iOS終止，。

  3）異常代碼0xdead10cc表明一個應用程序被iOS終止，因其在后臺運行時鎖定了系統資源（如聯系人數據庫）。

  4）異常代碼0xdeadfa11表明一個應用程序被用戶強制退出。當用戶第一次按下開關鍵直到“移動滑鎖關機”屏幕出現，然后按下Home鍵。用戶之所以這么做的合理假設是應用程序變得翻譯遲鈍，但不是肯定的，任何應用程序都可以強制退出。

提示：

從多任務窗口中終止一個暫停的應用程序不會產生崩潰日志。一旦一個應用被暫停，它有資格被iOS在任何時間終止，因此不會產生崩潰日志。

<!--EndFragment-->