簡單記錄下我是如何根據(jù)友盟崩潰列表上的崩潰日志定位到具體哪行代碼導致崩潰的 .

首先, 我用的是下圖這個分析工具, 十分感謝作者的無私奉獻 , 附上下載地址, 喜歡的童鞋動動小手指Star下吧

https://github.com/answer-huang/dSYMTools

分析工具.png

打開工具后將對應版本的archive文件拖進來, 把圖中對應信息按照崩潰日志里的詳細信息填寫

(注意一定要是對應版本的archive文件, 否則定位信息不準! 所以保留之前打包信息還是很有必要且重要的!)

崩潰日志.png

大括號里面顯示調(diào)用堆棧信息, 程序調(diào)用順序是下往上調(diào)用的, 如上圖中箭頭所示, 最上面那個地址也就是最后一次調(diào)用的方法, 正式它導致了崩潰, 所以在分析工具中錯誤信息內(nèi)存地址就填這個就行了,CPU Type 和slide address 對應填即可 , 之后點擊分析, 如下圖所示

定位代碼.png

有可能錯誤的地方 顯示了是哪個文件的哪個方法的哪一行出錯, 這個不用解釋了, 直接去對應版本的代碼里找到錯誤的地方 :

錯誤代碼.png

定位到這行代碼導致了崩潰, 檢查下定位是否準確. 我們看看友盟上的錯誤信息

-[__NSArrayM objectAtIndex:]: index 9 beyond bounds [0 .. 2]

數(shù)組越界, 在崩潰不好重現(xiàn)的情況下, 我們可以很清晰的推測這行代碼確實存在問題, passStr 的值可能大于數(shù)組的數(shù)量, 這時我們需要做一個安全判斷,防止崩潰. 更好的方法是給數(shù)組的字典擴展一個方法, 取值時允許任何范圍, 但是越界就返回空 :

- (id)objectOrNilAtIndex:(NSUInteger)index {

return index < self.count ? self[index] : nil;

}

使用分類給數(shù)組增加以上方法, 字典同理, 調(diào)用此方法替換系統(tǒng)方法, 代碼更安全 .

有些錯誤日志定位的到錯誤信息是UmengSignalHandler時, 可以不用管

友盟的官方解釋是:

UmengSignalHandler 不是錯誤，是捕捉crash的方法，本身不引起crash， 當crash發(fā)生時由它來捕捉。如果您不需要使用錯誤統(tǒng)計，可以通過[MobClick setCrashReportEnabled:NO];關(guān)閉。

需要注意的是, 關(guān)閉錯誤統(tǒng)計之后就不會再收到用戶的崩潰日志, 所以要慎重, 在確定公司不需要統(tǒng)計用戶崩潰信息時再關(guān)閉.

錯誤日志可以看出很多東西, 要學會善用錯誤日志 , 比如下面這個日志:

約束沖突.png

這個日志根本不需要使用分析工具定位錯誤代碼, 直接看錯誤信息:

Auto Layout still required after executing -layoutSubviews. MoneyInfo's implementation of -layoutSubviews needs to call super.

如果是你負責的這部分, 那么你看到了這個信息應該能馬上反應自己的約束加的是不是有問題, 畢竟自己寫的代碼加的約束肯定自己最清楚弱點.

如果不是你負責的這部分, 可以去看看MoneyInfo這個文件, 看看xib或者storyboard 約束是否有問題. 如果是代碼加的約束, 那就只能挨個捋了.

千萬不要像下面這位童鞋一樣, 加完約束, 有沖突但程序沒崩就不管了 . 這個習慣非常不好，一定要杜絕.

xib約束沖突.png

Xcode里也有詳細的崩潰日志:

Xcode里的crash log.png

基本上能定位是哪個文件的哪個方法的哪個操作引起崩潰, 但是不能準確定位到是哪一行代碼, 這里后面的+7990, +2168, +2090, +4012等這些數(shù)字我也不知道什么意思, 還希望知道的盆友告知下, 先謝謝啦~

作者：勇敢的呆喵

鏈接：http://www.itdecent.cn/p/4a201e4b7ed0

來源：簡書

著作權(quán)歸作者所有。商業(yè)轉(zhuǎn)載請聯(lián)系作者獲得授權(quán)，非商業(yè)轉(zhuǎn)載請注明出處。