（點擊上方公眾號，可快速關注）
來源：南華Coder 自薦投稿
www.jianshu.com/p/3261493e6d9e
如有好文章投稿，請點擊 → 這裡了解詳情
一、捕獲iOS Crash
1、設置異常斷點並運行
設置異常斷點.png
說明：設置Xcode異常斷點後運行程序，發生Crash時，斷點會定位到出錯的代碼行，但僅適用於開發階段。線上APP的Crash還需要通過收集Crash機制來捕獲Crash並記錄在日誌中。
2、Mach異常 和 Unix信號
iOS Crash發生時，先產生Mach異常(最底層的內核級異常)，然後Mach異常在host層被ux_exception轉換為相應的Unix信號，並通過threadsignal將信號投遞到出錯的線程。
在捕獲Crash事件時，優選Mach異常。因為Mach異常處理會先於Unix信號處理發生，如果Mach異常的handler讓程序exit了，那麼Unix信號就永遠不會到達這個進程了。而轉換Unix信號是為了兼容更為流行的POSIX標準(SUS規範)，這樣就不必了解Mach內核也可以通過Unix信號的方式來兼容開發。
在方案實現時，通過捕獲Mach異常+Unix信號組合方式來捕獲Crash事件。在選擇具體方案時，可以選擇PLCrashReporter這樣優秀的開源項目，也可以選擇友盟、Bugly 這類完善的Crash上報和統計的產品(試項目需求而定)。
3、捕獲Crash
並不是所有的Crash都可以捕獲到NSException，如果捕獲不到，可以使用signal機制來捕獲Crash發生時的錯誤內容。
1) 可以捕獲的NSException，通過註冊NSUncaughtExceptionHandler捕獲異常信息
//註冊異常處理函數
NSSetUncaughtExceptionHandler(&uncaught_exception_handler);
//異常處理函數
static void uncaught_exception_handler (NSException *exception) {
//可以取到 NSException 信息
//...
abort();
}
說明： 使用Objective-C的異常處理是不能得到signal的。
2) 無法捕獲的NSException，利用Unix標準的signal機制，註冊SIGABRT, SIGBUS, SIGSEGV等信號發生時的處理函數。
//註冊處理SIGSEGV信號
signal(SIGSEGV,handleSignal);
// 註冊處理其他信號 ....
//信號處理函數
static void handleSignal( int sig ) {
}
二、Crash日誌組成
上部分介紹了Crash的捕獲，這部分來看看Crash日誌的組成。
1、日誌內容Demo
日誌主要分為六個部分：進程信息、基本信息、異常信息、線程回溯、線程狀態和二進位映像。下面是從某APP具體的Crash日誌抽出的主要信息，展示如下：
//1、進程信息
Hardware Model: iPhone9,2
Process: AppName [3580]
Path: /var/containers/Bundle/Application/C7B90C8A-E269-4413-A011-552971D1ED39/AppName.app
Identifier: xxxx.xxx.xxxx.xxx
Version: xx.xx
Code Type: ARM-64 (Native)
Parent Process: [1]
//2、基本信息
Date/Time: 2017-05-22 03:05:06.743 +0800
OS Version: iPhone OS 10.2.1 (14D27)
//3、異常信息
Exception Type: NSInvalidArgumentException(SIGABRT)
Exception Codes: -[NSNull integerValue]: unrecognized selector sent to instance 0x1a9d88ef8 at 0x00000001835c7014
Crashed Thread: 0
//4、線程回溯 （展示發生Crash線程的回溯信息，其他略）
Thread 0 Crashed:
0 libsystem_kernel.dylib 0x00000001835c7014 __pthread_kill + 4
1 libsystem_c.dylib 0x000000018353b400 abort + 140
2 AppName 0x0000000100a26704 0x0000000100028000 + 10479360
3 CoreFoundation 0x00000001845f9538 ___handleUncaughtException + 644
2 CoreFoundation 0x0000000184600268 ___methodDescriptionForSelector
3 CoreFoundation 0x00000001845fd270 ____forwarding___ + 916
4 CoreFoundation 0x00000001844f680c _CF_forwarding_prep_0 + 80
5 AppName 0x0000000100205280 0x0000000100028000 + 1954432
6 AppName 0x00000001002ae59c 0x0000000100028000 + 2647440
7 AppName 0x0000000100482944 0x0000000100028000 + 4565312
16 CoreFoundation 0x00000001845a6810 ___CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 12
+ 12
17 CoreFoundation 0x00000001845a43fc ___CFRunLoopRun + 1660
18 CoreFoundation 0x00000001844d22b8 CFRunLoopRunSpecific + 436
//5、進程狀態（展示部分）
Thread 0 crashed with ARM 64 Thread State:
x0: 000000000000000000 x1: 000000000000000000 x2: 000000000000000000 x3: 0xffffffffffffffff
x4: 0x0000000000000010 x5: 0x0000000000000020 x6: 000000000000000000 x7: 000000000000000000
x8: 0x0000000008000000 x9: 0x0000000004000000 x10: 000000000000000000 x11: 0x00000001ac336c83
x12: 0x00000001ac336c83 x13: 0x0000000000000018 x14: 0x0000000000000001 x15: 0x0000000000000881
x16: 0x0000000000000148 x17: 000000000000000000 x18: 000000000000000000 x19: 0x0000000000000006
//6、二進位映像 （展示部分）
Binary Images:
0x100028000 - 0x1011dbfff +AppName arm64 /var/containers/Bundle/Application/C7B90C8A-E269-4413-A011-552971D1ED39/AppName.app/AppName
0x18368a000 - 0x183693fff libsystem_pthread.dylib arm64 /usr/lib/system/libsystem_pthread.dylib
0x1835a8000 - 0x1835ccfff libsystem_kernel.dylib arm64 /usr/lib/system/libsystem_kernel.dylib
0x1834b1000 - 0x1834b5fff libdyld.dylib arm64 /usr/lib/system/libdyld.dylib
0x1834d8000 - 0x183556fff libsystem_c.dylib arm64 /usr/lib/system/libsystem_c.dylib
0x183481000 - 0x1834b0fff libdispatch.dylib arm64 /usr/lib/system/libdispatch.dylib
0x183028000 - 0x183401fff libobjc.A.dylib arm64 /usr/lib/libobjc.A.dylib
2、日誌內容組成分析
整個日誌內容中，直接和Crash信息相關，最能幫助開發者定位問題部分是： 異常信息 和 線程回溯部分的內容。
1) 進程信息：發生Crash閃退進程的相關信息
Hardware Model : 標識設備類型。 如果很多崩潰日誌都是來自相同的設備類型，說明應用只在某特定類型的設備上有問題。上面的日誌裡，崩潰日誌產生的設備是iPhone 7 Plus (iPhone 7 Plus 也是2個版本 iPhone9,2 和 iPhone9,4. 硬體代號為 D11AP 和 D111AP. 型號有: A1661, A1784, A1785 和 A1786. )
Process 是應用名稱。中括號裡面的數字是閃退時應用的進程ID。
2) 基本信息：給出了一些基本信息，包括閃退發生的日期和時間，設備的iOS版本。
3) 異常信息：閃退發生時拋出的異常類型。還能看到異常編碼和拋出異常的線程。
//以上面內容中的異常信息為例：
Exception Type: NSInvalidArgumentException(SIGABRT)
Exception Codes: -[NSNull integerValue]: unrecognized selector sent to instance 0x1a9d88ef8 at 0x00000001835c7014
Crashed Thread: 0
4) 線程回溯：回溯是閃退發生時所有活動幀清單。它包含閃退發生時調用函數的清單。
5) 線程狀態：閃退時寄存器中的值。一般不需要這部分的信息，因為回溯部分的信息已經足夠讓你找出問題所在。
6) 二進位映像：閃退時已經加載的二進位文件。
三、異常信息解讀
1、Exception Type（異常類型）
異常類型可能的原因調試方法EXC_CRASHunrecognized selectorAll Exception PointEXC_BAD_ACCESS內存訪問錯誤NSZombieSIGSEGV引用了released對象 / 引用未init的對象 / 數組越界/ 試圖往沒有寫權限的內存地址寫數據NSZombieSIGABRT邏輯錯誤導致的Crash,比如嘗試多次釋放同一個沒存邏輯檢查SIGPIPETCP突然斷開，再發送數據添加signal（SIGPIPE，XX）具體信號說明參見iOS異常捕獲（http://www.iosxxx.com/blog/2015-08-29-iosyi-chang-bu-huo.html）
2、Exception Code（異常編碼）
異常編碼描述0x8badf00date bad food ，表示應用是因為發生watchdog超時而被iOS終止的。通常是應用花費太多時間而無法啟動、終止或響應用系統事件。0xdeadfa11dead fall，用戶強制退出。0xbaaaaaad用戶按住Home鍵和音量鍵，獲取當前內存狀態，不代表崩潰。0xbad22222VoIP 應用因為過於頻繁重啟而被終止0xc00010ffcool off，因為太燙了被幹掉0xdead10ccdead lock，表明應用因為在後臺運行時佔用系統資源（如通訊錄資料庫）0xbbadbeefbad beef，發生致命錯誤說明1：詳細的異常編碼代表的含義請參考：Hexspeak
說明2：在後臺任務列表中關閉已掛起的應用不會產生崩潰日誌。 因為應用一旦被掛起，它何時被終止都是合理的。所以不會產生崩潰日誌。
四、Crash日誌符號化
1、概述
線程回溯部分內容如下：
5 AppName 0x0000000100205280 0x0000000100028000 + 1954432
6 AppName 0x00000001002ae59c 0x0000000100028000 + 2647440
這兩條記錄包括四列:（以第一條記錄為例子）
幀編號—— 5（數字越小，發生時間越晚，發生順序越往後，越好鎖定問題的範圍）
二進位庫的名稱 ——此處是 AppName.
調用方法的地址 ——此處是 0x0000000100205280.
第四列分為兩個子列，一個基本地址和一個偏移量。此處是 x0000000100028000 + 1954432, 第一個數字指向文件，第二個數字指向文件中的代碼行。
說明1：線程回溯部分並不是我們習慣使用方法名和行數，而是十六進位地址。所以我們在分析Crash前需要將這些十六進位地址轉化成方法名稱和行數，改過程被稱為符號化。
說明2：符號化Crash日誌需要獲取對應的應用二進位文件以及生成二進位文件時產生的 .dSYM 文件（符號表）。必需完全匹配才行。否則，日誌將無法被完全符號化。
說明3： Xcode編譯項目後，會得到同名的 dSYM 文件（符號表），dSYM 文件（符號表）是保存 16 進位函數地址映射信息的中轉文件，我們調試的 symbols 都會包含在這個文件中，並且每次編譯項目的時候都會生成一個新的 dSYM 文件，位於 /Users//Library/Developer/Xcode/Archives 目錄下，對於每一個發布版本我們都很有必要保存對應的 Archives 文件。
說明4：符號化可以使用Xcode的兩種命令 symbolicatecrash命令 + atos命令
2、symbolicatecrash命令
1）首選找到symbolicatecrash命令的位置
find /Applications -name symbolicatecrash -type f
//我的本機命令的位置：/Applications/Xcode.app/Contents/SharedFrameworks/DVTFoundation.framework/Versions/A/Resources/symbolicatecrash
2）找到線上版本對應的xcarchive文件。從中找到.dSYM和.app文件
xcarchive所在的路徑一般在： /Users//Library/Developer/Xcode/Archives 目錄下
3）獲取crash日誌文件
4）將symbolicatecrash、.dSYM、.app、crash.crash拷貝到桌面下同一個文件夾下
5）檢查 xx.app 和 xx.app.dSYM 文件以及crash 文件這三種的 UUID是否一致。
dwarfdump --uuid xx.app/xx (xx代表你的項目名)
dwarfdump --uuid xx.app.dSYM
查看crash 日誌中的Incident Identifier （crash 文件的 UUID）
6）使用命令，生成「可定位問題的crash文件」
//symbolreportXXX.crash就是符號化後的文件
./symbolicatecrash crashXXX.crash appName.app.dSYM > symbolreportXXX.crash
7） 根據符號化後的線程回溯信息，可以幫助定位出問題的代碼行。
說明：如果執行symbolicatecrash命令出現 Error: 「DEVELOPER_DIR」 is not defined at ./symbolicatecrash…這樣的錯誤，可以在執行命令前，輸入export DEVELOPER_DIR=」/Applications/XCode.app/Contents/Developer」
3、atos命令
在符號化時候，還可以使用atos命令。發現armv7處理器上的crash使用symbolicatecrash無法符號化。
1）將.dSYM、.app、crash.crash放到同一個文件夾下。
2） 知道crash文件的UUID：執行grep 「AppName arm」 *crash，得到結果
crash1.crash:0x100040000 - 0x100e23fff +AppName arm64 /var/containers/Bundle/Application/55A4D641-847F-4D24-86E1-129B28461858/AppName.app/AppName
crash2.crash:0x100060000 - 0x100e43fff +AppName arm64 /var/containers/Bundle/Application/3229ED68-8D19-406D-A3F5-EC0310C9DB7C/QAppName.app/AppName
crash3.crash: 0x5000 - 0xce8fff +AppName armv7 /var/containers/Bundle/Application/C6BE271D-2EAC-42C0-8E72-4523F88C76B2/AppName.app/AppName
其中0x100040000、0x100060000、0x5000是加載地址(loadingAddress), 而arm64、armv7 是 architecture 的值(architectureValue)，這兩個值後面都要用。
3）然後執行atos命令,輸入成功，進入待輸入狀態
xcrun atos -o appName.app.dSYM/Contents/Resources/DWARF/appName -l loadingAddress -arch architectureValue
4） 此時輸入App對應的Crash地址，得到發生crash的信息。
實例1：
grep "AppName arm" *crash
xcrun atos -o AppName.app.dSYM/Contents/Resources/DWARF/AppName -l 0x100040000 -arch arm64
實例2：
grep "AppName arm" *crash
xcrun atos -o AppName.app.dSYM/Contents/Resources/DWARF/AppName -l 0x5000 -arch armv7
五、常見的Crash
有一些Crash比較常見，下面羅列出5種常見的Crash。
1、數組操作
@implementation NSMutableArray (Safe)
- (id)safeObjectAtIndex:(NSUInteger)index{
if (index < self.count){
return [self objectAtIndex:index];
}else{
NSLog(@"警告:數組越界!!!");
}
return nil;
}
@end
說明：數組的刪除等操作處理類似，數組操作前要進行數據校驗。
2、多線程下的Crash
解決辦法：將UI更新操作放在主線程中，可以使用performSelectorOnMainThread 或 GCD
//子線程中，使用宏將更新UI的任務派發到主隊列
#define dispatch_main_sync_safe(block) \
if ([NSThread isMainThread]) { \
block(); \
} else { \
dispatch_sync(dispatch_get_main_queue(), block); \
}
#define dispatch_async_main(block) dispatch_async(dispatch_get_main_queue(), block)
場景2：多線程中創建單例解決辦法：使用dispatch_once，保證代碼只執行一次，保證線程安全。
//以QSAccountManager單例為例
static QSAccountManager *_shareManager = nil;
+ (instancetype)shareManager{
static dispatch_once_t once;
dispatch_once(&once, ^{
_shareManager = [[self alloc] init];
});
return _shareManager;
}
+ (instancetype)allocWithZone:(struct _NSZone *)zone{
static dispatch_once_t onceToken;
dispatch_once(&onceToken, ^{
_shareManager = [super allocWithZone:zone];
});
return _shareManager;
}
- (nonnull id)copyWithZone:(nullable NSZone *)zone{
return _shareManager;
}
3、WatchDog 超時造成的Crash
4、performSelector:withObject:afterDelay下的Crash
5、SIGPIPE導致的程序退出
當伺服器close一個連接時，若client端接著發數據。根據TCP協議的規定，會收到一個RST響應，client再往這個伺服器發送數據時，系統會發出一個SIGPIPE信號給進程，告訴進程這個連接已經斷開了，不要再寫了。而根據信號的默認處理規則，SIGPIPE信號的默認執行動作是terminate(終止、退出),所以client會退出。
場景：長連接socket或重定向管道進入後臺，沒有關閉解決辦法1：切換到後臺時，關閉長連接和管道，回到前臺再重建；解決辦法2：使用signal(SIGPIPE,SIG_IGN)，將SIGPIPE交給了系統處理。這麼做將SIGPIPE設為SIG_IGN，使得客戶端不執行默認動作，即不退出。
End
看完本文有收穫？請分享給更多人
關注「 iOS大全 」，提升iOS技能