在iOS開發(fā)調(diào)試過程中以及上線之后,程序經(jīng)常會出現(xiàn)崩潰的問題。簡單的崩潰還好說,復(fù)雜的崩潰就需要我們通過解析Crash文件來分析了,解析Crash文件在iOS開發(fā)中是比較常見的。
現(xiàn)在網(wǎng)上有很多關(guān)于解析崩潰信息的博客,但是大多質(zhì)量參差不齊,或者有些細(xì)節(jié)沒有注意到。如果有哪些錯誤或遺漏,還請指點(diǎn),謝謝
獲取崩潰信息
在iOS中獲取崩潰信息的方式有很多,比較常見的是使用友盟、百度等第三方分析工具,或者自己收集崩潰信息并上傳公司服務(wù)器。下面列舉一些我們常用的崩潰分析方式:
使用友盟、百度等第三方崩潰統(tǒng)計(jì)工具。
自己實(shí)現(xiàn)應(yīng)用內(nèi)崩潰收集,并上傳服務(wù)器。
Xcode-Devices中直接查看某個設(shè)備的崩潰信息。
使用蘋果提供的Crash崩潰收集服務(wù)。
收集崩潰信息
蘋果給我們提供了異常處理的類,NSException類。這個類可以創(chuàng)建一個異常對象,也可以通過這個類獲取一個異常對象。
這個類中我們最常用的還是一個獲取崩潰信息的C函數(shù),我們可以通過這個函數(shù)在程序發(fā)生異常的時候收集這個異常。
//?將系統(tǒng)提供的獲取崩潰信息函數(shù)寫在這個方法中,以保證在程序開始運(yùn)行就具有獲取崩潰信息的功能
-?(BOOL)application:(UIApplication?*)application?didFinishLaunchingWithOptions:(NSDictionary?*)launchOptions?{
//?將下面C函數(shù)的函數(shù)地址當(dāng)做參數(shù)
NSSetUncaughtExceptionHandler(&UncaughtExceptionHandler);
returnYES;
}
//?設(shè)置一個C函數(shù),用來接收崩潰信息
void?UncaughtExceptionHandler(NSException?*exception){
//?可以通過exception對象獲取一些崩潰信息,我們就是通過這些崩潰信息來進(jìn)行解析的,例如下面的symbols數(shù)組就是我們的崩潰堆棧。
NSArray?*symbols?=?[exception?callStackSymbols];
NSString?*reason?=?[exception?reason];
NSString?*name?=?[exception?name];
}
我們也可以通過下面方法獲取崩潰統(tǒng)計(jì)的函數(shù)指針:
NSUncaughtExceptionHandler?*handler?=?NSGetUncaughtExceptionHandler();
dSYM 符號集
進(jìn)行崩潰分析,首先要弄懂一個概念,就是符號集。
符號集是我們對ipa文件進(jìn)行打包之后,和.app文件同級的后綴名為.dSYM的文件,這個文件必須使用Xcode進(jìn)行打包才有。
每一個.dSYM文件都有一個UUID,和.app文件中的UUID對應(yīng),代表著是一個應(yīng)用。而.dSYM文件中每一條崩潰信息也有一個單獨(dú)的UUID,用來和程序的UUID進(jìn)行校對。
我們?nèi)绻皇褂?dSYM文件獲取到的崩潰信息都是不準(zhǔn)確的。
符號集中存儲著文件名、方法名、行號的信息,是和可執(zhí)行文件的16進(jìn)制函數(shù)地址對應(yīng)的,通過分析崩潰的.Crash文件可以準(zhǔn)確知道具體的崩潰信息。
我們每次Archive一個包之后,都會隨之生成一個dSYM文件。每次發(fā)布一個版本,我們都需要備份這個文件,以方便以后的調(diào)試。進(jìn)行崩潰信息符號化的時候,必須使用當(dāng)前應(yīng)用打包的電腦所生成的dSYM文件,其他電腦生成的文件可能會導(dǎo)致分析不準(zhǔn)確的問題。

當(dāng)程序崩潰的時候,我們可以獲得到崩潰的錯誤堆棧,但是這個錯誤堆棧都是0x開頭的16進(jìn)制地址,需要我們使用Xcode自帶的symbolicatecrash工具來將.Crash和.dSYM文件進(jìn)行符號化,就可以得到詳細(xì)崩潰的信息。
崩潰分析
命令行解析Crash文件
通過Mac自帶的命令行工具解析Crash文件需要具備三個文件
symbolicatecrash,Xcode自帶的崩潰分析工具,使用這個工具可以更精確的定位崩潰所在的位置,將0x開頭的地址替換為響應(yīng)的代碼和具體行數(shù)。
我們打包時產(chǎn)生的dSYM文件。
崩潰時產(chǎn)生的Crash文件。
我在解析崩潰信息的時候,首先在桌面上建立一個Crash文件夾,然后將.Crash、.dSYM、symbolicatecrash放在這個文件夾中,這樣進(jìn)入這個文件夾下,直接一行命令就解決了。
symbolicatecrash我們可以在下面路徑下可以找到,我用的是Xcode7,其他版本Xcode路徑不一樣,請自行Google。
/Applications/Xcode.app/Contents/SharedFrameworks/DTDeviceKitBase.framework/Versions/A/Resources/symbolicatecrash
然后Window->Organizer->Archives中,選中archive的版本右擊,選擇Show in Finder就可以獲取dSYM文件了。

