CN106685752A - 一种信息处理方法及终端 - Google Patents

Abstract

本发明公开了一种信息处理方法及终端；所述方法包括：终端监测自身的至少一个属性参数；判断所述至少一个属性参数是否处于异常状态，获得判断结果；基于所述判断结果统计第一时间范围内所述至少一个属性参数处于异常状态的次数；基于所述至少一个属性参数处于异常状态的次数分别确定所述至少一个属性参数对应的权重系数；基于所述至少一个属性参数对应的权重系数确定所述终端的运行状态；其中，所述至少一个属性参数包括以下参数的至少之一：表征应用程序无响应ANR的第一参数、表征中央处理器CPU的使用率的第二参数、表征应用进程重启的第三参数以及表征内存剩余量的第四参数。

Description

一种信息处理方法及终端

技术领域

本发明涉及互联网通信技术，尤其涉及一种信息处理方法及终端。

背景技术

卡顿，也就是通常用户所说的“卡”，一般出现在手机、笔记本等电子设备中，出现的现象为：在对各种电子设备进行操作的过程中，例如玩游戏的时候游戏运行不流畅，甚至游戏无法持续进行，或者听歌曲的时候画面滞帧，甚至无法继续播放歌曲。

现有技术中有一些专门检测手机帧率(FPS，Frames Per Second)的应用程序(APP，Application)，通过帧率的大小判断手机当前的卡顿情况，然而该方法只能监控自身APP页面的卡顿程度；现有技术中还存在监控手机所有操作界面卡顿情况的方案，即通过adb shell dumpsys SurfaceFlinger–latency命令获取系统帧绘制信息，进而得到帧率信息，然而，该方案需要root权限，也即通用性不强，且现有检测卡顿的技术方案均无法给出造成卡顿的原因。

发明内容

本发明实施例提供一种信息处理方法及终端，至少解决了现有技术中存在的问题，能够方便的实现对终端卡顿的检测，并得到卡顿原因，且具备通用性。

本发明实施例的技术方案是这样实现的：

本发明实施例提供了一种信息处理方法，所述方法包括：

终端监测自身的至少一个属性参数；

判断所述至少一个属性参数是否处于异常状态，获得判断结果；

基于所述判断结果统计第一时间范围内所述至少一个属性参数处于异常状态的次数；

基于所述至少一个属性参数处于异常状态的次数分别确定所述至少一个属性参数对应的权重系数；

基于所述至少一个属性参数对应的权重系数确定所述终端的运行状态；

其中，所述至少一个属性参数包括以下参数的至少之一：表征应用程序无响应(ANR)的第一参数、表征中央处理器(CPU)的使用率的第二参数、表征应用进程重启的第三参数以及表征内存剩余量的第四参数。

上述方案中，所述基于所述至少一个属性参数处于异常状态的次数分别确定所述至少一个属性参数对应的权重系数，包括：

预先配置多组第一对应关系；所述第一对应关系包括第一属性参数处于异常状态的次数范围对应的权重系数；其中，所述第一属性参数为所述至少一个属性参数中的任一属性参数；

基于所述第一属性参数处于异常状态的次数查询所述多组第一对应关系，确定对应的第一次数范围、以及所述第一次数范围对应的第一权重系数；

重复上述操作，直至确定所述至少一个属性参数对应的权重系数。

上述方案中，所述基于所述至少一个属性参数对应的权重系数确定所述终端的运行状态，包括：

预先配置多组第二对应关系；所述第二对应关系包括运行状态评价值范围对应的运行状态；

计算预设初始值与所述至少一个属性参数对应的权重系数的乘积，将所述乘积获得的数值作为第一运行状态评价值；

基于所述第一运行状态评价值查询所述多组第二对应关系，获得所述第一运行状态评价值对应的第一运行状态。

上述方案中，所述判断所述至少一个属性参数是否处于异常状态，获得判断结果，包括：

判断所述第一参数表征的ANR事件是否发生；当所述第一参数表征ANR事件发生时，获得的判断结果为所述第一参数处于异常状态；

和/或，判断所述第二参数表征的CPU使用率是否达到第一阈值；当所述第二参数表征CPU使用率达到第一阈值时，获得的判断结果为所述第二参数处于异常状态；

和/或，判断所述第三参数表征的应用进程重启事件是否发生；当所述第三参数表征应用进程重启事件发生时，获得的判断结果为所述第三参数处于异常状态；

和/或，判断所述第四参数表征的内存剩余量是否小于第二阈值；当所述第四参数表征内存剩余量小于第二阈值时，获得的判断结果为所述第四参数处于异常状态。

上述方案中，当所述至少一个属性参数包括：表征应用程序无响应(ANR)的第一参数、表征中央处理器(CPU)的使用率的第二参数以及表征应用进程重启的第三参数，且所述第一时间范围内所述第三参数处于异常状态的次数不为零时，

所述计算预设初始值与所述至少一个属性参数对应的权重系数的乘积，将所述乘积获得的数值作为第一运行状态评价值，包括：

计算预设初始值、所述第一参数对应的权重系数、所述第二参数对应的权重系数和所述第三参数对应的权重系数之间的乘积，将所述乘积获得的数值作为第一运行状态评价值。

上述方案中，当所述至少一个属性参数包括：表征应用程序无响应(ANR)的第一参数、表征中央处理器(CPU)的使用率的第二参数、表征应用进程重启的第三参数以及表征内存剩余量的第四参数，且所述第一时间范围内所述第三参数处于异常状态的次数为零时，

所述计算预设初始值与所述至少一个属性参数对应的权重系数的乘积，将所述乘积获得的数值作为第一运行状态评价值，包括：

计算预设初始值、所述第一参数对应的权重系数、所述第二参数对应的权重系数、所述第三参数对应的权重系数和所述第四参数对应的权重系数之间的乘积，将所述乘积获得的数值作为第一运行状态评价值。

