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