前言

iOS崩潰是讓iOS開發人員比較頭痛的事情，app崩潰了，說明程式碼寫的有問題，這時如何快速定位到崩潰的地方很重要。除錯階段是比較容易找到出問題的地方的，但是已經上線的app並分析崩潰報告就比較麻煩了。

之前我總是找到一個改一個，並靠別人測試重現來找出問題的地方，這樣往往比較耗費時間。而且比較難找到原因的時候每次都是到網上找各種資源搜尋，解決了之後也沒有認真分析原因及收集，時間長了之後就會忘記原來解決過的問題，別人來問我的時候我也不能很快找到答案。所以這裡寫一個關於崩潰的文章，以便之後自己查詢用。

這裡也會開始寫一個demo，爭取把所有的崩潰原因都寫進demo裡。

1.崩潰分析

1.1.崩潰日誌（crash log）

1.1.1.xcode中檢視崩潰資訊

xcode->Window->Organizer->Crashes

1.1.2.根據符號表來監測奔潰位置

什麼是符號表

符號表就是指在Xcode專案編譯後，在編譯生成的二進位制檔案.app的同級目錄下生成的同名的.dSYM檔案。

.dSYM檔案其實是一個目錄，在子目錄中包含了一個16進位制的儲存函式地址對映資訊的中轉檔案，所有Debug的symbols都在這個檔案中(包括檔名、函式名、行號等)，所以也稱之為除錯符號資訊檔案。

符號表有什麼用

符號表就是用來符號化 crash log（崩潰日誌）。crash log中有一些方法16進位制的記憶體地址等，通過符號表就能找到對應的能夠直觀看到的方法名之類。

如何得到.dsYM檔案

我們在Archive的時候會生成.xcarchive檔案，然後顯示包內容就能夠在裡面找到.dsYM檔案和.app檔案。

如何使用.dsYM

1.友盟.dsYM分析

如果是使用友盟的話，我們能在錯誤列表裡看到一些錯誤，然後可以匯出奔潰資訊，匯出的檔案為.csv檔案。友盟有一個分析工具，使用那個工具可以看到一些錯誤的函式，行號等。但是很容易分析失敗，不知道為什麼？

注意：使用的時候要確保你的.xcarchive在 ~/Library/Developer/Xcode/或該路徑的子目錄下。

.xcarchive裡的.dsYM檔案和.app檔案是有對應的UUID的。然後你的錯誤詳情裡也是有UUID，只有當UUID相等時才能分析對。

我犯的錯誤：因為我們是兩個人開發，Archive的時候都是在另一個人的電腦上Archive的，所以我的電腦里根本沒有對應的.xcarchive檔案。所以我在我電腦上用友盟的分析工具分析是時候是監測不出來錯誤的。

2.第三方小工具.dsYM分析

或者自己找到.xcarchive檔案和錯誤記憶體地址(友盟錯誤詳情裡標綠色的為錯誤記憶體地址)。然後通過一個小應用來分析出對應的函式。應用下載地址,具體可參考文章dSYM 檔案分析工具

下圖是我友盟裡的錯誤資訊，可以分析的記憶體地址就是標綠的地方，圖中zhefengle就是你的app名，這部分後面的地址就是可以解析符號化的地址：

下圖是分析工具分析上面的錯誤記憶體地址：

分析工具

3.命令列工具symbolicatecrash

symbolicatecrash是xcode的一個符號化crash log的命令列工具。使用方法也就是匯出.crash檔案（crash log）和找到.dsYM檔案，然後進行分析。

4.還有命令列工具atos

如果你有多個“.ipa”檔案，多個".dSYMB"檔案，你並不太確定到底“dSYM”檔案對應哪個".ipa"檔案，那麼，這個方法就非常適合你。

特別當你的應用釋出到多個渠道的時候，你需要對不同渠道的crash檔案，寫一個自動化的分析指令碼的時候，這個方法就極其有用。

1.1.3.奔潰日誌分析

以上是一個完整的崩潰日誌。其實友盟錯誤詳情裡的就是上圖的第4部分。

如何得到崩潰日誌

1.把裝置連上電腦，得到自己裝置的崩潰日誌

崩潰日誌可以從xcode裡開啟Devices看到對應手機的一些奔潰資訊。點選下圖的View Device Logs就能看到崩潰日誌。

2.使用第三方崩潰管理工具

我暫時只使用過友盟，友盟裡面有錯誤分析，就是擷取的崩潰日誌。

3.自己擷取崩潰日誌