本发明实施例还提供了一种终端，所述终端包括：监测模块、判断模块、统计模块及确定模块；其中，

所述监测模块，用于监测终端的至少一个属性参数；

所述判断模块，用于判断所述至少一个属性参数是否处于异常状态，获得判断结果；

所述统计模块，用于基于所述判断结果统计第一时间范围内所述至少一个属性参数处于异常状态的次数；

所述确定模块，用于基于所述至少一个属性参数处于异常状态的次数分别确定所述至少一个属性参数对应的权重系数；

以及，基于所述至少一个属性参数对应的权重系数确定所述终端的运行状态；

其中，所述至少一个属性参数包括以下参数的至少之一：表征应用程序无响应(ANR)的第一参数、表征中央处理器(CPU)的使用率的第二参数、表征应用进程重启的第三参数以及表征内存剩余量的第四参数。

上述方案中，所述确定模块，还用于预先配置多组第一对应关系；所述第一对应关系包括第一属性参数处于异常状态的次数范围对应的权重系数；其中，所述第一属性参数为所述至少一个属性参数中的任一属性参数；

基于所述第一属性参数处于异常状态的次数查询所述多组第一对应关系，确定对应的第一次数范围，以及所述第一次数范围对应的第一权重系数；

重复上述操作，直至确定所述至少一个属性参数对应的权重系数。

上述方案中，所述确定模块，还用于预先配置多组第二对应关系；所述第二对应关系包括运行状态评价值范围对应的运行状态；

计算预设初始值与所述至少一个属性参数对应的权重系数的乘积，将所述乘积获得的数值作为第一运行状态评价值；

基于所述第一运行状态评价值查询所述多组第二对应关系，获得所述第一运行状态评价值对应的第一运行状态。

上述方案中，所述判断模块，还用于判断所述第一参数表征的ANR事件是否发生；当所述第一参数表征ANR事件发生时，获得的判断结果为所述第一参数处于异常状态；

和/或，判断所述第二参数表征的CPU使用率是否达到第一阈值；当所述第二参数表征CPU使用率达到第一阈值时，获得的判断结果为所述第二参数处于异常状态；

和/或，判断所述第三参数表征的应用进程重启事件是否发生；当所述第三参数表征应用进程重启事件发生时，获得的判断结果为所述第三参数处于异常状态；

和/或，判断所述第四参数表征的内存剩余量是否小于第二阈值；当所述第四参数表征内存剩余量小于第二阈值时，获得的判断结果为所述第四参数处于异常状态。

上述方案中，当所述至少一个属性参数包括：表征应用程序无响应(ANR)的第一参数、表征中央处理器(CPU)的使用率的第二参数以及表征应用进程重启的第三参数，且所述第一时间范围内所述第三参数处于异常状态的次数不为零时，

所述确定模块，还用于计算预设初始值、所述第一参数对应的权重系数、所述第二参数对应的权重系数和所述第三参数对应的权重系数之间的乘积，将所述乘积获得的数值作为第一运行状态评价值。

上述方案中，当所述至少一个属性参数包括：表征应用程序无响应(ANR)的第一参数、表征中央处理器(CPU)的使用率的第二参数、表征应用进程重启的第三参数以及表征内存剩余量的第四参数，且所述第一时间范围内所述第三参数处于异常状态的次数为零时，

所述确定模块，还用于计算预设初始值、所述第一参数对应的权重系数、所述第二参数对应的权重系数、所述第三参数对应的权重系数和所述第四参数对应的权重系数之间的乘积，将所述乘积获得的数值作为第一运行状态评价值。

应用本发明所述实施例，终端监测自身的至少一个属性参数，判断所述至少一个属性参数是否处于异常状态，获得判断结果；基于所述判断结果统计第一时间范围内所述至少一个属性参数处于异常状态的次数；基于所述至少一个属性参数处于异常状态的次数分别确定所述至少一个属性参数对应的权重系数；基于所述至少一个属性参数对应的权重系数确定所述终端的运行状态；其中，所述至少一个属性参数包括以下参数的至少之一：表征应用程序无响应(ANR，Application Not Responding)的第一参数、表征中央处理器(CPU，Central Processing Unit)的使用率的第二参数、表征应用进程重启的第三参数以及表征内存剩余量的第四参数。如此，终端通过自身监测得到的至少一种属性参数处于异常状态的次数确定对应的权重系数，进而通过不同的属性参数对应的权重系数确定终端的运行状态，即确定该终端是否卡顿；避免了在终端不具备root权限时下无法检测终端是否卡顿的情况，具备通用性；而且，通过终端监测得到的至少一种属性参数处于异常状态的次数，可以令用户直观的得到终端卡顿的原因，用户体验高。

附图说明

图1为本发明实施例中信息处理方法的流程示意图一；

图2为本发明实施例中信息处理方法的流程示意图二；

图3为本发明实施例中一种卡顿结构分布情况示意图；

图4为本发明实施例中信息处理方法的流程示意图三；

图5为本发明实施例中信息处理方法的流程示意图四；

图6为本发明实施例中一种卡顿趋势变化示意图；

图7为本发明实施例中终端的组成结构示意图；

图8为本发明实施例中终端作为硬件实体的一个示例图。

具体实施方式

下面结合附图及具体实施例对本发明作进一步详细的说明。

实施例一

本发明实施例提供了一种信息处理方法，所述方法应用于终端，图1所示为本发明实施例中信息处理方法的第一种流程示意图，本发明实施例中信息处理方法包括：

步骤101：终端监测自身的至少一个属性参数。

在实际应用过程中，导致手机卡顿的主要是原因是绘制帧的时候时间超时导致丢帧，丢帧越多说明越卡顿；然而，导致绘制帧的时间超时的原因除开个别页面比较复杂之外，更多的是由于系统的资源不足导致；因此，在实施本发明实施例时，所述至少一个属性参数设置为包括以下参数的至少之一：表征应用程序无响应ANR的第一参数、表征CPU的使用率的第二参数、表征应用进程重启的第三参数以及表征内存剩余量的第四参数；

