IOS崩溃文件符号化实践

1.背景与项目难点

1.1 背景

由于公司之前使用的友盟要收费，filebase服务由谷歌提供，存在数据合规风险。需要实现稳定性分析功能，通过支持app崩溃信息实时采集、实时上报、实时自动解析并定位出代码问题，帮助研发同学及时定位崩溃原因并修复；同时对崩溃信息进行统计和可视化展示，通过数据辅助研发和PM同学进行产品功能迭代决策。

1.2 难点

ios端崩溃文件未经符号化且端上无法直接将符号化后的文件上传发送到服务端, 因此需要设计一套自动流程采集打包产生的dsym，实时采集ios上报后的崩溃文件，文件符号化后存储崩溃数据，对崩溃信息进行统计和可视化展示，在稳定性分析模块以供数据研发定位代码问题和PM进行产品功能迭代。

2. crash日志的分析与收集

2.1 如何获取dsym文件

dysm生成：dsym文件在触发打包过程中生成，生成后的文件存储在打包机上，因此第一步是将打包机上的dsym文件发送到崩溃解析服务器上。

2.1.1 初始方案

采用ftp文件传输，编写python脚本，在打包过程生成dsym文件后，发送到崩溃解析服务器。

产生问题：

由于公司使用的ios打包机安装在一台mac电脑上，mac电脑所在的集群网络和崩溃解析服务器所在的集群网络不通，且无法将mac电脑加入到崩溃解析服务器所在的集群，通过ftp方式上传文件无法满足此需求。因此需要引入中间文件存储工具，使用http的方式将文件上传到崩溃解析服务器上。

2.1.2 file browser引入

file browser：https://github.com/filebrowser/filebrowser
file browser可以创建属于自己的云的软件，可以在其中将其安装在服务器上，将其定向到一个路径，然后通过一个 Web 界面访问您的文件。filebrowser 提供指定目录下的文件管理界面，可用于上传、删除、预览、重命名和编辑文件。它允许创建多个用户，每个用户可以有自己的目录。它可以用作独立的应用程序。

基于filebrowser的以上功能，在崩溃解析服务器上安装filebrowser，用于保存dsym文件和crash文件。

2.1.3 最终方案

将filebrowser安装在崩溃解析服务器上，通过http请求filebrowser提供的上传文件接口，将打包上增加python脚本，生成的dsym文件后，调用filebrowser上传文件接口发送到崩溃解析服务器。

2.2 崩溃解析流程

2.2.1获取dsym文件流程

打包机将文件上传到崩溃解析服务器的具体流程为：
1.打包触发python脚本，通过脚本将dsym文件发送到崩溃解析服务器内的filebrowser
2.启动watch dog监听文件变更，监听到创建新的dsym文件，解析出dsym的uuid，并将文件发送到dsym存储表，以供展示平台可视化展示。

2.2.2 crash文件上报过程

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

2.2.3 分析crash文件方法

crash日志结构

基本信息

崩溃原因

线程

Binary Images

分析crash日志的方法symbolicatecrash

需要文件
1.有crash崩溃文件
2.有app.dsym文件
需要软件
Xcode
执行命令
/Applications/Xcode.app/Contents/SharedFrameworks/DVTFoundation.framework/Versions/A/Resources/symbolicatecrash yourCrashLog.crash yourAppName.app.dSYM > outputFileName.txt

2.2.4 符号化过程

1.客户端通过sdk上报crash文件到埋点服务器
2.埋点服务器将未符号化的crash文件存放到filebrowser中
3.运行在崩溃解析服务器上的watchdog监听到有新的crash文件创建，则去匹配和crash文件版本一致&uuid一致的dsym文件，执行symbolicatecrash解析命令
4.将符号化以后的文件存储在filebrowser并且发送到flink任务
5.flink任务将crash数据存入埋点数据库
6.可视化平台对崩溃数据查询

至此，符号化解析过程完毕，该方案在开发和测试过程中还暴露出一些问题

1. 崩溃解析服务器的macos环境是由虚拟机搭建，开发过程中会出现由于macos系统版本的问题，导致crash文件解析失败，后续更换macos版本问题解决，但不确定该问题是否会随着xcode版本升级或者ios系统版本升级等变化再次出现。
2. crash文件解析还需维护系统符号表，由于崩溃解析服务器存储空间限制，目前仅维护用户使用量较高的几个版本，并且目前系统符号表只能由人工上传维护。

3.总结

至此，我们完成了从crash文件上传、符号化解析到最终可视化界面平台展示的全流程的设计。
有了此功能，能够极大的提高了研发排查、解决线上问题的效率，提升了App的稳定性，也能够帮助PM进行产品功能迭代。

参考
简述分析crash日志的方法之symbolicatecrash
iOS 用symbolicatecrash符号化崩溃日志中系统库方法堆栈