瞭解和分析iOS Crash Report

翻譯自蘋果官方文件： Understanding and Analyzing Application Crash Reports

nimo: 這篇長達1w多字的文章，大概前後翻譯了一個月，“寫”了三遍：第一遍是直譯，第二遍是把直譯改成程式設計師看著舒服的“行話”，第三遍是把原文裡說的過於抽象或者簡單的部分加上我的註解（大家看見所有以nimo開頭的部分）。 文章釋出後我才發現，這並不是針對iOS Crash report唯一的翻譯版本。哪篇翻譯的更好這個見仁見智，但我希望這篇是翻譯的最用心的版本。

當app發生crash時會產生crash report，這對我們定位crash的原因非常有幫助。這篇文件重點介紹瞭如何符號化、看懂並解析一篇crash Report。

介紹

當app發生crash時，系統會生成crash report並存儲在裝置上。crash report會描述app在何種情況之下被系統終止執行，一般情況下描述會包括完整的執行緒呼叫堆疊，這對app的除錯（和問題的定位）是非常有幫助的。所以你應當仔細研讀這些crash report，去了解你的app究竟發生的是哪種crash，並嘗試修復它們。

Crash Report ，尤其是堆疊資訊，在被 符號化 之前是不可讀的。所謂符號化就是把記憶體地址用可讀的函式名和行數來替換。如果你不是從裝置直接獲取的crash日誌，而是通過Xcode的Device Window(即通過檢視操作而非手動命令列)，它們會在幾秒之後自動被符號化。當然你也可以把 .crash 檔案加入到Xcode的Device Window並自行將它符號化。

Low Memory Report 與其它crash report不同，它沒有堆疊資訊。當由於低記憶體而發生crash時，你必須反思你的記憶體使用模式和你針對低記憶體警告的應對方法。本文會提供給你幾個記憶體管理的參考實現，供你參考。

獲取Crash Report和Low Memory Report

如何除錯已經部署好的iOS Apps 討論瞭如何從一個iOS裝置直接拿到crash report和low memory report。App釋出指南里的分析Crash Reports討論瞭如何檢視那些crash report，這些report既包含通過TestFlight下載的測試使用者處獲得，又包含通過App Store下載的正式使用者處獲得。

符號化一篇Crash report

符號化指的是一種手段，這種手段指的是把堆疊資訊（二進位制資訊）解釋成原始碼裡的方法名或者函式名，也就是所謂符號。只有符號化成功後，crash report才能幫助開發者定位問題。

注意：Low Memory Report不需要被符號化（因為沒有堆疊資訊）。 注意 ：在MacOS平臺上產生的crash report在生成的時候一般都會被完全符號化過或者半符號化過。因此本節指的符號化針對的是從iOS、watchOS乃至tvOS中提取出來的crash report。整體處理流程上，macOS的carsh report比較類似。

1. 編譯器在把你的原始碼轉換成機器碼的同時，也會生成一份對應的Debug符號表。Debug符號表其實是一個對映表，它把每一個藏在編譯好的binary資訊中的機器指令對映到生成它們的每一行原始碼中。通過build setting裡的 Debug Information Format(DEBUG_INFORMATION_FORMAT) ,這些Debug符號表要麼被儲存在編譯好的binary資訊中，要麼單獨儲存在Debug Symbol檔案中(也就是dSYM檔案)：一般來說，debug模式構建的app會把Debug符號表儲存在編譯好的binary資訊中，而release模式構建的app會把debug符號表儲存在dSYM檔案中以節省體積。 在每一次的編譯中，Debug符號表和app的binary資訊通過構建時的UUID相互關聯。每次構建時都會生成新的唯一的能夠標識那次構建的UUID，即便你用同樣的原始碼，通過同樣的編譯setting，UUID也不會相同。相應的，dSYM檔案也不能用於解析其它（UUID對應的）binary資訊，即便構建自於同一個原始碼。

nimo: 意思就是說，同一次構建，app+dSYM+UUID是一套的。如果這幾個檔案不屬於同一次構建，即便是相同的原始碼，互相之間在符號化這個事情上也無法互相工作。

2. 當你為了分發app而選擇Archive（存檔）時，Xcode會把app的二進位制資訊和.dYSM檔案儲存在你的home資料夾下的某個地方。你可以在Xcode的Organizer裡面通過”Archived”選項找到所有你存檔過的app。 更多存檔app的細節，請點選官方文件-分發你的App一文。

注意：想要解析來自於測試、app review或者客戶的crash report，你需要保留分發出去的那些構建過的archive檔案。

3. 如果你是通過App Store分發app或者是Test Flight分發的beta版本的app，你將在上傳archive到ITC（iTunes Connect）時看見一個“是否將dSYM一起上傳”的選項。在上傳對話方塊中，請勾選”在app中包含app符號表”。上傳你的dYSM檔案對於從TestFlight使用者和客戶以及願意分享診斷資訊的客戶那邊接收crash report是很有必要的。更多詳情請參考官方文件-分發你的App一文。

注意：接收自App Review的crash report是不會被符號化的，及時你再上傳你的app到ITC時勾選了包含dSYM檔案。任何來自於App Review的crash report都需要在Xcode裡做符號化。

4. 當你的app 發生crash時，一個沒有被符號化的crash report會被建立並存儲在裝置上。

5. 使用者可以通過除錯已部署的iOS APP裡提到的方法來直接從他們的裝置裡獲得crash report。如果你通過AdHoc或者企業證書分發app，這是你唯一能從使用者獲取crash report的方法。

6. 從裝置上直接獲取的crash report是沒有被符號化的，你需要通過Xcode來符號化。Xcode會結合dSYM檔案和你app的二進位制資訊把堆疊裡的每一個地址對應到原始碼中。處理後的結果就是一個符號化過的crash report。