在一实施例中，优选地，终端对第一参数的监测为实时监测，只要有程序无响应的情况出现便记录相应的应用程序及出现ANR的总的次数；对第二参数的监测为周期性的监测，如每隔30秒检测一次CPU使用率并记录；对第三参数的监测为周期性的监测，如每隔5分钟检测一次进程重启的数目及相应的进程；对第四参数的监测可以为周期性的监测或依据需要/指令进行检测；通过监测上述参数的变化，更便于了解终端的资源消耗情况及运行情况等。

步骤102：判断所述至少一个属性参数是否处于异常状态，获得判断结果。

在实际实施时，终端判断某个属性参数是否处于异常状态，具体与该属性参数特点相对应，在一实施例中，终端判断所述第一参数表征的ANR事件是否发生，当所述第一参数表征ANR事件发生时，获得的判断结果为所述第一参数处于异常状态；

和/或，判断所述第二参数表征的CPU使用率是否达到第一阈值；当所述第二参数表征CPU使用率达到第一阈值时，获得的判断结果为所述第二参数处于异常状态；其中，第一阈值可以依据实际需要进行设定，如设定第一阈值为85％；在实际应用中，也可设定某个阀值，当CPU使用率超过该阀值X％时便认定为第二参数处于异常状态，X值可依据需要进行设定，如40；

和/或，判断所述第三参数表征的应用进程重启事件是否发生；当所述第三参数表征应用进程重启事件发生时，获得的判断结果为所述第三参数处于异常状态；

和/或，判断所述第四参数表征的内存剩余量是否小于第二阈值；当所述第四参数表征内存剩余量小于第二阈值时，获得的判断结果为所述第四参数处于异常状态；其中，第二阈值可以依据实际需要进行设定，如设定第二阈值为10％。

步骤103：基于所述判断结果统计第一时间范围内所述至少一个属性参数处于异常状态的次数。

在实际应用中，第一时间的设定可以依据实际情况及实际需要进行设定，例如：设定第一时间为1小时。

步骤104：基于所述至少一个属性参数处于异常状态的次数分别确定所述至少一个属性参数对应的权重系数。

由于统计的是所述至少一个属性参数处于异常状态的次数，可知，处于异常状态的次数越少，终端卡顿的可能性越小，即终端系统运行更流畅。

在本发明实施例中，由于确定权重系数的目的是基于该权重系数确定终端的运行状态，即确定终端的卡顿情况，因此，若属性参数处于异常状态的次数与相应的权重系数呈正相关关系，则该权重系数与终端的卡顿情况呈正相关关系，即若异常状态次数越多权重系数越大，则权重系数越大终端的卡顿情况越严重，即越卡；而若属性参数处于异常状态的次数与相应的权重系数呈负相关关系，则该权重系数与终端的卡顿情况呈负相关关系，即若异常状态次数越多权重系数越小，则权重系数越小终端的卡顿情况越严重，即越卡；

在一实施例中，基于某一个属性参数处于异常状态的次数确定该属性参数对应的权重系数的方法如下：

预先配置多组第一对应关系；所述第一对应关系包括第一属性参数处于异常状态的次数范围对应的权重系数；其中，所述第一属性参数为所述至少一个属性参数中的任一属性参数；例如：对于本实施例中第一参数来说，第一参数处于异常状态的次数小于5次时，对应的权重系数为1；第一参数处于异常状态的次数处于5次到10次之间时，对应的权重系数为0.8；第一参数处于异常状态的次数处于10次到15次之间时，对应的权重系数为0.6；第一参数处于异常状态的次数大于15次时，对应的权重系数为0.4；

基于所述第一属性参数处于异常状态的次数查询所述多组第一对应关系，确定对应的第一次数范围、以及所述第一次数范围对应的第一权重系数。

当终端需要获取两个或两个以上属性参数对应的权重系数时，可重复上述操作，直至获取到所有属性参数对应的权重系数。

步骤105：基于所述至少一个属性参数对应的权重系数确定终端的运行状态。

在实际实施时，可基于表征ANR的第一参数、表征CPU的使用率的第二参数、表征应用进程重启的第三参数以及表征内存剩余量的第四参数中的一个或多个对应的权重系数来确定终端的运行状态，即卡顿情况；

具体可以包括：预先配置多组第二对应关系并预先设定一个初始值；例如，设定所述初始值为5，所述第二对应关系包括运行状态评价值范围对应的运行状态；例如：设定运行状态评价值小于1时，对应的运行状态为非常卡顿；运行状态评价值处于1和2之间时，对应的运行状态为比较卡顿；运行状态评价值处于2和3之间时，对应的运行状态为偶尔卡顿；运行状态评价值处于3和4之间时，对应的运行状态为比较流畅；运行状态评价值处于4和5之间时，对应的运行状态为非常流畅；

计算预设初始值与所述至少一个属性参数对应的权重系数的乘积，将所述乘积获得的数值作为第一运行状态评价值；

基于所述第一运行状态评价值查询所述多组第二对应关系，获得所述第一运行状态评价值对应的第一运行状态。

应用本发明上述实施例，终端通过自身监测得到的至少一种属性参数处于异常状态的次数确定对应的权重系数，进而通过不同的属性参数对应的权重系数确定终端是否卡顿；如此，避免了在终端不具备root权限时下无法检测终端是否卡顿的情况，具备通用性，而且，通过终端监测得到的至少一种属性参数处于异常状态的次数，可以令用户直观的得到终端卡顿的原因，例如：终端监测得到第一应用程序出现无响应的次数较高，第二应用程序的CPU使用率较高，可知，造成终端卡顿的主要原因是上述第一应用程序及第二应用程序，进而可使用户采取相应措施，提高了用户体验。

实施例二

