iOS crash 日志堆栈解析

.crash文件

打开Xcode，选择Window -> Devices（如果是Xcode6以下，则是Window -> Organizer -> Devices），选择你自己的机器，然后点击View Device Logs，这时候会打开一个小窗口，这就是你机器上至目前为止存的所有app的崩溃信息了。如果是好久没看过这个信息，打开后还要读取好久才能完全读完，总之，找到你的app最后一次崩溃记录，右键导出。

.dSYM 文件

dSYM 是保存十六进制函数地址映射信息的中转文件，我们调试的 symbols 都会包含在这个文件中。每次编译项目的时候都会生成一个新的 dSYM 文件，我们应该保存每个正式发布版本的 dSYM 文件，以备我们更好的调试问题。一般是在我们 Archives 时保存对应的版本文件的，里面也有对应的 .dSYM 和 .app 文件。路径为：

~/Library/Developer/Xcode/Archives

.dSYM 文件默认在 debug 模式下是不生成的，我们去 Build Settings -> Debug Information Format 下，将 DWARF 修改为 DWARF with dSYM File，再重新编译下就能生成 .dSYM 文件了，直接去项目工程的 Products 目录下找就行。

symbols 是什么呢？

symbols 就是函数名或变量名。

找到 symbolicatecrash

symbolicatecrash是 Xcode 自带的 crash 日志分析工具，我们需要先找到它：

find /Applications/Xcode.app -name symbolicatecrash -type f

接着用真机打个包。打好包之后，不要用 Xcode build，直接用打好的包运行我们能导致 crash 的代码，这样就生成好 .crash 日志文件了。

之后，我们去 Xcode -> Window -> Devices and Simulators 或者快捷键 Command + Shift + 2

找到对应时间点的 .crash 文件，右击 Export Log。

拿到 .app 文件

.app文件可以使用真机编译下，去项目Products目录下获取，也可以去 Archives 目录下获取。

符号解析

利用 dSYM

将.dSYM、.crash及symbolicatecrash放到同一个文件下，执行命令：

./symbolicatecrash .crash文件路径 .dSYM文件路径 > 名字.crash

利用 app

将.app、.crash及symbolicatecrash放到同一个文件下，执行命令：

./symbolicatecrash .crash文件路径 .app/appName 路径 > 名字.crash

可能会报错误：

Error:"DEVELOPER_DIR"is not defined at ./symbolicatecrash line 69.

执行下命令就行：

exportDEVELOPER_DIR=/Applications/Xcode.app/Contents/Developer

然后再重新生成下新的 .crash 文件就行。

使用命令行工具 atos

ymbolicatecrash 可以帮助我们很好的分析 crash 日志，但是有它的局限性 --- 不够灵活。我们需要 symbolicatecrash、.crash 及 .dSYM 三个文件才能解析。

相对于 symbolicatecrash， atos 命令更加灵活，特别是你需要对不同渠道的 crash 文件，写一个自动化的分析脚本的时候，这个方法就极其有用。

但是这种方式也有个不方便的地方：一个线上的 App，用户使用的版本存在差异，而每个版本所对应的 .dSYM 都是不同的。必须确保 .crash 和 .dSYM 文件是匹配的，才能正确符号化，匹配的条件就是它们的 UUID 一致。在这之前，先介绍下 UUID：

什么是 UUID ?

UUID 是由一组 32 位数的十六进制数字所构成。每一个可执行程序都有一个 build UUID 唯一标识。.crash日志包含发生 crash 的这个应用的 build UUID 以及 crash 发生时，应用加载的所有库文件的 build UUID。

获取 UUID

.crash UUID

执行命令：

grep --after-context=2"Binary Images:"*crash

输出：

T.crash:Binary Images:T.crash-0x7c000 - 0x87fff DreamDemo armv7 /var/containers/Bundle/Application/DEEBE571-D512-4E8F-B712-ED4D19CE64F9/DreamDemo.app/DreamDemoT.crash-0xa9000 - 0xd4fff dyld armv7s /usr/lib/dyld

.dSYM UUID

执行命令：

dwarfdump --uuid xxxxx.app.dSYM

工具

直接操作atos命令毕竟是有点不方便，GitHub 上有个工具，可以辅助我们解析dSYMTools

系统库的符号化解析

用户/用户名称xxx/资源库/Developer/Xcode/iOS DeviceSupport

这些库的版本都是和 .crash 文件中是对应的

一旦我把这个 10.2 (14C5077b) 系统的符号化库删掉，.crash 文件就会变成这样：

可以明显的发现，系统库的堆栈变成了一堆地址。

新版本，每当我们手机连上 Xcode 时，都会把当前版本的系统符号库自动导入到 /用户/用户名称xxx/资源库/Developer/Xcode/iOS DeviceSupport 目录下。但是 iOS 版本那么多，之前旧的系统符号库该怎么获取呢？有人已经整理好了 iOS-System-Symbols，我们只需要根据 .crash 文件的版本信息，下载对应的系统符号化文件到目录下即可。

如何判断符号化是否完成

总结

利用 symbolicatecrash 解析，可以将整个.crash日志堆栈解析，但是由于依赖symbolicatecrash、.crash以及.dSYM三个文件，或者.app、.crash及symbolicatecrash三个文件，导致不太灵活。

利用atos命令只需要.crash和.dSYM，或者.crash和.app，知道对应的堆栈地址，就能解析，方便自动化脚本分析，但是 crash 堆栈可能需要自己实现收集。

注意

1、系统库是否包含相应符号解析库以及armv7s arm64e(如果是拿到设备导出crash文件怎么不存在这个问题，因为xcode会自动复制相关符号解析库)