CN113190401A - 快游戏的异常监控方法、电子设备、移动终端以及存储介质 - Google Patents

Abstract

本申请公开了一种快游戏的异常监控方法、电子设备、移动终端以及存储介质，该异常监控方法包括：收集快游戏产生的错误；其中，收集的错误类型可自定义；获取与错误相关联的日志信息；将关联的错误和日志信息上报给服务器。通过上述方式，本申请能够及时收集快游戏产生的错误并通过日志信息准确找到错误来源，从而帮助开发者追踪快游戏的异常并进行针对性的修复，进而提升快游戏运行性能和改善用户体验。

Description

快游戏的异常监控方法、电子设备、移动终端以及存储介质

技术领域

本申请涉及快游戏领域，特别是涉及一种快游戏的异常监控方法、电子设备、移动终端以及存储介质。

背景技术

通常，随着人们对游戏的便捷性以及快速性需求，在打开浏览器并且闲暇时间短暂时，用户往往希望能够快速进入到打游戏的页面，从而使得快游戏的用户体验尤为重要。

一般，将快游戏平台与网页浏览器进行绑定来运行快游戏，从而避免用户的安装，为快速进入快游戏界面提供可能，这极大地降低了开发者的开发成本以及接入成本。

目前，每一款游戏都会在运行中产生异常，而现有的快游戏的异常错误往往通过用户发送异常错误信息给开发者来进行反馈，比如发送文字或截图进行反馈，这导致开发者无法有效且快速追踪到用户反馈的错误，从而使得错误多样化，开发者每次修复错误类型比较单一，进而降低快游戏运行性能并影响用户体验。

发明内容

本申请实施例的第一方面提供了一种快游戏的异常监控方法，该异常监控方法包括：收集快游戏产生的错误；其中，收集的错误类型可自定义；获取与错误相关联的日志信息；将关联的错误和日志信息上报给服务器。

本申请实施例的第二方面提供了一种电子设备，包括：收集模块，用于收集快游戏产生的错误；其中，收集的错误类型可自定义；获取模块，用于获取与错误相关联的日志信息；上报模块，用于将关联的错误和日志信息上报给服务器。

本申请实施例的第三方面提供了一种移动终端，包括：处理器和存储器，存储器中存储有计算机程序，处理器用于执行计算机程序以实现本申请实施例第一方面提供的异常监控方法。

本申请实施例的第四方面提供了一种计算机可读存储介质，该计算机可读存储介质存储有计算机程序，计算机程序能够被处理器执行时实现本申请实施例第一方面提供的异常监控方法。

本申请的有益效果是：区别于现有技术的情况，本申请针对目前快游戏的异常监控方法，通过自定义错误类型以及获取与错误相关联的日志信息，能够及时收集快游戏产生的错误并通过日志信息准确找到错误来源，如此帮助开发者有效地追踪快游戏产生的异常，并获取到日志信息中的多种错误类型，从而使得开发者对多种错误类型进行针对性的修复，进而提升快游戏运行性能和改善用户体验。

附图说明

为了更清楚地说明本申请实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本申请快游戏的异常监控方法第一实施例的流程示意图；

图2是本申请图1中步骤S11的一具体流程示意图；

图3是本申请图2中步骤S23的一具体流程示意图；

图4是本申请图1中步骤S12之前的一具体实施例的流程示意图；

图5是本申请图4中步骤S42的一具体流程示意图；

图6是本申请快游戏的异常监控方法一具体实施例的流程示意图；

图7是本申请的电子设备一实施例的示意框图；

图8是本申请的移动终端一实施例的示意框图；

图9是本申请的计算机可读存储介质一实施例的示意框图；

图10是本申请电子设备的硬件架构的示意框图。

具体实施方式

以下描述中，为了说明而不是为了限定，提出了诸如特定系统结构、技术之类的具体细节，以便透彻理解本申请实施例。然而，本领域的技术人员应当清楚，在没有这些具体细节的其它实施例中也可以实现本申请。在其它情况中，省略对众所周知的系统、装置、电路以及方法的详细说明，以免不必要的细节妨碍本申请的描述。

应当理解，当在本说明书和所附权利要求书中使用时，术语“包括”指示所描述特征、整体、步骤、操作、元素和/或组件的存在，但并不排除一个或多个其它特征、整体、步骤、操作、元素、组件和/或其集合的存在或添加。

