一种智能设备设备频繁网络请求的监控系统及方法与流程

本发明涉及网络通讯，特别涉及一种智能设备设备频繁网络请求的监控系统及方法。

背景技术：

随着电话手表越来越受欢迎功能越来越丰富，手表里面不但是只有内置的应用，还引入了大量的第三方应用。由于引入的第三方应用的策略不同，很多应用会在后台保活，或者是拥有自己的心跳。从而导致手表未在使用的情况下由于很多后台网络请求导致很快就把电耗完，对电话手表的续航有很大的影响同时很影响产品的口碑。

目前没有办法对这类型应用进行监控，常规的手段是客户投诉耗电快，再通过特定的方法获取问题机器的日志进行功耗分析，由于网络请求很少有日志打印信息很难分析定位到是哪个应用频繁触发网络请求，需要抓包才能发现这类型应用不但效率低下而且分析定位问题比较困难、问题解决的周期长、而且比较被动。目前有的做法是通过后台强制关闭掉应用的方式，由于后台保活的机制五花八门没办法完全杜绝掉，同时有很多应用有自动拉起或者守护进程即便系统强制关闭掉应用还是会通过特殊途径自动拉起导致频繁强制关闭掉重启的现象。另外还有通过监控应用消耗流量，但是这类型应用每次触发rrc并不会发送很多数据导致流量监控的方法无法识别出这类型应用，即对该类应用频繁网络请求导致耗电无法进行预警和监控。

技术实现要素：

为解决上述技术问题，本发明提供一种智能设备设备频繁网络请求的监控系统及方法，其具体的解决方案如下：

一方面提供一种智能设备设备频繁网络请求的监控系统，包括：

rcc统计模块，用于当每次rrc释放时，统计本次rcc中触发网络请求的应用，并产生rrc统计结果；

数据统计模块，用于将在本次rcc中触发网络请求的应用的累计网络请求次数加一；

问题应用输出模块，用于当任一应用的累计网络请求次数大于预设最大请求次数且所述应用的异常网络请求次数大于预设最大异常次数时，将所述应用标记为问题应用，将所述问题应用及其网络请求数据推送给指定的外部设备。

在本技术方案中，通过对于应用的网络请求次数的分析，然后寻找到在网络请求上耗电异常的问题应用，然后告知问题应用的开发者去对该问题应用进行处理与修复，从而克服了原有技术存在着的效率低下而且分析定位问题比较困难的技术问题，提高了对在网络请求上耗电异常的问题应用的寻找速度，进而减少电力消耗。

优选地，所述问题应用输出模块部署在云端；

还包括区间生成模块，用于周期性的将全部所述应用的累计网络请求次数传输到所述云端，并重置全部所述累计网络请求次数为零。

在本技术方案中，通过周期性的进行数据的上传，同时进行数据清理以及累计网络请求次数的归零，从而极大的减少了每一次上传的数据量，并且实现了及时的无用数据的处理，减少了数据存储所消耗的资源。

进一步优选地，所述区间数据上传模块的周期为一天。

优选地，问题应用报告生成模块，用于根据所述问题应用的网络请求数据生成所述问题应用的分析报告，并将所述分析报告推送给指定的外部设备。

优选地，还包括网络请求分布报告模块，用于根据全部所述应用的网络请求数据，生成网络请求分布报告，并将所述分析报告推送给指定的外部设备。

另一方面，本发明提供一种智能设备设备频繁网络请求的监控方法，包括：

当每次rrc释放时，统计本次rcc中触发网络请求的应用，并产生rrc统计结果；

根据所述rrc统计结果，将在本次rcc中触发网络请求的应用的累计网络请求次数加一；

当任一应用的累计网络请求次数大于预设最大请求次数且所述应用的异常网络请求次数大于预设最大异常次数时，将所述应用标记为问题应用，将所述问题应用及其网络请求数据推送给指定的外部设备。

在本技术方案中，通过对于应用的网络请求次数的分析，然后寻找到在网络请求上耗电异常的问题应用，然后告知问题应用的开发者去对该问题应用进行处理与修复，从而克服了原有技术存在着的效率低下而且分析定位问题比较困难的技术问题，提高了对在网络请求上耗电异常的问题应用的寻找速度。

优选地，所述将在本次rcc中触发网络请求的应用的累计网络请求次数加一后包括：

当到达指定周期点时，将全部所述应用的累计网络请求次数传输到云端，并重置全部所述累计网络请求次数为零。

