iOS Swift Crash的捕獲
crash捕獲介紹
-
如果對crash捕獲不太瞭解，可以先參考這篇文章,本文進行
Mach異常+Unix信號方式捕獲crash。 -
NSException一般只在OC當中被捕獲，一般情況下在捕獲NSException異常後同時也會捕獲到一個對應的signal異常。但如果你使用的是純swift開發，如下代碼並不會捕獲相關的crash
NSSetUncaughtExceptionHandler(UncaughtExceptionHandler)
swift崩潰捕獲
-
swift通常都是通過對應的signal來捕獲crash。對於swift的崩潰捕獲，Apple的文檔中有描述說需要通過
SIGTRAP信號捕獲強轉失敗，及非可選的nil值導致的崩潰.具體描述如下：Trace Trap[EXC_BREAKPOINT // SIGTRAP] 類似於異常退出，此異常旨在使附加的調試器有機會在其執行中的特定點中斷進程。您可以使用該__builtin_trap()函數從您自己的代碼觸發此異常。如果沒有附加調試器，則該過程將終止並生成崩潰報告。 較低級的庫（例如，libdispatch）會在遇到致命錯誤時捕獲進程。有關錯誤的其他信息可以在崩潰報告的“ 附加診斷信息”部分或設備的控制檯中找到。 如果在運行時遇到意外情況，Swift代碼將以此異常類型終止，例如： 1.具有nil值的非可選類型 2.一個失敗的強制類型轉換 -
對於swift還有一種崩潰需要捕獲(Intel處理器,我認爲應該是指在模擬器上的崩潰)，爲保險起見，也需要將信號
SIGILL進行註冊，Apple同樣對其中做了描述Illegal Instruction[EXC_BAD_INSTRUCTION // SIGILL] 該過程嘗試執行非法或未定義的指令。該過程可能嘗試通過錯誤配置的函數指針跳轉到無效地址。 在Intel處理器上，ud2操作碼引起EXC_BAD_INSTRUCTION異常，但通常用於進程調試目的。如果在運行時遇到意外情況，Intel處理器上的Swift代碼將以此異常類型終止。有關詳細信息，請參閱Trace Trap。
crash捕獲實現代碼參考
//對於OC的exception採取如下方式捕獲
NSSetUncaughtExceptionHandler(UncaughtExceptionHandler)
//對於Swift則捕獲相關signa，一般來說如下幾種已經能夠捕獲大部分crash。(其中SIGTRAP一定要捕獲,swift大量的crash都會通過它）
signal(SIGABRT, SignalExceptionHandler)
signal(SIGSEGV, SignalExceptionHandler)
signal(SIGBUS, SignalExceptionHandler)
signal(SIGTRAP, SignalExceptionHandler)
signal(SIGILL, SignalExceptionHandler)
獲取Slide Address
通過獲取到偏移量地址Slide
Address和錯誤信息的內存地址基本即可定位錯誤，錯誤信息的內存地址在捕獲的crash信息中會體現，Slide
Address則需要我們自己獲取，通過調用如下C方法我們可以獲取到偏移量地址，這裏通過OC文件來調用C方法。方法如下:
//MARK: - 獲取偏移量地址
long calculate(void){
long slide = 0;
for (uint32_t i = 0; i < _dyld_image_count(); i++) {
if (_dyld_get_image_header(i)->filetype == MH_EXECUTE) {
slide = _dyld_get_image_vmaddr_slide(i);
break;
}
}
return slide;
}
crash分析介紹
- 如果想要定位錯誤，通過拿到
Slide Address和錯誤信息的內存地址即可定位(實際上錯誤信息地址可以通過Slide Address加上偏移量獲得) - 拿到
Slide Address和錯誤信息的內存地址後我們可以通過一個開源工具dSYMTools直接定位到我們想要的信息。感謝作者的貢獻，讓我們更加方便快捷的分析問題。 - dSYMTools 需要傳入.xcarchive文件，你可以通過Xcode找到你對應提交版本的.xcarchive。你也可以在提交前保留對應的.xcarchive，以供萬一產生crash分析使用,這裏的.xcarchive一定要與產生crash信息的版本對應，否則無法定位到崩潰信息
具體分析
-
當自己捕獲NSException Crash並上傳到服務器之後，正常crash大概會顯示信息如下，我們大概能夠知道是由於數組溢出導致的崩潰。
Stack: slideAdress:0xec000 name:NSRangeException reason:Optional("*** -[__NSArray0 objectAtIndex:]: index 66 beyond bounds for empty NSArray") 0 CoreFoundation 0x0000000181646ff0 <redacted> + 148 1 libobjc.A.dylib 0x00000001800a8538 objc_exception_throw + 56 2 CoreFoundation 0x00000001815b2eb8 <redacted> + 0 3 CrashManager 0x00000001000f3000 CrashManager + 28672 4 UIKit 0x00000001877ab0ec <redacted> + 96 5 UIKit 0x00000001877ab06c <redacted> + 80 6 UIKit 0x00000001877955e0 <redacted> + 440 7 UIKit 0x00000001877aa950 <redacted> + 576 8 UIKit 0x00000001877aa46c <redacted> + 2480 9 UIKit 0x00000001877a5804 <redacted> + 3192 10 UIKit 0x0000000187776418 <redacted> + 340 11 UIKit 0x0000000187f6ff64 <redacted> + 2400 12 UIKit 0x0000000187f6a6c0 <redacted> + 4268 13 UIKit 0x0000000187f6aaec <redacted> + 148 14 CoreFoundation 0x00000001815f5424 <redacted> + 24 15 CoreFoundation 0x00000001815f4d94 <redacted> + 540 16 CoreFoundation 0x00000001815f29a0 <redacted> + 744 17 CoreFoundation 0x0000000181522d94 CFRunLoopRunSpecific + 424 18 GraphicsServices 0x0000000182f8c074 GSEventRunModal + 100 19 UIKit 0x00000001877db130 UIApplicationMain + 208 20 CrashManager 0x00000001000f139c CrashManager + 21404 21 libdyld.dylib 0x000000018053159c <redacted> + 4如上所示，slideAdress我們已經通過程序獲取，這裏是0xec000，由上往下找，我們可以看到
3 CrashManager 0x00000001000f3000 CrashManager + 28672出現了CrashManager信息，那麼0x00000001000f3000則有可能爲我們想要定位的錯誤信息地址。將我們得到數據帶入工具可清晰定位到錯誤：![NSException錯誤信息.png]()
NSException錯誤信息.png
-
如果捕獲到的Signal Crash，可能crash顯示的信息大概會如下：
Stack: slideAdress:0xa4000 0 CrashManager 0x00000001000a8f10 CrashManager + 20240 1 CrashManager 0x00000001000a9024 CrashManager + 20516 2 libsystem_platform.dylib 0x000000018070530c _sigtramp + 36 3 CrashManager 0x00000001000ab1bc CrashManager + 29116 4 CrashManager 0x00000001000aaa64 CrashManager + 27236 5 UIKit 0x00000001877ab0ec <redacted> + 96 6 UIKit 0x00000001877ab06c <redacted> + 80 7 UIKit 0x00000001877955e0 <redacted> + 440 8 UIKit 0x00000001877aa950 <redacted> + 576 9 UIKit 0x00000001877aa46c <redacted> + 2480 10 UIKit 0x00000001877a5804 <redacted> + 3192 11 UIKit 0x0000000187776418 <redacted> + 340 12 UIKit 0x0000000187f6ff64 <redacted> + 2400 13 UIKit 0x0000000187f6a6c0 <redacted> + 4268 14 UIKit 0x0000000187f6aaec <redacted> + 148 15 CoreFoundation 0x00000001815f5424 <redacted> + 24 16 CoreFoundation 0x00000001815f4d94 <redacted> + 540 17 CoreFoundation 0x00000001815f29a0 <redacted> + 744 18 CoreFoundation 0x0000000181522d94 CFRunLoopRunSpecific + 424 19 GraphicsServices 0x0000000182f8c074 GSEventRunModal + 100 20 UIKit 0x00000001877db130 UIApplicationMain + 208 21 CrashManager 0x00000001000a939c CrashManager + 21404 22 libdyld.dylib 0x000000018053159c <redacted> +
一般我們無法從signal產生的這些信息中直觀獲取到crash產生的原因，這裏崩潰的地址我們一般優先選擇_sigtramp後第一條有我們程序信息的地址，所以這裏將slideAdress：0xa4000和可能的錯誤信息地址0x00000001000ab1bc代入：
signalCrash.png
注意事項
- 如果你使用工具解析後得到的信息是類似於這樣的
_hidden#30_ (in libswiftObjectiveC.dylib) (__hidden#70_:0),那麼極有可能是因爲你提交版本的時候勾選了BitCode，勾選了Bitcode之後,用戶安裝的二進制文件是蘋果服務器經過優化後生成的,其對應的調試符號信息丟失了,所以你看到的全部是類似於__hidden#70_:0這樣的信息，所以也無法通過還原奔潰現場找原因了.如果你如果你不太理解BitCode,可以參考這篇BitCode介紹和這篇討論 - 如果你使用模擬器，那麼由於本身綁定相關dSYM文件，你獲取到的crash信息中可能不是錯誤地址而是很明顯的相關錯誤信息，這不在本文討論範圍內，畢竟在調試過程中獲取崩潰信息相對容易，本文闡述的是你的應用已經提交後捕獲和分析用戶使用過程中產生的crash
資源支持
這是一個完整的Demo,本篇文章所闡述的內容在Demo中都有體現，你可以直接使用Demo中的模塊完成Crash捕獲，也可以參考Demo閱讀本文，相信可以更快理解，如果對你有幫助，給個star唄。
crash捕獲參考文檔連接