还应当理解，在此本申请说明书中所使用的术语仅仅是出于描述特定实施例的目的而并不意在限制本申请。如在本申请说明书和所附权利要求书中所使用的那样，除非上下文清楚地指明其它情况，否则单数形式的“一”、“一个”及“该”意在包括复数形式。

还应当进一步理解，在本申请说明书和所附权利要求书中使用的术语“和/或”是指相关联列出的项中的一个或多个的任何组合以及所有可能组合，并且包括这些组合。

如在本说明书和所附权利要求书中所使用的那样，术语“如果”可以依据上下文被解释为“当...时”或“一旦”或“响应于确定”或“响应于检测到”。类似地，短语“如果确定”或“如果检测到[所描述条件或事件]”可以依据上下文被解释为意指“一旦确定”或“响应于确定”或“一旦检测到[所描述条件或事件]”或“响应于检测到[所描述条件或事件]”。

为了说明本申请的技术方案，下面通过具体实施例来进行说明。随着快游戏用户量的日益增长，快游戏的用户体验越来越重要。本申请提供一种快游戏的异常监控方法。请参阅图1，图1是本申请本申请快游戏的异常监控方法第一实施例的流程示意图，该异常监控方法具体包括以下步骤：

S11：收集快游戏产生的错误；其中，收集的错误类型可自定义；

通常，快游戏具有免下载安装，性能优越，节省空间等特点，通过一键发布功能和相关技术接口，帮助开发者快速将H5游戏打包成快游戏，极大降低开发者的开发成本和接入成本。

其中H5游戏又称Web游戏，无端网游，简称页游，是基于Web浏览器的网络在线多人互动游戏，无需下载客户端，不存在机器配置不够的问题，最重要的是关闭或者切换极其方便。

在快游戏运行的过程中，会产生异常或错误，通常错误类型是固定的，但本申请收集的错误类型可以自定义，如此能及时获取到自定义的错误，进而使得开发者有效地追踪到快游戏产生的错误。

S12：获取与错误相关联的日志信息；

一般来讲，在客户端预设有日志记录，用于记录快游戏运行时得到的状态信息并保存在客户端的内存中，在满足上报条件时对其进行上报，有助于帮助开发者排查和解决错误。

通常设置有预设时间段，在快游戏运行时，在预设时间段内可以调用日志对快游戏的运行进行实时记录，比如：最近日志写后五分钟内没有错误发生，那么这些日志就丢弃掉。为避免内存被日志占用太多，五分钟清理一次内存，只保留五分钟内发生的30条日志。

当错误发生时，将错误标记(id)和日志关联一起，比如可以通过绑定的方式进行关联，然后将错误与该错误相关联的日志信息写入持久缓存，从而使得开发者能及时通过错误id获取与错误相关联的日志信息，进而获取相关联的错误。

S13：将关联的错误和日志信息上报给服务器。

通常，服务器以及客户端设置有错误上报条件，用于判定错误是否满足上报条件，若满足，则将关联的错误和日志信息上报给服务器，若不满足，则执行继续收集快游戏产生的错误的步骤。

具体地，上报条件可以是错误次数，比如设定错误只有达到五次的时候才允许上报，也可以是收集错误的时间，还可以是错误的优先级别，比如若部分错误优先级低，不需要重复的上报，而满足错误优先级别的错误才进行上报，本领域相关技术人员对此可以根据需要去进行选择，具体此处不做限定。

本申请针对目前快游戏的异常监控方法，通过自定义错误类型以及获取与错误相关联的日志信息，能够及时收集快游戏产生的错误并通过日志信息准确找到错误来源，如此帮助开发者有效地追踪快游戏产生的异常，并获取到日志信息中的多种错误类型，从而使得开发者对多种错误类型进行针对性的修复，进而提升快游戏运行性能和改善用户体验。

更进一步地，收集快游戏产生的错误，请参阅图2，图2是本申请图1中步骤S11的一具体流程示意图，具体包括以下步骤：

S21：开始收集错误；

通常来说，一旦快游戏运行，则可以开始进行错误收集，也可以根据游戏本身的属性预设一段时间，对在预设时间段之后的时间内开始收集错误，比如该预设时间段可以是快游戏的脚本加载连接到客户端之间所需要的时间。

在脚本加载的时候，先对快游戏本身的错误钩子和错误对象进行重载，比如onError错误钩子和console对象进行重写，具体地，插入软件开发工具包(SoftwareDevelopment Kit，SDK)对错误类型进行自定义。收集到错误时会先进行SDK的上报，完成后才进行用户覆盖之前的错误处理行为，因此不影响业务原先定义的逻辑。

