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

Posted 2021-05-16 小伟り

背景

有赞在基础保障平台的实践中完成了 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的稳定性。