原文是? 2017-02-21 Technical Note TN2151

（時間有限，翻譯粗糙，見諒，日后再整理）

? 當應用崩潰時，崩潰日志就被創建起來，這對查找崩潰原因非常有幫助，這個文檔包含一系列基本的信息關于怎樣符號化，理解并解釋崩潰報告。

簡介：

當一個應用崩潰時，一封崩潰報告就會被設備創建和保留。在應用結束前崩潰報告描述了一些情況，大多數都包含一份完整的可執行線程，這通常對調試程序非常有用，你應該查看這些崩潰報告去理解你的應用有哪些崩潰并且試著修復這些問題。

可回溯的崩潰報告必須在分析前被符號化，符號用可讀性的方法名和行數替代了內存地址，如果你在Xcode的Devices窗口得到了崩潰日志，他們會在幾秒后自動的為你自動的進行符號化，如果沒有，那你就必須自己通過Xcode的Devices窗口符號化它們，具體細節參考 ?Symbolicating Crash Reports 這篇文章。

低內存的報告和其他崩潰報告不一樣，在這種報告中沒有回溯信息。當低內存崩潰發生時，你應該檢查你的內存使用模式，和當低內存警告出現時你的處理方式。這篇文章指出了特別對你有用的一些內存管理指南。

獲取崩潰和低內存報告

Debugging Deployed iOS Apps ?討論了怎樣從iOS設備直接中檢索崩潰和低內存報告

App Distribution Guide 中的 Analyzing Crash Reports ?討論了怎樣從在App Store下載你的應用的TestFlight測試和用戶中查看崩潰報告的總數；

符號化崩潰報告：

符號化是解決回溯地址到源代碼方法或方法名的過程，比如符號。如果沒有符號化崩潰報告就很難決定崩潰發生的地方。

注意：低內存報告不需要被符號化。

注意：崩潰報告在macOS系統產生時通常會被符號化或者部符號化，這一章節主要講iOS，watchOS，tvOS的崩潰報告符號化，但是大體過程和macOS的一樣。

圖1: 崩潰報告和符號化過程的概述

1 當編譯器把你的源代碼翻譯成機器碼，它還生成調試符號，將編譯后的二進制指令中的每個機器指令映射到源代碼中的代碼行。根據調試信息格式（DEBUG_INFORMATION_FORMAT）編譯設置，這些調試符號儲存在二進制或配套調試符號文件中。默認情況下，調試版本的應用程序 儲存 調試符號在編譯的二進制文件中，而發布版本的應用程序 儲存 調試符號在配置dsym文件中，從而減少二進制文件的大小。

調試符號文件和應用二進制文件通過生成的UUID捆綁在一份編譯文件。你建立并生成每個應用程序的都會產生一個唯一標識的UUID。即使一個功能相同的可執行文件從相同的源代碼重構，并具有相同的編譯器設置，但是會有不同的編譯UUID。后續版本的調試符號文件，甚至來自同一個源文件，不會與其他版本的二進制文件互用。

2 當你在發布應用程序而存檔時，Xcode會隨著.dsym文件存放在主頁文件夾時存儲應用程序二進制文件。你可以在“Archived”部分下的“Xcode Organizer”中找到所有的存檔應用。更多關于創建存檔的資料，請參見App Distribution Guide.

注意：為了符號化測試員，應用審查人員和客戶的崩潰報告，你必須保留每個你發布的應用程序的存檔。

3 如果你通過App Store發布的應用程序，或使用TestFlight進行測試，你可以在上傳存檔到iTunes Connect時選擇包含dSYM文件。在提交會話欄中選擇 “Include app symbols for your application…”。上傳你的dSYM文件對選擇了分享診斷數據的TestFlight用戶中搜集的崩潰報告來說是必要的，更多關于崩潰報告服務的信息，參考 App Distribution Guide.

注意：即使你在上傳你的歸檔到iTunesConnect ，在App Review中得到的崩潰報告不會被符號化。你需要通過Xcode符號化任何從AppReview中接受的崩潰報告，參見Symbolicating Crash Reports With Xcode.

4 當你的應用程序崩潰，一個unsymbolicated崩潰報告創建并存儲在設備上。

5 用戶能夠按照Debugging Deployed iOS Apps.中的步驟直接從他們的設備中搜索崩潰報告，如果你的應用通過AdHoc或者企業版發布，這是唯一你能從你的用戶獲得崩潰報告的路徑。