其中，SDK是指软件开发工具包，一般都是一些被软件工程师用于为特定的软件包、软件框架、硬件平台、操作系统等建立应用软件的开发工具的集合。

S22：利用快游戏自带的错误钩子收集快游戏产生的错误；

快游戏自带的错误钩子可以为qg.onError错误钩子，用于收集快游戏产生的错误；其中，qg.onError错误钩子对应有原有的错误对象，原有的错误对象有对应原有的错误类型，用于对快游戏产生的错误进行分类，从而使得开发者在上报的错误里快速找到对应错误的错误类型。

另外，快游戏自带的错误钩子可以为错误脚本，用于收集快游戏产生的错误，当然，本领域相关技术人员对快游戏自带的错误钩子还可以根据需要去进行选择，以收集快游戏产生的错误，具体此处不做限定。

S23：利用自定义的软件开发工具包收集快游戏产生的错误。

错误收集主要有两种途径，一种通过onError收集，比如上述步骤S22中的qg.onError错误钩子，另一种则是通过SDK对外提供的自定义上报错误方法进行手动收集错误，比如通过SDK对外提供的reportError方法手动上报错误来对错误进行收集。

具体地，通过利用自定义的软件开发工具包可以对错误对象进行重写，具体地可以对对应的错误类型进行新增，如此，可以收集快游戏产生的自定义错误。

其中，重写是通过重载的方式采用SDK对onError进行二次包装，对console的错误类型进行增添，在不改变原来onError对错误信息的收集的情况下，增加自定义错误收集类型和方式。

更进一步地，利用自定义的软件开发工具包收集快游戏产生的错误，请参阅图3，图3是本申请图2中步骤S23的一具体流程示意图，具体包括以下步骤：

S31：获取自定义的软件开发工具包，软件开发工具包根据错误进行自定义更新；

通常，开发者通过对错误类型的自定义，可以及时获取需要关注的错误类型。快游戏本身的错误对象对应的错误类型比如有：错误(errors)、警告(warnings)等。

而通过开发者使用软件开发工具包对错误类型进行自定义，也即软件开发包可以根据错误进行自定义更新，可以得到更符合客户端的错误类型，比如信息(info)、日志(logs)、补丁(debug)和/或累赘(verbose)等。

通过获取自定义的软件开发工具包，则可以对错误对象对应的错误类型进行新增更新，其中，自定义的软件开发工具包在快游戏运行时并不影响原有错误对象对应的错误类型对错误的收集。

S32：调用自定义的软件开发工具包对错误钩子进行重载，以新增错误类型；

因为错误钩子包括错误对象，错误对象对应错误类型的分类。所以通过调用自定义的软件开发工具包对错误钩子进行重载，可以新增错误类型。

具体地，本申请因为错误钩子至少包括onError错误钩子，而onError错误钩子包括console错误对象，console错误对象对应具体的错误类型。所以通过调用自定义的软件开发工具包对onError错误钩子进行重载，可以新增具体的错误类型。

结合步骤S31，比如在原有的错误(errors)、警告(warnings)等错误类型前提条件下，将自定义的信息(info)、日志(logs)、补丁(debug)和/或累赘(verbose)等自定义错误类型重载到原有的错误类型上，以实现新增错误类型。

S33：利用自定义的软件开发工具包对快游戏产生的满足新增的错误类型的错误进行收集。

因为自定义错误类型重载到原有的错误类型上，只是通过新增的方式对错误类型进行更新，所以在对错误进行收集时，并不影响快游戏本身原有的错误类型对错误的收集。

也就是说，快游戏本身对错误的收集有两种具体的收集方式，一种是通过快游戏本身原有的错误类型对错误进行分类收集，而另一种是通过新增的错误类型对错误进行分类收集。

因此，可以利用自定义的软件开发工具包对快游戏产生的满足新增的错误类型的错误进行收集，具体地，一方面可以通过将自定义的错误类型绑定在原有的错误类型的框架上，同时对错误进行收集，另一方面，还可以通过将自定义的错误类型在原有错误类型的框架上分离开来，先通过原有的错误类型对错误进行收集，然后再利用自定义的错误类型对错误进行收集。当然，本领域技术人员完全可以想到还可以根据其他方式对满足新增的错误类型的错误进行收集，此处不做限定。

更进一步地，在获取与错误相关联的日志信息之前，请参阅图4，图4是图1是本申请图1中步骤S12之前的一具体实施例的流程示意图；该异常监控方法还具体包括以下步骤：

