昨天,運(yùn)維的同事反饋說(shuō)線上的App在某個(gè)賬號(hào)身上發(fā)生了多次的崩潰,需要我排查一下原因.
因?yàn)楣镜臋C(jī)制比較奇葩,沒(méi)有使用第三方的Bug跟蹤框架處理崩潰,導(dǎo)致唯一在我手上的bug信息就是后臺(tái)運(yùn)維提供的崩潰日志,以及手機(jī)信息和賬號(hào)信息.
其實(shí)我一直以來(lái)都不是特別會(huì)處理這種bug,更何況只有一堆堆棧信息.
slide: db0000 crashTime: 2019-06-05 15:27:40 Exception reason: +[NSMethodSignature signatureWithObjCTypes:]: type signature is empty.
Exception name: NSInvalidArgumentException
Exception stack:(
0 CoreFoundation 0x00000002245d9294 <redacted> + 252,
1 libobjc.A.dylib 0x00000002237b39f8 objc_exception_throw + 56,
2 CoreFoundation 0x00000002244cee88 <redacted> + 1268,
...
后面的還有很多信息,但是關(guān)鍵的就是這一些了.
關(guān)鍵是這個(gè)[NSMethodSignature signatureWithObjCTypes:]: type signature is empty.
根據(jù)之前看的資料和查閱的資料看,簡(jiǎn)單看就是對(duì)象在發(fā)送消息的時(shí)候,其類型為空導(dǎo)致了崩潰.
道理我都懂,但是在茫茫的代碼中去找一個(gè)這樣的空對(duì)象談何容易?
于是乎,我就是死馬當(dāng)活馬醫(yī)的想法,先去官網(wǎng)的App分析中去看看.
進(jìn)入后我們選擇需要查看的App然后點(diǎn)這個(gè)崩潰:
點(diǎn)擊后我們可以看到崩潰的詳細(xì):
至此,我基本得到了結(jié)論,那就是在我的App正式版本1.2.1中,6月7日發(fā)生了崩潰,而且蘋果也記錄下了此次崩潰,這樣就好說(shuō)了.接下來(lái)我們就需要通過(guò)Xcode嘗試去還原一下犯罪現(xiàn)場(chǎng),不對(duì)是Bug現(xiàn)場(chǎng).
先通過(guò)git工具checkout一份當(dāng)時(shí)的代碼,為什么要一份當(dāng)時(shí)的代碼,我們往后走就知道了.
先在菜單中選擇Window
對(duì)應(yīng)App以及對(duì)應(yīng)的版本下載崩潰日志
果其不然,要崩潰日志下載下來(lái),最后一步還原現(xiàn)場(chǎng):
點(diǎn)擊崩潰的地方,系統(tǒng)會(huì)提示打開(kāi)對(duì)于的工程去崩潰發(fā)生的位置:
最后我們達(dá)到現(xiàn)場(chǎng):
最后,其實(shí)這個(gè)是一個(gè)使用第三方NullSafe.m文件導(dǎo)致的崩潰,其實(shí)這個(gè)Bug比較尷尬,因?yàn)樵谖医邮诌@個(gè)項(xiàng)目前,項(xiàng)目中一直使用這個(gè)文件,主要是處理NSNull的情況.
于是我跑去github上看看情況:
我使用的1.3.4的release版本,而現(xiàn)在這個(gè)類已經(jīng)到2.0了而且有很大的改動(dòng).
作者的一句話引起了我的注意:
大概意思就是說(shuō),隨著iOS版本的升級(jí),會(huì)導(dǎo)致崩潰.
我會(huì)看了運(yùn)維提供的手機(jī)與版本信息,6plus iOS12.3.1,因此我懷疑就是這個(gè)類在作怪,一次崩潰的分析也找到了答案.
但是問(wèn)題是我如何去移除這個(gè)使用已久的類而不改變代碼的健壯性呢?
