01 崩溃信息的自动化处理是趋势
程序崩溃是由于发生某种严重错误而导致程序无法继续执行下去，从而异常退出的现象，它是质量保证过程中遇到最频繁的问题之一，通常这类问题需要我们非常重视对待。当用户在使用你的 APP 遇到频繁闪退或者崩溃时，会造成大量用户流失。
引起程序崩溃的原因有很多，通常是因为以下几点：
- 程序逻辑问题，发生了如数组越界、堆栈溢出、空指针异常等问题；
- 设备兼容性问题，因为设备和系统的多样性，特别是安卓系统，可能达到上千种，很难做到完全的设备兼容；
- 内存管理错误，程序内部存在内存泄漏问题，长时间的运行和无法释放对象的累积，导致了内存溢出，最终发生程序崩溃；或者是程序所需要的运行内存超过了设备限制等。
现实生产过程中，因为多种版本的迭代，可能会让我们面对海量的崩溃数据，需要对每一条数据逐个的去进行人工校验，筛选出重复问题，保留有效数据，并且提交 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：
JIRA 中包含了当前的版本号、编译号、崩溃偏移地址、统计的崩溃次数、系统信息等。分析过程中还提取了崩溃堆栈中的关键信息，放在 JIRA 描述中，可以方便的让开发人员定位相关问题。通过这种有效的筛选分析，我们可以把一个版本上万个崩溃数据汇总进几十个 JIRA 里面， 大大提升了崩溃问题的处理效率。
04 崩溃数据统计
平台化地管理当前发生的崩溃问题，可以让开发/测试/项目管理者更方便地根据平台、版本号、JIRA 状态等信息来查找统计相关问题：
我们还可以根据 Hash 汇总，快速地查看到在哪些版本发生了相同的问题、发生的频率如何，在以后的开发过程中可以进行更好的规避：
同时还可以定时记录每日的崩溃数据，获取崩溃增量最高且未解决的 JIRA 进行每日崩溃 Top10 告警，提醒相关开发人员跟进最高优先级的问题：
通过我们的自动化实践，提升了问题解决的效率，减少了任务堆积和研发成本，在不断提升代码质量的同时加速了版本迭代的速度，客观上不断提升了用户体验，为公司业务的发展不断添砖加瓦。
Dev for Dev 专栏介绍
Dev for Dev（Developer for Developer）是声网 Agora 与 RTC 开发者社区共同发起的开发者互动创新实践活动。透过工程师视角的技术分享、交流碰撞、项目共建等多种形式，汇聚开发者的力量，挖掘和传递最具价值的技术内容和项目，全面释放技术的创造力。