7. 如果使用者願意和Apple共享診斷資訊，或者使用者通過TestFlight下載了你的beta版本app，那crash report會被上傳到App Store。

8. App Store在符號化crash report後會把內部所有的crash reports做彙總並分組，這種聚合（相似crash report）的方法叫做crash聚類。

9. 這些符號化後的crash report可以在你的Xcode的Crash Organizer中進行檢視。

Bitcode

Bitcode（位編碼）是一個編譯好的專案的中間表現形式。當你在允許bitcode的前提下Archive一個app時，編譯器會在二進位制中包含bitcode而不是機器碼。一旦binary資訊被上傳到App Store中，bitcode會被再次編譯成機器碼。也許App Store會在將來二次編譯bitcode，例如為提高編譯器效能而二次編譯等。不過這不重要，因為一切對你來說是透明的，也就不需要你來額外付出什麼。

因為你的binary資訊的最終編譯結果是在App Store上體現的，因此你的Mac將不會包含那些需要對從App Review或者使用者的裝置那裡獲取到的Crash report所必須的符號化用的dSYM。

nimo:這裡原文很拗口，大概意思就是需要的東西都在App Store雲端，之後的操作會自動進行，見下文。

雖然當你Archive你的app時會建立dSYM檔案，但它們只能用在bitcode binary資訊中，並不能用於符號化crash report。 App Store允許你從Xcode或者ITC網站中下載這些隨著bitcode編譯而產生的dSYM檔案。 為了解析從App Review或者給你傳送crash report的使用者的crash report，你必須要下載這些dSYM檔案，這樣才能符號化crash report。 如果是從crash reporting service那裡接收crash report，符號化會自動完成。

注意：App Store上編譯的binary資訊和提交的原始檔案的UUID是不同的。

從Xcode下載dSYM檔案

• 在Archives organizer，選擇你之前提交到App Store的Archive檔案
• 選擇Download dSYM按鈕Archive

Xcode會下載dSYM檔案並且把他們插入到選擇的Archive中。

從ITC網站上下載dSYM檔案

• 開啟App詳情頁面
• 點選 Activity
• 從所有的構建中，選擇一個版本
• 點選 下載dSYM檔案的連結

把"隱藏的"符號名還原成原始名

當你把一個帶有bitcode的app上傳到App Store時，你也許在提交對話方塊中並沒有勾選“上傳你的app的符號表資訊以便從Apple那邊接收符號化過的 report”的選項。 當你選擇不傳送符號表資訊給Apple時，Xcode會在你傳送app到ITC之前用晦澀難懂的符號例如”_ hidden#109 ”等來替換你的app裡的dSYM檔案。Xcode會建立一個原始符號和”隱藏”符號的對照表，並且將其儲存在Archive的app檔案中的一個bcsymbolmap檔案裡。每一個dSYM檔案都會有一個對應的bcsymbolmap檔案。

在符號化crash report之前，你需要把那些從ITC中下載下來的dSYM檔案中的晦澀資訊給解析一下。 如果你使用Xcode中的 下載dSYM 按鈕，這步解析會自動完成。但是，如果你通過 ITC網站 來下載dSYM的話，你需要開啟Terminal並且手動輸入下面的命令來做解析（把example的path資訊和sSYM資訊替換一下）

xcrun dsymutil -symbol-map ~/Library/Developer/Xcode/Archives/2017-11-23/MyGreatApp\ 11-23-17\,\ 12.00\ PM.xcarchive/BCSymbolMaps ~/Downloads/dSYMs/3B15C133-88AA-35B0-B8BA-84AF76826CE0.dSYM
複製程式碼

針對每一個dSYMs資料夾下的dSYM檔案都執行一次這條命令。

如何判斷Crash report是否已經符號化

一個crash report有可能未符號化，完全符號化，也有可能部分符號化。未符號化的crash report不會在堆疊資訊中包含方法名或者函式名。相反，你會在載入好的binary資訊中發現可執行的16進位制地址資訊。在完全符號化的crash report裡，堆疊中的每一行16進位制地址資訊都會被替換成對應的符號。在部分符號化的crash report中，只有一部分堆疊資訊被替換成相應的符號資訊。

顯然，你應當盡力去完全符號化你的crash report，因為那樣你才能夠獲得crash report裡最有價值的資訊。一個部分符號化的crash report也許包含了可以理解crash的資訊，這取決於crash的型別和哪一部分被成功符號化了。一個未符號化的crash report用處有限。

用Xcode符號化iOS的Crash report

一般來說，Xcode會自動嘗試符號化它所有的Crash report。所以你只需要把crash report加到Xcode Organizer就可以了。

Note：Xcode只認.crash字尾的crash report。如果你收到的crash report沒有後綴名或者字尾是txt，在執行下列步驟之前先把它改成.crash。

• 把iOS裝置連線到你的Mac
• 從Window選單欄選擇Devices
• 在Devices左側，選擇一個裝置
• 點選右邊在“Device Information“ 下面的 ”View Device Logs” 按鈕
• 把你的Crash report拖拽到左側panel中
• Xcode會自動符號化Crash report並且顯示結果

為了符號化一個Crash report，Xcode需要去定位如下資訊：

• 崩潰的app的binary資訊以及dSYM檔案
• 所有app關聯的自定義framework的binary資訊以及dSYM檔案。如果是從app構建出來的framework，它們的dYSM會隨著app的dSYM檔案一起拷貝到archive中。如果是第三方的framework，你需要去找作者要dYSM檔案。
• 發生crash時app所依賴的OS的符號表資訊。這些符號表包含了特定OS版本（例如iOS9.3.3）上的framework所需除錯資訊。 OS 符號表的架構具有獨特性——一個64位的iOS裝置不會包含armv7的符號表。Xcode將要自動拷貝你連線到的特定版本的Mac的符號表。

