腾讯如何捕获和分析游戏崩溃

1. 背景简介

崩溃捕获和分析不是一个新话题，自从有软件开始，崩溃就是最严重的问题之一，崩溃率也是评估一个软件质量的重要指标。解决崩溃问题是一个刚需。从PC时代到移动时代，已经有不少崩溃捕获和分析的工具，那么腾讯游戏建设的一套新的崩溃分析系统，到底解决了哪些新问题和新挑战呢？

总结来说有三点：

1.对游戏引擎层垂直领域深度支持的需求

2.游戏多端出包的新趋势，在一个平台统一查看多端崩溃的需求

3.出海项目需符合海外数据合规需求

基于以上行业的新趋势和新需求，最终推动我们建设一个新的崩溃管理平台，当前已覆盖腾讯游戏海内外几乎所有的项目。虽然背景和游戏行业特有的需求相关，但本文的分享内容，是通用的思考框架，通用的问题解决方法，希望能与行业内的同学进行探讨。

2. 监控广度-如何捕获和分析FOOM？

对于监控广度，以下会先谈一下对于监控广度整体的思考，然后会挑选其中的FOOM问题监控的实践作为示例，具体分析一下，

崩溃监控，基本的要求：

1.崩溃情况，捕获的要全。典型场景：为什么用户反馈程序崩了，平台查不到？

2.崩溃时关键信息要上报的全。典型场景：有崩溃记录，但信息太少定位不了问题。

以上列出的所有点，平台几乎都有做优化和提升，比如重要的“堆栈信息”这一部分，除了提升了堆栈还原的稳定性之外，还支持内联函数的还原，函数参数的数值还原，帮助开发更精准的定位问题；比如对于“自定义数据”的支持，对自定义数据可以自动聚合分析，提高了问题定位和复现的效率。这里主要就FOOM（Foreground Out of Memory）监控实践进行下具体的分享。

对于FOOM的情况，因为没有系统直接的信号量通知，只能采用间接的方法来监控。行业通用的方案是以Facebook在2015年的一篇文章《Reducing FOOMs in the Facebook iOS app-Engineering at Meta》 为基础，文章提出了把正常的崩溃情况都排除，其他就是FOOM的，也就是“排除法”的方案。这个方案的一个问题就是，误报率比较高，排除一些简单的情况之后仍然有很多崩溃不是FOOM。国内的厂商多是在此基础上进行优化，进一步地排除掉其他情况，减少误报率，但排除法的思路没有改变。

但是在实践中会发现，简单的排除之后，剩余的崩溃还有不少类型，甚至比OOM更不好判断。比如CPU调度过于频繁，线程死锁，启动超时，过度的资源使用，运行时权限变更，程序的一些依赖消失……，林林总总，十数种被系统强杀的情况。与其排除，不如反过来，直接判断OOM，即内存使用量是否触达了系统的OOM阈值线，更加方便和准确。

本平台创新性地以大数据统计的方式，直接统计不同内存，机型，系统版本下的OOM阈值线。这样只要知道被强杀前最后时段的内存使用状态，就可以判断是否为OOM。

以iOS为例，其系统OOM的阈值线，和内存，机型，系统版本都相关，几个维度叉乘组合起来也是比较多的，比如：

“RAM：3G，机型：iPhoneX，系统版本：iOS12”，这组条件下OOM阈值为1800M

“RAM：3G，机型：iPhoneX，系统版本：iOS13”，更换来一个版本，OOM阈值变为1849M

“RAM：3G，机型：iPhone11，系统版本：iOS13”，再更换一个机型，OOM阈值变为2098M

使用大数据的方式，把一组参数下所有被强杀情况的机器，强杀前一时刻都内存使用量，展示成一条曲线，会发现内存使用最高值会有一个上限值，没有使用内存的值可以超过这条线，这个就是此参数下的系统OOM阈值，触碰到这个值的机器都被系统强杀了。

下图是“RAM：2G，机型：iPhone11，系统版本：iOS13"被系统强杀前一时刻的机器内存使用量示意图，此参数下系统OOM阈值为1449M。

3. 分析深度-如何自动识别问题？

对于上报来的数据，如何更好的分析利用起来？按其作用效果来分，可以划分为三个层次：

• 辅助定位

• 主动识别

• 问题解决

​​​​​​​

对于辅助定位，主要是基于统计分析，展示数据的规律。如基础性的统计：Top问题统计，新增问题提示，版本分布，操作分布，机型分布，上报趋势等。进阶性的统计：基于自定义数据的业务特征统计，特定场景统计，序列数据的最大公共序列推荐等。但这些都还是辅助，没有达到主动识别，并进一步推荐解决方案的程度。

本平台实践了“基于规则的问题自动化识别功能”，让开发人员的经验以规则的形式积累在平台上，然后以规则自动化识别问题，进一步完成自动提缺陷单（与缺陷管理系统打通），自动告警，推荐解决方案。完成了崩溃的捕获-上报-分析-解决的全链路。当前在公司内部的高星级项目上都得以应用，某头部项目，上报的崩溃80%+都可以被规则自动识别，大大减少了人工成本，提升了研发效率。

从产品层面来看，自动化识别的功能，能够被项目组使用起来，得益于它形成了一个正反馈的增强回路，使得整个功能得以不断增强，使用者持续受益。

具体运作流程如下所示：

首先，问题识别规则，分为“通用规则”和“自定义规则”，平台先总结通用规则，如安卓音频组件问题，苹果GPU问题等，让项目组使用起来就有帮助，也熟悉了自动识别的运作流程。

其次，项目组自行添加项目级问题的规则。

再次，项目级问题的规则中又可以提取出平台级通用的规则，比如内存分配问题等，又反哺通用问题规则的能力。

这样又增加了新项目使用此功能时的意愿，如此就形成了一个正反馈的增强回路，整个功能得以不断增强。

4. 研效提升-如何联动研发系统提升效率？

平台和工具目的，一方面提供解决问题的能力。另一方面，提升信息流转和管理的效率。

崩溃问题，如果能自动识别了，再发展一步，很自然的就需要自动提缺陷单，自动告警。就需要融合到整个内部的研发流程之中去。

当然，项目总会有自己一些独有的需求，如阶段性的数据分析，质量报告，自动化集成等，对于长尾的，非共同性的需求，平台采用API的形式灵活的进行满足。

5. 总结展望

展望未来，平台在产品专业性和效率提升方面会持续提升。同时坚持从实际需求出发，不断完善产品能力，不断打磨产品的易用性。欢迎点击阅读原文，免费尝鲜试用WeTest新能力。