本发明实施例提供了一种信息处理方法，所述方法应用于终端，图2所示为本发明实施例中信息处理方法的第二种流程示意图，本发明实施例中信息处理方法包括：

步骤201：终端监测自身的至少一个属性参数。

在实际应用过程中，导致手机卡顿的主要是原因是绘制帧的时候时间超时导致丢帧，丢帧越多说明越卡顿；然而，导致绘制帧的时间超时的原因除开个别页面比较复杂之外，更多的是由于系统的资源不足导致；因此，在实施本发明实施例时，所述至少一个属性参数设置为包括以下参数的至少之一：表征应用程序无响应ANR的第一参数、表征CPU的使用率的第二参数、表征应用进程重启的第三参数以及表征内存剩余量的第四参数；

在一实施例中，优选地，终端对第一参数的监测为实时监测，只要有程序无响应的情况出现便记录相应的应用程序及出现ANR的总的次数；对第二参数的监测为周期性的监测，如每隔30秒检测一次CPU使用率并记录；对第三参数的监测为周期性的监测，如每隔5分钟检测一次进程重启的数目及相应的进程；对第四参数的监测可以为周期性的监测或依据需要/指令进行检测；通过监测上述参数的变化，更便于了解终端的资源消耗情况及运行情况等。

步骤202：判断所述至少一个属性参数是否处于异常状态，并基于判断结果统计第一时间范围内所述至少一个属性参数处于异常状态的次数。

在本实施例中，终端判断所述至少一个属性参数是否处于异常状态，包括：

终端判断所述第一参数表征的ANR事件是否发生，当所述第一参数表征ANR事件发生时，获得的判断结果为所述第一参数处于异常状态；

和/或，判断所述第二参数表征的CPU使用率是否达到第一阈值；当所述第二参数表征CPU使用率达到第一阈值时，获得的判断结果为所述第二参数处于异常状态；其中，第一阈值可以依据实际需要进行设定，如设定第一阈值为85％；在实际应用中，也可设定某个阀值，当CPU使用率超过该阀值X％时便认定为第二参数处于异常状态，X值可依据需要进行设定，如40；

和/或，判断所述第三参数表征的应用进程重启事件是否发生；当所述第三参数表征应用进程重启事件发生时，获得的判断结果为所述第三参数处于异常状态；

和/或，判断所述第四参数表征的内存剩余量是否小于第二阈值；当所述第四参数表征内存剩余量小于第二阈值时，获得的判断结果为所述第四参数处于异常状态；其中，第二阈值可以依据实际需要进行设定，如设定第二阈值为10％。

在实际应用中，第一时间的设定可以依据实际情况及实际需要进行设定，例如：设定第一时间为1小时。

步骤203：基于所述至少一个属性参数处于异常状态的次数分别确定所述至少一个属性参数对应的权重系数。

在本实施例中，本步骤具体包括：

预先配置多组第一对应关系；所述第一对应关系包括第一属性参数处于异常状态的次数范围对应的权重系数；其中，所述第一属性参数为所述至少一个属性参数中的任一属性参数；例如：对于本实施例中第二参数来说，第二参数处于异常状态的次数小于5次时，对应的权重系数为1；第二参数处于异常状态的次数处于5次到10次之间时，对应的权重系数为0.8；第二参数处于异常状态的次数处于10次到20次之间时，对应的权重系数为0.6；第二参数处于异常状态的次数大于20次时，对应的权重系数为0.4；

基于所述第一属性参数处于异常状态的次数查询所述多组第一对应关系，确定对应的第一次数范围、以及所述第一次数范围对应的第一权重系数；如：得到第二参数处于异常状态的次数为8次，查询所述多组第一对应关系可知其对应的第一次数范围为5次到10次之间、以及该第一次数范围对应的第一权重系数为0.8；

当终端需要获取两个或两个以上属性参数对应的权重系数时，可重复上述操作，直至获取到所有属性参数对应的权重系数。

步骤204：计算预设初始值与所述至少一个属性参数对应的权重系数的乘积，将所述乘积获得的数值作为第一运行状态评价值。

在本实施例中，当所述至少一个属性参数包括：表征ANR的第一参数、表征CPU的使用率的第二参数以及表征应用进程重启的第三参数，且所述第一时间范围内所述第三参数处于异常状态的次数不为零时，本步骤具体包括：

计算预设初始值、所述第一参数对应的权重系数、所述第二参数对应的权重系数和所述第三参数对应的权重系数之间的乘积，将所述乘积获得的数值作为第一运行状态评价值；其中，所述预设初始值是为了得到用于确定终端卡顿情况的运行状态评价值而设定的一个数值，如5。

由于终端系统的内存剩余量会影响应用进程的重启，内存剩余量如果少的话，相应的，进程重启次数便会增多；因此，当检测到在所述第一时间范围内所述第三参数处于异常状态的次数为零时，需进一步考虑表征内存剩余量的第四参数的影响；

也即，当所述至少一个属性参数包括：表征ANR的第一参数、表征CPU的使用率的第二参数、表征应用进程重启的第三参数以及表征内存剩余量的第四参数，且所述第一时间范围内所述第三参数处于异常状态的次数为零时，本步骤具体包括：

计算预设初始值、所述第一参数对应的权重系数、所述第二参数对应的权重系数、所述第三参数对应的权重系数和所述第四参数对应的权重系数之间的乘积，将所述乘积获得的数值作为第一运行状态评价值。

步骤205：基于第一运行状态评价值查询预先配置的多组第二对应关系，获得第一运行状态评价值对应的第一运行状态。

这里，第二对应关系包括运行状态评价值范围对应的运行状态；例如：设定运行状态评价值小于1时，对应的运行状态为非常卡顿；运行状态评价值处于1和2之间时，对应的运行状态为比较卡顿；运行状态评价值处于2和3之间时，对应的运行状态为偶尔卡顿；运行状态评价值处于3和4之间时，对应的运行状态为比较流畅；运行状态评价值处于4和5之间时，对应的运行状态为非常流畅。

