iOS Crash收集与分析详解（基础篇）

Posted 2023-04-25

参考技术A

最近测试妹子老是抱怨我偶现的Bug不好复现，我这边出于偷懒（其实是工作很忙）一直再说不能复现Bug的妹子不是好测试，最近闲下来了，正好谈谈Crash的收集和分析。

噔噔噔噔~万能的官方文档又出现了，先上地址
Understanding and Analyzing Application Crash Reports

如果你把你的手机连接到Mac，并选择Xcode->Windows->Device and Simulator，然后点击View Device Logs，你会看到手机上会有好多Log，其中Type为Crash的就是崩溃的Log,如下图：

1）打开设置->隐私->分析->分析数据，在其中找到你想要的应用程序的日志，日志将使用以下格式命名：<应用名称> _ <崩溃时间> _ <设备名>
2）选择所需的日志，复制文本或点击右上角的分享按钮分享出去，并且把分享得到的.ips.synced或者复制文本而来的.txt文件的后缀名改为.crash，因为Xcode不接受没有.crash扩展名的崩溃日志。

What the fuck??面对一大串的16进制数字你可能会感到一脸懵逼，莫惊慌，如果你仔细的看了看官方文档，你就会发现收集Crash的Log是一件很轻松的事情，然而分析Crash却并不是那么容易的事情（看完这篇文章后你会发现也很容易！！！！）
我们能把16进制数字转换成能看懂的东西么？当然可以，这个时候就需要理解dSYM符号集，细心的小伙伴在看第一张Crash流程图中可能已经发现.xcarchive文件中包含了.dSYM文件。

看到这里你可能已经知道，通过dSYM中存储的信息可以把crash日志中的16进制数字一一对应成我们看得懂的文件名、函数名和行号，这个过程就叫做符号化，那么如何做呢？

获取.crash的UUID

获取.dSYM的UUID

获取.app的的UUID

比如上图能看到三者的UUID都是一致的，可以安心去符号化文件啦。

1）如果本地存在.crash对应的.dSYM文件，则直接到上文中（1、使用Xcode从设备获取崩溃日志：）到 View Device Logs 这步，把文件拖入右边的logs列表，Xcode会自动去符号化文件，如果满眼都是16进制数字的化，点击 Re-Symbolicate Log 即可

如果你不想用Xcode去符号化，你也可以通过 symbolicatecrash 来手动符号化crash日志， symbolicatecrash 是Xcode下的一个工具。
1）首先先找到这个工具，我们通过Spotlight搜索找到 symbolicatecrash 并复制到桌面的CrashSignifying文件夹中，在这个文件夹下同样放入.crash、.dSYM文件。
2）打开终端，进入你刚才创建的CrashSignifying文件夹中，输入命令行

然后在输入

如果报No such file or directory : at ./symbolicatecrash line 909.错误，尝试执行

以上图为例，大部分字段都是不言而喻的，下面列举一些有用处的。（在官方文档都有解释，这里做归纳与翻译）

接着是最重要的堆栈信息，由下到上为最后调用的顺序：

文章写了一半开始忙了起来，第三第四节的内容现在才补上来（已经三天过去啦），如果能给小伙伴带来一点帮助，那我就很开心了，咱们下周再见。

最佳实践有赞crash平台符号化实践

背景

有赞在基础保障平台的实践中完成了 Crash平台 的建设，但是iOS的崩溃日志未经符号化，排查问题比较困难。为了降低iOS App的crash率，快速排查线上crash，疑难crash的跟踪处理，符号化崩溃日志显得尤为重要！

1. crash日志的收集与分析

1.1 如何收集crash日志

1. 手机上直接看，在隐私-分析与改进 -分析数据，可以找到所有崩溃日志，未符号化。
2. 连接电脑，通过“音乐”同步到本地 ~/Library/Logs/CrashReporter/MobileDevice/xxx的 iPhone. 缺点：日志没有符号化，需要自己手动符号化
3. 连接电脑，打开Xcode-window-Diveces and Simulators。Xcode会尝试在本地查找符号表文件，自动符号化。

以上3种方法都局限于拿得到设备的情况。

     4. 查看别人手机上的crash日志 Xcode-Window-Organizer。

这种方式找符号表会有2种途径

• 上传AppStore的时候会让你勾选上传符号表「Include App symbols for your Application…」，如果上传了，苹果自动帮你在云端做解析。
• 如果没有上传，Xcode尝试在本地找符号表文件进行符号化。

缺点：这种方式也只能收集在手机设置中打开了上传crash开关，以及TestFlight用户的crash日志。企业分发或 AdHoc 安装，需要自行获取崩溃日志。信息不全，线程信息不够。

   5. 自己收集crash日志，比如接入KSCrash、plcrashreporter等，但是要自己做符号化。

1.2 crash日志的结构

