应用流量监测方法、装置及Android设备与流程

文档序号:14993376发布日期:2018-07-20 22:58阅读:189来源:国知局

本发明涉及数据监测技术领域,特别是涉及一种应用流量监测方法、装置及android设备。



背景技术:

随着通信技术的快速发展,android设备可选择的通信方式越来越多,如wifi、2g、3g和4g等通信方式。尽管现在wifi的覆盖范围越来越广,用户的移动流量套餐当中可支配的流量越来越多,但在android设备中各个应用程序的流量使用状况仍然是用户很关注的问题。

在目前的android设备中,对android设备中各个应用程序的流量监测方式有:1、通过android设备中的android.net.trafficstats类能够获取该android设备的数据流量和总的网络流量消耗(一般情况下得到wi-fi下的流量信息);2、通过android设备中的networkstatsmanager类获取访问权限来实现了对该android设备的流量使用统计。

在实现过程中,发明人发现传统技术中至少存在如下问题:传统的对android设备的应用流量监测,无法明确android设备上的各个应用的流量统计情况,对应用流量监测效率低。



技术实现要素:

基于此,有必要针对传统的技术方案中对应用流量监测效率低的问题,本发明提供了一种针对应用流量监测方法、装置及android设备。

为了实现上述目的,一方面,本发明实施例提供了一种应用流量监测方法,包括以下步骤:

监测程序在启动且未查询到待测设备的通知时,获取包含待测设备中各应用程序的应用信息的应用列表;

监测程序通过广播监听待测设备的当前网络制式;

在监听到当前网络制式在预设时间段内产生跳变时,获取各应用程序在跳变时刻的第一当前网络消耗流量,并根据第一当前网络消耗流量更新应用列表中对应的应用信息;

在监听到当前网络制式在预设时间段内未发生跳变时,获取各应用程序在预设时间段内的第二当前网络消耗流量,并根据第二当前网络消耗流量更新应用列表中对应的应用信息。

在其中一个实施例中,监测程序为嵌入sdk的应用程序;

还包括步骤:

嵌入sdk的应用程序在启动且查询到通知时,按照预设周期,查询待测设备,直至未查询到通知;

嵌入sdk的应用程序在启动且未查询到通知时,生成新的通知。

在其中一个实施例中,还包括步骤:

嵌入sdk的应用程序依次筛选各应用程序;

并在筛选出的应用程序的程序属性为系统应用程序时,删除系统应用程序在应用列表中对应的应用信息。

在其中一个实施例中,还包括步骤:

嵌入sdk的应用程序获取各应用程序的网速数据,并根据网速数据更新应用列表中对应的应用信息。

在其中一个实施例中,嵌入sdk的应用程序获取各应用程序的网速数据,并根据网速数据更新应用列表中对应的应用信息的步骤之前包括步骤:

嵌入sdk的应用程序在网速采集阈值范围内,随机生成当前采集次数和当前采集周期;并根据采集次数和当前采集周期,依次获取各应用程序的网速数据。

在其中一个实施例中,网速数据包括上传网速和下载网速。

另一方面,本发明实施例还提供了一种应用流量监测装置,包括:

应用信息获取单元,用于监测程序在启动且未查询到待测设备的通知时,获取包含待测设备中各应用程序的应用信息的应用列表;

广播监听单元,用于监测程序通过广播监听待测设备的当前网络制式;

第一流量获取单元,用于在监听到当前网络制式在预设时间段内产生跳变时,获取各应用程序在跳变时刻的第一当前网络消耗流量,并根据第一当前网络消耗流量更新应用列表中对应的应用信息;

第二流量获取单元,用于在监听到当前网络制式在预设时间段内未发生跳变时,获取各应用程序在预设时间段内的第二当前网络消耗流量,并根据第二当前网络消耗流量更新应用列表中对应的应用信息。

在其中一个实施例中,还包括:

应用程序筛选单元,用于嵌入sdk的应用程序依次筛选各应用程序;