在实际应用中，所述方法还包括：

在第二时间范围内周期性的获取两次以上所述终端的运行情况；

基于所述两次以上所述终端的运行情况确定所述终端在第二时间范围内的卡顿结构分布情况；

这里所说的卡顿结构分布情况指的是在第二时间范围内，终端不同的运行状态所占的比例。

当然，终端在确定自身的运行情况后，可将自身的运行情况上报给服务器，进而可由服务器统计同一时间范围内，多个用户终端的卡顿结构分布情况，如图3所示为本发明实施例中一种卡顿结构分布情况示意图；

在实际应用中，所述方法还包括：

确定所述终端为root终端，获取所述终端的FPS信息；

基于所述终端的FPS信息确定其对应的权重系数；在一实施例中，当50<FPS<60时，对应的权重系数为1；40<FPS<50时，对应的权重系数为0.8；30<FPS<40时，对应的权重系数为0.6；20<FPS<30时，对应的权重系数为0.4；0<FPS<20时，对应的权重系数为0.2；

基于所述终端的FPS对应的权重系数及所述预设初始值得到所述终端的第二运行状态评价值；实际实施时，可采用第二运行状态评价值＝预设初始值*终端的FPS对应的权重系数；如预设初始值为5，权重系数为0.6，则得到终端的第二运行状态评价值为3；

基于所述第二运行状态评价值验证确定的所述第一运行状态的准确度。在实际应用中，将获得的第一运行状态评价值与第二运行状态评价值进行比较，差值越小，即二者越接近，表明得到的第一运行状态的准确度越高。

应用本发明上述实施例，终端通过自身监测得到的至少一种属性参数处于异常状态的次数确定对应的权重系数，进而通过不同的属性参数对应的权重系数确定终端是否卡顿；如此，避免了在终端不具备root权限时下无法检测终端是否卡顿的情况，具备通用性，而且，通过终端监测得到的至少一种属性参数处于异常状态的次数，可以令用户直观的得到终端卡顿的原因，例如终端监测到某一种参数出现的次数较多，相应的可能是该参数表征的情况导致的终端卡顿，进而可使用户在了解卡顿原因后采取相应措施，提高了用户体验。

实施例三

本发明实施例提供了一种信息处理方法，所述方法通过终端上设置的一种应用APP来实现，图4所示为本发明实施例中信息处理方法的第三种流程示意图，本发明实施例中信息处理方法包括：

步骤301：第一APP监测终端表征ANR的第一参数、表征CPU的使用率的第二参数及表征应用进程重启的第三参数。

在本实施例中，第一参数表征ANR，第二参数表征CPU的使用率，第三参数表征应用进程重启；其中，对第一参数的监测为实时监测，对第二参数的监测为周期性的监测，优选地，周期为30秒，对第三参数的监测为周期性的监测，优选地，周期为5分钟。

在实际应用中，所述第一APP可以为终端上的手机管家应用。

步骤302：统计第一时间范围内第一参数、第二参数及第三参数处于异常状态的次数。

在实际应用中，第一APP确定ANR事件发生时，则第一参数处于异常状态；例如，确定终端上设置的QQ应用无响应，则可相应记录QQ应用无响应的时间及累计次数；确定CPU使用率达到第一阈值时，则第二参数处于异常状态；第一阈值可以依据实际需要进行设定，在本实施例中，第一阈值为85％；确定应用进程重启事件发生时，则第三参数处于异常状态。

第一时间的设定可以依据实际情况及实际需要进行设定，在本实施例中，设定第一时间为1小时。

步骤303：基于第一时间范围内第一参数、第二参数及第三参数处于异常状态的次数，分别确定各个参数对应的权重系数。

查找每个参数的异常状态次数范围对应的权重系数，基于该参数处于异常状态的次数确定相应的权重系数；在本实施例中，对于第一参数来说，第一参数处于异常状态的次数小于5次时，对应的权重系数为1；第一参数处于异常状态的次数处于5次到10次之间时，对应的权重系数为0.8；第一参数处于异常状态的次数处于10次到15次之间时，对应的权重系数为0.6；第一参数处于异常状态的次数大于15次时，对应的权重系数为0.4。

对于第二参数、第三参数来说，第二参数、第三参数处于异常状态的次数小于5次时，对应的权重系数为1；第二参数、第三参数处于异常状态的次数处于5次到10次之间时，对应的权重系数为0.8；第二参数、第三参数处于异常状态的次数处于10次到20次之间时，对应的权重系数为0.6；第二参数、第三参数处于异常状态的次数大于20次时，对应的权重系数为0.4。

步骤304：判断第三参数处于异常状态的次数是否为零，如果是，执行步骤305；如果不是，执行步骤307。

这里，由于终端系统的内存剩余量会影响应用进程的重启，内存剩余量如果少的话，相应的，进程重启次数便会增多；因此，当检测到在所述第一时间范围内进程重启的次数为零时，需进一步考虑表征内存剩余量的第四参数的影响；而当在所述第一时间范围内进程重启的次数不为零时，则无需考虑内存剩余量的影响。

步骤305：获取终端的内存剩余量，并依据所述内存剩余量确定相应的权重系数。

在本实施例中，不同的内存剩余量范围对应不同的权重系数，如：当内存剩余量小于5％时，相应的权重系数为0.4，当内存剩余量处于5％～10％时，相应的权重系数为0.6，当内存剩余量处于10％～15％时，相应的权重系数为0.8，当内存剩余量大于15％时，相应的权重系数为1。

步骤306：获取预设初始值，并计算预设初始值与第一参数、第二参数、第三参数及第四参数对应的权重系数的乘积，将乘积得到的数值作为终端的运行状态评价值，并执行步骤308。