在上述任何一處，如果沒有Xcode，你將無法符號化一個crash report，或者只能部分符號化一個crash report。

用atos符號化Crash report

atos 命令可以把地址裡的數字替換成等價的符號。如果除錯符號資訊是完備的，則atos的輸出資訊將會包含檔名和對應的資源行數。 atos 命令可以被用來單獨符號化那些 未符號化 或者 部分符號化 過的crash report（中的堆疊資訊裡的地址）。 想要使用 atos 符號化crash report可以按如下方式操作：

1. 找到你想要符號化的那一行，記下第二列的binary資訊名，以及第三列的地址。
2. 從crash report底部的binary資訊名列表中找到那個名字，記下來架構名和載入的地址。

nimo: 例如在下圖裡，我們想符號化的部分就是 0x00000001000effdc ,binary資訊名是 The Elements ，底部能找到對應的名字的架構名稱是 arm64 ，載入地址是 0x1000e4000 。

atos
atos

atos -arch <Binary Architecture> -o <Path to dSYM file>/Contents/Resources/DWARF/<binary image name> -l <load address> <address to symbolicate>
複製程式碼

清單1 使用atos命令的樣例，以及結果輸出

$ atos -arch arm64 -o TheElements.app.dSYM/Contents/Resources/DWARF/TheElements -l 0x1000e4000 0x00000001000effdc
複製程式碼

-[AtomicElementViewController myTransitionDidStop:finished:context:]
複製程式碼

利用符號化排查問題

如果Xcode沒有完全符號化一個crash report，很可能是你的Mac丟失了app binary資訊對應的dSYM檔案，或者是丟了一個或多個app關聯的framework的dSYM檔案，也有可能在發生Crash時OS層面的app的裝置符號表丟失了。下列步驟顯示瞭如何使用Spotlight來判斷那些可以符號化對應堆疊地址資訊的dSYM檔案是否在你的Mac上。

1. 在Xcode無法符號化的堆疊裡找一行，注意第二列的binary資訊的名字。
2. 在crash report的底部中的二進位制資訊列表裡找到那個名字。這個列表包含了每一個crash事故現場存在於程序裡的二進位制資訊的UUID。

nimo:本例中需要關注的binary資訊的名字是 The Element ，在底部列表中對應的二進位制資訊的UUID是 77b672e2b9f53b0f95adbc4f68cb80d6

列表2 你可以用grep命令來快速找到二進位制資訊的列表資訊

$ grep --after-context=1000 "Binary Images:" <Path to Crash Report> | grep <Binary Name>
複製程式碼

3. 把二進位制資訊的UUID按照 8-4-4-4-12格式(XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX)轉換成32個字元組成的字串。注意所有字母必須大寫。
4. 用mdfind命令，結合”com_apple_xcode_dsym_uuids == ”（包含引號）來查詢UUID資訊。

列表3 使用mdfind命令來通過給定UUID查詢dSYM檔案。

$ mdfind "com_apple_xcode_dsym_uuids == <UUID>"
複製程式碼

5. 如果spotlight找到了UUID對應的dSYM檔案，mdfind會把dSYM檔案和可能包含的歸檔檔案的路徑打印出來。如果一個UUID對應的dSYM檔案沒有找到，mdfind會直接退出。

如果spotlight找到了二進位制對應的dSYM檔案，但是Xcode沒有能結合二進位制資訊成功把地址符號化，那你應該上報一枚bug並且把crash report和對應的dSYM檔案一起附到bug report中。作為權宜之策，你可以手動用atos來對地址進行符號化。

如果spotlight沒有找到二進位制資訊對應的dSYM檔案，確保你還有app發生crash的那個版本的Xcode歸檔檔案，並且這個檔案存在於spotlight可以找到的某個地方。如果你的app是支援bitcode方式構建的，確保你已經從App Store下載了最終編譯版本的dSYM檔案。

如果你覺得你已經有了二進位制資訊對應的正確的dSYM檔案，那你可以用dwarfdump命令來列印對應的匹配UUID。你也可以用用dwarfdump命令來列印二進位制的UUID。

xcrun dwarfdump --uuid <Path to dSYM file>

注意：你必須儲存你最開始上傳到App Store的發生crash的app的歸檔檔案。dSYM檔案和app二進位制檔案是一一對應，且每次構建都不相同。即便通過相同的原始碼和配置，再執行一次構建，生成的dSYM檔案也無法和之前的crash report做符號化匹配。 如果你不在存有這個歸檔檔案，你應該重新提交一次有歸檔的新版本，以確保再發生crash的時候你可以符號化crash report。

分析Crash report

這段將會討論一篇標準crash report的各章節的含義。

Header

每一篇crash report都有一個header。

列表4 一篇crash report的header部分

Incident Identifier: B6FD1E8E-B39F-430B-ADDE-FC3A45ED368C
CrashReporter Key: f04e68ec62d3c66057628c9ba9839e30d55937dc
Hardware Model: iPad6,8
Process: TheElements [303]
Path: /private/var/containers/Bundle/Application/888C1FA2-3666-4AE2-9E8E-62E2F787DEC1/TheElements.app/TheElements
Identifier: com.example.apple-samplecode.TheElements
Version: 1.12
Code Type: ARM-64 (Native)
Role: Foreground
Parent Process: launchd [1]
Coalition: com.example.apple-samplecode.TheElements [402]
 
Date/Time: 2016-08-22 10:43:07.5806 -0700
Launch Time: 2016-08-22 10:43:01.0293 -0700
OS Version: iPhone OS 10.0 (14A5345a)
Report Version: 104
複製程式碼

大部分欄位的含義是不言自明的，但是有一些值得特別指出：