在本技术方案中，通过周期性的进行数据的上传，同时进行数据清理以及累计网络请求次数的归零，从而极大的减少了每一次上传的数据量，并且实现了及时的无用数据的处理，减少了数据存储所消耗的资源。

进一步优选地，所述区间数据上传模块的周期为一天。

优选地，还包括：根据所述问题应用的网络请求数据生成所述问题应用的分析报告，并将所述分析报告推送给指定的外部设备。

优选地，还包括：根据全部所述应用的网络请求数据，生成网络请求分布报告，并将所述分析报告推送给指定的外部设备。

本发明至少包括以下一项技术效果：

(1)通过对于应用的网络请求次数的分析，然后寻找到在网络请求上耗电异常的问题应用，然后告知问题应用的开发者去对该问题应用进行处理与修复，从而克服了原有技术存在着的效率低下而且分析定位问题比较困难的技术问题，提高了对在网络请求上耗电异常的问题应用的寻找速度。

(2)通过周期性的进行数据的上传，同时进行数据清理以及累计网络请求次数的归零，从而极大的减少了每一次上传的数据量，并且实现了及时的无用数据的处理，减少了数据存储所消耗的资源。

附图说明

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

图1为本发明实施例1的结构示意图；

图2为本发明实施例2的结构示意图；

图3为本发明实施例3的结构示意图；

图4为本发明实施例4的结构示意图；

图5为本发明实施例5的结构示意图；

图6为本发明实施例6的结构示意图；

图7为本发明实施例7的结构示意图。

具体实施方式

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

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

为使图面简洁，各图中只示意性地表示出了与本发明相关的部分，它们并不代表其作为产品的实际结构。另外，以使图面简洁便于理解，在有些图中具有相同结构或功能的部件，仅示意性地绘出了其中的一个，或仅标出了其中的一个。在本文中，“一个”不仅表示“仅此一个”，也可以表示“多于一个”的情形。

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

另外，在本申请的描述中，术语“第一”、“第二”等仅用于区分描述，而不能理解为指示或暗示相对重要性。

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对照附图说明本发明的具体实施方式。显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图，并获得其他的实施方式。

实施例1：

如图1所示，本实施例提供一种智能设备设备频繁网络请求的监控系统，包括：

rcc统计模块(1)，用于当每次rrc释放时，统计本次rcc中触发网络请求的应用，并产生rrc统计结果；

数据统计模块(2)，用于将在本次rcc中触发网络请求的应用的累计网络请求次数加一；

问题应用输出模块(3)，用于当任一应用的累计网络请求次数大于预设最大请求次数且所述应用的异常网络请求次数大于预设最大异常次数时，将所述应用标记为问题应用，将所述问题应用及其网络请求数据推送给指定的外部设备(6)。

在传统技术中，由于网络请求很少有日志打印信息很难分析定位到是哪个应用频繁触发网络请求，需要抓包才能发现这类型应用不但效率低下而且分析定位问题比较困难、问题解决的周期长、而且比较被动，即便是通过后台强制关闭掉应用的方式，由于后台保活的机制五花八门没办法完全杜绝掉，同时有很多应用有自动拉起或者守护进程即便系统强制关闭掉应用还是会通过特殊途径自动拉起导致频繁强制关闭掉重启的现象，而如果是监控应用消耗流量，但是存在一种类型应用每次触发rrc并不会发送很多数据导致流量监控的方法无法识别出这类型应用，即对该类应用频繁网络请求导致的耗电无法进行预警和监控。

故在本实施例中，并不进行流量的监控，而是转而监控累计的rrc中的网络请求的次数，具体而言，监控每一次rrc释放时，在该次rrc中进行网络请求的应用，譬如说本次rrc过程中，涉及到有a、b、c三个应用，a、b、c三个的应用的累计网络请求次数分别为998、999、1000，说明a、b、c分别在过去的rrc过程中，分别进行了998、999、1000次的网络请求，进行了网络请求，然后由于a、b、c三个应用都进行了，将a、b、c三个应用的累计网络请求次数分别加1，表明了在本次rrc连接中，a、b、c三个应用都进行了网络请求，故其累计网络请求次数现在分别为999、1000、1001，假设最大请求次数为1000，最大异常次数为100，现在由于c的累计网络请求次数大于了1000，且其中异常网络请求次数的次数大于100，也就是说c应用被判定为问题应用，应当对c应用进行优化处理，故会将c应用传输给指定的设备，也就是开发者的设备，告知开发者“你的这个应用频繁进行网络请求，应当进行优化”，然后再由开发者对这个应用进行分析，并进行优化修复。