自己寫入程式碼，然後擷取到崩潰日誌，把崩潰日誌傳送到開發者郵箱裡。
iOS Crash（崩潰）除錯技巧這篇文章中有介紹如何擷取崩潰日誌併發送到郵箱。

分析崩潰日誌

崩潰日誌中的（3）異常

Exception Type異常型別
通常包含1.7中的Signal訊號和EXC_BAD_ACCESS。

Exception Codes:異常編碼
0x8badf00d: 讀做 “ate bad food”! (把數字換成字母，是不是很像 :p)該編碼表示應用是因為發生watchdog超時而被iOS終止的。 通常是應用花費太多時間而無法啟動、終止或響應用系統事件。

0xbad22222: 該編碼表示 VoIP 應用因為過於頻繁重啟而被終止。

0xdead10cc: 讀做 “dead lock”!該程式碼表明應用因為在後臺執行時佔用系統資源，如通訊錄資料庫不釋放而被終止 。

0xdeadfa11: 讀做 “dead fall”! 該程式碼表示應用是被使用者強制退出的。根據蘋果文件, 強制退出發生在使用者長按開關按鈕直到出現 “滑動來關機”, 然後長按 Home按鈕。強制退出將產生 包含0xdeadfa11 異常編碼的崩潰日誌, 因為大多數是強制退出是因為應用阻塞了介面。

崩潰日誌中的（4）執行緒回溯

這部分提供應用中所有執行緒的回溯日誌。 回溯是閃退發生時所有活動幀清單。它包含閃退發生時呼叫函式的清單。看下面這行日誌:

它包括四列:
幀編號—— 此處是2。（數子從大到小為發生的順序）
二進位制庫的名稱 ——此處是 XYZLib.
呼叫方法的地址 ——此處是 0x34648e88.
第四列分為兩個子列，一個基本地址和一個偏移量。此處是0×83000 + 8740, 第一個數字指向檔案，第二個數字指向檔案中的程式碼行。

1.2.野指標分析方法(Enable Malloc Scribble)

介紹

因為野指標的原因發生崩潰是常常出現的事，而且比較隨機。關於一些原因及概念後面我們會講到。所以我們要提高野指標的崩潰率好來幫我們快速找到有問題的程式碼。

物件釋放後只有出現被隨機填入的資料是不可訪問的時候才會必現Crash。

這個地方我們可以做一下手腳，把這一隨機的過程變成不隨機的過程。物件釋放後在記憶體上填上不可訪問的資料，其實這種技術其實一直都有，xcode的Enable Scribble就是這個作用。

DSCrashDemo這個demo裡有上面這篇文章裡寫的關於提高野指標崩潰率的例子。

1.3.殭屍模式(NSZombieEnabled)

介紹

啟用了NSZombieEnabled的話，它會用一個殭屍來替換預設的dealloc實現，也就是在引用計數降到0時，該殭屍實現會將該物件轉換成殭屍物件。殭屍物件的作用是在你向它傳送訊息時，它會顯示一段日誌並自動跳入偵錯程式。

所以當啟用NSZombieEnabled時，一個錯誤的記憶體訪問就會變成一條無法識別的訊息傳送給殭屍物件。殭屍物件會顯示接受到得資訊，然後跳入偵錯程式，這樣你就可以檢視到底是哪裡出了問題。

所以這時一般崩潰的原因是：呼叫了已經釋放的記憶體空間，或者說重複釋放了某個地址空間。

如何找出問題

1.NSZombieEnabled

開啟NSZombieEnabled之後，如果遇到對應的崩潰型別既呼叫了已經釋放的記憶體空間，或者說重複釋放了某個地址空間。那麼就能在GDB中看到對應的輸出資訊。

比如會出現如下這樣的問題：
[__NSArrayM addObject:]: message sent to deallocated instance 0x7179910

2.MallocStackLoggingNoCompact

如果崩潰是發生在當前呼叫棧，通過上面的做法，系統就會把崩潰原因定位到具體程式碼中。但是，如果崩潰不在當前呼叫棧，系統就僅僅只能把崩潰地址告訴我們，而沒辦法定位到具體程式碼，這樣我們也沒法去修改錯誤。這時就可以修改scheme，讓xcode記錄每個地址alloc的歷史，這樣我們就可以用命令把這個地址還原出來。
如圖：(跟設定NSZombieEnabled一樣，新增MallocStackLoggingNoCompact，並且設定為YES)

這樣，當出現崩潰原因是message sent to deallocated instance 0x7179910，我們可以使用以下命令，把記憶體地址還原：

(gdb) nfo malloc-history 0x7179910

也可以使用下面的命令
(gdb) shell malloc_history {pid/partial-process-name} {address}

