声网崩溃数据的自动化闭环处理

01 崩溃信息的自动化处理是趋势

程序崩溃是由于发生某种严重错误而导致程序无法继续执行下去，从而异常退出的现象，它是质量保证过程中遇到最频繁的问题之一，通常这类问题需要我们非常重视对待。当用户在使用你的 APP 遇到频繁闪退或者崩溃时，会造成大量用户流失。

引起程序崩溃的原因有很多，通常是因为以下几点：

1.程序逻辑问题，发生了如数组越界、堆栈溢出、空指针异常等问题；

2.设备兼容性问题，因为设备和系统的多样性，特别是安卓系统，可能达到上千种，很难做到完全的设备兼容；

3.内存管理错误，程序内部存在内存泄漏问题，长时间的运行和无法释放对象的累积，导致了内存溢出，最终发生程序崩溃；或者是程序所需要的运行内存超过了设备限制等。

现实生产过程中，因为多种版本的迭代，可能会让我们面对海量的崩溃数据，需要对每一条数据逐个的去进行人工校验，筛选出重复问题，保留有效数据，并且提交 BUG 进行跟踪。不仅费时费力，效率低下，还很有可能会引发严重问题的疏漏。所以建立一条便捷高效的自动化的闭环处理流程十分必要。

02 常见解决方案的不足

以往常见的解决方案是集成腾讯的 Bugly SDK，用来捕获 Android 或者 iOS APP 中的崩溃信息。Bugly 提供了一套完整的崩溃信息监控和解决方案。开发者将移动应用集成 Bugly，然后通过崩溃监控后台服务，可以方便的展示出用户在使用 APP 过程中出现的崩溃/ANR 等问题，并根据上报的崩溃信息快速定位和解决问题。但是这种方案并不能应用在桌面应用上(Windows/Mac 等)，而且 Bugly 目前也没有开放第三方接口，让我们获取崩溃数据列表以便于进行自动化分析处理。崩溃信息都要人工去进行处理过滤，最终达到的效果并不能让人满意。

03 跨平台的崩溃自动化闭环处理方案

为了解决上述问题，Agora 开发了一套跨平台(Android/iOS/Mac/Windows)的崩溃信息采集处理方案。当发生崩溃的时候，Agora 的 SDK 会将相关信息（版本号、平台、编译号、崩溃偏移地址、符号表地址、DMP 文件链接等）提交到我们的后台系统，后台通过绑定的堆栈信息和符号表进行符号化，提取出地址和符号的对应关系，进而还原成开发人员可以理解的崩溃堆栈信息。

符号化完成之后，系统会判断当前的 SDK 版本是不是已经提交了相同问题的 JIRA，如果没有提交，就新增 JIRA。在新增 JIRA 的过程中还可以根据崩溃的模块指派到对应的负责人，比如最终定位到是 audio 模块的崩溃，就指定到 audio 模块开发负责人，video 模块的崩溃，就指定到 video 模块的负责人，网络模块的崩溃，就指定到网络模块的负责人，优化了手动指派负责人的过程、大大提升了问题处理的效率。如果当前分析的结果是已经提交过 JIRA，则自动关联到相关的问题上并更新对应问题的崩溃次数。整个处理的流程如下图所示：

怎么区分一个版本相同的问题是否提交过呢？目前有两个维度，一个是通过编译号和崩溃偏移地址确认，如果多个崩溃数据的编译号和崩溃偏移地址是一致的，那么我们就将这几个崩溃数据归类为同一个问题，提交 JIRA 的时候会汇总同一个问题产生的次数。但是经过一段时间的实践，我们发现很多情况下同一个版本的编译号和崩溃偏移地址不一致，但有可能是由于同一个问题导致的。所以我们需要引入第二个维度，提取出堆栈详情进行分析。我们把能够解析出来的行的信息拼接起来，得到拼接字符串 Hash 值，然后根据 Hash 值是否相同去进行判断，同样的问题是否已经有过提交记录。通过两个维度的筛选，可以有效的去除重复问题的 JIRA 提交，并且可以更有效的进行崩溃数量的统计。其中我们可以制定一些不同的 Hash 生成方案来进行重复崩溃问题的过滤，可以通过最为宽松的方案，如通过最终崩溃的类名+方法名来生成 Hash；严格的方案如根据最终崩溃的文件名+模块名+类名+方法名+参数名来生成 Hash。下图是我们实践过程中，通过自动化解析崩溃数据提交的一个 JIRA：