轉 理解與分析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-->