總結

還有官方文件Enabling the Malloc Debugging Features介紹了類似NSZombieEnabled和MallocStackLoggingNoCompact這類的環境變數的作用。

TODO：翻譯Enabling the Malloc Debugging Features這篇文章，寫對應的demo測試這類變數設定後如何找出記憶體出錯問題。

1.4.Enable Address Sanitizer（地址消毒劑）

設定這個引數後就能看到一些更詳細的錯誤資訊提示，甚至會有記憶體使用情況的展示。

C語言是一門危險的語言，記憶體安全是一個主要的問題。C語言中根本沒有記憶體安全可言。像下面的程式碼，會被正常的編譯，而且可能正常執行：
char *ptr = malloc(5);
ptr[12] = 0;
對於記憶體安全的驗證已經有一些解決方案了。如Clang的靜態程式碼分析，可以從程式碼中查詢特定型別的記憶體安全問題。如Valgrind之類的程式可以在執行時檢測到不安全的記憶體訪問。

Address Sanitizer是另外一種解決方案。它使用了一種新的方法，有利有弊。但仍不失為一個查詢程式碼問題的有力工具。

這類工具的理論依據是：訪問記憶體時，通過比較訪問的記憶體和程式實際分配的記憶體，驗證記憶體訪問的有效性，從而在bug發生時就檢測到它們，而不會等到副作用產生時才有所察覺。

malloc函式總是最少分配16個位元組。為了儲存針對標準malloc的記憶體的保護，需要分配記憶體到16位元組的範圍內，因此，若分配的記憶體大小不是16位元組的整數倍，餘出的幾個位元組將不受保護。

Address Sanitizer會追蹤受限記憶體，使用了一種簡單但是很巧妙的方法：它在程序的記憶體空間上儲存了一個固定的區域，叫做“影子記憶體區”。用記憶體消毒劑的術語來說，一個被標記為受限的記憶體被稱作“中毒”記憶體。“影子記憶體區”會記錄哪些記憶體位元組是中毒的。通過一個簡單的公式，可以將程序中的記憶體空間對映到“影子記憶體區”中，即：每8位元組的正常記憶體塊對映到一個位元組的影子記憶體上。在影子記憶體上，會跟蹤這8位元組的“中毒狀態”。

1.5.Static Analyzer（靜態分析）

Static Analyzer是一個非常好的工具去發現編譯器警告不會提示的問題和一些個人的內錯洩露和死儲存（不會用到的賦了值的變數）錯誤。這個方法可能大大的提高記憶體使用和效能，以及提升應用的整體穩定性和程式碼質量。

開啟方式：Xcode->Product-Analyze
然後我們就能看到如下藍色箭頭所示的一些有問題的程式碼。

1.6.unrecognized selector send to instancd 快速定位

在debug navigator的斷點欄裡新增Create Symbolic Breakpoint。

在Symbolic中填寫如下方法簽名：
-[NSObject(NSObject) doesNotRecognizeSelector:]

設定完成後再遇到類似的錯誤就會定位到具體的程式碼。

1.7.Signal和EXC_BAD_ACCESS錯誤分析

1.7.1.Signal

什麼是Signal

在電腦科學中，訊號（英語：Signals）是Unix、類Unix以及其他POSIX相容的作業系統中程序間通訊的一種有限制的方式。它是一種非同步的通知機制，用來提醒程序一個事件已經發生。當一個訊號傳送給一個程序，作業系統中斷了程序正常的控制流程，此時，任何非原子操作都將被中斷。如果程序定義了訊號的處理函式，那麼它將被執行，否則就執行預設的處理函式。

在iOS中就是未被捕獲的Objective-C異常（NSException），導致程式向自身傳送了SIGABRT訊號而崩潰。

Signal訊號的型別

SIGABRT–程式中止命令中止訊號
SIGALRM–程式超時訊號
SIGFPE–程式浮點異常訊號
SIGILL–程式非法指令訊號
SIGHUP–程式終端中止訊號
SIGINT–程式鍵盤中斷訊號
SIGKILL–程式結束接收中止訊號
SIGTERM–程式kill中止訊號
SIGSTOP–程式鍵盤中止訊號
SIGSEGV–程式無效記憶體中止訊號
SIGBUS–程式記憶體位元組未對齊中止訊號
SIGPIPE–程式Socket傳送失敗中止訊號
iOS異常捕獲這篇文章中有對各種訊號的解釋。

SIGABRT

就crash而言，SIGABRT是一個比較好解決的，因為他是一個可掌控的crash。App會在一個目的地終止，因為系統意識到app做了一些他不能支援的事情。