將.Crash、.dSYM、symbolicatecrash三個文件都放在我們在桌面建立的Crash文件夾中。

開啟命令行工具,進(jìn)入崩潰文件夾中
cd /Users/username/Desktop/崩潰文件夾
使用命令解析Crash文件
./symbolicatecrash ./*.crash ./*.app.dSYM > symbol.crash
如果上面命令不成功,使用命令檢查一下環(huán)境變量
xcode-select -print-path
返回結(jié)果:
/Applications/Xcode.app/Contents/Developer/
如果不是上面的結(jié)果,需要使用下面命令設(shè)置一下導(dǎo)出的環(huán)境變量,然后重復(fù)上面解析的操作。
export DEVELOPER_DIR=/Applications/XCode.app/Contents/Developer
解析完成后會生成一個新的.Crash文件,這個文件中就是崩潰詳細(xì)信息。圖中紅色標(biāo)注的部分就是我們代碼崩潰的部分。

注意,以下情況不會有崩潰信息產(chǎn)生:
內(nèi)存訪問錯誤(不是野指針錯誤)
低內(nèi)存,當(dāng)程序內(nèi)存使用過多會造成系統(tǒng)低內(nèi)存的問題,系統(tǒng)會將程序內(nèi)存回收
因?yàn)槟撤N原因觸發(fā)看門狗機(jī)制
通過Xcode查看設(shè)備崩潰信息
除了上面的系統(tǒng)分析工具來進(jìn)行分析,如果是我們自己直接使用手機(jī)連接崩潰或者崩潰之后連接手機(jī),選擇window-> devices -> 選擇自己的手機(jī) -> view device logs 就可以查看我們的崩潰信息了。

只要手機(jī)上的應(yīng)用是這臺電腦安裝打包的,這樣的崩潰信息系統(tǒng)已經(jīng)為我們符號化好了,我們只需要進(jìn)去之后等一會就行(不要相信這里面的進(jìn)度刷新,并不準(zhǔn)確),如果還是沒有符號化完畢 ,我們選擇文件,然后右擊選擇Re-Sysbomlicate就可以。
如果是使用其他電腦進(jìn)行的打包,我們可以在這里面將Crash文件導(dǎo)出,自己通過命令行的方式進(jìn)行解析。
使用第三方崩潰分析工具
現(xiàn)在有很多第三方工具都可以進(jìn)行崩潰統(tǒng)計(jì)分析,使用比較多的是友盟崩潰統(tǒng)計(jì),友盟崩潰統(tǒng)計(jì)被集成在友盟SDK中,具體用法直接看官方文檔是最好的方法,下面列出友盟崩潰統(tǒng)計(jì)文檔地址。
在這里我并不推薦友盟這個第三方,而是推薦一個更好用的第三方—bugHD。這個第三方和友盟的最大區(qū)別就是可以直接將崩潰信息分析結(jié)合dSYM分析好,在web網(wǎng)頁上展現(xiàn)出來,而且還可以統(tǒng)計(jì)崩潰數(shù)、崩潰設(shè)備、系統(tǒng)版本等。
下面是我公司使用bugHD統(tǒng)計(jì)的一些崩潰情況

在bugHD服務(wù)器已經(jīng)幫我們使用dSYM將崩潰符號化完成。我們可以通過點(diǎn)擊某條崩潰,查看詳細(xì)崩潰堆棧,以及崩潰設(shè)備分布和系統(tǒng)分布。

蘋果自帶崩潰統(tǒng)計(jì)工具
蘋果在Xcode中為我們集成了崩潰統(tǒng)計(jì)功能,在Window->Organizer->Crashes中可以看到

蘋果自帶的崩潰統(tǒng)計(jì)工具并不推薦用,如果想要使用這個功能,需要用戶在iPhone中進(jìn)行設(shè)置
設(shè)置->隱私->診斷與用量->診斷與用量數(shù)據(jù)(iOS8一下在通用中設(shè)置)
選擇自動發(fā)送,并與開發(fā)者共享即可
第三方工具惡意覆蓋
崩潰收集統(tǒng)計(jì)函數(shù)應(yīng)該只進(jìn)行一次調(diào)用,如果用第三方的話也最好只用一個第三方,這樣我們獲取崩潰統(tǒng)計(jì)信息的途徑也是唯一的。
第三方統(tǒng)計(jì)工具并不是用的越多越好,使用多個崩潰收集第三方會導(dǎo)致NSSetUncaughtExceptionHandler()函數(shù)指針的惡意覆蓋,導(dǎo)致有些第三方不能收到崩潰信息。
現(xiàn)在很多第三方崩潰收集工具為了確保自己能最大可能的收集到崩潰信息,會對NSSetUncaughtExceptionHandler()函數(shù)指針的惡意覆蓋。因?yàn)檫@個函數(shù)是將函數(shù)地址當(dāng)做參數(shù)傳遞,所以只要重復(fù)調(diào)用就會被覆蓋,這樣就不能保證崩潰收集的穩(wěn)定性。
我們解析崩潰信息時,看到崩潰堆棧只有main.m文件中的崩潰,并且可以確定不是因?yàn)閙ain.m文件中的bug導(dǎo)致的崩潰,就基本可以確定是NSSetUncaughtExceptionHandler()函數(shù)指針被惡意覆蓋。