6 從設備中獲得的崩潰報告沒有符號化，需要通過Xcode符號化，Xcode使用二進制文件相關聯的dSYM文件替代在源代碼中的原位置的每個回溯中的地址。結果就是符號化的崩潰報告。

7 如果用戶選擇了給蘋果公司分享診斷數據，或者用戶通過TestFlight安裝了測試版本，崩潰報告就會上傳到App Store。

8 App Store 符號化這些崩潰報告并且將相識的崩潰報告分組，這些相似的崩潰報告歸納起來叫做崩潰點（Crash Point）。

9 可以通過 Xcode的Crashes organizer符號化崩潰報告。

Bitcode

Bitcode 是編譯程序這種的中間表示。但你使用bitcode enabled 來歸檔一個應用時，編譯生成的二進制文件包含bitcode而不是機器碼。一旦二進制文件被上傳到App Store，bitcode就被編譯成機器碼。利用未來編譯器的改進，App Store可能以后會再次編譯bitcode，這對你的部分不會有影響。

圖2: 概述bitcode編譯過程

因為你的二進制文件在App Store中進行最后的編譯，你的mac將不會包含從應用審查或者從他們設備發送崩潰報告的用戶中需要符號化崩潰報告的調試符號文件，雖然dSYM文件在你歸檔應用的時候產生，但是只能用來bitcode二進制文件，并且不能符號化崩潰報告，App Store從Xcode或者iTunes Connect網站得到bitcode編譯文件供你下載。為了那些從App Review或者用戶從他們的設備發送的崩潰報告中符號化崩潰報告，你必須下載這些dSYM文件。通過崩潰報告服務的崩潰報告將會被自動的符號化。

注意：通過App Store的二進制編譯文件將會和最初提交的二進制文件有不通的UUID。

通過Xcode下載dSYM文件：

1 在 Archives organizer 中，選擇你最初提交到App Store的歸檔。

2 點擊 Download dSYMs 按鈕。

Xcode下載dSYM 文件后嵌入到選擇的歸檔文件中。

通過 iTunes Connect 網址下載dSYMs文件

1 打開 App Details 頁面。

2 點擊Activity。

3 從所有編譯文件中，選擇一個版本。

4 點擊 Download dSYM 鏈接。

確定一份崩潰報告是否被符號化

一份崩潰報告可能沒有被符號化，完全符號化或者部分符號化。沒有被符號化的崩潰報告不會在回溯中包含方法或者函數名。在裝載的二進制圖像你有可執行代碼的十六位進制地址。在一份全部符號化的崩潰報告，在回溯的每行代碼的十六進制地址都被相應的符號替代。在部分被符號化的報告中，總有一部分回溯中的地址被相應的符號替代。

很顯然，你應該嘗試著完全符號化所有你收到的崩潰報告，這將為崩潰提供最清晰的說明。部分的符號化崩潰報告依賴崩潰的類型和成功符號化的部分回溯可能包含足夠的信息去理解崩潰。沒有被符號化的崩潰報告幾乎沒有用。

圖 3 ?：基于一份回溯的各種級別的符號化。

使用Xcode來符號化崩潰報告

Xcode會自動嘗試他所遇到的所有崩潰報告。為了符號化你所要做的只是在 Xcode Organizer中添加崩潰報告。

1 把你的iOS設備連接上你的Mac。

2 在“window”目錄選擇“devices”。

3 在“devices”部分的左欄中，選擇一個設備。

4 在右面板的“Device information”部分點擊“view device logs”按鈕

5 拖動你的崩潰報告到展示面板的左欄。

6 Xcode會自動的符號化崩潰報告并顯示結果

為了能符號化崩潰報告，Xcode需要找到如下：

1 崩潰應用的二進制文件和dSYM文件

2 應用鏈接的所有自定義框架的二進制和dSYM文件。對于應用的源碼編譯的框架，他們的dSYM文件伴隨著應用的dSYM文件被復制到歸檔中。對于用第三方編譯的框架，你必須向作者索要dSYM文件。

3當應用崩潰時運行的操作系統的符號文件。這些符號文件為框架包含了有特定操作系統發布版本的調試信息，（比如iOS9.3.3）。

操作系統符號文件是有特定架構的，64bit設備的操作系統不會包含arm7符號文件。Xcode會自動復制連接你Mac的設備的操作系統符號文件。

如果 如上文件有遺失。Xcode就不會或者只會部分的符號化崩潰報告。