S41：记录快游戏产生的日志；

通常来说，一旦快游戏运行，则可以用日志开始记录快游戏的运行状态，也可以根据游戏本身的属性预设一段时间，对在预设时间段之后的时间内开始记录快游戏的运行状态，比如从快游戏运行时调用错误对象后开始记录快游戏的运行状态。

因为日志记录可以从快游戏开始一直持续到快游戏结束时，如此，通过记录快游戏的运行状态，可以得到相应的日志，也即日志信息。具体地，在日志写的时候，会先保存到客户端的内存中。比如最近一次日志写后五分钟内没有错误发生，可将这些日志丢弃掉。

为避免内存被日志占用太多，五分钟清理一次内存，只保留五分钟内发生的30条日志，当然也可以设置其他的预设时间段比如10分钟来对内存进行清理，以及可以设置预设时间内保留预定数量比如20条的日志信息，具体此处不做限定。

S42：在错误满足关联条件时，建立错误与日志信息相关联；

通常因为日志信息比较多，而错误又比较少，两者之间的呈现出比较极端的情况，所以为了使得开发者能够在众多的日志信息里及时找到错误，需要建立错误与日志信息之间相关联。

因此，设定一定的关联条件是必要的，用于判断错误是否满足相关联的执行条件，也即是说，对于满足关联条件的错误，则建立错误与日志信息相关联，若不满足关联条件的错误，则将日志信息丢弃。

具体地，可以设定预设周期，比如5分钟、10分钟、20分钟、30分钟以及1小时等，在预设周期内，若检测有错误存在，则确定满足关联条件，比如当错误发生时，将错误id和日志信息关联；或可以设定预设次数，比如10条、20条、30条以及50条等，通过产生错误的次数满足预设次数，则确定满足关联条件，以此建立错误与日志信息相关联。

S43：储存错误的标记与错误相关联的日志信息。

通常是通过绑定的方式，建立错误与日志信息相关联，在此建立关联的过程中，因为错误内容较多，所以绑定就比较占内存，如此会影响快游戏的运行，甚至在占用内存过多的情况下，出现快游戏卡顿，从而影响客户端的体验。

具体地，建立错误与日志信息相关联，实际上是可以通过将错误标记和日志信息进行关联，从而建立错误与日志信息相关联，也就是说，可以通过错误标记找到对应的错误，以此错误标记为找到错误的指引。

因为收集到的错误由两部分，一部分是由快游戏本身原有的错误类型收集而来的，另一部分是有自定义的错误类型收集而来的，所以可以通过先将错误内容放入堆栈中进行存储，经过堆栈对两部分的错误进行格式化处理，再统一进行包装，从而可以将两部分收集的错误内容进行统一包装，产生错误对应的错误标记(id)，从而便于建立错误与日志信息相关联。

如此，通过绑定建立了错误与日志信息相关联的效果，再把错误的标记与错误相关联的日志信息进行储存，因此，通过错误标记来对错误进行标记，既可以达到建立错误与日志信息相关联的效果，也可以达到储存错误的标记与错误相关联的日志信息的效果，从而避免因错误内容占用内存过多而出现游戏卡顿的现象。

更进一步地，将关联的错误和日志信息上报给服务器，请参阅图5，图5是本申请图4中步骤S42的一具体流程示意图，具体包括以下步骤：

S51：对错误进行去重，得到错误类型不同的去重错误；

因为快游戏运行产生的错误内容信息非常多，因此，可能会得到重复的错误信息内容，若对同样的错误消息进行上报，不仅达不到对错误类型的精准查询效果，还可能造成上报资源的浪费。

所以需要对错误进行去重，从而排除掉相同的错误内容信息，进而得到错误类型不同的去重错误，以精简错误信息内容。

其中，在对错误进行去重之前，还可以设定上报条件，用于判断错误是否需要进行上报，若需要进行上报，则再对错误进行去重、对去重错误进行抽样的操作，若不需要进行上报，则可以摒弃这些错误信息内容，为新的错误腾出空间进行存储。

S52：对去重错误进行抽样；

去重错误的错误信息内容虽然不同，但是往往由于快游戏中产生的错误类型的重要程度并没有进行规定，所以对上报的错误信息内容不能完全进行优先级的挑选。并且部分业务的页面浏览量(page view，PV)或点击量可能非常大，这种情况下，不需要对每个错误进行收集上报。一来完全上报，服务端的压力非常大。二来上报对客户端也是流量的浪费。故需要对错误进行抽样，抽样完成后便进入最终的上报处理流程。