本实施例通过对于应用的网络请求次数的分析，然后寻找到在网络请求上耗电异常的问题应用，然后告知问题应用的开发者去对该问题应用进行处理与修复，从而克服了原有技术存在着的效率低下而且分析定位问题比较困难的技术问题，提高了对在网络请求上耗电异常的问题应用的寻找速度。

实施例2：

如图2所示，本实施例基于实施例1，提供一种智能设备设备频繁网络请求的监控系统，所述问题应用输出模块部署在云端；

还包括区间生成模块(4)，用于周期性的将全部所述应用的累计网络请求次数传输到所述云端，并重置全部所述累计网络请求次数为零。

由于每一次都从这个应用开始使用到终止使用的rrc中请求网络的次数，一方面比较繁琐，另一方面也不适合于数据分析与处理，故在本实施例中，采取周期性的方法进行，也就是说周期性的进行数据的上传，同时进行数据清理以及累计网络请求次数的归零，进一步讲，也就是每一次上传的数据，仅有关于这个周期内的数据，从而极大的减少了工作量。

同时，进一步优选地，所述区间数据上传模块的周期为一天。

在本实施例中，每天定时定点每个应用的网络请求的量进行获取，一般是每天的7点，获取到从前一天7点到今天的7点的所有的应用的网络请求的量，从应用本身的更新以及运行周期来看，一天的周期正好可以体现出一个应用的运行的过程，可以有效地采集到其关于网络请求的运行情况，同时，在智能设备第一次开机的时候，也要进行一次数据上传。

本实施例通过周期性的进行数据的上传，同时进行数据清理以及累计网络请求次数的归零，从而极大的减少了每一次上传的数据量，并且实现了及时的无用数据的处理，减少了数据存储所消耗的资源。

实施例3：

如图3所示，本实施例基于实施例1，问题应用报告生成模块(5)，用于根据所述问题应用的网络请求数据生成所述问题应用的分析报告，并将所述分析报告推送给指定的外部设备(6)。

由于在实际的应用过程中，简简单单告诉开发人员“你的这个应用有问题”等于什么都没有告诉开发人员，故在本实施例中，不仅仅要告诉开发人员“你的这个应用有问题”还要告诉开发人员“你的这个应用有什么问题”，故在实际的应用过程中，针对问题应用的网络请求数据进行分析，以生成相应的分析报告并将相应的分析报告发送给开发人员，从而告知开发人员这个应用有什么样的问题。

优选地，还包括网络请求分布报告模块，用于根据全部所述应用的网络请求数据，生成网络请求分布报告，并将所述分析报告推送给指定的外部设备(6)。

在本优选的实施例中，不仅仅要告诉开发人员“你的这个应用有什么问题”，还要告诉开发人员，正常的情况或者说是现在大家的平均水平是什么样的，从而对开发者的优化活动起到指导意义。

实施例4：

如图4所示，本实施例提供一种智能设备设备频繁网络请求的监控方法，包括：

s1：当每次rrc释放时，统计本次rcc中触发网络请求的应用，并产生rrc统计结果；

s2：将在本次rcc中触发网络请求的应用的累计网络请求次数加一；

s4：当任一应用的累计网络请求次数大于预设最大请求次数且所述应用的异常网络请求次数大于预设最大异常次数时，将所述应用标记为问题应用；

s6：将所述问题应用及其网络请求数据推送给指定的外部设备。

在传统技术中，由于网络请求很少有日志打印信息很难分析定位到是哪个应用频繁触发网络请求，需要抓包才能发现这类型应用不但效率低下而且分析定位问题比较困难、问题解决的周期长、而且比较被动，即便是通过后台强制关闭掉应用的方式，由于后台保活的机制五花八门没办法完全杜绝掉，同时有很多应用有自动拉起或者守护进程即便系统强制关闭掉应用还是会通过特殊途径自动拉起导致频繁强制关闭掉重启的现象，而如果是监控应用消耗流量，但是存在一种类型应用每次触发rrc并不会发送很多数据导致流量监控的方法无法识别出这类型应用，即对该类应用频繁网络请求导致的耗电无法进行预警和监控。

