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

解析 crash log （一）

前言

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

刚开始丢了个重现构建的新包给这几位用户将就的用着，但直到今天 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

0x104e40000 和 0x0000000104f90198 这两个地址是什么意思呢？我们再看这张图：

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

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

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

其它工具

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

• dwarfdump。这个工具用来应付普通的 crash 日志符号化完全是小题大做，但不排除某些极端下的情况。这个我没使用过，不做展开。
• lldb。lldb 在日常使用 Xcode 进行开发的过程中已经非常熟悉了，是 Xcode 的默认调试器。这部分我也没试过，大家可以自行搜索进行尝试。

总结

后续如果有时间会学习着开发一套适合自己业务流程的 crash 分析平台，依赖于内部的分析平台会受限很多，部分情况下不能满足需求，只能依靠自己动手去改造，如果你对自建 crash 分析平台感兴趣的话，可以参考这篇文章