为了排除一些上报优先级更低的错误信息内容或/和抓取其中一些错误信息内容，具体地，可以采用抽样的方式对去重错误进行处理，比如采用随机抽样对去重错误进行抽样。

通常，预设有抽样条件，用于对去去重错误进行判定，比如在错误类型中随机选取预设数量个权重排名靠前的错误类型对去重错误进行抽样选取，其中权重排名靠前的错误类型可以通过统计每个错误类型在快游戏运行时出现的次数多少进行计算，出现的次数按照从高到低进行排列，以此作为随机抽样进行抽养的筛选样本。

S53：将满足抽样条件的关联错误、关联错误对应的日志信息以及环境信息进行整合，以上报给服务器。

日志记录至少包括错误序号、客户段id，错误类型，错误信息，错误路径，环境标记，出错时间以及日志标志中的一种。环境信息至少包括客户端的系统版本(比如1081)、品牌(比如：OPPO)、型号(比如PBEM00)、制造商(OPPO)、模型(OPPO R11s)、产品类型(R11s)、内存操作系统(android)、操作系统版本名称(8.1.0)、操作系统版本代码(27)、厂商名称(ColorOS)、供应商OS版本(V5.2.1)、平台版本名称(1.0.8.1)、平台版本代码(1081)、语言类型(zh)、地区(CN)、屏幕密度(3)、屏幕宽度(1080)、屏幕长度(2160)、状态栏高度(0)、窗口宽度(1080)、窗口高度(2016)、设备类型(phone)中的一种，其中这些括号中的具体数字或符号是对应环境信息的一种具体举例。值得注意的是，针对不同的客户端或机型，实际上产生的错误是相类似的，所以这里的环境信息具备一定的全面性。

由于上报的错误涉及到开发者后期的修复效率，为了更为全面的找到出错的信息内容，尽可能将日志记录以及环境进行囊括，然后由于环境信息因素众多，通常可以通过筛选一些关键信息与关联错误和关联错误对应的日志信息进行整合。

如此，将满足抽样条件的关联错误、关联错误对应的日志信息以及环境信息进行整合，整合之后得到整合的错误信息可以上报给服务器，其整合后的错误信息可以如下表表一所示：

表一 整合后的错误信息

更进一步地，将关联的错误和日志信息上报给服务器之后，该异常监控方法具体还包括：

S54：清除储存的错误的标记与错误相关联的日志信息。

为避免内存占用太多，在整合后的错误信息向服务器进行上报后可以对错误的标记与错误相关联的日志信息进行清除。

具体地，在整合后的错误信息上报之后的预定时间内，对相应的内存进行清理，考虑到整合后的错误信息的大小，可以通过标准的流量速率来预计出上报所需要的时间，比如设置预定时间为5分钟，10分钟、20分钟等，具体出出不做限定。

因此，本申请针对目前快游戏的异常监控方法，通过自定义错误类型以及获取与错误相关联的日志信息，能够及时收集快游戏产生的错误并通过日志信息准确找到错误来源，如此帮助开发者有效地追踪快游戏产生的异常，并获取到日志信息中的多种错误类型，从而使得开发者对多种错误类型进行针对性的修复，进而提升快游戏运行性能和改善用户体验。

下面进一步，结合下文将结合具体的应用场景对本申请快游戏的异常监控方法进行详细描述。鉴于目前快游戏平台还没有异常监控，第一，快游戏生产环境上无法有效且快速追踪排查用户反馈的问题，不利于业务的稳定、推广和口碑的建立，甚至对业务的安全运营有潜在的威胁。第二，在用户终端上运行期间众多错误不能被开发者感知收集以改善用户体验。面对大量用户反馈和投诉，开发者往往比较头疼，往往投入众多人力和时间，却事倍功半。第三因为没有必要的辅助信息，排查问题上类似于盲人摸象。修复版本上线后更不能追踪跟进了多少用户的访问体验，没有确切的数据指标支撑。所以目前快游戏产生的错误监控目前处于一种比较粗糙的状态，本申请先进性地提出一种快游戏平台统一错误收集上报方案。请参阅图6，图6是本申请快游戏的异常监控方法一具体实施例的流程示意图，具体包括以下步骤：

S601：开始；

本申请的该具体实施例主要分成三部分：1.错误收集；2.错误上报；3.日志上报，在快游戏运行时，可以先确定好同时运行的基本部分。

