日志结构

1. Process Information

这部分给出了进程crash后的部分信息

Incident Identifier: crash报告的唯一标识

CrashReporter Key: crash报告映射到Device Identifier的唯一键值（key）。表面上看上去没有任何含义，但实际上给我们提供了一个有用信息，假如我们所获得的大量crash log拥有同样的Crashreport Key，一定程度上说明这个crash问题并不是普遍存在，也许只是对一些特定的设备存在。

Hardware Model: 当前设备类型。假如我们所获得的大量crash log拥有同样的Hardware Model，很大程度上可以说明app在该类设备上运行存在适配的问题。

Process: app的名字。

2. Basic Information

这部分给出了crash的一些基本信息：crash发生的时间，当前设备上操作系统的版本等。如果多数crash log拥有相同的iOS版本号，一定程度上说明app对于该版本iOS系统存在适配问题。

3. Exception

这部分给出了crash的异常类型，异常错误码和抛出异常的线程。

4. Threads backtraces

这部分给出了crash时app所有线程的堆栈记录，列出crash时函数调用堆栈。包含四列：编号，调用的库或工程的名称，函数指针（被调用的方法的地址），文件地址+行编号。

5. Thread state

这部分给出了crash时寄存器中的值。事实上，堆栈记录已经提供了类似的信息。

6. Binary images

这部分列出了crahs时加载的所有文件。

日志分析

获取一份crash崩溃日志，我们需要把十六进制地址等原始信息映射为源代码级别的方法名称和代码行数，使其对开发人员可读。这个过程称为符号化解析。要成功地符号化(Symbolication)解析一份crash日志，我们需要有对应的应用程序二进制文件以及符号（.dSYM）文件。

符号化的过程中我们需要三个文件： .app .crash .dSYM 三者缺一不可，同时需要依赖Xcode的符号化工具——symbolicatecrash。

什么是 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 文件了。