通常, SIGABRT 異常是由於某個物件接收到未實現的訊息引起的。 或者，用簡單的話說，在某個物件上呼叫了不存在的方法。

SIGSEGV

SIGSEGV程式無效記憶體中止訊號，一般是表示記憶體不合法,

SIGBUS

SIGBUS程式記憶體位元組未對齊中止訊號,

擷取Signal和Exception從容的崩潰

DSSignalHandlerDemo
這是一個防止奔潰的原始碼，可以使一些原本會奔潰的操作彈出UIAlertView。裡面寫了兩種訊號量的崩潰：SIGSEGV、SIGABRT，還有一些訊號大家可以寫上去提個PR給我。

下圖為原始碼的執行圖，其中Signal中的Signal(EGV)第一次點選的時候能彈出alert，如果第二次點選就沒有崩潰和alert，感覺像卡死一樣。

而Signal(BRT)中的這種訊號錯誤多次點選也是沒有問題的還是能繼續下去。個人猜測可能是SIGSEGV這種訊號錯誤會導致了整個程序掛了。

注意：測試的時候如果測試Signal型別的崩潰，不要在xcode下的debug模式進行測試。因為系統的debug會優先去攔截。應該build好應用之後直接點選執行app進行測試。

1.7.2.EXC_BAD_ACCESS

EXC_BAD_ACCESS是一個比較難處理的crash了，當一個app進入一種毀壞的狀態，通常是由於記憶體管理問題而引起的時，就會出現出現這樣的crash。通常1.7.1中的Signal訊號錯誤都會提醒EXC_BAD_ACCESS。

文中1.3就介紹了用一些變數設定來找出這類錯誤。

2.崩潰型別收集

2.1.新老作業系統相容

原因

開發人員在進行開發的時候，常常使用的是某個作業系統版本，所以在開發人員進行開發測試的那個系統版本上基本不會出現問題。但在其他版本上開發人員無法進行完全的測試，這就導致了在新系統上執行正常，但在舊系統上卻崩潰的情況。

在新 iOS 上正常的應用，到了老版本 iOS 上秒退最常見原因是系統動態連結庫或Framework無法找到。這種情況通常是由於 App 引用了一個新版作業系統裡的動態庫（或者某動態庫的新版本）或只有新 iOS 支援的 Framework，而又沒有對老系統進行測試，於是當 App 執行在老系統上時便由於找不到而秒退。

還有就是有些方法是新版作業系統才支援的，而又沒有對該方法是否存在於老系統中做出判斷。這種情況其實還是比較難出現的，除非開發人員太low了，因為這類方法在xcode編碼時編輯器都會有提醒的。

解決

這種問題一般就是使用者升級作業系統或者開發人員修改問題以相容老系統。

2.2.本地儲存的資料結構改變

原因

程式在升級時，修改了本地儲存的資料結構，但是對使用者既存的舊資料沒有做好升級，結果導致初始化時因為無法正確讀取使用者資料而秒退。

解決

第一種：是把服務端傳過來的一些資訊儲存在本地，使用的時候從本地資料庫取。

剛開始的時候我是第一次從服務端得到資料的時候直接解析成對應的model然後存入plist檔案裡面。這時就有一個問題，比如服務端新傳了欄位newId，但是我舊版model裡面沒有定義過，存入本地的資料還是沒有這個欄位。

然後等我升級了程式，新程式裡model，定義了這個newId欄位，但是舊版裡面資料已經儲存過一遍了沒有這個欄位。這時再去取就取不到了。

所以後來我就把儲存時解析資料改成了讀取時解析資料。就是不管服務端傳什麼資料都把它存下來，然後在使用的時候再把它解析成對應的model，這樣就不會丟失欄位了。

第二種：自己的一些資料儲存在本地SQLlite，新版的時候表結構改了。

SQLlite只支援更改一個表的名字，或者向表中增加一個欄位（列），但是我們不能刪除一個已經存在的欄位，或者更改一個已經存在的欄位的名稱、資料型別、限定符等等。

這種就是有時候新版又新增欄位了，或者改變了欄位的名稱了。一般來說原有的欄位名稱不應該改變，但是新增新欄位是常有的事。

一般做法是在第一次建立表的時候加一些冗餘欄位，以防後面不時之需。但是如果真沒辦法需要在舊錶上增加新欄位了，那就要做資料遷移了。

這裡有一個庫在FMDB基礎上管理SQLlite資料庫了，可以用來做資料遷移用。FMDBMigrationManager