值得注意的是：开始后的实线和虚线的流程是同步进行的。该步骤具体可如图2中的步骤S21相类似，此处不再赘述。

S602：重写错误钩子；

在脚本加载的时候，先对快游戏本身的onError错误钩子和console对象进行重写，插入SDK的自定义的收集和上报行为。收集到错误时会先进行SDK的上报，完成后才进行用户覆盖之前的错误处理行为，不影响业务原先定义的逻辑。

其中，onerror事件会在文档或图像加载过程中发生错误时被触发。比如在装载文档或图像的过程中如果发生了错误，就会调用该事件句柄。

S603：重写错误对象；

由于错误收集主要有两种途径，一种通过onError收集，另一种则是通过SDK对外提供的reportError方法手动上报错误。错误钩子对应有错误对象，所以重写错误钩子实际上是重写错误对象，也即重写onError错误钩子实际上是重写console错误对象。

S604：原错误钩子收集错误；

因为利用通过重载的方式采用SDK对onError进行二次包装，对console的错误类型进行增添，在不改变原来onError对错误信息的收集的情况下，增加自定义错误收集类型和方式。所以可以利用原错误钩子收集错误，也即通过onError收集错误。

S605：自定义错误钩子收集错误；

通过SDK自定义方式对错误钩子、错误对象以及错误类型进行新增，所以可以通过自定义错误钩子收集错误。

S606：堆栈格式化、统一包装错误；

因为收集到的错误由两部分，一部分是由快游戏本身原有的错误类型收集而来的，另一部分是有自定义的错误类型收集而来的，所以可以通过先将错误内容放入堆栈中进行存储，经过堆栈对两部分的错误进行格式化处理，再统一进行包装，从而可以将两部分收集的错误内容进行统一包装，产生错误对应的错误标记(id)，从而便于之后建立错误与日志信息相关联。

收集到错误后需要进行错误堆栈的格式化和上报格式的包装。因为部分的堆栈信息是没有必要上报的，堆栈格式化节省了网络带宽，同时方便在数据库存储。

S607：发送错误标记；

向记录快游戏运行状态的日志发送错误标记，可以使得日志能及时记录到需要上报的错误标记。

S608：对错误去重；

因为快游戏运行产生的错误内容信息非常多，因此，可能会得到重复的错误信息内容，若对同样的错误消息进行上报，不仅达不到对错误类型的精准查询效果，还可能造成上报资源的浪费。

所以需要对错误进行去重，从而排除掉相同的错误内容信息，进而得到错误类型不同的去重错误，以精简错误信息内容。

其中，在对错误进行去重之前，还可以设定上报条件，用于判断错误是否需要进行上报，若需要进行上报，则再对错误进行去重、对去重错误进行抽样的操作，若不需要进行上报，则可以摒弃这些错误信息内容，为新的错误腾出空间进行存储。

S609：对错误抽样；

部分业务的页面浏览量(page view，PV)或点击量可能非常大，这种情况下，不需要对每个错误进行收集上报。一来完全上报，服务端的压力非常大。二来上报对客户端也是流量的浪费。故需要对错误进行抽样，抽样完成后便进入最终的上报处理流程。

S701：调用错误对象；

在步骤S601中快游戏开始的同时，就可以调用错误对象，对游戏的运行状态进行全面的跟踪。

S702：写入内存日志；

将快游戏的运行状态记录入内存日志中，也即可以采用写入的方式来更新内存日志。

S703：日志拣取；

在日志写的时候，会先保存到内存中。最近日志写后五分钟内没有错误发生，那么这些日志就丢弃掉。为避免内存被日志占用太多，五分钟清理一次内存，只保留五分钟内发生的30条日志。

S704：绑定错误标记和日志信息；

通常是通过绑定的方式，建立错误与日志信息相关联，在此建立关联的过程中，因为错误内容较多，所以绑定就比较占内存，如此会影响快游戏的运行，甚至在占用内存过多的情况下，出现快游戏卡顿，从而影响客户端的体验。

具体地，建立错误与日志信息相关联，实际上是可以通过将错误标记和日志信息进行关联，从而建立错误与日志信息相关联，也就是说，可以通过错误标记找到对应的错误，以此错误标记为找到错误的指引。

S705：本地写入储存；

通过绑定建立了错误与日志信息相关联的效果，再把错误的标记与错误相关联的日志信息进行储存，因此，通过错误标记来对错误进行标记，既可以达到建立错误与日志信息相关联的效果，也可以达到储存错误的标记与错误相关联的日志信息的效果，从而避免因错误内容占用内存过多而出现游戏卡顿的现象。

