前语
何谓符号化？简单来说就是把看不懂的十六机制地址转换为看得懂的函数名的这一进程，即为符号化。
当一个 app 产生 crash 时，操作体系会收集 app 产生溃散时的各种确诊信息。其间对我们开发者最重要的一部分就是 thread backtraces，它会包括一系列的十六进制地址。开发者将其符号化之后，再依据相关的信息去定位溃散的原因。
如何判断当前陈述是否符号化
当你定位问题时，一份完好的符号化陈述肯定是你最需求的，由于未符号化的陈述都是十六进制地址，对我们来说是没有什么价值的。
完好符号化陈述
一份完好的符号化陈述，backtrace 的每一帧都会包括函数名，而不是十六进制的内存地址。每一帧则代表某一个详细线程上单个函数调用。下面是一个完好符号化陈述的比如：
6 CrashDemo 0x104a69e0c -[ViewController touchesBegan:withEvent:] + 152
详细每一行代表什么含义可以拜见这篇文章。
部分符号化陈述
完好的符号化陈述，每一帧都会包括函数姓名。而部分符号化陈述则是某些帧会包括函数姓名，而有些帧则是包括十六进制地址。即便部分符号化陈述供给了定位问题的头绪，我们也应该将其完全符号化，来确保得到完好的头绪。下面是一个部分符号化陈述的比如：
5 CoreFoundation 0x19157c158 0x1022c0000 + 49064
6 CrashDemo 0x104a69e0c -[ViewController touchesBegan:withEvent:] + 152
未符号化陈述
未符号化陈述的每一帧都只包括十六进制地址，它对我们定位问题是没啥协助的。下面是一个完好符号化陈述的比如：
5 CoreFoundation 0x19157c158 0x1022c0000 + 49064
符号化的两种方法
用 Xcode 符号化
用 Xcode 符号化是官方引荐的一种方法，由于它会一起运用 Mac 上一切可用的 DSYM 文件来对陈述进行符号化。
Tips：溃散陈述必须是 .crash 的文件后缀。如果文件没有后缀或许是其他后缀，比如 txt。必须将后缀改为 crash 再进行符号化。
- 挑选 Xcode 的 Window – Devices and Simulators window
- 点击 Device Logs
- 将陈述拖到空白处即可
如果执行完上面的操作，Xcode 并没有成功的将陈述符号化，那你需求下面的过程了：
- 如果是体系库没有被符号化，则你需求去找跟溃散陈述中体系库版别匹配的设备。
- 如果是自己的 app、app extension 或许 framework 未被符号化，你需求找到相应的 DSYM 文件。
用指令行符号化
当你没有完好的陈述，只要某些未符号化的帧时，可以运用指令行东西来对每一帧进行符号化。
由 LLDB 供给的 atos 可以将十六进制的地址转为函数名和行号：
atos -arch <BinaryArchitecture> -o <PathToDSYMFile>/Contents/Resources/DWARF/<BinaryName> -l <LoadAddress> <AddressesToSymbolicate>
Tips:dSYM 文件是 macOS 包，其间包括带有调试符号的文件。当调用 atos 时，必须在包内供给此文件的途径，而不仅仅是外部 dSYM 包的途径。
下面是官网的示例图，标示了详细哪个参数对应哪个：
依据上图，atos 的指令如下：
atos -arch arm64 -o TouchCanvas.app.dSYM/Contents/Resources/DWARF/TouchCanvas -l 0x1022c0000 0x00000001022df754
输出如下：
ViewController.touchesEstimatedPropertiesUpdated(_:) (in TouchCanvas) + 304
总结
本文首要讲述了何为符号化、以及如何运用 Xcode 或 atos 进行陈述符号化。希望本文会对大家进行线上溃散问题定位时有协助。