日志可以分成4个部分，基本信息，崩溃的原因，所有线程调用，Binary Images （二进制文件列表）。

1.2.1 基本信息

1.2.2 崩溃原因

1.2.3 线程

2. 如何进行crash日志符号化

crash日志符号化通常是通过 atos 和 symbolicatecrash 这两个工具来完成。

2.1 atos

atos 是苹果提供的符号化工具，在Mac OS系统下默认安装，他的缺点是只能一个地址一个地址逐个翻译。我们看下这个工具的使用说明：

使用方法：

atos -arch <Binary Architecture> -o <Path to dSYM file>/Contents/Resources/DWARF/<binary image name> -l <load address> <address to symbolicate>

需要传入这几个信息：arch 架构、dSYM路径、binary image 载入内存的初始地址、崩溃的地址。

参数内容可以从crash日志中取得，如下图所示：

example：

$ atos -arch arm64 -o TheElements.App.dSYM/Contents/Resources/DWARF/TheElements -l 0x1000e4000 0x00000001000effdc
  -[AtomicElementViewController myTransitionDidStop:finished:context:]

3. 有赞符号化方案

通过上面的原理分析，我们基本掌握了 crash 符号化的步骤，下面介绍下我们有赞是如何做符号化的。

3.1 dSYM符号表保存

首先，进行符号化必不可少的一个文件就是 dSYM 符号表，我们需要保存每次正式发布的App版本对应的符号表文件。如下图所示：

1. 打包机（gitlab runner）：有赞目前有自己的持续构建平台 MBD，业务方在 MBD 上发起打包构建任务后系统会根据算法分配到不同的打包机上。更多关于有赞移动 CI/CD 我们在之前做过一次技术沙龙，详细内容见这里｜PPT资料
2. 项目打包完成后会执行一个保存符号表的脚本，会保存符号表到本地，并且上传到云端做备份。备份完成后调用MBD接口，上报符号表uuid，bundleId，版本号，build号，打包机唯一标识。
3. 由于有多台打包机导致每次打包产出的符号表分布在不同的打包机上，我们需要建立dSYM文件与打包机的关系。第一步中的保存符号表脚本会上报信息到MBD，MBD把dSYM符号表uuid和打包机唯一标识做一个映射关系。
4. 当发生一个crash时，crash日志中包含符号表uuid，通过uuid查表，就能定位到执行构建的打包机。

3.2 crash上报

dSYM符号表已经保存下来了，接下来就是crash的上报和解析，crash上报大致流程见下图：

1. crash信息通过SDK上报到埋点平台，我们通过Flink监听到crash信息的上报，并把它写入数据库。
2. Flink是实时计算平台提供的用来实时消费上报的数据的程序，支持大并发量的数据。

更多关于crash平台的建设我们近期也发表过一篇文章，详情见 这里。

3.3 crash文件符号化

步骤二中已经上报了crash信息并展示在了我们的内部平台中，接下来我们需要对此crash文件结合对应的dSYM进行符号化解析，具体流程如下：

1. 在 Crash前端页面，点击符号化按钮会发起 MBD 的一次符号化构建，并将 crash 的信息传递给 MBD。
2. MBD把crash的uuid拿出来，根据uuid去查 dSYM文件所在的 打包机，并把任务给到这个打包机。
3. 打包机运行脚本，这个脚本的作用是使用symbolicatecrash程序符号化crash日志，并把符号化后的结果通知到MBD。
4. MBD 把符号化结果写入数据库，并通知Crash后端。
5. Crash前端页面收到通知后刷新页面，展示符号化后的结果。

至此，我们完成了crash文件的符号化解析工作，但是使用过程中暴露出了一些问题：

1. 目前每次打包都会产生dSYM文件并直接保存在打包机上，MBD每天的打包任务有很多，导致占用空间浪费资源。我们计划只维护符号表的cdn链接，用到时再去下载符号表。
2. 这种方案下线一台打包机后，会造成一部分crash日志无法符号化，目前我们正在优化，计划统一把符号表放到一台打包机上，这样就能解决这个问题。
3. 系统符号表的维护也是一个问题，我们需要在每台打包机上都要加上系统符号表，而且每次苹果发布新版都需要拿新的系统符号表过来，维护起来挺麻烦的。目前的解决方案是人工放到打包机上。

4. 总结

至此，我们了解了如何收集crash日志，明白了crash日志中每个部分的意思，符号化的工具，以及如何对crash日志进行符号化。已经可以解答出来上面提出的问题，对符号化的原理有了非常清晰的认识。

我们的符号化方案对于有赞多台打包机环境而言，非常合适，下线一台或者新增一台打包机，可以无缝支持。另外，整套方案非常轻量，能够快速集成符号化功能，符号化链路清晰。

Crash平台拥有符号化crash日志的能力后，极大的提高了大家排查、解决线上问题的效率，提升了App的稳定性。