iOS 【使用 dSYM 符号集对线上 App 进行崩溃修复】

前言

之前发过一篇博客是捕捉崩溃日志的，然后上传到公司服务器，大家可以参照：

Xcode 【发布状态下如何捕获崩溃日志上传到服务器】

这个方式可以让我们自己去管理我们的错误日志，而非去集成一些第三方 SDK 来操作，让代码更加的简单。但或许我们获取的崩溃日志是“一手资料”，崩溃日志需要一点点的解读，有些甚至看都看不懂，如下：

NSInvalidArgumentExceptionreason:-[NSURLError objectForKeyedSubscript:]: unrecognized selector sent to instance 0x174a57010callStackSymbols:0   CoreFoundation                      0x0000000183e52ff8 <redacted> + 1481   libobjc.A.dylib                     0x00000001828b4538 objc_exception_throw + 562   CoreFoundation                      0x0000000183e59ef4 <redacted> + 03   CoreFoundation                      0x0000000183e56f54 <redacted> + 9164   CoreFoundation                      0x0000000183d52d4c _CF_forwarding_prep_0 + 925   BPB                                 0x00000001000df2e4 BPB + 1604846   BPB                                 0x00000001000d2424 BPB + 1075567   BPB                                 0x00000001001adbb4 BPB + 10065168   BPB                                 0x00000001001c0574 BPB + 10827409   libdispatch.dylib                   0x0000000182d0a9e0 <redacted> + 2410  libdispatch.dylib                   0x0000000182d0a9a0 <redacted> + 1611  libdispatch.dylib                   0x0000000182d0f3c0 _dispatch_main_queue_callback_4CF + 44412  CoreFoundation                      0x0000000183e010c8 <redacted> + 1213  CoreFoundation                      0x0000000183dfece4 <redacted> + 157214  CoreFoundation                      0x0000000183d2eda4 CFRunLoopRunSpecific + 42415  GraphicsServices                    0x0000000185798074 GSEventRunModal + 10016  UIKit                               0x0000000189fe9058 UIApplicationMain + 20817  BPB                                 0x0000000100121aac BPB + 43281218  libdyld.dylib                       0x0000000182d3d59c <redacted> + 4

这个错误可以从字面上大致推测，我们将一个 Error 类型的变量当做 NSDictionary 来使用，显然这是我们不允许的。但是推测有了，我们却无法准确定位到底错误出现在哪里。

dSYM 符号集

• 符号集是我们对 ipa 文件进行打包之后，和 .app 文件同级的后缀名为 .dSYM 的文件，这个文件必须使用 Xcode 进行打包才有。
• 每一个 .dSYM 文件都有一个 UUID，和 .app 文件中的 UUID 对应，代表着是一个应用。而 .dSYM 文件中每一条崩溃信息也有一个单独的 UUID，用来和程序的 UUID 进行校对。
• 我们如果不使用 .dSYM 文件获取到的崩溃信息都是不准确的。
• 符号集中存储着文件名、方法名、行号的信息，是和可执行文件的16进制函数地址对应的，通过分析崩溃的 .Crash 文件可以准确知道具体的崩溃信息。

如何获取 .dSYM 文件夹

解析崩溃日志

实际上，我们完全不需要去拿到这个 .dSYM 文件，我们可以借助一个工具 DSYMTools 来帮我们操作：

DSYMTools 会帮助我们自动匹配我们打包过的 .xcarchive 文件，然后我们选择崩溃的机型对应的 arm64 或者 armv7。（真机 32 位处理器需要 armv7，或者 armv7s 架构，真机 64 位处理器需要 arm64 架构。）

接下来我们要将未解析成功的崩溃信息内存地址粘贴到第三行，何为未解析成功的崩溃信息呢？如下：

5   BPB                                 0x00000001000df2e4 BPB + 1604846   BPB                                 0x00000001000d2424 BPB + 1075567   BPB                                 0x00000001001adbb4 BPB + 10065168   BPB                                 0x00000001001c0574 BPB + 1082740

我们发现这四句崩溃信息只有 内存地址 和 UUID。类似的崩溃信息就是我们需要的。

如上图我们发现了可能发生错误的地方，经查证，此处在设置字体的地方误将 “PingFang SC” 写成了 “PangFang SC”，确实很逗的错误，但是只有个别的 iPhone 机型出现了崩溃现象，而且还不是每次都出现。这种 bug 的确很头疼。

当然，我们也可以使用 Xcode 自带的 symbolicatecrash 工具来将 .Crash 和 .dSYM 文件进行符号化，就可以得到详细崩溃的信息。