应用信息删除单元,用于筛选出的应用程序的程序属性为系统应用程序时,删除系统应用程序在应用列表中对应的应用信息。

另一方面,本发明实施例还提供了一种andriod设备,包括存储器和处理器,存储器存储有计算机程序,处理器执行计算机程序时实现以下步骤:

监测程序在启动且未查询到待测设备的通知时,获取包含待测设备中各应用程序的应用信息的应用列表;

监测程序通过广播监听待测设备的当前网络制式;

在监听到当前网络制式在预设时间段内产生跳变时,获取各应用程序在跳变时刻的第一当前网络消耗流量,并根据第一当前网络消耗流量更新应用列表中对应的应用信息;

在监听到当前网络制式在预设时间段内未发生跳变时,获取各应用程序在预设时间段内的第二当前网络消耗流量,并根据第二当前网络消耗流量更新应用列表中对应的应用信息。

另一方面,本发明实施例还提供了一种计算机可读存储介质,其上存储有计算机程序,计算机程序被处理器执行时实现以下步骤:

监测程序在启动且未查询到待测设备的通知时,获取包含待测设备中各应用程序的应用信息的应用列表;

监测程序通过广播监听待测设备的当前网络制式;

在监听到当前网络制式在预设时间段内产生跳变时,获取各应用程序在跳变时刻的第一当前网络消耗流量,并根据第一当前网络消耗流量更新应用列表中对应的应用信息;

在监听到当前网络制式在预设时间段内未发生跳变时,获取各应用程序在预设时间段内的第二当前网络消耗流量,并根据第二当前网络消耗流量更新应用列表中对应的应用信息。

上述技术方案中的一个技术方案具有如下优点和有益效果:

监测程序在启动且未查询到待测设备的通知时,获取包含待测设备中各应用程序的应用信息的应用列表,实现了同一待测设备上多个监测程序同时运行时,轮询分配优先采集权,避免了重复采集数据。监测程序通过广播监听待测设备的当前网络制式;根据监听结果,若当前网络制式在预设时间段内产生跳变,获取各应用程序在跳变时刻的第一当前网络消耗流量;若当前网络制式在预设时间段内未产生跳变,获取各应用程序在预设时间段内的第二当前网络消耗流量,并将各第一当前网络消耗流量和各第二当前网络消耗流量更新在应用列表中对应的应用信息,从而实现在不需要额外的访问权限下,可直接得到待测设备上的各个应用程序在不同网络制式下的流量统计情况,提高了对应用流量监测的效率。

附图说明

图1为一个实施例中应用流量监测方法的应用环境图;

图2为一个实施例中应用流量监测方法的流程示意图;

图3为一个实施例中通知查询步骤的流程示意图;

图4为一个实施例中程序筛选步骤的流程示意图;

图5为另一个实施例中应用流量监测方法的流程示意图;

图6为一个实施例中通知查询步骤的流程结构图;

图7为一个实施例中流量采集步骤的流程结构图;

图8为一个实施例中网速采集步骤的流程结构图;

图9为一个实施例中应用流量监测装置的结构框图;

图10为一个实施例中应用流量监测装置的程序筛选结构框图;

图11为一个实施例中android设备的内部结构图。

具体实施方式

为了便于理解本发明,下面将参照相关附图对本发明进行更全面的描述。附图中给出了本发明的首选实施例。但是,本发明可以以许多不同的形式来实现,并不限于本文所描述的实施例。相反地,提供这些实施例的目的是使对本发明的公开内容更加透彻全面。

除非另有定义,本文所使用的所有的技术和科学术语与属于本发明的技术领域的技术人员通常理解的含义相同。本文中在本发明的说明书中所使用的术语只是为了描述具体的实施例的目的,不是旨在于限制本发明。本文所使用的术语“及/或”包括一个或多个相关的所列项目的任意的和所有的组合。

