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