解析 crash log（一）

原文地址：PJ 的 iOS 开发之路

前言

在负责的产品中有最近一段时间有极个别用户总是反馈有偶尔闪退的状况，并且就这几个用户反复出现，其它用户，甚至就坐在他边上的用户进行了同样的操做都没有任何问题。

刚开始丢了个重现构建的新包给这几位用户将就的用着，但直到今天 PM 受不了了，让我不管如何都要想办法解决这个问题，但我也一脸懵逼啊，按照用户的操做路径来看我也没能复现，甚至分析平台都抓不到对应信息，更况且这仍是个企业级应用，没上到 AppStore，也就无法从 iTunes Connect 中拿到崩溃日志。

因此开始酝酿了一个事情......

分析问题

为了快速定位到问题所在，PM 和 leader 再三的跟用户进行交流，你们都没有一个比较好的方案，最后我厚着脸皮让用户照着下面这张图从设备中导出了一份崩溃日志发送给我：

从真机中拿到这份 ips 文件后就好办了不少，若是此时直接打开这个文件，能够看到以下图所示内容：

可以拿到真机的状况下，

• 在不删掉 app 的状况下直接调试；
• 没法复现问题，则把真机插入电脑，打开 Xcode -> Window -> Devices and Simulators -> View Device Logs，直接找到须要的 log；

在拿不到真机的状况下，先来直接讲解一个可以解决问题的流程：

第一步：ips 文件

“死皮赖脸”的让用户经过图 1 所示方法导出一份最新的 .ips 文件，并让用户分享给本身，并把文件名修改成 .crash 后缀，使其标识为 crash 类型；

第二步：.dSYM 文件

.dSYM 文件（debugging SYMBols，调试符号表）。从打包机（若是是经过打包机隔离构建的话）或本机上导出一份与用户设备中安装的 app 版本一致的 .dSYM 文件，该文件中详细的记录了 16 进制下的函数地址的映射信息。

须要注意的是，Xcode 的默认设置是会在 release 和 debug 环境下已经配置好了 archive 时自动带出 .dSYM 文件，若是你发现打开包内容时并无发现 .dSYM 文件，能够到 Xcode 的 Build Settings 中查看 Debug Infomation Format 字段的配置进行修改。

.dSYM 文件对于后续排查问题十分重要，每一次 release 版本都最好要保存对应的 dSYM 文件或把整个 Archives 文件进行保存；

第三步：symbolicatecrash 工具

symbolicatecrash 工具。该工具跟随 Xcode，是获取符号化结果的最方便工具。symbolicatecrash 的地址视 Xcode 的安装路径而定，大体的地址为：

你的Xcode安装路径/Xcode.app/Contents/SharedFrameworks/DVTFoundation.framework/Versions/A/Resources/symbolicatecrash
复制代码

第四步：获取崩溃代码信息

有了 .ips 文件、.dSYM 文件和 symbolicatecrash 工具后就能够直接进行解析日志了～由于我把这三个文件都统一放在了一个文件夹中，因此实际上命令看起来会是这样：

./symbolicatecrash ./yourApp.crash ./yourApp.dSYM > crash.log

若是在输入这条命令时告知找不到 DEVELOPER_DIR，能够导出一份：

export DEVELOPER_DIR="你的Xcode安装位置/Xcode.app/Contents/Developer"
复制代码

对输出的结果重定向到了当前路径下的 crash.log 中，此时打开该文件，看到的内容是这样的：

很崩溃啊！重要的细节一个都没有展现出来！随后我换了一个思路，咱们从新回到第三步

回到第三步：atos 命令

关于 atos 命令的描述，可使用 man atos 查看具体信息：

...
DESCRIPTION
     The atos command converts numeric addresses to their symbolic equiva-
     lents.  If full debug symbol information is available, for example in a
     .app.dSYM sitting beside a .app, then the output of atos will include
     file name and source line number information.
...
复制代码

这是一个专用于 macOS 的控制台工具，从描述中能够看出，能够将地址转换为实际二进制图像的符号化字符串（实际代码）。上文中说到的 symbolicatecrash 工具是 apple 基于 atos 方便开发者进行的优化封装，但不知为什么个人 symbolicatecrash 并不能完整的符号化全部 crash log 中的内容。因此如今将直接使用 atos 进行符号化，操做稍微繁琐一些，咱们能够把对应的命令修改成：

atos -o yourApp.dSYM/Contents/Resources/DWARF/yourApp -arch arm64 -l 0x104e40000 0x0000000104f90198

arm64 为 Xcode 中设置的支持的 CPU 架构，按需修改。0x104e40000 和 0x0000000104f90198 这两个地址是什么意思呢？咱们再看这张图：

0x104e40000 为 local address，0x0000000104f90198 为 address，这两个地址在不借助其它工具的前提下能够直接手算出来，若是你对手算地址感兴趣的话，能够看这篇文章。

经过执行上述 atos 命令，能够看到输出了正确的信息，以下图所示：

接下来就能够把多个地址进行解析，配合着在堆栈中的这几个关键信息基本上就能够定位到具体的 crash 代码文件和行数。

其它工具

关于符号化奔溃报告，还有如下几种：

• dwarfdump。这个工具用来应付普通的 crash 日志符号化彻底是小题大作，但不排除某些极端下的状况。这个我没使用过，不作展开。
• lldb。lldb 在平常使用 Xcode 进行开发的过程当中已经很是熟悉了，是 Xcode 的默认调试器。这部分我也没试过，你们能够自行搜索进行尝试。

总结

后续若是有时间会学习着开发一套适合本身业务流程的 crash 分析平台，依赖于内部的分析平台会受限不少，部分状况下不能知足需求，只能依靠本身动手去改造，若是你对自建 crash 分析平台感兴趣的话，能够参考这篇文章