簡單記錄下我是如何根據(jù)友盟崩潰列表上的崩潰日志定位到具體哪行代碼導(dǎo)致崩潰的 .
首先, 我用的是下圖這個(gè)分析工具, 十分感謝作者的無私奉獻(xiàn) , 附上下載地址, 喜歡的童鞋動動小手指Star下吧
https://github.com/answer-huang/dSYMTools
打開工具后將對應(yīng)版本的archive文件拖進(jìn)來, 把圖中對應(yīng)信息按照崩潰日志里的詳細(xì)信息填寫
(注意一定要是對應(yīng)版本的archive文件, 否則定位信息不準(zhǔn)! 所以保留之前打包信息還是很有必要且重要的!)
大括號里面顯示調(diào)用堆棧信息, 程序調(diào)用順序是下往上調(diào)用的, 如上圖中箭頭所示, 最上面那個(gè)地址也就是最后一次調(diào)用的方法, 正式它導(dǎo)致了崩潰, 所以在分析工具中錯(cuò)誤信息內(nèi)存地址就填這個(gè)就行了,CPU Type 和slide address 對應(yīng)填即可 , 之后點(diǎn)擊分析, 如下圖所示
有可能錯(cuò)誤的地方 顯示了是哪個(gè)文件的哪個(gè)方法的哪一行出錯(cuò), 這個(gè)不用解釋了, 直接去對應(yīng)版本的代碼里找到錯(cuò)誤的地方 :
定位到這行代碼導(dǎo)致了崩潰, 檢查下定位是否準(zhǔn)確. 我們看看友盟上的錯(cuò)誤信息
-[__NSArrayM objectAtIndex:]: index 9 beyond bounds [0 .. 2]
數(shù)組越界, 在崩潰不好重現(xiàn)的情況下, 我們可以很清晰的推測這行代碼確實(shí)存在問題, passStr 的值可能大于數(shù)組的數(shù)量, 這時(shí)我們需要做一個(gè)安全判斷,防止崩潰. 更好的方法是給數(shù)組的字典擴(kuò)展一個(gè)方法, 取值時(shí)允許任何范圍, 但是越界就返回空 :
- (id)objectOrNilAtIndex:(NSUInteger)index {
return index
}
使用分類給數(shù)組增加以上方法, 字典同理, 調(diào)用此方法替換系統(tǒng)方法, 代碼更安全 .
有些錯(cuò)誤日志定位的到錯(cuò)誤信息是UmengSignalHandler時(shí), 可以不用管
友盟的官方解釋是:
UmengSignalHandler 不是錯(cuò)誤，是捕捉crash的方法短蜕，本身不引起crash峭范， 當(dāng)crash發(fā)生時(shí)由它來捕捉。如果您不需要使用錯(cuò)誤統(tǒng)計(jì)饰序，可以通過
[MobClick setCrashReportEnabled:NO]; 關(guān)閉浴滴。
需要注意的是, 關(guān)閉錯(cuò)誤統(tǒng)計(jì)之后就不會再收到用戶的崩潰日志, 所以要慎重, 在確定公司不需要統(tǒng)計(jì)用戶崩潰信息時(shí)再關(guān)閉.
錯(cuò)誤日志可以看出很多東西, 要學(xué)會善用錯(cuò)誤日志 , 比如下面這個(gè)日志:
這個(gè)日志根本不需要使用分析工具定位錯(cuò)誤代碼, 直接看錯(cuò)誤信息:
Auto Layout still required after executing -layoutSubviews. MoneyInfo's implementation of -layoutSubviews needs to call super.
如果是你負(fù)責(zé)的這部分, 那么你看到了這個(gè)信息應(yīng)該能馬上反應(yīng)自己的約束加的是不是有問題, 畢竟自己寫的代碼加的約束肯定自己最清楚弱點(diǎn).
如果不是你負(fù)責(zé)的這部分, 可以去看看MoneyInfo這個(gè)文件, 看看xib或者storyboard 約束是否有問題. 如果是代碼加的約束, 那就只能挨個(gè)捋了.
千萬不要像下面這位童鞋一樣, 加完約束, 有沖突但程序沒崩就不管了 . 這個(gè)習(xí)慣非常不好彻磁，一定要杜絕.
Xcode里也有詳細(xì)的崩潰日志:
基本上能定位是哪個(gè)文件的哪個(gè)方法的哪個(gè)操作引起崩潰, 但是不能準(zhǔn)確定位到是哪一行代碼, 這里后面的+7990, +2168, +2090, +4012等這些數(shù)字我也不知道什么意思, 還希望知道的盆友告知下, 先謝謝啦~
