声网崩溃数据的自动化闭环处理
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 开发者社区共同发起的开发者互动创新实践活动。透过工程师视角的技术分享、交流碰撞、项目共建等多种形式,汇聚开发者的力量,挖掘和传递最具价值的技术内容和项目,全面释放技术的创造力。
- 音频技术的下一个“热点”,会出现在哪个领域?丨一期一会 • 音频工程师专场
- 桌面软件开发框架大赏
- 即时通讯场景下安全合规的实践和经验
- 大家谈的视频体验指标,都有哪些?如何测定?
- 从开源模型、框架到自研,声网 Web 端虚拟背景算法正式发布
- 声网的混沌工程实践
- 声网崩溃数据的自动化闭环处理
- 视频图像色彩增强的主要方法与落地实践
- 声网AI降噪测评系统初探
- Agora Flat:在线教室的开源初体验
- 三步开启你的网络服务全球动态加速之旅
- 如何基于 React Native 快速实现一个视频通话应用
- 小谈音视频质量检测
- Android 音视频 - MediaCodec 编解码音视频
- 【AI 全栈 SOTA 综述 】这些你都不知道,怎么敢说会 AI?【语音识别原理 实战】
- Android 音视频 - EGL 源码解析以及 C 实现
- Android 音视频采集那些事
- 别再傻傻分不清 AVSx H.26x MPEG-x 了
- 音视频编解码 -- 编码参数 CRF
- 【音视频专题】音频质量评估方法那些事