本申请提供的无线通信的干扰感知方法,可以应用于如图1所示的应用环境中。其中,终端102可包括若干个应用程序,若干个应用程序中可包括至少一个监测程序。终端102中的监测程序在启动且未查询到待测设备的通知时,获取包含终端102中各应用程序的应用信息的应用列表;监测程序通过广播监听终端102的当前网络制式;在监听到当前网络制式在预设时间段内产生跳变时,获取各应用程序在跳变时刻的第一当前网络消耗流量,并根据第一当前网络消耗流量更新应用列表中对应的应用信息;在监听到当前网络制式在预设时间段内未发生跳变时,获取各应用程序在预设时间段内的第二当前网络消耗流量,并根据第二当前网络消耗流量更新应用列表中对应的应用信息。其中,终端102可以但不限于是各种个人计算机、笔记本电脑、智能手机、平板电脑和便携式可穿戴设备。

传统的对终端102中的各应用程序进行流量监测,通常是通过android.net.trafficstats类实现对终端的应用流量监测无法获取应用在不同网络类型中的流量消耗数据,且无法获取某个时间段内的流量消耗数据;而通过networkstatsmanager类实现对终端的应用流量监测需要额外的访问权限,无法直接得到android设备上的各个应用的流量统计情况,降低了对应用流量监测效率。

而本发明实施例提供的一种应用流量监测方法可实现在不需要额外的访问权限下,可直接得到终端102上的各个应用程序在不同网络制式下的流量统计情况,提高了对应用流量监测的效率。

在一个实施例中,如图2所示,提供了一种应用流量监测方法,以该方法应用于图1中的终端为例进行说明,包括以下步骤:

步骤s210,监测程序在启动且未查询到待测设备的通知时,获取包含待测设备中各应用程序的应用信息的应用列表。

其中,待测设备可以是具有操作系统且安装有若干个应用程序的终端。应用程序指的是指安装在待测设备上的软件,完善原始系统的不足与个性化。通知可以是告知当前待测设备上是否有监测程序开启监测功能的信息。待测设备的各应用程序可包含至少一个监测程序,监测程序可以是具有监测功能的应用程序。应用列表可以是包含各个应用程序的应用信息的数据表。应用信息可包括应用程序的报名、应用名和初始流量信息等。

优选的,监测程序的启动可以是第一次启动,也可以是从关闭到再次打开的重新启动。

具体地,待测设备上的监测程序启动,在未查询到待测设备上有通知时,开启监测程序的监测功能,通过监测程序获取包含待测设备中各应用程序的应用信息的应用列表。其中获取的各应用程序的应用信息包括该监测程序的应用信息。通过获取待测设备中各应用程序的应用信息的应用列表,从而快速建立包含各个应用程序应用信息的数据表,可便携的添加监测到数据,可直观的观察应用列表中各个应用程序的监测数据变化情况。

步骤s220,监测程序通过广播监听待测设备的当前网络制式。

其中,网络制式指的是网络的类型。待测设备的当前网络制式可包括但不限于:1g(firstgeneration:第一代移动通讯技术)、2g(secondgeneration:第二代移动通讯技术)、3g(3rd-generation:第三代移动通信技术)、4g(the4thgenerationmobilecommunicationtechnology:第四代移动通信技术)和wifi(wireless-fidelity:无线保真)。

具体地,监测程序可注册广播,通过广播来监听待测设备的当前网络制式,可选的注册广播的方式可以是静态注册广播,也可以是动态注册广播。

步骤s230,在监听到当前网络制式在预设时间段内产生跳变时,获取各应用程序在跳变时刻的第一当前网络消耗流量,并根据第一当前网络消耗流量更新应用列表中对应的应用信息。

其中,流量指的是上网产生的流量数据,打开软件或进行互联网操作时,会和服务器之间交换数据,流量就是指这数据的大小;流量的单位是采取1024进制的,单位有gb(千兆字节)、mb(兆字节)、kb(千字节)、b(字节)。第一当前网络消耗流量可以是在网络制式发生跳变时,获取到的应用程序的消耗流量数据。优选的,第一当前网络消耗流量可包括上传流量和下载流量。

