技術(shù)貼:手游頻繁崩潰”閃退”的原因是什么?(2)

三.crash日志的解析

如果是腳本層邏輯導(dǎo)致的crash，如上所述，這種情況是可以直接根據(jù)收集的日志內(nèi)容來定位導(dǎo)致crash的邏輯的。如果是引擎層發(fā)生了問題，該如何定位解析呢。先來看一個(gè)crash的栗子：

如上圖所示，

1)crash標(biāo)識(shí)是應(yīng)用進(jìn)程產(chǎn)生crash時(shí)的一些標(biāo)識(shí)信息，它描述了該crash的唯一標(biāo)識(shí)(E838FEFB-ECF6-498C-8B35-D40F0F9FEAE4)，所發(fā)生的硬件設(shè)備類型(iphone3,1代表iphone4)，以及App進(jìn)程相關(guān)的信息等;

2)基本信息描述的是crash發(fā)生的時(shí)間和系統(tǒng)版本;

3)異常類型描述的是crash發(fā)生時(shí)拋出的異常類型和錯(cuò)誤碼;

4)線程回溯描述了crash發(fā)生時(shí)所有線程的回溯信息，每個(gè)線程在每一幀對(duì)應(yīng)的函數(shù)調(diào)用信息(這里由于空間限制沒有全部列出);

5)二進(jìn)制映像是指crash發(fā)生時(shí)已加載的二進(jìn)制文件。以上就是一份crash日志包含的所有信息，接下來就需要根據(jù)這些信息去解析定位導(dǎo)致crash發(fā)生的代碼邏輯， 這就需要用到符號(hào)化解析的過程(洋名叫：symbolication)。

符號(hào)化解析過程有三種方法：

xcode可視化查看，

symbolicatecrash工具，

atos工具;但是這三種方法都需要用到構(gòu)建app時(shí)生成的.app文件和.app.dsym這兩個(gè)文件，第一種方式已經(jīng)在第二章節(jié)提到過，不再贅述，下面介紹第二種和第三種解析的方式。

3.1 symbolicatecrash解析

symbolicatecrash是xcode自帶的一個(gè)命令行工具，在xcode5.0以前的位置是/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/Library/PrivateFrameworks/DTDeviceKit.framework/Versions/A/Resources/，xcode5.0以后路徑就變成了/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/Library/PrivateFrameworks/DTDeviceKitBase.framework/Versions/A/Resources/

比如以上述提到的TestFlight App為例，將TestFlight .crash?TestFlight .app和TestFlight .app.dsym三個(gè)文件放在同一個(gè)目錄下，然后運(yùn)行 symbolicatecrash?TestFlight.crash TestFlight.app.dsym>?TestFlight .log，查看TestFlight.log文件的內(nèi)容：

從圖中連線可以看出具體出現(xiàn)問題的邏輯代碼是在那個(gè)文件的哪一行，這樣就根據(jù)解析出來的指定函數(shù)來定位crash的發(fā)生原因。

3.2 atos方法

atos是一個(gè)BSD平臺(tái)的通用指令，通過它可以將數(shù)字地址轉(zhuǎn)換為對(duì)應(yīng)的二進(jìn)制映像或者進(jìn)程的符號(hào)，通過該指令進(jìn)行符號(hào)化解析的時(shí)候需要說明一點(diǎn)的是只有當(dāng).app文件、crash文件和.app.dsym文件三者的UUID都是一致的時(shí)候，該crash文件才能被正確解析，否則解析失敗。(注：uuid是app應(yīng)用在移動(dòng)設(shè)備上的唯一標(biāo)識(shí))可以通過以下方式來查看.app和.app.dsym文件的uuid，以上述提到的TestFlight應(yīng)用為例:

而crash日志文件的uuid在二進(jìn)制映像中的第一行：

由此可見armv7架構(gòu)下三者保持一致，都是4a42d422a466338aa56e88840b74de3d，那接下來開始進(jìn)行符號(hào)化解析。

從上文crash日志文件的線程回溯可以發(fā)現(xiàn)閃退時(shí)函數(shù)的回溯列表里格式不是完全一致，比如下圖中的方式1和方式2在第2列的表達(dá)方式上不太一樣，方式1是用的庫函數(shù)名，方式2則是一個(gè)基本地址。其實(shí)這兩種方式都可以用一種通用的解析方式來搞定：

首先計(jì)算加載地址(load address):

以方式1中的0x333d8049 UIApplicationMain + 1137 為例，這一幀對(duì)應(yīng)的 load address=0x333d8049 -1137=0x333d7bd8

也就是UIApplicationMain的地址是0x333df12;方式2的0x00068b19 0x36000 + 207641，通過上述方式的計(jì)算就是load address=0x00068b19 -207641=0x36000 ，可以發(fā)現(xiàn)結(jié)果與第二列的值是相同的，也就是它的加載地址就是第二列的值0x36000? 然后用xcrun atos -arch armv7 -o TestFlight.app/TestFlight? 0x36000 0x00068b19 的指令來解析crash日志線程0和線程3中帶有TestFlight模塊的地址，結(jié)果發(fā)現(xiàn)TestFlight程序的代碼回溯過程：

可以看出base

address(基地址)是4000，函數(shù)的回溯過程是main.m文件的第16行的某個(gè)函數(shù)出現(xiàn)問題，然后該函數(shù)在邏輯調(diào)用中會(huì)調(diào)用到AFURLConnnectionOperation.m文件的第162行的某個(gè)函數(shù)，這個(gè)邏輯的調(diào)用與第一種方法解析的TestFlight.log文件作對(duì)比,crash的解析完全一致，由此就可以定位到crash的原因所在，接下來去解決crash文件也就水到渠成了。

四.小結(jié)

以上是根據(jù)自己的經(jīng)驗(yàn)和理解對(duì)iOS平臺(tái)下的crash問題(包括原理、收集和解析過程)進(jìn)行的一次剖析，雖然蘋果的沙盒系統(tǒng)對(duì)iOS平臺(tái)的下的很多應(yīng)用信息的提取有較多的限制，但是要相信方法總比問題多。對(duì)于crash問題的理解和收集過程可以很好地輔助項(xiàng)目組來提高項(xiàng)目的質(zhì)量，同時(shí)對(duì)于更深入地理解iOS平臺(tái)知識(shí)和crash原理有很好的幫助。當(dāng)然，本文更多的涉及iOS平臺(tái)下的crash問題，對(duì)于Android平臺(tái)的crash問題涉及較少。雖然細(xì)節(jié)的實(shí)現(xiàn)上可能有差異，但是內(nèi)部的原理邏輯應(yīng)該是相同或者相似的，后續(xù)筆者還將繼續(xù)關(guān)注關(guān)于Android平臺(tái)相關(guān)問題的調(diào)研學(xué)習(xí)。