S801：获取环境信息；

为了能准确找到错误出现的客观条件，可以获取环境信息来进行，比如客户端的系统版本(比如1081)、品牌(比如：OPPO)、型号(比如PBEM00)、制造商(OPPO)、模型(OPPOR11s)、产品类型(R11s)等，具体根据实际需要，此处不做限定。

S706：整合上报错误；

将抽样后得到的错误信息、与该错误信息相关联的日志信息以及环境信息进行整合，从而得到错误信息打包件，用于向服务器进行上传。

S707：上报错误和与错误相关联的日志信息；

上报错误和与错误相关联的日志信息主要分为两部分，以使错误上报，二是日志上报，具体如下进行详细说明：

错误上报，因为上报SDK会暴露错误钩子，开发者可以自行决定哪些错误不进行上报，过滤不需要上报的错误。部分错误优先级低，不需要重复的上报，还需要提供一个错误去重，允许业务去定制。比如设定错误只有达到五次的时候才允许上报。为了更高效的上报效率，需要设定分批分量、不同的错误优先级设定不同的上报策略，严重错误优先上报。上报还会上报快游戏的运行环境，比如品牌、系统版本信息等。

日志上报。上报错误发生前一段时间的日志有助于帮助排查和解决错误。上报仅上报那些已经上报过的错误的日志，如错误没有上报，日志就不应该被上报。当错误发生时，将错误id和日志关联一起写入持久缓存。错误抽样通过后，进入上报阶段，优先上报错误，错误上报完成后再上报对应的日志。这样在查看错误的时候，就可以查看到相应的日志。

比如项目A，接入了快游戏监控，每日累计收集错误平均三百多条，开发人员只需访问监控提供的后台界面，即可快速知道快游戏的报错情况。进而解决修复。其收集的错误效果包含了错误信息、堆栈、环境和日志等关键信息，具体可如表一所示。

S708：清除日志信息和存储信息；

为避免内存占用太多，在整合后的错误信息向服务器进行上报后可以对错误的标记与错误相关联的日志信息进行清除。

S709：结束。

其中，值得注意的是，收集错误的流程、写日志的流程与获取环境信息的流程可以是同步进行的异步处理方法，具体的步骤可以适当进行调整，当满足绑定条件、上报条件时，则可以进行发送或提取。因此本申请技术方案所产生的有益效果如下：

1.开发者可以及时收集处理到快游戏终端的错误，分析快游戏的健康度，帮助更好地改善应用。

2.日志上报，数据量小，对业务影响小。通过日志和错误结合帮助排查分析错误。

3.异常信息能够有效帮助定位问题，对于用户投诉和反馈的问题，我们能够制定用户准确收集到对应用户的所有异常信息，信息非常简洁清晰，对于定位问题的帮助有很大的提升。

因此，本申请突破性地提出了一种在快游戏上的异常监控方案，帮助业务改善快游戏的体验，提升稳定性。并且在错误异常上报的同时，将错误发生前的日志和环境信息也一起上报，辅助帮助开发者更迅速地分析解决错误，提高用户的游戏粘性。

请参阅图7，图7是本申请的电子设备一实施例的示意框图。本申请实施例提供了一种电子设备6，该电子设备6包括：

收集模块61，用于收集快游戏产生的错误；其中，收集的错误类型可自定义；

获取模块62，用于获取与错误相关联的日志信息；

上报模块63，用于将关联的错误和日志信息上报给服务器。

本申请针对目前快游戏的异常监控方法，通过自定义错误类型以及获取与错误相关联的日志信息，通过收集模块61能够及时收集快游戏产生的错误并通过日志信息准确找到错误来源，如此帮助开发者有效地用获取模块62追踪快游戏产生的异常，并获取到日志信息中的多种错误类型，从而使得开发者对多种错误类型进行针对性的修复，进而提升快游戏运行性能和改善用户体验。

进一步地，请参见图8，图8是的移动终端一实施例的示意框图。本申请实施例提供一种移动终端7，包括：处理器71和存储器72，存储器72中存储有计算机程序721，处理器71用于执行计算机程序721以本申请实施例第一方面的异常监控方法，在此不再赘述。

请参阅图9，图9是本申请的计算机可读存储介质一实施例的示意框图。如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在计算机可读存储介质80中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储装置中，包括若干指令(计算机程序81)用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或处理器(processor)执行本申请各个实施方式方法的全部或部分步骤。而前述的存储装置包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种介质以及具有上述存储介质的电脑、手机、笔记本电脑、平板电脑、相机等电子设备。