具体地,在监听到当前网络制式在预设时间段内产生跳变时,例如在预设时间段内,当前网络制式为2g网络,在跳变时刻,当前网络制式变为4g网络,则在网络制式跳变时刻,获取各个应用程序在2g网络下的第一当前网络消耗流量。并将第一当前网络消耗流量更新到应用列表中对应的应用信息。从而快速得到各个应用程序在不同网络制式下的消耗流量数据。

步骤s240,在监听到当前网络制式在预设时间段内未发生跳变时,获取各应用程序在预设时间段内的第二当前网络消耗流量,并根据第二当前网络消耗流量更新应用列表中对应的应用信息。

其中,第二当前网络消耗流量可以是在预设时间段内未发生跳变时,获取到的应用程序的消耗流量数据。

具体地,在监听到当前网络制式在预设时间段内未发生跳变时,例如在预设时间段内,当前网络制式一直为2g网络,则获取各个应用程序在预设时间段内的第二当前网络消耗流量。并将第二当前网络消耗流量更新到应用列表中对应的应用信息。从而可减少消耗流量数据的丢失,提高流量监测的准确度。

需要说明的是,上述实施例中各步骤是有待测设备中的监测程序执行的。监测程序可以是具有监测功能的应用程序。优选的,待测设备可以是android设备;监测程序可以是嵌入sdk(softwaredevelopmentkit:软件开发工具包)的应用程序。

上述应用流量监测方法实施例中,监测程序在启动且未查询到待测设备的通知时,获取包含待测设备中各应用程序的应用信息的应用列表,实现了同一待测设备上多个监测程序同时运行时,轮询分配优先采集权,避免了重复采集数据。监测程序通过广播监听待测设备的当前网络制式;根据监听结果,获取各应用程序的第一当前网络消耗流量和各应用程序的第二当前网络消耗流量,并将各第一当前网络消耗流量和各第二当前网络消耗流量更新在应用列表中对应的应用信息,从而实现在不需要额外的访问权限下,可直接得到待测设备上的各个应用程序在不同网络制式下的流量统计情况,提高了对应用流量监测的效率。

在一个实施例中,监测程序为嵌入sdk的应用程序。如图3所示,通知查询步骤还包括:

步骤s310,嵌入sdk的应用程序在启动且查询到通知时,按照预设周期,查询待测设备,直至未查询到通知。

其中,嵌入sdk的应用程序除了可执行自身应用程序的功能外,还可以执行sdk的监测功能。预设周期可通过定时器而生成。

具体地,待测设备上的嵌入sdk的应用程序启动时,对待测设备上的通知进行查询,若查询到通知,表示有其他嵌入sdk的应用程序正在监测。每隔预设周期再对待测设备进行通知查询,直至未查询到通知,则开启该嵌入sdk的应用程序的监测功能。

步骤s320,嵌入sdk的应用程序在启动且未查询到通知时,生成新的通知。

具体地,嵌入sdk的应用程序未查询到通知,在开启该嵌入sdk的应用程序的监测功能,同时生成新的通知。通过该新的通知告知其他嵌入sdk的应用程序在启动且预开启sdk监测功能时,已有嵌入sdk的应用程序正在进行监测。

上述实施例中,在嵌入sdk的应用程序启动时,通过查询待测设备上是否有通知,确定嵌入sdk的应用程序的优先采集权,防止重复采集数据。

在一个实施例中,待测设备上有3个嵌入sdk的应用程序(第一应用程序、第二应用程序和第三应用程序),第一应用程序先启动,由于前面没有其他应用程序启动sdk监测功能,则第一应用程序就会开启这个sdk监测功能。若再启动第二应用程序或者第三应用程序,由于第一应用程序已经启动sdk监测功能,第二应用程序或者第三应用程序就不会启动该sdk监测功能,如此类推。第一应用程序启动了该sdk监测功能之后,就会发出一个通知,当第二应用程序启动的时候就会查询到该通知,得知第一应用程序已经启动sdk监测功能,就不启动该sdk监测功能(而第二应用程序的其他的功能正常运行)。从而避免了重复采集数据,提供了数据采集效率。