这里，运行状态评价值＝预设初始值*第一权重系数*第二权重系数*第三权重系数*第四权重系数；其中第一权重系数、第二权重系数、第三权重系数、第四权重系数分别为第一参数、第二参数、第三参数及第四参数对应的权重系数；例如：预设初始值为5，四个权重系数分别为0.8、0.8、1、0.6；则运行状态评价值＝5*0.8*0.8*1*0.6＝1.92。

步骤307：获取预设初始值，并计算预设初始值与第一参数、第二参数及第三参数对应的权重系数的乘积，将乘积得到的数值作为终端的运行状态评价值。

这里，运行状态评价值＝预设初始值*第一权重系数*第二权重系数*第三权重系数；例如：预设初始值为5，三个权重系数分别为0.4、0.4、0.6；则运行状态评价值＝5*0.4*0.4*0.6＝0.48。

步骤308：基于获得的运行状态评价值确定终端的卡顿情况。

在本实施例中，终端不同的卡顿情况对应不同的运行状态评价值范围，基于得到的运行状态评价值查找该对应关系，可得到终端的卡顿情况；运行状态评价值小于1时，对应的运行状态为非常卡顿；运行状态评价值处于1和2之间时，对应的运行状态为比较卡顿；运行状态评价值处于2和3之间时，对应的运行状态为偶尔卡顿；运行状态评价值处于3和4之间时，对应的运行状态为比较流畅；运行状态评价值处于4和5之间时，对应的运行状态为非常流畅。基于步骤307得到的运行状态评价值可知，终端非常卡顿，造成卡顿的原因主要是ANR及CPU使用率异常，用户可找出出现多次程序无响应的程序，以及CPU使用率较高的进程，结束相应的应用进程或者卸载并重新安装等；而基于步骤306得到的运行状态评价值可知，终端比较卡顿。

步骤309：结束本次处理流程。

实施例四

本发明实施例提供了一种信息处理方法，所述方法通过手机上设置的手机管家来实现，且该终端为超级用户终端，即具备root权限，本发明实施例中信息处理方法包括：

手机管家首先启动对各个指标的监控(包括：FPS、ANR次数、CPU使用率、进程重启数、手机内存剩余量)，当各个指标发生异常时记录，每隔一段时间(一小时)对各个指标的异常次数做评估，根据不同次数对应的权重系数相乘以得到最后的分数，其处理流程示意图如图5所示：终端上设置了如图所示的FPS检测器，用于监测FPS；ANR发生检测器，用于检测ANR发生的次数及记录相应的进程和时间；CPU使用率检测器，用于检测CPU使用率及手机运行的程序对应的CPU使用率；进程重启检测器，用于检测进程重启次数及相应的进程；内存剩余检测器，用于检测手机内存剩余量。

具体用于评价手机的卡顿情况的分值计算方法包括：

1)、初始分值是满分5分；

2)、监测ANR发生的次数，小于5次权重系数是1，10>ANR>5时，权重系数是0.8，15>ANR≥10时，权重系数是0.6，大于15时，权重系数是0.4，这项监测后分数A＝5*ANR权重系数；

3)、检测CPU异常次数(CPU使用率超过阀值40％定义为异常，阀值可依据需要设定)，小于5次时，权重系数是1，10>cpu>5时，系数是0.8，20>cpu≥10时，权重系数是0.6，大于20时，权重系数是0.4，这项检测后分数B＝分数A*CPU权重系数；

4)、检测进程重启的进程数，小于5次，权重系数是1，10>proc>5，权重系数是0.8，20>proc≥10，权重系数是0.6，大于20，权重系数是0.4，这项检测后分数C＝分数B*proc系数

5)如果上一步的进程重启数等于0，则进一步检测当前系统内存剩余量，剩余内存小于5％系数是0.4，处于5％～10％，权重系数是0.6，处于5％～15％，权重系数是0.8，其他是1；可得最终分数D＝分数C*进程重启的权重系数；

而若上一步的进程重启数不等于0，则无需考虑内存剩余量，最终分数D＝分数C；

最终分数D就是手机管家对手机当前卡顿等级的打分，小于1分(非常卡顿)、1分～2分(比较卡顿)、2分～3分(偶尔卡顿)、3分～4分(比较流畅)、4分～5分(非常流畅)。

由于本实施例中手机具备root权限，因此，可以通过另外一个纬度来对用户进行评分，就是获取系统的帧率(FPS)，满分5分，50<fps<60，权重系数是1，40<fps<50，权重系数0.8，30<fps<40，权重系数是0.6，20<fps<30，权重系数是0.4，0<fps<20，权重系数是0.2，最终可以得到分数E＝5*fps权重系数。

分数E和分数D越接近，说明分数D的评估是越能体现用户真实的卡顿情况。

通过统计某个版本的手机管家的所有用户的手机卡顿情况，便可得到该版本的手机管家的所有用户的手机卡顿情况分布图，如图3所示。

而通过统计手机在不同时刻的卡顿情况，可以确定一段时间内手机的卡顿趋势变化，如图6所示为本发明实施例中一种卡顿趋势变化示意图。进而可以追踪不同版本的手机管家的用户的卡顿趋势变化。

实施例五

本发明实施例提供了一种终端，如图7所示，所述终端包括：监测模块71、判断模块72、统计模块73及确定模块74；其中，

所述监测模块71，用于监测终端的至少一个属性参数；

所述判断模块72，用于判断所述至少一个属性参数是否处于异常状态，获得判断结果；

所述统计模块73，用于基于所述判断结果统计第一时间范围内所述至少一个属性参数处于异常状态的次数；

所述确定模块74，用于基于所述至少一个属性参数处于异常状态的次数分别确定所述至少一个属性参数对应的权重系数；

以及，基于所述至少一个属性参数对应的权重系数确定所述终端的运行状态；

其中，所述至少一个属性参数包括以下参数的至少之一：表征应用程序无响应ANR的第一参数、表征中央处理器CPU的使用率的第二参数、表征应用进程重启的第三参数以及表征内存剩余量的第四参数。