关于计算机可读存储介质中的计算机程序的执行过程的阐述可以参照上述本申请移动终端7的异常监控方法实施例中阐述，在此不再赘述。

请参阅图10，图10是本申请电子设备的硬件架构的示意框图，该电子设备900可以为工业电脑、平板电脑、手机以及笔记本电脑等，本实施例图示以手机为例。该电子设备900的结构可以包括射频(radio frequency，RF)电路910、存储器920、输入单元930、显示单元940、传感器950、音频电路960、WiFi(wireless fidelity)模块970、处理器980以及电源990等。其中，RF电路910、存储器920、输入单元930、显示单元940、传感器950、音频电路960以及WiFi模块970分别与处理器980连接；电源990用于为整个电子设备900提供电能。

具体而言，RF电路910用于接发信号；存储器920用于存储数据指令信息；输入单元930用于输入信息，具体可以包括触控面板931以及操作按键等其他输入设备932；显示单元940则可以包括显示面板等；传感器950包括红外传感器、激光传感器等，用于检测用户接近信号、距离信号等；扬声器961以及传声器(或者麦克风)962通过音频电路960与处理器980连接，用于接发声音信号；WiFi模块970则用于接收和发射WiFi信号，处理器980用于处理移动终端的数据信息。

以上所述仅为本申请的部分实施例，并非因此限制本申请的保护范围，凡是利用本申请说明书及附图内容所作的等效装置或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本申请的专利保护范围内。

Claims (10)

1.一种快游戏的异常监控方法，其特征在于，所述异常监控方法包括：

收集所述快游戏产生的错误；其中，收集的错误类型可自定义；

获取与所述错误相关联的日志信息；

将关联的所述错误和所述日志信息上报给服务器。

2.根据权利要求1所述的异常监控方法，其特征在于，

所述收集所述快游戏产生的错误，包括：

利用所述快游戏自带的错误钩子收集所述快游戏产生的错误；以及

利用自定义的软件开发工具包收集所述快游戏产生的错误。

3.根据权利要求2所述的异常监控方法，其特征在于，

所述利用自定义的软件开发工具包收集所述快游戏产生的错误，包括：

获取自定义的软件开发工具包，所述软件开发工具包根据所述错误进行自定义更新；

调用所述自定义的软件开发工具包对所述错误钩子进行重载，以新增所述错误类型；

利用所述自定义的软件开发工具包对所述快游戏产生的满足所述新增的错误类型的错误进行收集。

4.根据权利要求1所述的异常监控方法，其特征在于，

所述获取与所述错误相关联的日志信息之前，所述方法还包括：

记录所述快游戏产生的日志；

在所述错误满足关联条件时，建立所述错误与所述日志信息相关联；

储存所述错误的标记与所述错误相关联的所述日志信息。

5.根据权利要求4所述的异常监控方法，其特征在于，

所述在所述错误满足关联条件时，建立所述错误与所述日志信息相关联，包括：

在预设周期内，若检测有所述错误存在，则确定满足所述关联条件；或

产生所述错误的次数满足预设次数，则确定满足所述关联条件。

6.根据权利要求1所述的异常监控方法，其特征在于，

所述将关联的所述错误和所述日志信息上报给服务器，包括：

对所述错误进行去重，得到错误类型不同的去重错误；

对所述去重错误进行抽样；

将满足抽样条件的关联错误、所述关联错误对应的所述日志信息以及环境信息进行整合，以上报给所述服务器。

7.根据权利要求1～6任一项所述的异常监控方法，其特征在于，

所述将关联的所述错误和所述日志信息上报给服务器之后，所述异常监控方法包括：

清除储存的所述错误的标记与所述错误相关联的所述日志信息。

8.一种电子设备，其特征在于，包括：

收集模块，用于收集所述快游戏产生的错误；其中，收集的错误类型可自定义；

获取模块，用于获取与所述错误相关联的日志信息；

上报模块，用于将关联的所述错误和所述日志信息上报给服务器。

9.一种移动终端，其特征在于，包括：处理器和存储器，所述存储器中存储有计算机程序，所述处理器用于执行所述计算机程序以实现如权利要求1-7任一项所述的异常监控方法。

10.一种计算机可读存储介质，其特征在于，该计算机可读存储介质存储有计算机程序，计算机程序能够被处理器执行时实现如权利要求1-7任一项所述的异常监控方法。

Images