面试题：Objective-C崩溃日志分析之符号化处理

Question

当获取到一份Objective-C应用的崩溃日志后，发现其中的地址信息未符号化，难以直接定位到具体的代码行。请阐述如何对崩溃日志进行符号化处理，包括需要哪些工具、符号表文件的来源以及具体的操作流程，同时说明符号化不准确可能存在的原因及解决办法。

Answer 1

符号化所需工具

1. Xcode：苹果官方的集成开发环境，包含符号化所需的工具。
2. atos：Xcode自带的命令行工具，用于将内存地址转换为符号化的函数名和行号。

符号表文件来源

1. dSYM文件：在构建应用时，Xcode会生成对应的dSYM（Debug Symbol）文件。每个可执行文件都有一个与之对应的dSYM文件，它包含了符号表信息，用于将内存地址映射到源代码中的函数和行号。这些dSYM文件通常位于Xcode的DerivedData目录下，也可以在Archive的Products中找到。
2. 符号表缓存：Xcode会在本地缓存符号表信息，以加快符号化的速度。这些缓存文件位于~/Library/Developer/Xcode/iOS DeviceSupport目录下。

具体操作流程

1. 获取dSYM文件：确保拥有与崩溃日志对应的应用版本的dSYM文件。如果是从App Store下载的应用，需要从苹果开发者后台下载对应的Archive文件，从中提取dSYM文件。
2. 配置Xcode：将dSYM文件添加到Xcode中。在Xcode的Organizer中，选择对应的Archive，点击“Show in Finder”，然后将dSYM文件拖入到Xcode的项目导航栏中。
3. 符号化崩溃日志：
   • 使用Xcode：在Xcode中，选择“Window” -> “Devices and Simulators”，在左侧选择对应的设备，然后在右侧的“Device Logs”中找到崩溃日志。双击打开崩溃日志，Xcode会自动进行符号化处理。
   • 使用atos命令：在终端中，使用atos命令进行符号化。命令格式如下：

atos -arch <architecture> -o <path to dSYM file>/Contents/Resources/DWARF/<executable name> -l <load address> <memory address>

<architecture>是设备的架构，如arm64；<path to dSYM file>是dSYM文件的路径；<executable name>是应用的可执行文件名；<load address>是崩溃日志中的加载地址；<memory address>是崩溃日志中的内存地址。

符号化不准确可能存在的原因及解决办法

1. dSYM文件不匹配：
   • 原因：使用了错误版本的dSYM文件，或者dSYM文件在生成后被修改。
   • 解决办法：确保使用的dSYM文件与崩溃日志对应的应用版本完全一致。可以通过对比应用的版本号、构建号以及dSYM文件的修改时间来确认。
2. 缺失符号表信息：
   • 原因：应用在构建时可能没有包含完整的符号表信息，例如启用了Strip Debug Symbols等优化选项。
   • 解决办法：在Xcode的项目设置中，确保“Strip Debug Symbols During Copy”选项设置为“No”，以保留完整的符号表信息。
3. 架构不匹配：
   • 原因：使用了错误的架构信息进行符号化，例如在arm64设备上使用了x86_64的dSYM文件。
   • 解决办法：确认设备的架构信息，并使用与之对应的dSYM文件和架构参数进行符号化。
4. 地址转换问题：
   • 原因：崩溃日志中的地址可能需要进行偏移计算，特别是在应用使用了动态库或进行了代码签名等情况下。
   • 解决办法：根据崩溃日志中的加载地址和其他相关信息，对内存地址进行正确的偏移计算，然后再进行符号化。