图形化分析crash日志

崩溃的日志的获取是调试程序过程中一个重要的环节.每个程序都会有bug,但是你多久能拿到崩溃日志,多久能够通过这些日志分析出问题所在 ,并解决,怎么样规避一些比较低级的bug.这是我们经常碰到的问题.今天就来分享一下自己在调试过程的崩溃信息的追踪方式.

今天主要有一下几点:

1.crash 文件的采集的具体步骤.

2.crash文件中的内容的含义.

4.dysm 文件来源和作用

5.crash文件中崩溃的地址的手动解析的方法

什么是 dSYM 文件

Xcode编译项目后，我们会看到一个同名的 dSYM 文件，dSYM 是保存 16 进制函数地址映射信息的中转文件，我们调试的 symbols 都会包含在这个文件中，并且每次编译项目的时候都会生成一个新的 dSYM 文件，位于 /Users/<用户名>/Library/Developer/Xcode/Archives 目录下，对于每一个发布版本我们都很有必要保存对应的 Archives 文件 ( AUTOMATICALLY SAVE THE DSYM FILES 这篇文章介绍了通过脚本每次编译后都自动保存 dSYM 文件)。

dSYM 文件有什么作用

当我们软件 release 模式打包或上线后，不会像我们在 Xcode 中那样直观的看到用崩溃的错误，这个时候我们就需要分析 crash report 文件了，iOS 设备中会有日志文件保存我们每个应用出错的函数内存地址，通过 Xcode 的 Organizer 可以将 iOS 设备中的 DeviceLog 导出成 crash 文件，这个时候我们就可以通过出错的函数地址去查询 dSYM 文件中程序对应的函数名和文件名。大前提是我们需要有软件版本对应的 dSYM 文件，这也是为什么我们很有必要保存每个发布版本的 Archives 文件了。

一.xcode 还原法

每次打包app的时候我们都会勾上两个选项.其中第二个选项就是我们上传的日志文件.

然后我们就可以每周来看一下崩溃日志.xcode已经直接图形化崩溃日志并且有完整的调用栈. 这个可能需要将代码会退到和上传版本一样的地方 ,否则会出现定位错误.

二.友盟还原法.

这种方法适用于线上App的错误分析.

这个是我们现在正在使用的一种方法,就不细讲啦.

就是打包之后获取当前 ipa包的dysm文件,上传到友盟后台.

三.dsymTools的工具还原法.手动解析方式.

比如:我们遇到一个 -[__NSArrayM objectAtIndex:]: index 50 beyond ,或则是字典报错,有时候能够定位到这个错误,但是有时候定位不到,只是给出了内存地址.如果在项目中查找那么多的数组,显然不是很现实.类似的定位不到位置的很多.那么我们这时就可以使用手动解析的方法.通过第三方工具直接定位到我们工程中代码的位置.

还有一种就是:测试的设备上的崩溃比较难以复现的bug 就直接连接设备获取崩溃日志然后进行手动解析!

1.获取设备的crash 文件

连接崩溃设备获取crash 文件