• Incident Identifier: 一個crash report的唯一ID。兩個 report不會使用同一個Incident Identifier。
• CrashReporter Key: 一個匿名的裝置相關ID。同一個裝置的兩篇crash report會有相同的CrashReporter Key。
• Beta Identifier：一個整合了發生crash app的裝置和供應商資訊的ID。來自同一個供應商和裝置的兩篇report會包含相同的ID值。這個欄位只有當app通過TestFlight分發的時候出現，並且出現在應該出現Crash Reporter Key Field的地方。
• Process：發生Crash時的程序名。這個和app資訊屬性列表裡的CFBundleExecutable Key中的值可以匹配上。
• Version：發生crash的版本號。這個值可以關聯到發生 crash的app的CFBundleVersion 和 CFBundleVersionString上。
• Code Type：發生crash的上下文所在架構環境。有ARM-64,ARM,X86-64和X86.
• Role：在發生crash時程序的的task_role。

enum task_role {
TASK_RENICED = -1,
TASK_UNSPECIFIED = 0,
TASK_FOREGROUND_APPLICATION,
TASK_BACKGROUND_APPLICATION,
TASK_CONTROL_APPLICATION,
TASK_GRAPHICS_SERVER,
TASK_THROTTLE_APPLICATION,
TASK_NONUI_APPLICATION,
TASK_DEFAULT_APPLICATION
};
複製程式碼

• OS Version: OS version，包含發生crash時的所屬app的編譯碼。

異常資訊

遇到Objective-C/C++時不要懵（即便有些會導致Crash）。這章列出了Mach異常型別和相應的能提供crash的蛛絲馬跡的一些欄位資訊。當然，不是所有欄位都會出現在每一篇crash report裡。

列表5 由於uncaught Objective-C exception而導致的程序被停止的crash report的摘錄

Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Exception Note: EXC_CORPSE_NOTIFY
Triggered by Thread: 0
複製程式碼

列表6 由於反向引用了一個NULL指標而造成程序被終止的crash report的摘錄

Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Subtype: KERN_INVALID_ADDRESS at 0x0000000000000000
Termination Signal: Segmentation fault: 11
Termination Reason: Namespace SIGNAL, Code 0xb
Terminating Process: exc handler [0]
Triggered by Thread: 0
複製程式碼

可能出現在這一章節的某些欄位解讀如下。

• Exception Codes： 和異常是有關的處理器指定資訊，這些資訊會被編碼成一個或者多個64位二進位制數字。一般來說，這個欄位不應該存在，因為crash report生成時會把exception code轉化成可讀的資訊並在其它欄位進行體現。
• Exception Subtype：可讀的exception code的名稱。
• Exception Message：從exception code中解析出來的附加的可讀資訊。
• Exception Note：不特指某一種異常的額外資訊。如果這個欄位包含”SIMULATED”(不是Crash)，則程序並沒有發生crash，而是在系統層面被kill掉了，比如看門狗機制。

• Termination Reason：當程序被終止時的原因及資訊。關鍵的資訊模組，不論是程序內還是程序外，當遇到一個致命錯誤（fatal error，例如bad code signature，缺失依賴庫，不恰當的訪問私有敏感資訊等）。MacOS Sierra,iOS 10, watch OS3和tvOS 10 已經採用新的架構去記錄這些錯誤資訊，所以這些系統之下的crash report會在Termination Reason這個欄位裡描述error message資訊。
• Triggered by Thread：指出異常是在哪個執行緒發生的

接下來的章節會解釋常見的異常型別：