TODO：做一個數據遷移的demo

2.3.訪問的資料為空或訪問資料型別不對

原因

這類情況是比較常見的，後端傳回了空資料，客戶端沒有做對應的判斷繼續執行下去了，這樣就產生了crash。或者自己本地的某個資料為空資料而去使用了。還有就是訪問的資料型別不是期望的資料型別而產生崩潰。

解決

第一種：

服務端都加入預設值，不返回空內容或無key，但是服務端往往會不太願意改，還有就是有些確實應該無值的話key也不用傳，減少資料量的傳輸。

第二種：

這種就是客戶端自己做判斷，如果每次都是自己去if判斷是否為空或格式是否正確那肯定是比較麻煩的。所以這裡用到了NSArray和NSDictionary的Category。一般我們訪問的資料都是NSArray或NSDictionary，所以在取值方法裡面做一下判斷，返回正確的資料型別或預設值即可。

DSCategories這裡面有兩個CategoryNSArray+SafeAccessM和NSDictionary+SafeAccess可以看一下。

2.4.操作了不該操作的物件，野指標之類

2.4.1野指標介紹

iOS中有空指標和野指標兩種概念。

空指標是沒有儲存任何記憶體地址的指標。如Student s1 = NULL;和Student s2 = nil;

而野指標是指指向一個已刪除的物件（"垃圾"記憶體既不可用記憶體）或未申請訪問受限記憶體區域的指標。野指標是比較危險的。因為野指標指向的物件已經被釋放了，不能用了，你再給被釋放的物件傳送訊息就是違法的，所以會崩潰。

空指標和野指標這篇文章介紹了空指標和野指標的概念。

2.4.2野指標崩潰情況

野指標訪問已經釋放的物件crash其實不是必現的，因為dealloc執行後只是告訴系統，這片記憶體我不用了，而系統並沒有就讓這片記憶體不能訪問。

所以野指標的奔潰是比較隨機的，你在測試的時候可能沒發生crash，但是使用者在使用的時候就可能發生crash了。

注意：arc環境比非arc環境更少出現野指標。

現實出現問題大概是下面幾種可能的情況：

1. 物件釋放後記憶體沒被改動過，原來的記憶體儲存完好，可能不Crash或者出現邏輯錯誤（隨機Crash）。
2. 物件釋放後記憶體沒被改動過，但是它自己析構的時候已經刪掉某些必要的東西，可能不Crash、Crash在訪問依賴的物件比如類成員上、出現邏輯錯誤（隨機Crash）。
3. 物件釋放後記憶體被改動過，寫上了不可訪問的資料，直接就出錯了很可能Crash在objc_msgSend上面（必現Crash，常見）。
4. 物件釋放後記憶體被改動過，寫上了可以訪問的資料，可能不Crash、出現邏輯錯誤、間接訪問到不可訪問的資料（隨機Crash）。
5. 物件釋放後記憶體被改動過，寫上了可以訪問的資料，但是再次訪問的時候執行的程式碼把別的資料寫壞了，遇到這種Crash只能哭了（隨機Crash，難度大，概率低）！！
6. 物件釋放後再次release（幾乎是必現Crash，但也有例外，很常見）。

參考下面這張圖：

2.5.記憶體處理不當

說到因為記憶體處理不當崩潰就要涉及到記憶體管理問題了。記憶體管理是軟體開發中一個重要的課題。iOS自從引入ARC機制後，對於記憶體的管理開發者好像輕鬆了很多，但是還會發生一些記憶體洩露之類的問題。

對於這一塊知識點需要了解ARC的一些機制，還有用instruments排查記憶體洩露問題等。這部分我後面會專門寫一篇文章進行闡述。

2.6.主執行緒UI長時間卡死，被系統殺掉

主執行緒被卡住是非常常見的場景，具體表現就是程式不響應任何的UI互動。這時按下除錯的暫停按鈕，檢視堆疊，就可以看到是到底是死鎖、死迴圈等，導致UI執行緒被卡住。

這部分需要研究多執行緒，還有如何看除錯欄裡的執行緒的資訊。

GCD死鎖這篇文章介紹了GCD使用多執行緒時的死鎖問題。
還有這篇iOS多執行緒中，佇列和執行的排列組合結果分析也值得參考

TODO：寫死鎖demo

2.7.多執行緒之間切換訪問引起的crash

多執行緒引起的崩潰大部分是因為使用資料庫的時候多執行緒同時讀寫資料庫而造成了crash。
多執行緒導致的iOS閃退分析這篇文章就是關於多執行緒crash的除錯。

3.參考文章及原始碼