【譯】理解與分析ios應用的崩潰報告，ios崩潰報告

【譯】理解與分析ios應用的崩潰報告，ios崩潰報告

源網址：

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-->