在一实施例中，所述确定模块74，还用于预先配置多组第一对应关系；所述第一对应关系包括第一属性参数处于异常状态的次数范围对应的权重系数；其中，所述第一属性参数为所述至少一个属性参数中的任一属性参数；

基于所述第一属性参数处于异常状态的次数查询所述多组第一对应关系，确定对应的第一次数范围，以及所述第一次数范围对应的第一权重系数；

重复上述操作，直至确定所述至少一个属性参数对应的权重系数。

在一实施例中，所述确定模块74，还用于预先配置多组第二对应关系；所述第二对应关系包括运行状态评价值范围对应的运行状态；

计算预设初始值与所述至少一个属性参数对应的权重系数的乘积，将所述乘积获得的数值作为第一运行状态评价值；

基于所述第一运行状态评价值查询所述多组第二对应关系，获得所述第一运行状态评价值对应的第一运行状态。

在一实施例中，所述判断模块72，还用于判断所述第一参数表征的ANR事件是否发生；当所述第一参数表征ANR事件发生时，获得的判断结果为所述第一参数处于异常状态；

和/或，判断所述第二参数表征的CPU使用率是否达到第一阈值；当所述第二参数表征CPU使用率达到第一阈值时，获得的判断结果为所述第二参数处于异常状态；

和/或，判断所述第三参数表征的应用进程重启事件是否发生；当所述第三参数表征应用进程重启事件发生时，获得的判断结果为所述第三参数处于异常状态；

和/或，判断所述第四参数表征的内存剩余量是否小于第二阈值；当所述第四参数表征内存剩余量小于第二阈值时，获得的判断结果为所述第四参数处于异常状态。

在一实施例中，当所述至少一个属性参数包括：表征应用程序无响应ANR的第一参数、表征中央处理器CPU的使用率的第二参数以及表征应用进程重启的第三参数，且所述第一时间范围内所述第三参数处于异常状态的次数不为零时，

所述确定模块74，还用于计算预设初始值、所述第一参数对应的权重系数、所述第二参数对应的权重系数和所述第三参数对应的权重系数之间的乘积，将所述乘积获得的数值作为第一运行状态评价值。

在一实施例中，当所述至少一个属性参数包括：表征应用程序无响应ANR的第一参数、表征中央处理器CPU的使用率的第二参数、表征应用进程重启的第三参数以及表征内存剩余量的第四参数，且所述第一时间范围内所述第三参数处于异常状态的次数为零时，

所述确定模块74，还用于计算预设初始值、所述第一参数对应的权重系数、所述第二参数对应的权重系数、所述第三参数对应的权重系数和所述第四参数对应的权重系数之间的乘积，将所述乘积获得的数值作为第一运行状态评价值。

在本发明实施例中，所述终端中的监测模块71、判断模块72、统计模块73及确定模块74，均可由终端中的中央处理器(CPU，Central Processing Unit)或数字信号处理器(DSP，Digital Signal Processor)、或现场可编程门阵列(FPGA，Field ProgrammableGate Array)、或集成电路(ASIC，Application Specific Integrated Circuit)实现。

这里需要指出的是：以上涉及终端的描述，与上述方法描述是类似的，同方法的有益效果描述，不做赘述。对于本发明所述终端实施例中未披露的技术细节，请参照本发明方法实施例的描述。

本实施例中，终端作为硬件实体的一个示例如图8所示。所述终端包括处理器61、存储介质62以及至少一个外部通信接口63；所述处理器61、存储介质62以及外部通信接口63均通过总线64连接。

本领域的技术人员可以理解：实现上述方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成，前述的程序可以存储于一计算机可读取存储介质中，该程序在执行时，执行包括上述方法实施例的步骤；而前述的存储介质包括：移动存储设备、随机存取存储器(RAM，Random Access Memory)、只读存储器(ROM，Read-Only Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

或者，本发明上述集成的单元如果以软件功能模块的形式实现并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明实施例的技术方案本质上或者说对相关技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机、终端、或者网络设备等)执行本发明各个实施例所述方法的全部或部分。而前述的存储介质包括：移动存储设备、RAM、ROM、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应以所述权利要求的保护范围为准。

Claims (12)

1.一种信息处理方法，其特征在于，所述方法包括：

终端监测自身的至少一个属性参数；

判断所述至少一个属性参数是否处于异常状态，获得判断结果；

基于所述判断结果统计第一时间范围内所述至少一个属性参数处于异常状态的次数；

基于所述至少一个属性参数处于异常状态的次数分别确定所述至少一个属性参数对应的权重系数；

基于所述至少一个属性参数对应的权重系数确定所述终端的运行状态；

其中，所述至少一个属性参数包括以下参数的至少之一：表征应用程序无响应ANR的第一参数、表征中央处理器CPU的使用率的第二参数、表征应用进程重启的第三参数以及表征内存剩余量的第四参数。

2.根据权利要求1所述的方法，其特征在于，所述基于所述至少一个属性参数处于异常状态的次数分别确定所述至少一个属性参数对应的权重系数，包括：

预先配置多组第一对应关系；所述第一对应关系包括第一属性参数处于异常状态的次数范围对应的权重系数；其中，所述第一属性参数为所述至少一个属性参数中的任一属性参数；

基于所述第一属性参数处于异常状态的次数查询所述多组第一对应关系，确定对应的第一次数范围、以及所述第一次数范围对应的第一权重系数；

重复上述操作，直至确定所述至少一个属性参数对应的权重系数。

3.根据权利要求1所述的方法，其特征在于，所述基于所述至少一个属性参数对应的权重系数确定所述终端的运行状态，包括：

预先配置多组第二对应关系；所述第二对应关系包括运行状态评价值范围对应的运行状态；

计算预设初始值与所述至少一个属性参数对应的权重系数的乘积，将所述乘积获得的数值作为第一运行状态评价值；

基于所述第一运行状态评价值查询所述多组第二对应关系，获得所述第一运行状态评价值对应的第一运行状态。