故在本实施例中，并不进行流量的监控，而是转而监控累计的rrc中的网络请求的次数，具体而言，监控每一次rrc释放时，在该次rrc中进行网络请求的应用，譬如说本次rrc过程中，涉及到有a、b、c三个应用，a、b、c三个的应用的累计网络请求次数分别为998、999、1000，说明a、b、c分别在过去的rrc过程中，分别进行了998、999、1000次的网络请求，进行了网络请求，然后由于a、b、c三个应用都进行了，将a、b、c三个应用的累计网络请求次数分别加1，表明了在本次rrc连接中，a、b、c三个应用都进行了网络请求，故其累计网络请求次数现在分别为999、1000、1001，假设最大请求次数为1000，最大异常次数为100，现在由于c的累计网络请求次数大于了1000，且其中异常网络请求次数大于100，也就是说c应用被判定为问题应用，应当对c应用进行优化处理，故会将c应用传输给指定的设备，也就是开发者的设备，告知开发者“你的这个应用频繁进行网络请求，应当进行优化”，然后再由开发者对这个应用进行分析，并进行优化修复。

本实施例通过对于应用的网络请求次数的分析，然后寻找到在网络请求上耗电异常的问题应用，然后告知问题应用的开发者去对该问题应用进行处理与修复，从而克服了原有技术存在着的效率低下而且分析定位问题比较困难的技术问题，提高了对在网络请求上耗电异常的问题应用的寻找速度。

实施例5：

如图5所示，本实施例提供一种智能设备设备频繁网络请求的监控方法，包括：

s1：当每次rrc释放时，统计本次rcc中触发网络请求的应用，并产生rrc统计结果；

s2：将在本次rcc中触发网络请求的应用的累计网络请求次数加一；

s3：当到达指定周期点时，将全部所述应用的累计网络请求次数传输到云端，并重置全部所述累计网络请求次数为零。

s4：当任一应用的累计网络请求次数大于预设最大请求次数且所述应用的异常网络请求次数大于预设最大异常次数时，将所述应用标记为问题应用；

s6：将所述问题应用及其网络请求数据推送给指定的外部设备。

由于每一次都从这个应用开始使用到终止使用的rrc中请求网络的次数，一方面比较繁琐，另一方面也不适合于数据分析与处理，故在本实施例中，采取周期性的方法进行，也就是说周期性的进行数据的上传，同时进行数据清理以及累计网络请求次数的归零，进一步讲，也就是每一次上传的数据，仅有关于这个周期内的数据，从而极大的减少了工作量。

同时，进一步优选地，所述区间数据上传模块的周期为一天。

在本实施例中，每天定时定点每个应用的网络请求的量进行获取，一般是每天的7点，获取到从前一天7点到今天的7点的所有的应用的网络请求的量，从应用本身的更新以及运行周期来看，一天的周期正好可以体现出一个应用的运行的过程，可以有效地采集到其关于网络请求的运行情况，同时，在智能设备第一次开机的时候，也要进行一次数据上传。

本实施例通过周期性的进行数据的上传，同时进行数据清理以及累计网络请求次数的归零，从而极大的减少了每一次上传的数据量，并且实现了及时的无用数据的处理，减少了数据存储所消耗的资源。

实施例6：

如图6所示，本实施例提供一种智能设备设备频繁网络请求的监控方法，包括：

s1：当每次rrc释放时，统计本次rcc中触发网络请求的应用，并产生rrc统计结果；

s2：将在本次rcc中触发网络请求的应用的累计网络请求次数加一；

s3：当到达指定周期点时，将全部所述应用的累计网络请求次数传输到云端，并重置全部所述累计网络请求次数为零；所述区间数据上传模块的周期为一天。

s4：当任一应用的累计网络请求次数大于预设最大请求次数且所述应用的异常网络请求次数大于预设最大异常次数时，将所述应用标记为问题应用；

s5：根据所述问题应用的网络请求数据生成所述问题应用的分析报告，并将所述分析报告推送给指定的外部设备。

s6：将所述问题应用及其网络请求数据推送给指定的外部设备。

由于在实际的应用过程中，简简单单告诉开发人员“你的这个应用有问题”等于什么都没有告诉开发人员，故在本实施例中，不仅仅要告诉开发人员“你的这个应用有问题”还要告诉开发人员“你的这个应用有什么问题”，故在实际的应用过程中，针对问题应用的网络请求数据进行分析，以生成相应的分析报告并将相应的分析报告发送给开发人员，从而告知开发人员这个应用有什么样的问题。

优选地，还包括s7：根据全部所述应用的网络请求数据，生成网络请求分布报告，并将所述分析报告推送给指定的外部设备。

在本优选的实施例中，不仅仅要告诉开发人员“你的这个应用有什么问题”，还要告诉开发人员，正常的情况或者说是现在大家的平均水平是什么样的，从而对开发者的优化活动起到指导意义。