Bad Memory Access [EXC_BAD_ACCESS // SIGSEGV // SIGBUS]

程序試圖去訪問無效的記憶體空間，或者嘗試訪問的方法是不被允許的（例如給只讀的記憶體空間做寫操作）。在Exception Subtype欄位中如果出現kern_return_t的話，說明記憶體地址空間被不正確的訪問了。 這裡有幾個除錯bad memory crash的小貼士：

• 如果 objc_msgSend 或者 objc_release出現在crash的執行緒的附近，則程序有可能嘗試去給一個被釋放的物件傳送訊息。你應當用Zombie instrument方式來執行profile，來更好地瞭解發生crash的原因。
• 如果gpus_ReturnNotPermittedKillClient在近crash的執行緒附近，則程序有可能是嘗試在後臺通過OpenGL ES或者Metal來做渲染。可以參見 QA1766: How to fix OpenGL ES application crashes when moving to the background
• 通過在執行你的app時勾選Address Sanitizer。address sanitizer會在編譯期間在記憶體訪問時新增額外的操作，當你的app執行，Xcode會在記憶體可能發生crash的時候給出提示資訊。

Abnormal Exit [EXC_CRASH // SIGABRT]

程序異常退出。這種異常最常見的原因在於 uncaught Objective-C/C++ exception 並且呼叫了 abort() 。 擴充套件App(nimo：App Extensions，例如輸入法)如果花了太多時間做初始化的話就會以這種異常退出（看門狗機制）。如果擴充套件程式由於在啟動時掛起進而被kill掉，那 report中的Exception Subtype欄位會寫LAUNCH_HANG。因為擴充套件App沒有main函式，所以任何情況下的在static constructors和+load方法裡的初始化時間都會體現在你的擴充套件或者依賴庫中。因此你應當儘可能的推遲這些邏輯。

Trace Trap [EXC_BREAKPOINT // SIGTRAP]

和 Abnormal Exit 類似，這種異常是由於在特殊的節點加入debugger除錯節點的原因。你可以在你自己的程式碼裡通過使用 __builtin_trap() 函式來觸發這個異常。如果沒有debugger存在，則執行緒會被終止並生成一個crash report。 底層庫（例如libdispatch）會在遇到fatal錯誤的時候陷入這個困局。關於錯誤的相關資訊會在crash report的章節或者是裝置的的列印資訊裡找到。 Swift程式碼會在執行時的時候遇到下述問題時丟擲這種異常：

• 一個non-optional的型別被賦予一個nil值
• 一個失敗的強制轉換

遇到這種錯誤，查下堆疊資訊並想清楚是在哪裡遇到了未知情況(unexpected condition)。額外資訊也可能會在裝置的控制檯的日誌裡出現。你應當儘量修改你的程式碼，去優雅的處理這種執行時錯誤。例如，處理一個optional的值，通過可選繫結(Optional binding)而不是強制解包來獲得其值。

if let actualValue = maybeHasValue(){
foo(actualValue)
}
複製程式碼

Illegal Instruction [EXC_BAD_INSTRUCTION // SIGILL]

當嘗試去執行一個非法或者未定義的指令時會觸發該異常。有可能是因為執行緒在一個配置錯誤的函式指標的誤導下嘗試jump到一個無效地址。 在Intel處理器上，ud2操作碼會導致一個EXC_BAD_INSTRUCTIONY異常，但是這個通常用來做除錯用途。在Intel處理器上，Swift會在執行時碰到未知情況時被停止。 詳情參考Trace Trap。

Quit [SIGQUIT]

這個異常是由於其它程序擁有高優先順序且可以管理本程序（因此被高優先順序程序Kill掉）所導致。SIGQUIT不代表程序發生Crash了，但是它確實反映了某種不合理的行為。 iOS中，如果佔用了太長時間，鍵盤擴充套件程式會隨著宿主app被幹掉。因此，這種情況的異常下不太可能會在Crash report中出現合理可讀的異常程式碼。大概率是因為一些其它程式碼在啟動時佔用了太長時間但是在總時間限制前（看門狗的時間限制，見上文中的表格）成功結束了，但是執行邏輯在extension退出的時候被錯誤的執行了。你應該執行Profile，仔細分析一下extension的各部分消耗時間，把耗時較多的邏輯放到background或者推遲（推遲到extension載入完畢）。

Killed[SIGKILL]

程序收到系統指令被幹掉。請自行檢視Termination Reason來定位執行緒被幹掉的原因。 Termination Reason欄位會包含一個名稱空間和程式碼。以下程式碼只針對watchOS：

• 程式碼 0xc51bad01 表示watchOS在後臺任務佔用了過多的cpu時間而導致watch app被幹掉。想要解決這個問題，優化後臺任務，提高CPU執行效率，或者減少後臺的任務執行數量。
• 程式碼 0xc51bad02 表示在後臺的規定時間內沒有完成指定的後臺任務而導致watch app被幹掉。想要解決這個問題，需要當app在後臺執行時減少app的處理任務。
• 程式碼 0xc51bad03 表示watch app沒有在規定時間內完成後臺任務，且系統一直非常忙以至於app無法獲取足夠的CPU時間來完成後臺任務。雖然一個app可以通過減少自身在後臺的執行任務來避免這個問題，但是 0xc51bad03 這個錯誤把矛頭指向了過高的系統負載，而非app本身有什麼問題。

Guarded Resource Violation [EXC_GUARD]

程序違規訪問了一個被保護的資源。系統庫會把特定的檔案描述符標記為被 被保護 ，因此任何對這些檔案描述符的常規操作都會丟擲 EXC_GUARD 異常（nimo: 當系統想操作這些檔案描述符時，它們會用特殊的被授權過的私有API）。所以遇到諸如私自關閉掉系統開啟的檔案描述符之類的操作時您可以快速察覺。例如，如果一個app關閉掉了曾經支援Core Data 儲存的SQLite檔案的檔案描述符，你會發現Core Data過一會兒神祕crash。guard exception會在不久之後注意到並且讓他們更容易被debug。 更新版本的iOS crash report會在Exception Subtype和Exception Message欄位裡包含關於 EXC_GUARD 異常的可讀詳細資訊。在macOS或者是更老版本的iOS的crash report中，這條資訊會被加密成第一個Exception Code並以位資訊進行呈現，它可以被這麼解讀：

• [63:61] - Guard Type:被保護的資源的型別。0x2值表示資源是一個檔案描述符。
• [60:32] - Flavor:在何種情況之下出現的問題。 如果第一個(1<<0)bit被設值，則程序嘗試在一個被保護的檔案描述符上呼叫close()

如果第二個(1<<1)bit被設值，則程序嘗試在被保護的檔案描述符上用 F_DUPFD 或 F_DUPFD_CLOEXEC 呼叫 dup(), dup2(), 或 fcntl() 命令。

如果第三個(1<<2)bit被設值，則程序嘗試通過socket傳送一個被保護的檔案描述符。

如果第五個(1<<4)bit被設值，則程序嘗試寫一個被保護的檔案描述符。

• [31:0] - File Descriptor：程序嘗試修改被保護的檔案描述符。

Resource Limit [EXC_RESOURCE]

程序的資源超過限定閾值。這條推送是OS發出的，表示程序佔有了太多的資源。準確的資源列在了 Exception Subtype 的欄位裡。如果 Exception Note 欄位包含了 NON-FATAL CONDITION （非嚴重錯誤），則即便是生成了crash report，程序也不會被kill掉。

• 如果 EXCEPTION SUBTYPE 裡出現 MEMORY 則暗示了程序佔用已經超過系統限制。如果之後出現由於系統佔用過多程序被Kill，可能和這有關。
• 如果 EXCEPTION SUBTYPE 裡出現 WAKEUP 則暗示執行緒每秒被程序喚醒太多次了，進而導致CPU被頻繁喚醒並且造成電量損耗。 通常，這種事發生在程序間通訊（通過 peformSelector:onThread: 或者 dispatch_async ），而且會遠比預想的發生的更頻繁。因為發生這種異常的通訊被觸發的如此頻繁，所以很多後臺程序會出現彼此高度雷同的堆疊資訊——恰恰暗示了它們是從哪兒來的。

Other Exception Types

有些crash report可能會出現無名的Exception Type，這時候在這個欄位上會出現純16進位制值（例如00000020）。如果你收到這樣的crash report，直接去Exception Code檢視更多資訊。

• 如果Exception Code是 0xbaaaaaad 則說明此條logs是系統堆疊快照，並非crash report。可以通過同時按（手機）側邊按鈕和音量鍵來記錄堆疊快照。通常情況下，這些logs是使用者無意中生成的，並非表示錯誤。
• 如果Exception Code是 0xbad22222 表示一個VoIP應用因為頻繁暫停被iOS系統終止掉。
• 如果Exception Code是 0x8badf00d （讀起來像badfood）則說明一個應用因為觸發了看門狗機制被iOS系統終止掉，有可能是應用花了太長時間啟動，終止，或者是響應系統事件。一種常見原因是在主執行緒上做網路同步邏輯。不論Thread0上（也就是主執行緒）想做什麼（重要的事），都應該轉移到後臺執行緒，或者換一種方式觸發，這樣它才不會阻塞主執行緒。
• 如果Exception Code是 0xc00010ff 則說明app因為環境過熱（的事件）被iOS系統幹掉了。這個也許是和發生crash的特定裝置有關，或者是和它所在的環境有關。如果想知道更多高效執行app的tips，請參考WWDC的文章: iOS Performance and Power Optimization with Instruments 。
• 如果Exception Code是 0xdead10cc (讀起來像deadlock)則說明一個應用被系統終止掉，原因是在應用掛起時拿到了檔案鎖或者sqlite資料庫所長期不釋放直到被凍結。如果你的app在掛起時拿到了檔案鎖或者sqlite資料庫鎖，它必須請求額外的後臺執行時間( request additional background execution time )並在被掛起前完成解鎖操作。
• 如果Exception Code是 0x2bad45ec 則說明app因為違規操作（安全違規）被iOS系統終止。終止描述會寫：“程序被查到在安全模式進行非安全操作”，暗示app嘗試在禁止螢幕繪製的時候繪製螢幕，例如當螢幕鎖定時。使用者可能會忽略這種異常，尤其當螢幕是關閉的或者當這種終止發生時正好鎖屏。

Note：通過App Switcher(就是雙擊home鍵出現的那個介面)並不會生成crash report。一旦app進入掛起狀態，被iOS在任何時間終止掉都是合理的，因此這時候不會生成crash report。

額外的診斷資訊

本章節包含終止相關的額外診斷資訊，包括：

• 應用的具體資訊：在程序被終止前捕捉到的框架錯誤資訊
• 核心資訊：關於程式碼簽名問題的細節
• Dyld （動態連結庫）錯誤資訊：被動態連結器提交的錯誤資訊

從macOS Sierra, iOS 10, watchOS 3, 和 tvOS 10開始，大部分這種資訊都在 Exception Information 的 Termination Reason 欄位下了。 你應當閱讀本章節來更好的明白當程序被終止的時候發生了什麼。

表7：一段因為找不到連結庫而導致程序被終止的crash report的摘錄

Dyld Error Message:
Dyld Message: Library not loaded: @rpath/MyCustomFramework.framework/MyCustomFramework
Referenced from: /private/var/containers/Bundle/Application/CD9DB546-A449-41A4-A08B-87E57EE11354/TheElements.app/TheElements
Reason: no suitable image found.
複製程式碼

表8：一段因為沒能快速載入初始view controller而導致程序被終止的crash report的摘錄

Application Specific Information:
com.example.apple-samplecode.TheElements failed to scene-create after 19.81s (launch took 0.19s of total time limit 20.00s)
Elapsed total CPU time (seconds): 7.690 (user 7.690, system 0.000), 19% CPU
Elapsed application CPU time (seconds): 0.697, 2% CPU
複製程式碼

堆疊資訊

一個crash report最有意思的部分一定是每個執行緒在被終止時的堆疊資訊。這些資訊和你在debug時看到的很類似。

列表9：一個完全符號化的crash report的堆疊部分摘錄

Thread 0 name: Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0TheElements0x000000010006bc20 -[AtomicElementViewController myTransitionDidStop:finished:context:] (AtomicElementViewController.m:203)
1UIKit0x0000000194cef0f0 -[UIViewAnimationState sendDelegateAnimationDidStop:finished:] + 312
2UIKit0x0000000194ceef30 -[UIViewAnimationState animationDidStop:finished:] + 160
3QuartzCore0x0000000192178404 CA::Layer::run_animation_callbacks(void*) + 260
4libdispatch.dylib0x000000018dd6d1c0 _dispatch_client_callout + 16
5libdispatch.dylib0x000000018dd71d6c _dispatch_main_queue_callback_4CF + 1000
6CoreFoundation0x000000018ee91f2c __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 12
7CoreFoundation0x000000018ee8fb18 __CFRunLoopRun + 1660
8CoreFoundation0x000000018edbe048 CFRunLoopRunSpecific + 444
9GraphicsServices0x000000019083f198 GSEventRunModal + 180
10UIKit0x0000000194d21bd0 -[UIApplication _run] + 684
11UIKit0x0000000194d1c908 UIApplicationMain + 208
12TheElements0x00000001000653c0 main (main.m:55)
13libdyld.dylib0x000000018dda05b8 start + 4

Thread 1:
0libsystem_kernel.dylib0x000000018deb2a88 __workq_kernreturn + 8
1libsystem_pthread.dylib0x000000018df75188 _pthread_wqthread + 968
2libsystem_pthread.dylib0x000000018df74db4 start_wqthread + 4

...
複製程式碼

第一行列出了當前的執行緒號，以及當前的執行佇列的id。其餘各行列出來每一個堆疊中堆疊片段資訊，從左到右分別是：

• 堆疊片段號。堆疊的展示順序會和呼叫順序一致，片段0是在程式被終止時執行的函式。片段1是呼叫片段0的函式，以此類推。
• 在堆疊片段中駐留的執行函式的名稱
• 片段0代表機器指令在被終止的生活所在的地址。其它片段表示如果片段0執行完成之後下一個執行的片段地址
• 在一個符號化的crash report中，代表在堆疊片段中的函式名稱

異常

Objective-C中的異常通常用來表明在執行時發生的程式碼錯誤，例如越界訪問陣列，或者更改immutable的物件，沒有實現protocol中必須實現的方法，或者給接收者無法識別的物件傳送資訊。

Note：給之前已經釋放的物件傳送訊息會引發 NSInvalidArgumentException 異常進而crash，而非記憶體訪問違規。這會在新的變數正好佔據了之前釋放變數所在記憶體時。如果你的app因為 NSInvalidArgumentException 發生crash（在堆疊資訊中檢視 [NSObject(NSObject) doesNotRecognizeSelector:] ），考慮通過Zombies instrument 來profiling你的應用，來排除剛才提到的記憶體管理問題。

如果異常沒有被捕捉到，他會被一個叫 uncaught exception 方法所攔截。預設的 uncaught exception 的日誌會顯示到裝置的控制檯，之後會終止程序。異常堆疊資訊會在生成的crash report的 上一個異常堆疊（Last Exception Backtrace） 下，就像列表10所寫。異常訊息會被crash report忽略。如果你收到了一個帶有上一個異常堆疊（Last Exception Backtrace）的crash report，你應當去獲取原始裝置並獲取其控制檯日誌資訊，來更好的瞭解發生crash的原因。

List10：發生了上一個異常堆疊（Last Exception Backtrace）的未符號化crash report摘錄

Last Exception Backtrace:

(0x18eee41c0 0x18d91c55c 0x18eee3e88 0x18f8ea1a0 0x195013fe4 0x1951acf20 0x18ee03dc4 0x1951ab8f4 0x195458128 0x19545fa20 0x19545fc7c 0x19545ff70 0x194de4594 0x194e94e8c 0x194f47d8c 0x194f39b40 0x194ca92ac 0x18ee917dc 0x18ee8f40c 0x18ee8f89c 0x18edbe048 0x19083f198 0x194d21bd0 0x194d1c908 0x1000ad45c 0x18dda05b8)
複製程式碼

一個只包含16進位制資訊的有Last Exception Backtrace資訊的crash日誌必須被符號化，以獲取有價值的堆疊資訊，就像列表11所寫。

列表11：一個包含Last Exception Backtrace資訊的符號化的crash report。這個異常出現在載入app的storyboard時，需要響應的IBOutlet的對應元素丟失了。

Last Exception Backtrace:

0CoreFoundation0x18eee41c0 __exceptionPreprocess + 124
1libobjc.A.dylib0x18d91c55c objc_exception_throw + 56
2CoreFoundation0x18eee3e88 -[NSException raise] + 12
3Foundation0x18f8ea1a0 -[NSObject(NSKeyValueCoding) setValue:forKey:] + 272
4UIKit0x195013fe4 -[UIViewController setValue:forKey:] + 104
5UIKit0x1951acf20 -[UIRuntimeOutletConnection connect] + 124
6CoreFoundation0x18ee03dc4 -[NSArray makeObjectsPerformSelector:] + 232
7UIKit0x1951ab8f4 -[UINib instantiateWithOwner:options:] + 1756
8UIKit0x195458128 -[UIStoryboard instantiateViewControllerWithIdentifier:] + 196
9UIKit0x19545fa20 -[UIStoryboardSegueTemplate instantiateOrFindDestinationViewControllerWithSender:] + 92
10UIKit0x19545fc7c -[UIStoryboardSegueTemplate _perform:] + 56
11UIKit0x19545ff70 -[UIStoryboardSegueTemplate perform:] + 160
12UIKit0x194de4594 -[UITableView _selectRowAtIndexPath:animated:scrollPosition:notifyDelegate:] + 1352
13UIKit0x194e94e8c -[UITableView _userSelectRowAtPendingSelectionIndexPath:] + 268
14UIKit0x194f47d8c _runAfterCACommitDeferredBlocks + 292
15UIKit0x194f39b40 _cleanUpAfterCAFlushAndRunDeferredBlocks + 560
16UIKit0x194ca92ac _afterCACommitHandler + 168
17CoreFoundation0x18ee917dc __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 32
18CoreFoundation0x18ee8f40c __CFRunLoopDoObservers + 372
19CoreFoundation0x18ee8f89c __CFRunLoopRun + 1024
20CoreFoundation0x18edbe048 CFRunLoopRunSpecific + 444
21GraphicsServices0x19083f198 GSEventRunModal + 180
22UIKit0x194d21bd0 -[UIApplication _run] + 684
23UIKit0x194d1c908 UIApplicationMain + 208
24TheElements0x1000ad45c main (main.m:55)
複製程式碼

如果你發現本應該被捕捉的異常並沒有被捕捉到，請確定您沒有在building應用或者library時添加了 -no_compact_unwind 標籤。

64位IOS用了 zero-cost 的異常實現機制。在 zero-cost 系統裡，每一個函式都有一個額外的資料，它會描述如果一個異常在跨函式範圍內實現，該如何展開相應的堆疊資訊。如果一個異常發生在多個堆疊但是沒有可展開的資料，那麼異常處理函式自然無法跟蹤並記錄。也許在堆疊很上層的地方有異常處理函式，但是如果那裡沒有一個片段的可展開資訊，沒辦法從發生異常的地方到那裡。指定了 -no_compact_unwind 標籤表明你那些程式碼沒有可展開資訊，所以你不能跨越函式丟擲異常（也就是說無法通過別的函式捕捉當前函式的異常）。

Thread State(執行緒狀態)

這章列出了crash執行緒的執行緒狀態。這裡列出了註冊過的值。在你讀一個crash report的時候，瞭解執行緒狀態並非必須，但是如果你想更好地瞭解crash的細節，這也許會起一些幫助。

列表12：ARM64裝置的crash report的一段Thread State摘錄

Thread 0 crashed with ARM Thread State (64-bit):

x0: 0x0000000000000000x1: 0x000000019ff776c8x2: 0x0000000000000000x3: 0x000000019ff776c8
x4: 0x0000000000000000x5: 0x0000000000000001x6: 0x0000000000000000x7: 0x00000000000000d0
x8: 0x0000000100023920x9: 0x0000000000000000x10: 0x000000019ff7dff0x11: 0x0000000c0000000f
x12: 0x000000013e63b4d0x13: 0x000001a19ff75009x14: 0x0000000000000000x15: 0x0000000000000000
x16: 0x0000000187b3f1b9x17: 0x0000000181ed488cx18: 0x0000000000000000x19: 0x000000013e544780
x20: 0x000000013fa49560x21: 0x0000000000000001x22: 0x000000013fc05f90x23: 0x000000010001e069
x24: 0x0000000000000000x25: 0x000000019ff776c8x26: 0xee009ec07c8c24c7x27: 0x0000000000000020
x28: 0x0000000000000000fp: 0x000000016fdf29e0lr: 0x0000000100017cf8
sp: 0x000000016fdf2980pc: 0x0000000100017d14 cpsr: 0x60000000
複製程式碼

Binary Images

這一章列出了在程序被終止時載入在程序中的二進位制檔案（binary images）。

列表13：一段crash report的完整二進位制檔案摘錄

Binary Images:

0x100060000 - 0x100073fff TheElements arm64 <2defdbea0c873a52afa458cf14cd169e> /var/containers/Bundle/Application/888C1FA2-3666-4AE2-9E8E-62E2F787DEC1/TheElements.app/TheElements

...
複製程式碼

每一行都包含了一個二進位制檔案的以下細節資訊：

a

讀懂低記憶體 report(Low Memory Reports)

當系統檢測到記憶體不足時，iOS系統裡的虛擬記憶體系統會協同各應用來做記憶體釋放。每個執行著的應用都會接收到系統發來低記憶體推送（Low-memory notification)，要求釋放記憶體空間，從而達到減少整體記憶體消耗的目的。如果記憶體壓力依然存在，系統可能會終止後臺程序以減輕記憶體壓力。如果（整體）記憶體釋放夠了，你的應用將可以繼續執行；不然，你的應用會被iOS終止，因為可供你的應用執行的記憶體不夠，這時候會生成一個低記憶體 report（Low-Memory Report）並存儲在你的裝置中。 低記憶體 report的格式和其它crash report略有不同，它沒有應用的堆疊資訊。一個低記憶體 report的Header會和crash report的header有些類似。緊接著Header的時各個欄位的系統級別的記憶體統計資訊。記錄下頁大小（Page Size）欄位。每一個程序的記憶體佔用大小是根據記憶體的頁的數量來 report的。 一個低記憶體 report最重要的部分是程序表格。這個表格列出了所有的執行程序，包括系統在生成低記憶體 report時的守護程序。如果一個程序被”遺棄”了，會在[原因]一列附上具體的原因。一個程序可能被遺棄的原因有：

• [per-process-limit] :程序佔用超過了它的最大記憶體值。每一個程序在常駐記憶體上的限制是早已經由系統為每個應用分配好了的。超過這個限制會導致程序被系統幹掉。

注意：擴充套件程式(nimo: Extension app, 例如輸入法等)的最大記憶體值更少。一些技術，例如地圖檢視和SpriteKit，佔用非常多的基礎記憶體，因此不適合用在擴充套件程式裡。

• [vm-pageshortage]/[vm-thrashing]/[vm] :由於系統記憶體壓力被幹掉。
• [vnode-limit] : 開啟太多檔案了。

注意：系統會盡量避免在vnodes已經枯竭的時候幹掉高頻app。因此你的應用如果在後臺，即便並沒有佔用什麼vnode，而有可能被殺掉。

• [highwater] :一個系統守護程序超過過了它的記憶體佔用高水位（就是已經很危險了）。
• [jettisoned] :程序因為其它不可描述的原因被殺掉。

如果你沒有在你的應用或者擴充套件程式裡看到原因，那crash的原因就不是低記憶體壓力。仔細檢視一下.crash檔案（在之前章節裡有寫）。

當你發現一個低記憶體crash，與其去擔心哪一部分的程式碼出現問題，還不如仔細審視一下自己的記憶體使用習慣和針對低記憶體告警（low-memory warning）的處理措施。 Locating Memory Issues in Your App 列出瞭如何使用Leaks Instrument工具來檢查記憶體洩漏，和如何使用Allocations Instrument的Mark Heap 功能來避免記憶體浪費。 Memory Usage Performance Guidelines 討論瞭如何處理接受到低記憶體告警的問題，以及如何高效使用記憶體。當然，也推薦你去看下2010年的WWDC中的 Advanced Memory Analysis with Instruments 那一章節。

重要:Leaks和Allocation工具不能檢測所有的記憶體使用情況。你需要和VM Tracker工具一起執行(包含在Allocation工具裡)來檢視你的記憶體執行。預設VM Tracker是不可用的。如果想通過VM Tracker來profile你的應用，點選instrument工具，選中”Automatic Snapshotting”標籤或者手動點選”Snapshot Now”按鈕。