4.根据权利要求1所述的方法，其特征在于，所述判断所述至少一个属性参数是否处于异常状态，获得判断结果，包括：

判断所述第一参数表征的ANR事件是否发生；当所述第一参数表征ANR事件发生时，获得的判断结果为所述第一参数处于异常状态；

和/或，判断所述第二参数表征的CPU使用率是否达到第一阈值；当所述第二参数表征CPU使用率达到第一阈值时，获得的判断结果为所述第二参数处于异常状态；

和/或，判断所述第三参数表征的应用进程重启事件是否发生；当所述第三参数表征应用进程重启事件发生时，获得的判断结果为所述第三参数处于异常状态；

和/或，判断所述第四参数表征的内存剩余量是否小于第二阈值；当所述第四参数表征内存剩余量小于第二阈值时，获得的判断结果为所述第四参数处于异常状态。

5.根据权利要求3所述的方法，其特征在于，当所述至少一个属性参数包括：表征应用程序无响应ANR的第一参数、表征中央处理器CPU的使用率的第二参数以及表征应用进程重启的第三参数，且所述第一时间范围内所述第三参数处于异常状态的次数不为零时，

所述计算预设初始值与所述至少一个属性参数对应的权重系数的乘积，将所述乘积获得的数值作为第一运行状态评价值，包括：

计算预设初始值、所述第一参数对应的权重系数、所述第二参数对应的权重系数和所述第三参数对应的权重系数之间的乘积，将所述乘积获得的数值作为第一运行状态评价值。

6.根据权利要求3所述的方法，其特征在于，当所述至少一个属性参数包括：表征应用程序无响应ANR的第一参数、表征中央处理器CPU的使用率的第二参数、表征应用进程重启的第三参数以及表征内存剩余量的第四参数，且所述第一时间范围内所述第三参数处于异常状态的次数为零时，

所述计算预设初始值与所述至少一个属性参数对应的权重系数的乘积，将所述乘积获得的数值作为第一运行状态评价值，包括：

计算预设初始值、所述第一参数对应的权重系数、所述第二参数对应的权重系数、所述第三参数对应的权重系数和所述第四参数对应的权重系数之间的乘积，将所述乘积获得的数值作为第一运行状态评价值。

7.一种终端，其特征在于，所述终端包括：监测模块、判断模块、统计模块及确定模块；其中，

所述监测模块，用于监测终端的至少一个属性参数；

所述判断模块，用于判断所述至少一个属性参数是否处于异常状态，获得判断结果；

所述统计模块，用于基于所述判断结果统计第一时间范围内所述至少一个属性参数处于异常状态的次数；

所述确定模块，用于基于所述至少一个属性参数处于异常状态的次数分别确定所述至少一个属性参数对应的权重系数；

以及，基于所述至少一个属性参数对应的权重系数确定所述终端的运行状态；

其中，所述至少一个属性参数包括以下参数的至少之一：表征应用程序无响应ANR的第一参数、表征中央处理器CPU的使用率的第二参数、表征应用进程重启的第三参数以及表征内存剩余量的第四参数。

8.根据权利要求7所述的终端，其特征在于，

所述确定模块，还用于预先配置多组第一对应关系；所述第一对应关系包括第一属性参数处于异常状态的次数范围对应的权重系数；其中，所述第一属性参数为所述至少一个属性参数中的任一属性参数；

基于所述第一属性参数处于异常状态的次数查询所述多组第一对应关系，确定对应的第一次数范围，以及所述第一次数范围对应的第一权重系数；

重复上述操作，直至确定所述至少一个属性参数对应的权重系数。

9.根据权利要求7所述的终端，其特征在于，

所述确定模块，还用于预先配置多组第二对应关系；所述第二对应关系包括运行状态评价值范围对应的运行状态；

计算预设初始值与所述至少一个属性参数对应的权重系数的乘积，将所述乘积获得的数值作为第一运行状态评价值；

基于所述第一运行状态评价值查询所述多组第二对应关系，获得所述第一运行状态评价值对应的第一运行状态。

10.根据权利要求7所述的终端，其特征在于，

所述判断模块，还用于判断所述第一参数表征的ANR事件是否发生；当所述第一参数表征ANR事件发生时，获得的判断结果为所述第一参数处于异常状态；

和/或，判断所述第二参数表征的CPU使用率是否达到第一阈值；当所述第二参数表征CPU使用率达到第一阈值时，获得的判断结果为所述第二参数处于异常状态；

和/或，判断所述第三参数表征的应用进程重启事件是否发生；当所述第三参数表征应用进程重启事件发生时，获得的判断结果为所述第三参数处于异常状态；

和/或，判断所述第四参数表征的内存剩余量是否小于第二阈值；当所述第四参数表征内存剩余量小于第二阈值时，获得的判断结果为所述第四参数处于异常状态。

11.根据权利要求9所述的终端，其特征在于，当所述至少一个属性参数包括：表征应用程序无响应ANR的第一参数、表征中央处理器CPU的使用率的第二参数以及表征应用进程重启的第三参数，且所述第一时间范围内所述第三参数处于异常状态的次数不为零时，

所述确定模块，还用于计算预设初始值、所述第一参数对应的权重系数、所述第二参数对应的权重系数和所述第三参数对应的权重系数之间的乘积，将所述乘积获得的数值作为第一运行状态评价值。

12.根据权利要求9所述的终端，其特征在于，当所述至少一个属性参数包括：表征应用程序无响应ANR的第一参数、表征中央处理器CPU的使用率的第二参数、表征应用进程重启的第三参数以及表征内存剩余量的第四参数，且所述第一时间范围内所述第三参数处于异常状态的次数为零时，

所述确定模块，还用于计算预设初始值、所述第一参数对应的权重系数、所述第二参数对应的权重系数、所述第三参数对应的权重系数和所述第四参数对应的权重系数之间的乘积，将所述乘积获得的数值作为第一运行状态评价值。