实施例7：

如图7所示，本实施例提供一种智能设备设备频繁网络请求的监控方法，包括：

s1：每次rrc释放的时候获取该次rrc里面有多少个应用触发了网络请求并统计应用网络请求的累加次数并写入数据库。

s2:第二天早上7点或者是第二天第一次开机，检测昨天收集的应用网络请求数据是否上传服务器如果没有先上传服务器然后清空数据。重新统计应用网络请求次数。

s3:服务器后台根据策略对每台设备的应用当天网络请求次数进行判断大于预设值，如1000，的标志为频繁网络请求异常，同时该应用当天被标志为异常网络请求次数的数量大于预设值，如该应用当天激活量的百分之十，则该应用存在网络请求异常的行为并生成预警报告推送给开发人员，同时根据网络请求次数对应用进行排序然后生成各个应用的网络请求次数分布报告推送给开发人员。

s4开发人员收到频繁网络请求预警推送后开始介入进行问题分析、修复、优化等。开发人员收到网络请求次数分布报告推送后，分析报告是否还有网络请求次数优化的应用，然后做出相应的策略调整。

故在本实施例中，并不进行流量的监控，而是转而监控累计的rrc中的网络请求的次数，具体而言，监控每一次rrc释放时，在该次rrc中进行网络请求的应用，譬如说本次rrc过程中，涉及到有a、b、c三个应用，a、b、c三个的应用的累计网络请求次数分别为998、999、1000，说明a、b、c分别在过去的rrc过程中，分别进行了998、999、1000次的网络请求，进行了网络请求，然后由于a、b、c三个应用都进行了，将a、b、c三个应用的累计网络请求次数分别加1，表明了在本次rrc连接中，a、b、c三个应用都进行了网络请求，故其累计网络请求次数现在分别为999、1000、1001，假设最大请求次数为1000，最大异常次数为100，现在由于c的累计网络请求次数大于了1000，且其中异常网络请求次数的次数大于100，也就是说c应用被判定为问题应用，应当对c应用进行优化处理，然后到了一天的7点，会将c应用及其相关数据传输给指定的设备，也就是开发者的设备，告知开发者“你的这个应用频繁进行网络请求，应当进行优化”，然后再由开发者对这个应用进行分析，并进行优化修复。

最后通过两个报告，不仅仅要告诉开发人员“你的这个应用有问题”，并且告诉开发人员“你的这个应用有什么问题”，还要告诉开发人员，正常的情况或者说是现在大家的平均水平是什么样的，从而对开发者的优化活动起到指导意义。

本实施例通过每次在rrc释放的时候获取该次rrc里面有多少个应用触发了网络请求的方法来统计每天有多少个应用触发了网络请求分别触发了多少次的方式来监控各个应用的网络请求次数。降低分析的难度、降低人力成本、缩短问题修复的周期、特别是针对较大用户基数的产品尤为显著。将统计的网络请求次数，数据信息插入数据库。每天早上7点或者第一次开机的时候，再网络可用的情况下将数据上报服务器后台，避免数据丢失。后台服务器根据收集每台设备各个应用网络请求次数进行判断大于预设值(如1000)标志为频繁网络请求，并且判断该应用当天被标志为异常网络请求次数的数量是否大于预设值(如该应用当天活跃量的百分之十)生成应用频繁网络请求报告并推送给开发人员的方式来对应用频繁网络请求进行预警。提升功耗问题分析的效率和缩短问题解决周期、避免出现大规模耗电现象从而影响产品的口碑和用户体验。后台服务根据网络请求次数排序生成应用网络请求次数分布报告，来对网络请求进程监控。便于对应用网络请求次数的优化从而达到省电提升产品续航能力进而提升产品质量提高用户体验。

本发明通过前述实施例，实现了：

(1)通过对于应用的网络请求次数的分析，然后寻找到在网络请求上耗电异常的问题应用，然后告知问题应用的开发者去对该问题应用进行处理与修复，从而克服了原有技术存在着的效率低下而且分析定位问题比较困难的技术问题，提高了对在网络请求上耗电异常的问题应用的寻找速度。

(2)通过周期性的进行数据的上传，同时进行数据清理以及累计网络请求次数的归零，从而极大的减少了每一次上传的数据量，并且实现了及时的无用数据的处理，减少了数据存储所消耗的资源。

尽管已描述了本发明的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例作出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本发明范围的所有变更和修改。

显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。