优选的,可通过service(服务)通信对通知进行查询。service通信可指的是两个嵌入sdk的应用程序之间的通信。

在一个实施例中,如图4所示,程序筛选步骤还包括:

步骤s410,嵌入sdk的应用程序依次筛选各应用程序。

具体地,待测设备上(如android设备)的各个应用程序包含第三方的应用程序和系统应用程序(如计算器应用程序和相机应用程序等),通常系统应用程序的运行不需要消耗流量。

步骤s420,并在筛选出的应用程序的程序属性为系统应用程序时,删除系统应用程序在应用列表中对应的应用信息。

具体地,嵌入sdk的应用程序对待测设备上的各应用程序进行筛选,若筛选出的应用程序的程序属性为系统应用程序时,删除系统应用程序在应用列表中对应的应用信息,从而可减少无用数据。

上述实施例中,通过筛选待测设备上的各应用程序,删除系统应用程序在应用列表中对应的应用信息,从而可减少无用数据,提高对应用流量的监测效率。

在一个实施例中,还包括步骤:嵌入sdk的应用程序获取各应用程序的网速数据,并根据网速数据更新应用列表中对应的应用信息。

其中,网速指的是单位时间内消耗的流量数据,一般单位为mb/s(兆字节每秒)或者kb/s(千字节每秒)。

具体地,嵌入sdk的应用程序可在每次采集消耗流量(第一当前网络消耗流量和第一当前网络消耗流量)数据时,获取各应用程序的网速数据,并根据网速数据更新应用列表中对应的应用信息。嵌入sdk的应用程序也可在预设网速采集周期到来时,获取各应用程序的网速数据,并根据网速数据更新应用列表中对应的应用信息。通过采集各应用程序的网速数据,可得到各个应用程序消耗流量更全面的数据。

在一个实施例中,嵌入sdk的应用程序获取各应用程序的网速数据,并根据网速数据更新应用列表中对应的应用信息的步骤之前包括步骤:

嵌入sdk的应用程序在网速采集阈值范围内,随机生成当前采集次数和当前采集周期;并根据采集次数和当前采集周期,依次获取各应用程序的网速数据。

具体地,网速采集阈值范围可由待测设备的定时器定时得到,在网速采集阈值范围内,可随机生成当前采集次数和当前采集周期。从而嵌入sdk的应用程序可根据采集次数和当前采集周期,依次获取各应用程序的网速数据。通过随机抽样的采集次数和当前采集周期实现了对每个消耗流量的应用程序的网速计算和采集,避免了实时采集网速引起的数据量太大的问题。

在一个实施例中,网速数据包括上传网速和下载网速。

在一个实施例中,如图5所示,为另一个实施例中应用流量监测方法的流程示意图,该方法包括以下步骤:

步骤s510,嵌入sdk的应用程序在启动且查询到通知时,按照预设周期,查询待测设备,直至未查询到通知。

步骤s520,嵌入sdk的应用程序在启动且未查询到通知时,生成新的通知;并获取包含待测设备中各应用程序的应用信息的应用列表。

步骤s530,嵌入sdk的应用程序通过广播监听待测设备的当前网络制式

步骤s540,在监听到当前网络制式在预设时间段内产生跳变时,获取各应用程序在跳变时刻的第一当前网络消耗流量,并根据第一当前网络消耗流量更新应用列表中对应的应用信息。

步骤s550,在监听到当前网络制式在预设时间段内未发生跳变时,获取各应用程序在预设时间段内的第二当前网络消耗流量,并根据第二当前网络消耗流量更新应用列表中对应的应用信息。

步骤s560,嵌入sdk的应用程序获取各应用程序的网速数据,并根据网速数据更新应用列表中对应的应用信息。

