iOS开发笔记之六十二——如何构建大型App的Crash符号化系统

一、背景

最近梳理了公司的Crash管理流程，感觉这个过程可以作为一款较大业务量App的参考流程，调研了其他，基本都是大同小异。

二、Crash文件的产生与符号化

1、符号表

符号化的3种方法，不多说，前两种不是本文讨论的，直接略过，说第三种。

每一个可执行程序都有一个build UUID来唯一标识（这个UUID不同于用户设备的那个唯一UUID，这个是标示应用的），在Xcode项目编译后，在编译生成的二进制文件.app的同级目录下生成的同名的.dSYM文件（符号表文件）。.dSYM文件其实是一个目录，在子目录中包含了一个16进制的保存函数地址映射信息的中转文件，所有Debug的symbols都在这个文件中(包括文件名、函数名、行号等)，所以也称之为调试符号信息文件。

2、3个文件的一致性

这3个文件是：符号表（.dSYM文件）、应用二进制文件（.app文件）、崩溃日志（.crash文件）， 通过比较三者的uuid是一致的，只有在这三者一致的情况下，才能正确的把函数地址符号化出来。集齐这三个文件，我们再借助atos工具（实际是一个可以把地址转换为函数名（包括行号）的工具）就可以得到符号化后的crash信息了。

三、自动化系统的搭建

.dsym符号化文件是xcode编译阶段的产物，在打包编译时就要保留好。因为我们用户安装的ipa包里是没有这个文件的。所以需要每次打包完成都要save一份。如果要做到整个过程自动化，当然需要部署到机器上，创建一个符号化的服务，这个服务的大致过程如下：

1、.dsym与.app文件的上传

前面说了，符号化前提是集齐三个文件，其中.crash是用户提供，那么.dsym与.app就是发布者提供了。记住xcode打包不一定会自动创建符号化文件如果你xcode设置错误的话（Build Settings -> Build Options -> Debug Information Format 设置为DWARF with dSYM File），xcode打包完成时，启动对应的上传模块，将.dsym和.app压缩之后上传到远端服务。

2、用户.crash文件的获取

苹果的app每次crash都会产生一个.crash文件，不可能奢望用户给你提供设备去获取.crash文件，所以App首先需要拥有获取.crash文件并上传的能力，如果上传成功，推荐及时清理掉.crash文件（为了App的瘦身，也真是够拼了）。

3、符号化与Crash分类

经过上面2步之后，就集齐了Crash符号化的3个必需文件，获取到具体的代码文件信息后，可以根据代码的归属类，进行进一步的分类，找到对应代码的责任人，通过邮件或者其他方式通知责任人。

4、有没有其他的方案

从上面的过程中，需要你去启服务管理这个过程，如果你没有服务支持人员，仅靠客户端人员，也是有妥协方案的。例如，你可以将

.dsym文件打包一起进入ipa安装包（或者采取懒加载方式download，这个文件大小也是客观的），在App客户端集齐这三个文件，然后进行符号化（蛋疼的性能问题）。当然，这种也只适合小型App用。

四、参考文献：

1、https://developer.apple.com/library/content/documentation/IDEs/Conceptual/AppDistributionGuide/ConfiguringYourApp/ConfiguringYourApp.html

2、http://www.cocoachina.com/industry/20140514/8418.html

3、http://blog.csdn.net/longzs/article/details/51272980