簡單記錄下我是如何根據(jù)友盟崩潰列表上的崩潰日志定位到具體哪行代碼導(dǎo)致崩潰的 .
首先, 我用的是下圖這個分析工具, 十分感謝作者的無私奉獻 , 附上下載地址, 喜歡的童鞋動動小手指Star下吧
https://github.com/answer-huang/dSYMTools
打開工具后將對應(yīng)版本的archive文件拖進來, 把圖中對應(yīng)信息按照崩潰日志里的詳細信息填寫
(注意一定要是對應(yīng)版本的archive文件, 否則定位信息不準(zhǔn)! 所以保留之前打包信息還是很有必要且重要的!)
大括號里面顯示調(diào)用堆棧信息, 程序調(diào)用順序是下往上調(diào)用的, 如上圖中箭頭所示, 最上面那個地址也就是最后一次調(diào)用的方法, 正式它導(dǎo)致了崩潰, 所以在分析工具中錯誤信息內(nèi)存地址就填這個就行了,CPU Type 和slide address 對應(yīng)填即可 , 之后點擊分析, 如下圖所示
有可能錯誤的地方 顯示了是哪個文件的哪個方法的哪一行出錯, 這個不用解釋了, 直接去對應(yīng)版本的代碼里找到錯誤的地方 :
定位到這行代碼導(dǎo)致了崩潰, 檢查下定位是否準(zhǔn)確. 我們看看友盟上的錯誤信息
-[__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拦键， 當(dāng)crash發(fā)生時由它來捕捉。如果您不需要使用錯誤統(tǒng)計檩淋，可以通過[MobClick setCrashReportEnabled:NO];關(guān)閉芬为。
需要注意的是, 關(guān)閉錯誤統(tǒng)計之后就不會再收到用戶的崩潰日志, 所以要慎重, 在確定公司不需要統(tǒng)計用戶崩潰信息時再關(guān)閉.
錯誤日志可以看出很多東西, 要學(xué)會善用錯誤日志 , 比如下面這個日志:
這個日志根本不需要使用分析工具定位錯誤代碼, 直接看錯誤信息:
Auto Layout still required after executing -layoutSubviews. MoneyInfo's implementation of -layoutSubviews needs to call super.
如果是你負(fù)責(zé)的這部分, 那么你看到了這個信息應(yīng)該能馬上反應(yīng)自己的約束加的是不是有問題, 畢竟自己寫的代碼加的約束肯定自己最清楚弱點.
如果不是你負(fù)責(zé)的這部分, 可以去看看MoneyInfo這個文件, 看看xib或者storyboard 約束是否有問題. 如果是代碼加的約束, 那就只能挨個捋了.
千萬不要像下面這位童鞋一樣, 加完約束, 有沖突但程序沒崩就不管了 . 這個習(xí)慣非常不好，一定要杜絕.
Xcode里也有詳細的崩潰日志:
基本上能定位是哪個文件的哪個方法的哪個操作引起崩潰, 但是不能準(zhǔn)確定位到是哪一行代碼, 這里后面的+7990, +2168, +2090, +4012等這些數(shù)字我也不知道什么意思, 還希望知道的盆友告知下, 先謝謝啦~
