写点什么

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

作者:声网Agora
  • 2022 年 3 月 10 日
  • 本文字数:2096 字

    阅读完需:约 7 分钟

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

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:



JIRA 中包含了当前的版本号、编译号、崩溃偏移地址、统计的崩溃次数、系统信息等。分析过程中还提取了崩溃堆栈中的关键信息,放在 JIRA 描述中,可以方便的让开发人员定位相关问题。通过这种有效的筛选分析,我们可以把一个版本上万个崩溃数据汇总进几十个 JIRA 里面, 大大提升了崩溃问题的处理效率。

04 崩溃数据统计

平台化地管理当前发生的崩溃问题,可以让开发/测试/项目管理者更方便地根据平台、版本号、JIRA 状态等信息来查找统计相关问题:



我们还可以根据 Hash 汇总,快速地查看到在哪些版本发生了相同的问题、发生的频率如何,在以后的开发过程中可以进行更好的规避:



同时还可以定时记录每日的崩溃数据,获取崩溃增量最高且未解决的 JIRA 进行每日崩溃 Top10 告警,提醒相关开发人员跟进最高优先级的问题:



通过我们的自动化实践,提升了问题解决的效率,减少了任务堆积和研发成本,在不断提升代码质量的同时加速了版本迭代的速度,客观上不断提升了用户体验,为公司业务的发展不断添砖加瓦。


Dev for Dev 专栏介绍


Dev for Dev(Developer for Developer)是声网 Agora 与 RTC 开发者社区共同发起的开发者互动创新实践活动。透过工程师视角的技术分享、交流碰撞、项目共建等多种形式,汇聚开发者的力量,挖掘和传递最具价值的技术内容和项目,全面释放技术的创造力。

用户头像

声网Agora

关注

还未添加个人签名 2021.02.05 加入

声网 Agora 是实时互动 API 平台行业开创者,实时互动技术服务覆盖全球 200 多个国家和地区。开发者只需简单调用 API,即可在应用内构建多种实时音视频互动场景。

评论

发布
暂无评论
声网崩溃数据的自动化闭环处理_自动化_声网Agora_InfoQ写作平台