上述实施例中,在嵌入sdk的应用程序启动时,查询待测设备中是否存储有通知;若未查询到通知,获取待测设备上各应用程序的应用信息,将应用信息存储在应用列表;通过service查询通知,实现了同一待测设备上多个嵌入sdk的应用程序同时运行时,轮询分配优先采集权,避免了重复采集数据。通过广播监听待测设备的当前网络制式;根据监听结果,若当前网络制式在预设时间段内产生跳变,获取各应用程序的第一当前网络消耗流量;若当前网络制式在预设时间段内未产生跳变,获取各应用程序在预设时间段内的第二当前网络消耗流量,并将各第一当前网络消耗流量和各第二当前网络消耗流量更新在应用列表中对应应用信息的相应位置,从而实时在不需要额外的访问权限下,可直接得到待测设备上的各个应用程序在不同网络制式下的流量统计情况,提高了对应用流量监测的效率。嵌入sdk的应用程序通过获取各应用程序的网速数据,并根据网速数据更新应用列表中对应的应用信息。通过采集各应用程序的网速数据,可得到各个应用程序消耗流量更全面的数据。

在一个实施例中,如图6所示,为一个实施例中通知查询步骤的流程结构图。通知查询步骤的具体过程如下:

通过service(服务)启动socket((套接字:用于描述ip地址和端口,可以是通信链的句柄)去接收指令(通知),看是否有嵌入sdk的app(应用程序)已经在运行了;如果没有,则去通知设备上其他嵌入sdk的app,当前嵌入sdk的app在运行,并且开启嵌入sdk的app的流量及网速监测功能;如果有,则开始等待(开启轮询定时器),可每隔预设时间(如一分钟)又去询问一次,如此循环,直至接收到通知。

在一个实施例中,如图7所示,为一个实施例中流量采集步骤的流程结构图。流量采集步骤的具体过程如下:

嵌入sdk的app通过初始化获取应用列表,并注册广播监听网络变化。嵌入sdk的app第一次启动时,获取待测设备上各个app的包名、应用名、以及上传流量和下载流量等应用信息,并且筛选出第三方的app,丢弃系统应用,减少无用数据。在监听到网络发生变化,判断前后网络制式是否一致,若不一致,则前后两次总流量相减,得出前一次网络制式消耗了多少流量,并且统计了前一次网络制式的使用时间;若在预设时间段(如2分钟)没有发生网络制式变化,也会进行一次数据采集,可减少数据丢失。

在一个实施例中,如图8所示,为一个实施例中网速采集步骤的流程结构图。网速采集步骤的具体过程如下:

根据网速采集的阈值范围,每次随机抽取采集网速的时间和频率都不一样;不管app在前台还是后台,只要消耗了流量就采集获得上传网速和下载网速。例如,可根据产生的随机数,生成采集网速的时间和频率(如每隔1秒采集一次网速,共采集5次)。通过随机抽样实现了对每个消耗流量app的网速监测,避免了实时采集网速引起的数据量太大的问题。

上述实施例中,通过service通信查询通知,实现了同一设备上多个嵌入sdk的app同时在运行的时候通过客户端之间通信,轮询分配优先采集权,不重复采集数据。通过注册广播去监听网络变化,当出现2g、3g、4g和wifi等网络制式前后两次不一致的时候统计分制式的消耗流量数据。通过随机抽样采集时间和采集周期,实现了对每个消耗流量app的网速采集。

需要说明的是,上述各实施例中的嵌入sdk的应用程序监测待测设备上的各应用程序的消耗流量,主要是通过在sdk上使用不需要权限的trafficstats类的接口组合进行的。

应该理解的是,虽然图2-5的流程图中的各个步骤按照箭头的指示依次显示,但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明,这些步骤的执行并没有严格的顺序限制,这些步骤可以以其它的顺序执行。而且,图2-5中的至少一部分步骤可以包括多个子步骤或者多个阶段,这些子步骤或者阶段并不必然是在同一时刻执行完成,而是可以在不同的时刻执行,这些子步骤或者阶段的执行顺序也不必然是依次进行,而是可以与其它步骤或者其它步骤的子步骤或者阶段的至少一部分轮流或者交替地执行。

在一个实施例中,如图9所示,提供了一种应用流量监测装置,包括:应用信息获取单元910、广播监听单元920、第一流量获取单元930和第二流量获取单元940。其中:

应用信息获取单元910,用于监测程序在启动且未查询到待测设备的通知时,获取包含待测设备中各应用程序的应用信息的应用列表。

广播监听单元920,用于监测程序通过广播监听待测设备的当前网络制式。

第一流量获取单元930,用于在监听到当前网络制式在预设时间段内产生跳变时,获取各应用程序在跳变时刻的第一当前网络消耗流量,并根据第一当前网络消耗流量更新应用列表中对应的应用信息。

第二流量获取单元940,用于在监听到当前网络制式在预设时间段内未发生跳变时,获取各应用程序在预设时间段内的第二当前网络消耗流量,并根据第二当前网络消耗流量更新应用列表中对应的应用信息。

在一个实施例中,监测程序为嵌入sdk的应用程序;还包括:

轮询通知单元,用于嵌入sdk的应用程序在启动且查询到通知时,按照预设周期,查询待测设备,直至未查询到通知;

通知生成单元,用于嵌入sdk的应用程序在启动且未查询到通知时,生成新的通知。

在一个实施例中,如图10所示,为一个实施例中应用流量监测装置的程序筛选结构框图,还包括:

应用程序筛选单元912,用于嵌入sdk的应用程序依次筛选各应用程序。

应用信息删除单元914,用于筛选出的应用程序的程序属性为系统应用程序时,删除系统应用程序在应用列表中对应的应用信息。

在一个实施例中,还包括:

网速采集单元,用于嵌入sdk的应用程序获取各应用程序的网速数据,并根据网速数据更新应用列表中对应的应用信息。

关于应用流量监测装置的具体限定可以参见上文中对于应用流量监测方法的限定,在此不再赘述。上述应用流量监测装置中的各个模块可全部或部分通过软件、硬件及其组合来实现。上述各模块可以硬件形式内嵌于或独立于计算机设备中的处理器中,也可以以软件形式存储于计算机设备中的存储器中,以便于处理器调用执行以上各个模块对应的操作。

在一个实施例中,提供了一种android设备,该android设备可以是android手机、android平板和android可穿戴设备等,其内部结构图可以如图11所示。该android设备包括通过系统总线连接的处理器、存储器、网络接口、显示屏和输入装置。其中,该android设备的处理器用于提供计算和控制能力。该android设备的存储器包括非易失性存储介质、内存储器。该非易失性存储介质存储有操作系统和计算机程序。该内存储器为非易失性存储介质中的操作系统和计算机程序的运行提供环境。该android设备的网络接口用于与外部的终端通过网络连接通信。该计算机程序被处理器执行时以实现一种应用流量监测方法。该android设备的显示屏可以是液晶显示屏或者电子墨水显示屏,该android设备的输入装置可以是显示屏上覆盖的触摸层,也可以是android设备的外壳上设置的按键、轨迹球或触控板,还可以是外接的键盘、触控板或鼠标等。

本领域技术人员可以理解,图11中示出的结构,仅仅是与本申请方案相关的部分结构的框图,并不构成对本申请方案所应用于其上的android设备的限定,具体的android设备可以包括比图中所示更多或更少的部件,或者组合某些部件,或者具有不同的部件布置。

在一个实施例中,提供了一种android设备,包括存储器和处理器,存储器中存储有计算机程序,该处理器执行计算机程序时实现以下步骤:

监测程序在启动且未查询到待测设备的通知时,获取包含待测设备中各应用程序的应用信息的应用列表;

监测程序通过广播监听待测设备的当前网络制式;

在监听到当前网络制式在预设时间段内产生跳变时,获取各应用程序在跳变时刻的第一当前网络消耗流量,并根据第一当前网络消耗流量更新应用列表中对应的应用信息;

在监听到当前网络制式在预设时间段内未发生跳变时,获取各应用程序在预设时间段内的第二当前网络消耗流量,并根据第二当前网络消耗流量更新应用列表中对应的应用信息。

在一个实施例中,处理器执行计算机程序时还实现以下步骤:

嵌入sdk的应用程序在启动且查询到通知时,按照预设周期,查询待测设备,直至未查询到通知;

嵌入sdk的应用程序在启动且未查询到通知时,生成新的通知。

在一个实施例中,处理器执行计算机程序时还实现以下步骤:

嵌入sdk的应用程序依次筛选各应用程序;

筛选出的应用程序的程序属性为系统应用程序时,删除系统应用程序在应用列表中对应的应用信息。

在一个实施例中,处理器执行计算机程序时还实现以下步骤:

嵌入sdk的应用程序获取各应用程序的网速数据,并根据网速数据更新应用列表中对应的应用信息。

在一个实施例中,提供了一种计算机可读存储介质,其上存储有计算机程序,计算机程序被处理器执行时实现以下步骤:

监测程序在启动且未查询到待测设备的通知时,获取包含待测设备中各应用程序的应用信息的应用列表;

监测程序通过广播监听待测设备的当前网络制式;

在监听到当前网络制式在预设时间段内产生跳变时,获取各应用程序在跳变时刻的第一当前网络消耗流量,并根据第一当前网络消耗流量更新应用列表中对应的应用信息;

在监听到当前网络制式在预设时间段内未发生跳变时,获取各应用程序在预设时间段内的第二当前网络消耗流量,并根据第二当前网络消耗流量更新应用列表中对应的应用信息

在一个实施例中,计算机程序被处理器执行时还实现以下步骤:

嵌入sdk的应用程序在启动且查询到通知时,按照预设周期,查询待测设备,直至未查询到通知;

嵌入sdk的应用程序在启动且未查询到通知时,生成新的通知。

在一个实施例中,计算机程序被处理器执行时还实现以下步骤:

嵌入sdk的应用程序依次筛选各应用程序;

筛选出的应用程序的程序属性为系统应用程序时,删除系统应用程序在应用列表中对应的应用信息。

在一个实施例中,计算机程序被处理器执行时还实现以下步骤:

嵌入sdk的应用程序获取各应用程序的网速数据,并根据网速数据更新应用列表中对应的应用信息。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程,是可以通过计算机程序来指令相关的硬件来完成,所述的计算机程序可存储于一非易失性计算机可读取存储介质中,该计算机程序在执行时,可包括如上述各方法的实施例的流程。其中,本申请所提供的各实施例中所使用的对存储器、存储、数据库或其它介质的任何引用,均可包括非易失性和/或易失性存储器。非易失性存储器可包括只读存储器(rom)、可编程rom(prom)、电可编程rom(eprom)、电可擦除可编程rom(eeprom)或闪存。易失性存储器可包括随机存取存储器(ram)或者外部高速缓冲存储器。作为说明而非局限,ram以多种形式可得,诸如静态ram(sram)、动态ram(dram)、同步dram(sdram)、双数据率sdram(ddrsdram)、增强型sdram(esdram)、同步链路(synchlink)dram(sldram)、存储器总线(rambus)直接ram(rdram)、直接存储器总线动态ram(drdram)、以及存储器总线动态ram(rdram)等。

以上实施例的各技术特征可以进行任意的组合,为使描述简洁,未对上述实施例中的各个技术特征所有可能的组合都进行描述,然而,只要这些技术特征的组合不存在矛盾,都应当认为是本说明书记载的范围。

以上所述实施例仅表达了本申请的几种实施方式,其描述较为具体和详细,但并不能因此而理解为对发明专利范围的限制。应当指出的是,对于本领域的普通技术人员来说,在不脱离本申请构思的前提下,还可以做出若干变形和改进,这些都属于本申请的保护范围。因此,本申请专利的保护范围应以所附权利要求为准。

当前第1页1 2 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1