耗电量监测方法、装置、设备及其存储介质与流程

本申请一般涉及计算机技术领域，尤其涉及耗电量监测方法、装置、设备及其存储介质。

背景技术：

随着生活水平的不断提高，电子设备日益融入用户的生活。其中电子设备，例如可以是手机、笔记本电脑、台式电脑、平板电脑等移动终端设备。为了满足相应的智能化需求，移动终端上都需要安装一操作系统，例如windows系统、android系统、symbian系统等等。其中android系统的应用，为广大用户带来极大便利和较好的体验。

安装android系统的电子设备，不能直接地对安装在该系统内的应用程序的耗电量进行测量。现有技术中，例如可以采用基于电流表读取电子设备的电流，然后通过对比应用程序启动时和未启动时的电流的差异性来计算应用程序的耗电量。例如还可以采用基于电量测试工具(powerstat)调用操作系统接口来获取应用程序的耗电量信息。

上述这些方式中，前者由于其他应用程序的运行，可能导致测量结果不准确；后者则必须调用操作系统接口，才能实现应用程序的耗电量的监测。但是随着android系统的版本持续升级，操作系统接口的权限管理功能，逐渐向禁止开放的方向发展。

目前android系统内应用程序的耗电量监测面临着亟待解决的新的难题。

技术实现要素：

鉴于现有技术中的上述缺陷或不足，期望提供一种针对android系统内的应用程序的耗电量的监测方法、装置、设备及存储介质，期望可以在任意版本的android系统中均无需获取操作系统接口权限，便可以通过第三方应用程序完成对系统内应用程序的耗电量的监测。

第一方面，本申请实施例提供了一种应用程序耗电量监测方法，该方法包括：

获取操作系统内至少一个进程标识符pid；

获取操作系统内已安装的至少一个应用标识符uid；

初始化查询操作，以获取初始查询结果；

响应于触发事件来触发当前的查询操作，以获取当前查询结果，该查询结果是每次查询操作中获取的与进程标识符关联的cpu使用信息、内存使用信息和与应用标识符关联的网络流量使用信息；

基于初始查询结果和当前查询结果统计属于同一应用程序的cpu耗电量、内存耗电量以及网络流量耗电量。

第二方面，本申请实施例提供了一种应用程序耗电量监测装置，该装置包括：

进程标识获取单元，用于获取操作系统内至少一个进程标识符pid；

应用标识获取单元，用于获取操作系统内已安装的至少一个应用标识符uid；

初始化单元，用于初始化查询操作，以获取初始查询结果；

查询操作单元，用于响应于触发事件来触发当前的查询操作，以获取当前查询结果，该查询结果是每次查询操作中获取的与进程标识符关联的cpu使用信息、内存使用信息和与应用标识符关联的网络流量使用信息；

电量统计单元，用于基于初始查询结果和当前查询结果统计属于同一应用程序的cpu耗电量、内存耗电量以及网络流量耗电量。

第三方面，本申请实施例提供了一种计算机设备，包括存储器、处理器以及存储在存储器上并可在处理器上运行的计算机程序，该处理器执行该程序时实现如本申请实施例描述的方法。

第四方面，本申请实施例提供了一种计算机可读存储介质，其上存储有计算机程序，该计算机程序用于：

该计算机程序被处理器执行时实现如本申请实施例描述的方法。

本申请实施例提供的应用程序耗电量监测的技术方案，通过查询与进程标识符关联的cpu使用信息和内存使用信息以及与应用标识关联的网络流量使用信息，并将其按照相应的方法转换成应用程序对应cpu耗电量、内存耗电量、网络流量耗电量，从而避免了通过系统权限才能统计android系统中的应用程序的耗电量的问题。

进一步地，通过考虑多个进程共享一个包名、或者多个应用程序共享一个应用标识符等情况，将查询结果细分均摊给每个与之关联的应用程序，从而提高应用程序耗电量监测结果的准确率。

进一步地，通过考虑网络类型计算耗电量监测结果的准确性。

进一步地，通过将查询结果和计算得到的cpu耗电量、内存耗电量、网络流量耗电量经过压缩处理后，存入数据库，以提供实时统计应用程序多样化的耗电量。

附图说明

通过阅读参照以下附图所作的对非限制性实施例所作的详细描述，本申请的其它特征、目的和优点将会变得更明显：

图1示出了本申请实施例提供的应用程序耗电量监测方法的流程示意图；

图2示出了本申请实施例提供的步骤150的流程示意图；

图3示出了根据本申请一个实施例的应用程序耗电量监测装置300的示例性结构框图；

图4示出了本申请实施例提供的电量统计单元350的结构示意图；

图5示出了适于用来实现本申请实施例的终端设备的计算机系统的结构示意图。

具体实施方式

下面结合附图和实施例对本申请作进一步的详细说明。可以理解的是，此处所描述的具体实施例仅仅用于解释相关发明，而非对该发明的限定。另外还需要说明的是，为了便于描述，附图中仅示出了与发明相关的部分。

需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。下面将参考附图并结合实施例来详细说明本申请。

本申请实施例中在android系统内安装的应用程序都可以通过应用标识来表征。应用标识符，也可以称为用户标识符(useridentification，uid)，或表示为应用标识，应用标识符是应用程序安装过程中系统为其分配的唯一标识。在应用程序运行后，系统又为其分配一个身份标识，即进程标识符(processidentification，pid)，也可以表示为进程标识。在应用程序停止运行后，将其收回，再次开始运行时，将重新分配新的进程标识符。

在android系统中，还有一个用于唯一标识应用程序的定义，即包名，一个包名代表一个应用程序，包名主要用于系统识别应用程序。例如包名可以在androidmanifest.xml中定义。在android系统中的应用程序被启动时，与应用程序对应的进程的进程名一般就是包名。在通过runningappprocessinfo对象获取应用标识符uid之后，再通过getpackagemanager().getpackagesforuid()就可以获取得到相应的包名。

进程标识符、应用标识符和包名的对应关系属于现有技术，在此不再赘述。

请参考图1，图1示出了本申请实施例提供的应用程序耗电量监测方法的流程示意图。

如图1所示，该方法包括：

步骤110，获取操作系统内至少一个进程标识符pid。

本步骤中，获取android系统内的进程标识符pid，例如可以通过读取设备在系统启动后生成的″/proc/[pid]/stat″文件，来获取各个进程的信息。进程，即轻量级进程，又可以称为线程。/proc文件系统是一个伪文件系统，它只存在内存当中，而不占用外存空间。它以文件系统的方式为内核与进程提供通信的接口。

用户和应用程序可以通过/proc得到系统的信息，并可以改变内核的某些参数。由于系统的信息，如进程，是动态改变的，所以用户或应用程序读取/proc目录中的文件时，proc文件系统是动态从系统内核读出所需信息并提交的。/proc目录中有一些以数字命名的目录，它们是进程目录。系统中当前运行的每一个进程在/proc下都对应一个以进程号为目录名的目录/proc/pid，它们是读取进程信息的接口。例如pid为10010的进程，它描述的是信息保存在’/proc/10010/stat’文件里。不同进程之间pid是互不相同的，但是，有时也存在多个应用程序共享同一个进程的情形，或者一个应用程序可能存在多个进程的情形。其次，/proc/stat文件包含所有cpu活动的信息，该文件中的所有值都是从系统启动开始累计到当前时刻。不同内核版本中该文件的格式可能不大一致。

本申请实施例，还可以根据android系统的版本不同，采用不同方式来获取进程标识符。例如android系统4.4及以下版本，可以通过调用activitymanager.getrunningappprocesses方法，来获取所有的runningappprocessinfo，例如，publiclist<activitymanager.runningappprocessinfo>getrunningappprocess()说明：获取系统里正在运行的进程

根据进程名推断出应用的包名，按包名统计到应用。例如，string[]pkglist可以得到运行在该进程下的所有应用程序包名。

其中，runningappprocessinfo是获取运行中进程的相关信息的方法，相关信息例如可以是进程名、pid、uid等信息。但是此方法仅适用于android系统5.0以下的版本。

在android系统5.0及以上版本，例如可以通过调用activitymanager.getrunningservices方法，来获取到所有的runningserviceinfo。其中，runningserviceinfo是获得运行中服务信息的方法，所获得的信息例如可以包括应用包名、服务类名、pid、uid、进程名等。通常情况下，进程都会包括至少一个服务，采用该方法仅可以获取得到大多数的进程信息。考虑到这种方法获取的进程可能存在不全，本申请实施例还可以进一步通过遍历″proc/[pid]″文件夹，得到所有正在运行的进程的pid。然后尝试根据pid获取应用的包名，以此作为对getrunningservices方法的补充。

进一步地，本申请实施例还考虑了多个上述进程信息的pid可能相同的情况，在这种情况下，同一个pid进程的耗电量可以考虑平均分配到拥有该pid的所有应用程序中。

步骤120，获取操作系统内已安装的至少一个应用标识uid。

本步骤中，获取操作系统内已安装的至少一个应用程序的应用标识uid，例如可以通过调用packagemanager.getinstalledapplications方法，来获取所有已安装应用的applicationinfo。

其中，applicationinfo是获取应用信息的方法，可以获得包括应用程序的包名、uid等信息。

本申请实施例，还考虑了多个应用程序可能共享同一个uid的情况，在这种情况下，共享同一个uid的应用程序(或称为用户)的耗电量，可以考虑平均分配到共享同一个uid的所有应用程序中。

步骤130，初始化查询操作，以获取初始查询结果。

本步骤中，初始化查询操作，即在系统启动之后，通过首次查询操作来获取与进程标识符关联的cpu使用信息、内存使用信息和与应用标识符关联的网络流量使用信息等。

步骤140，响应于触发事件来触发当前的查询操作，以获取当前查询结果，其中查询结果是每次查询操作中获取的与进程标识符关联的cpu使用信息、内存使用信息和与应用标识符关联的网络流量使用信息。

本步骤中，在完成初始化查询操作之后，可以通过监测触发事件来触发当前的查询操作。触发事件，例如可以是监听网络类型的变化、注册定时器的变化等。其中，监听网络类型的变化，例如可以通过监听移动数据网络与wi-fi网络之间的切换，并在网络从移动数据网络切换为wi-fi网络或者从wi-fi网络切换至移动数据网络之后开始执行查询操作。定时器例如可以采用但不限于timer或handler，注册定时器后，在定时器的预设时间到达时，则会触发该定时器。在触发新一轮的查询之后，可以获取当前查询时刻对应的cpu使用信息、内存使用信息以及网络流量使用信息，这些信息间接地表征了进程的耗电情况，以及应用程序的耗电情况。

步骤150，基于初始查询结果和当前查询结果统计属于同一应用程序的cpu耗电量、内存耗电量以及网络流量耗电量。

本申请实施例，通过查询应用程序从初始查询时刻(例如程序启动时)到当前查询时刻的cpu使用信息、内存使用信息、以及网络流量使用信息等，按照相应的公式转换为cpu耗电量、内存耗电量以及网络流量耗电量。

本申请实施例，通过直接读取系统内的进程标识符和应用标识符避免了需要系统接口权限的问题，有效地解决android系统各个应用程序的耗电量的监测问题。

请参考图2，图2示出了本申请实施例提供的步骤150的流程示意图。

如图2所示，该步骤进一步地可以包括：

步骤210，根据进程标识符确定应用程序的包名；

步骤220，基于包名统计应用程序的cpu耗电量、内存耗电量；

步骤230，基于应用标识符统计应用程序的网络流量耗电量。

本申请实施例中，通过查询操作获取与进程标识符对应的cpu使用信息和内存使用信息以及与应用标识符对应的网络流量使用信息，然后将这些信息转换成应用程序相应的cpu耗电量、内存耗电量以及网络流量耗电量等。

本申请实施例中，步骤220例如还可以包括：

步骤2201，计算当前查询结果和初始查询结果中cpu使用信息的第一绝对差值，该第一绝对差值与进程标识相对应；

步骤2202，计算与包名关联的进程标识的第一绝对差值的和；

步骤2203，利用和、cpu耗电系数、进程权重系数相乘得到应用程序的cpu耗电量，其中进程权重系数是由与包名关联的进程标识的数量决定的。

步骤2204，计算当前查询结果中内存使用信息与所述始查询结果中的内存使用信息的算数平均值；

步骤2205，将算数平均值、内存耗电系数和时间差值相乘得到内存耗电量。该时间差值是当前查询时刻与初始查询时刻的差值。内存使用信息是每次查询之后，先将与进程标识符对应的内存使用信息与进程权重系数相乘得到积，再计算与包名关联的进程标识符的积的和，进程权重系数是由与包名关联的进程标识符的数量决定。

本申请实施例中，对于每个应用程序，从当前查询结果中查找到与该应用程序对应的所有pid的查询结果，每个pid对应的cpu使用信息，例如可以表示为cpuabs[pid]，初始查询结果中与该应用程序对应的所有pid的查询结果，每个pid对应的cpu使用信息，例如可以表示为cpuabs’[pid]。本申请实施例中，可以通过公式(1)来计算与包名关联的多个pid的cpu耗电量：

公式(1)中n的取值为与包名关联的所有pid的数量，其中，cpuabs[pid]-cpuabs′[pid]表示第一绝对差值，可以理解为进程pid在初始查询时刻到当前查询时刻使用的cpu时间片。

本申请实施例中，利用第一绝对差值乘以进程权重系数再累加求和，得到包名对应的应用程序使用的cpu时间片，最后乘以cpu耗电系数(kcpu)就可以换算成耗电量powcpu。其中，cpu耗电系数是指单位时间片的耗电量，该系数可以根据经验得出。

本申请实施例中，在获取当前查询结果之后，可以得到每个进程pid在当前时刻的内存使用信息，例如可以表示为memabs[pid]。假如考虑多个pid与一个包名对应的情况，可以将memabs[pid]乘以进程权重系数再累加求和得到mem[app]。如公式(2)描述的，得到包名在当前时刻的内存使用信息，其可以是所有与该包名关联的进程pid在当前时刻获取的内存使用信息与进程权重系数weightpid[pid]相乘，再累加求和得到，例如可以表示为mem[app]。同样地，初始查询操作中获取的相同包名对应的内存使用信息可以利用公式(2)计算得到，例如可以表示为mem′[app]。

公式(2)中n的取值为与包名关联的所有pid的数量。通过当前查询时刻和前一查询时刻(或初始查询时刻)获取的两个内存使用信息求算数平均值后，乘以两次查询的时间差值(dt)以及内存耗电系数(kmem)，将内存使用信息可以换算成内存耗电量powmem。其中，内存耗电系数指单位时间、单位内存占用的耗电量，该系数可以根据经验得出。这里求算数平均值是假设该应用程序在这段时间内内存的占用是均匀变化的。

步骤230，还可以包括：

步骤2301，计算当前查询结果和初始查询结果中的网络流量使用信息的第二绝对差值，其中第二绝对差值与应用标识相对应。

步骤2302，利用第二绝对差值、流量耗电系数和应用权重系数相乘，得到网络流量耗电量。其中，流量耗电系数是由前次查询的网络类型决定的，应用权重系数是由与应用标识符关联的应用程序的数量决定的。

本申请实施例中，在android系统中已安装的应用程序(也称为app程序)，假设多个应用程序可以共享一个uid，则每个应用程序的可以平均分配网络流量。具体分配可以根据应用权重系数weightuid[uid]来决定。

在当前查询结果中，可以得到uid在当前查询时刻的流量使用信息，例如可以表示为dataabs[uid]，在初始查询结果中，可以得到同一uid在初始查询时刻(或前一查询时刻)的流量使用信息，例如可以表示为dataabs’[uid]。本申请实施例中，可以根据公式(4)来求取网络流量耗电量。

在公式(4)中，dataabs[uid]-dataabs′[uid]表示第二绝对差值，可以理解为uid在初始查询时刻到当前查询时刻的流量使用情况。kdata/trffic表示移动数据网络流量的耗电系数，如果前一次查询时刻(例如初始查询时刻)的网络类型为移动数据网络，则从前一查询时刻到当前查询时刻的网络流量使用信息转换为相应的网络流量耗电量可以表示公式(4)中第一种情况。

第一种情况，利用kdata/trffic乘以第二绝对差值，再乘以应用权重系数得到从初始查询时刻与当前查询时刻内使用的流量data[app]的耗电量。

同理，kdata/wi-fi表示wi-fi网络流量的耗电系数，如果前一次查询时刻(例如初始查询时刻)的网络类型为wi-fi网络，则从前一查询时刻到当前查询时刻的网络流量使用信息转换为相应的网络流量耗电量可以表示公式(4)中第二种情况。

第一种情况，利用kdata/wi-fi乘以第二绝对差值，再乘以应用权重系数得到从初始查询时刻与当前查询时刻内使用的流量data[app]的耗电量。

公式(4)中，流量耗电系数指单位流量使用的耗电量。在实际网络环境中，移动网络数据的耗电量通常会比wi-fi网络高，因此，本申请实施例中，区别考虑网络类型对耗电量的影响，进一步地提高了耗电量监测的准确度。具体可以根据上次查询时的网络类型决定。

对于网络类型属于蓝牙等情况的网络类型，适用第三种情况。

本申请实施例中，每次查询操作得到的与应用标识关联的网络流量使用信息，例如可以按照效率从高到低的原则查找所述网络流量使用信息。如果采用效率较高的查找方式无法获取网络流量使用信息，则采用效率较低的方式进一步尝试获取。

查找方式例如可以是解析“/proc/net/xt_qtaguid/stats”文件；或解析“/proc/uid_stat/[uid]”文件；或调用trafficstats的api。

其中，解析″/proc/net/xt_qtaguid/stats″文件，该文件包含从设备启动时刻(例如初始查询时刻)到当前查询时刻，每个应用程序(也称为用户)的移动数据流量以及wi-fi流量使用情况。其效率最高。

在应用程序安装到设备上时，系统会为其分配一个uid，获取的网络流量使用信息通常是根据uid划分的。大多数情况下一个应用对应一个uid，但是也存在多个应用程序共享同一个uid的情况。假设当多个应用共享一个uid时，本申请实例例还可以退通过应用权重系数将同一个uid的网络流量平均分配到各个应用程序上，从而得到较为准确的结果。

解析″/proc/uid_stat/[uid]″文件，该文件包含从设备启动时刻(例如初始查询时刻)到当前查询时刻，每个应用程序的流量使用情况。例如可以通过″/proc/uid_stat/uid/tcp_send″获取上行流量数据或者通过″/proc/uid_stat/uid/tcp_rcv″获取下行流量数据。但是这种方式无法区分移动数据流量和wi-fi网络流量。其效率相比前者较低。

调用trafficstats方法，来获取从设备启动时刻(例如初始查询时刻)到当前查询时刻，每个应用程序的流量使用情况，这种方式可能在部分设备上无法区分移动数据流量和wi-fi流量。效率相比前两者更低。

本申请实施例中通过将应用程序的cpu使用信息、内存使用信息以及网络流量使用信息转换成cpu耗电量、内存耗电量以及网络流量耗电量，从而多角度了解应用程序的耗电量情况。

进一步，本申请实施例，还可以将cpu耗电量、内存耗电量以及网络流量耗电量、以及每次查询获取的网络流量使用信息、查询时间等信息存储数据库，并在存储的过程中采用相应的数据压缩方式进行数据处理，从而可以实时地更新应用程序的耗电量监测结果。

应当注意，尽管在附图中以特定顺序描述了本发明方法的操作，但是，这并非要求或者暗示必须按照该特定顺序来执行这些操作，或是必须执行全部所示的操作才能实现期望的结果。相反，流程图中描绘的步骤可以改变执行顺序。附加地或备选地，可以省略某些步骤，将多个步骤合并为一个步骤执行，和/或将一个步骤分解为多个步骤执行。

进一步参考图3，图3示出了根据本申请一个实施例的应用程序耗电量监测装置300的示例性结构框图。

如图3所示，该装置300包括：

进程标识获取单元310，用于获取操作系统内至少一个进程标识符pid。

本步骤中，获取android系统内的进程标识符pid，例如可以通过读取设备在系统启动后生成的″/proc/[pid]/stat″文件，来获取各个进程的信息。进程，即轻量级进程，又可以称为线程。/proc文件系统是一个伪文件系统，它只存在内存当中，而不占用外存空间。它以文件系统的方式为内核与进程提供通信的接口。

用户和应用程序可以通过/proc得到系统的信息，并可以改变内核的某些参数。由于系统的信息，如进程，是动态改变的，所以用户或应用程序读取/proc目录中的文件时，proc文件系统是动态从系统内核读出所需信息并提交的。/proc目录中有一些以数字命名的目录，它们是进程目录。系统中当前运行的每一个进程在/proc下都对应一个以进程号为目录名的目录/proc/pid，它们是读取进程信息的接口。例如pid为10010的进程，它描述的是信息保存在’/proc/10010/stat’文件里。不同进程之间pid是互不相同的，但是，有时也存在多个应用程序共享同一个进程的情形，或者一个应用程序可能存在多个进程的情形。其次，/proc/stat文件包含所有cpu活动的信息，该文件中的所有值都是从系统启动开始累计到当前时刻。不同内核版本中该文件的格式可能不大一致。

本申请实施例，还可以根据android系统的版本不同，采用不同方式来获取进程标识符。例如android系统4.4及以下版本，可以通过调用activitymanager.getrunningappprocesses方法，来获取所有的runningappprocessinfo，例如，publiclist<activitymanager.runningappprocessinfo>getrunningappprocess()说明：获取系统里正在运行的进程

根据进程名推断出应用的包名，按包名统计到应用。例如，string[]pkglist可以得到运行在该进程下的所有应用程序包名。其中，runningappprocessinfo是获取运行中进程的相关信息的方法，相关信息例如可以是进程名、pid、uid等信息。但是此方法仅适用于android系统5.0以下的版本。

在android系统5.0及以上版本，例如可以通过调用activitymanager.getrunningservices方法，来获取到所有的runningserviceinfo。其中，runningserviceinfo是获得运行中服务信息的方法，所获得的信息例如可以包括应用包名、服务类名、pid、uid、进程名等。通常情况下，进程都会包括至少一个服务，采用该方法仅可以获取得到大多数的进程信息。考虑到这种方法获取的进程可能存在不全，本申请实施例还可以进一步通过遍历″proc/[pid]″文件夹，得到所有正在运行的进程的pid。然后尝试根据pid获取应用的包名，以此作为对getrunningservices方法的补充。

进一步地，本申请实施例还考虑了多个上述进程信息的pid可能相同的情况，在这种情况下，同一pid进程的耗电量可以考虑平均分配到拥有该pid的所有应用程序中。

应用标识获取单元320，用于获取操作系统内已安装的至少一个应用标识uid。

本步骤中，获取操作系统内已安装的至少一个应用程序的应用标识uid，例如可以通过调用packagemanager.getinstalledapplications方法，来获取所有已安装应用的applicationinfo。

其中，applicationinfo是获取应用信息的方法，可以获得包括应用程序的包名、uid等信息。

本申请实施例，还考虑了多个应用程序可能共享同一个uid的情况，在这种情况下，共享同一个uid的应用程序(或称为用户)的耗电量，可以考虑平均分配到共享同一个uid的所有应用程序中。

初始化单元330，用于初始化查询操作，以获取初始查询结果。

本步骤中，初始化查询操作，即在系统启动之后，通过首次查询操作来获取与进程标识符关联的cpu使用信息、内存使用信息和与应用标识符关联的网络流量使用信息等。

查询操作单元340，用于响应于触发事件来触发当前的查询操作，以获取当前查询结果，其中查询结果是每次查询操作中获取的与进程标识符关联的cpu使用信息、内存使用信息和与应用标识符关联的网络流量使用信息。

本步骤中，在完成初始化查询操作之后，可以通过监测触发事件来触发当前的查询操作。触发事件，例如可以是监听网络类型的变化、注册定时器的变化等。其中，监听网络类型的变化，例如可以通过监听移动数据网络与wi-fi网络之间的切换，并在网络从移动数据网络切换为wi-fi网络或者从wi-fi网络切换至移动数据网络之后开始执行查询操作。定时器例如可以采用但不限于timer或handler，注册定时器后，在定时器的预设时间到达时，则会触发该定时器。在触发新一轮的查询之后，可以获取当前查询时刻对应的cpu使用信息、内存使用信息以及网络流量使用信息，这些信息间接地表征了进程的耗电情况，以及应用程序的耗电情况。

电量统计单元350，用于基于初始查询结果和当前查询结果统计属于同一应用程序的cpu耗电量、内存耗电量以及网络流量耗电量。

本申请实施例，通过查询应用程序从初始查询时刻(例如程序启动时)到当前查询时刻的cpu使用信息、内存使用信息、以及网络流量使用信息等，按照相应的公式转换为cpu耗电量、内存耗电量以及网络流量耗电量。

本申请实施例，通过直接读取系统内的进程标识符和应用标识符避免了需要系统接口权限的问题，有效地解决android系统各个应用程序的耗电量的监测问题。

请参考图4，图4示出了本申请实施例提供的电量统计单元350的结构示意图。

如图4所示，电量统计单元350可以包括：

包名确定子单元410，用于根据进程标识符确定应用程序的包名；

第一耗电量统计子单元420，用于基于包名统计应用程序的cpu耗电量、内存耗电量；

第二耗电量统计子单元430，用于基于应用标识符统计应用程序的网络流量耗电量。

本申请实施例中，通过查询操作获取与进程标识符对应的cpu使用信息和内存使用信息以及与应用标识符对应的网络流量使用信息，然后将这些信息转换成应用程序相应的cpu耗电量、内存耗电量以及网络流量耗电量等。

本申请实施例中，第一耗电量统计子单元420例如还可以包括：

第一绝对差值计算模块4201，用于计算当前查询结果和初始查询结果中cpu使用信息的第一绝对差值，该第一绝对差值与进程标识相对应；

第一求和模块4202，用于计算与包名关联的进程标识的第一绝对差值的和；

cpu耗电量计算模块4203，用于利用和、cpu耗电系数、进程权重系数相乘得到应用程序的cpu耗电量，其中进程权重系数是由与包名关联的进程标识的数量决定的。

均值计算模块4204，用于计算当前查询结果中内存使用信息与所述始查询结果中的内存使用信息的算数平均值。

内存耗电量计算模块4205，用于将算数平均值、内存耗电系数和时间差值相乘得到内存耗电量。该时间差值是当前查询时刻与初始查询时刻的差值。内存使用信息是每次查询之后，先将与进程标识符对应的内存使用信息与进程权重系数相乘得到积，再计算与包名关联的进程标识符的积的和，进程权重系数是由与包名关联的进程标识符的数量决定。

本申请实施例中，对于每个应用程序，从当前查询结果中查找到与该应用程序对应的所有pid的查询结果，每个pid对应的cpu使用信息，例如可以表示为cpuabs[pid]，初始查询结果中与该应用程序对应的所有pid的查询结果，每个pid对应的cpu使用信息，例如可以表示为cpuabs’[pid]。本申请实施例中，可以通过公式(1)来计算与包名关联的多个pid的cpu耗电量：

公式(1)中n的取值为与包名关联的所有pid的数量，其中，cpuabs[pid]-cpuabs′[pid]表示第一绝对差值，可以理解为进程pid在初始查询时刻到当前查询时刻使用的cpu时间片。

本申请实施例中，利用第一绝对差值乘以进程权重系数再累加求和，得到包名对应的应用程序使用的cpu时间片，最后乘以cpu耗电系数(kcpu)就可以换算成耗电量powcpu。其中，cpu耗电系数是指单位时间片的耗电量，该系数可以根据经验得出。

本申请实施例中，在获取当前查询结果之后，可以得到每个进程pid在当前时刻的内存使用信息，例如可以表示为memabs[pid]。假如考虑多个pid与一个包名对应的情况，可以将memabs[pid]乘以进程权重系数再累加求和得到mem[app]。如公式(2)描述的，得到包名在当前时刻的内存使用信息，其可以是所有与该包名关联的进程pid在当前时刻获取的内存使用信息与进程权重系数weightpid[pid]相乘，再累加求和得到，例如可以表示为mem[app]。同样地，初始查询操作中获取的相同包名对应的内存使用信息可以利用公式(2)计算得到，例如可以表示为mem′[app]。

公式(2)中n的取值为与包名关联的所有pid的数量。通过当前查询时刻和前一查询时刻(或初始查询时刻)获取的两个内存使用信息求算数平均值后，乘以两次查询的时间差值(dt)以及内存耗电系数(kmem)，将内存使用信息可以换算成内存耗电量powmem。其中，内存耗电系数指单位时间、单位内存占用的耗电量，该系数可以根据经验得出。这里求算数平均值是假设该应用程序在这段时间内内存的占用是均匀变化的。

第二耗电量统计子单元430，还可以包括：

第二绝对差值计算模块4301，用于计算当前查询结果和初始查询结果中的网络流量使用信息的第二绝对差值，其中第二绝对差值与应用标识相对应。

网络流量耗电量计算模块4302，用于利用第二绝对差值、流量耗电系数和应用权重系数相乘，得到网络流量耗电量。其中，流量耗电系数是由前次查询的网络类型决定的，应用权重系数是由与应用标识符关联的应用程序的数量决定的。

本申请实施例中，在android系统中已安装的应用程序(也称为app程序)，假设多个应用程序可以共享一个uid，则每个应用程序的可以平均分配网络流量。具体分配可以根据应用权重系数weightuid[uid]来决定。

在当前查询结果中，可以得到uid在当前查询时刻的流量使用信息，例如可以表示为dataabs[uid]，在初始查询结果中，可以得到同一uid在初始查询时刻(或前一查询时刻)的流量使用信息，例如可以表示为dataabs’[uid]。本申请实施例中，可以根据公式(4)来求取网络流量耗电量。

在公式(4)中，dataabs[uid]-dataabs′[uid]表示第二绝对差值，可以理解为uid在初始查询时刻到当前查询时刻的流量使用情况。kdata/trffic表示移动数据网络流量的耗电系数，如果前一次查询时刻(例如初始查询时刻)的网络类型为移动数据网络，则从前一查询时刻到当前查询时刻的网络流量使用信息转换为相应的网络流量耗电量可以表示公式(4)中第一种情况。

第一种情况，利用kdata/trffic乘以第二绝对差值，再乘以应用权重系数得到从初始查询时刻与当前查询时刻内使用的流量data[app]的耗电量。

同理，kdata/wi-fi表示wi-fi网络流量的耗电系数，如果前一次查询时刻(例如初始查询时刻)的网络类型为wi-fi网络，则从前一查询时刻到当前查询时刻的网络流量使用信息转换为相应的网络流量耗电量可以表示公式(4)中第二种情况。

第一种情况，利用kdata/wi-fi乘以第二绝对差值，再乘以应用权重系数得到从初始查询时刻与当前查询时刻内使用的流量data[app]的耗电量。

公式(4)中，流量耗电系数指单位流量使用的耗电量。在实际网络环境中，移动网络数据的耗电量通常会比wi-fi网络高，因此，本申请实施例中，区别考虑网络类型对耗电量的影响，进一步地提高了耗电量监测的准确度。具体可以根据上次查询时的网络类型决定。

对于网络类型属于蓝牙等情况的网络类型，适用第三种情况。

本申请实施例中，每次查询操作得到的与应用标识关联的网络流量使用信息，例如可以按照效率从高到低的原则查找所述网络流量使用信息。如果采用效率较高的查找方式无法获取网络流量使用信息，则采用效率较低的方式进一步尝试获取。

查找方式例如可以是解析“/proc/net/xt_qtaguid/stats”文件；或解析“/proc/uid_stat/[uid]”文件；或调用trafficstats的api。

其中，解析″/proc/net/xt_qtaguid/stats″文件，该文件包含从设备启动时刻(例如初始查询时刻)到当前查询时刻，每个应用程序(也称为用户)的移动数据流量以及wi-fi流量使用情况。其效率最高。

在应用程序安装到设备上时，系统会为其分配一个uid，获取的网络流量使用信息通常是根据uid划分的。大多数情况下一个应用对应一个uid，但是也存在多个应用程序共享同一个uid的情况。假设当多个应用共享一个uid时，本申请实例例还可以退通过应用权重系数将同一个uid的网络流量平均分配到各个应用程序上，从而得到较为准确的结果。

解析″/proc/uid_stat/[uid]″文件，该文件包含从设备启动时刻(例如初始查询时刻)到当前查询时刻，每个应用程序的流量使用情况。例如可以通过″/proc/uid_stat/uid/tcp_send″获取上行流量数据或者通过″/proc/uid_stat/uid/tcp_rcv″获取下行流量数据。但是这种方式无法区分移动数据流量和wi-fi网络流量。其效率相比前者较低。

调用trafficstats方法，来获取从设备启动时刻(例如初始查询时刻)到当前查询时刻，每个应用程序的流量使用情况，这种方式可能在部分设备上无法区分移动数据流量和wi-fi流量。效率相比前两者更低。

本申请实施例中通过将应用程序的cpu使用信息、内存使用信息以及网络流量使用信息转换成cpu耗电量、内存耗电量以及网络流量耗电量，从而多角度了解应用程序的耗电量情况。

进一步，本申请实施例，该装置还可以包括触发事件获取单元，用于获取所述触发事件，其中触发事件包括以下至少一种：监听网络类型的变化；注册定时器的变化。

压缩存储单元，用于将所述cpu耗电量、内存耗电量以及网络流量耗电量、查询时间、查询结果压缩处理后存入数据库将cpu耗电量、内存耗电量以及网络流量耗电量、以及每次查询获取的网络流量使用信息、查询时间等信息存储数据库，并在存储的过程中采用相应的数据压缩方式进行数据处理，从而可以实时地更新应用程序的耗电量监测结果。

应当理解，装置300-400中记载的诸单元或模块与参考图1-2描述的方法中的各个步骤相对应。由此，上文针对方法描述的操作和特征同样适用于装置300-400及其中包含的单元，在此不再赘述。装置300-400可以预先实现在电子设备的浏览器或其他安全应用中，也可以通过下载等方式而加载到电子设备的浏览器或其安全应用中。装置300-400中的相应单元可以与电子设备中的单元相互配合以实现本申请实施例的方案。

下面参考图5，其示出了适于用来实现本申请实施例的终端设备的计算机系统500的结构示意图。

本申请实施例中，终端设备包括但不限于手机、笔记本电脑、平板电脑、台式电脑、相机等设备，且在终端设备上安装有android系统。

如图5所示，计算机系统500包括中央处理单元(cpu)501，其可以根据存储在只读存储器(rom)502中的程序或者从存储部分508加载到随机访问存储器(ram)503中的程序而执行各种适当的动作和处理。在ram503中，还存储有系统500操作所需的各种程序和数据。cpu501、rom502以及ram503通过总线504彼此相连。输入/输出(i/o)接口505也连接至总线504。

以下部件连接至i/o接口505：包括键盘、鼠标等的输入部分506；包括诸如阴极射线管(crt)、液晶显示器(lcd)等以及扬声器等的输出部分507；包括硬盘等的存储部分508；以及包括诸如lan卡、调制解调器等的网络接口卡的通信部分509。通信部分509经由诸如因特网的网络执行通信处理。驱动器510也根据需要连接至i/o接口505。可拆卸介质511，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器510上，以便于从其上读出的计算机程序根据需要被安装入存储部分508。

特别地，根据本公开的实施例，上文参考图1-2描述的过程可以被实现为计算机软件程序。例如，本公开的实施例包括一种计算机程序产品，其包括有形地包含在机器可读介质上的计算机程序，上述计算机程序包含用于执行图1-2的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信部分509从网络上被下载和安装，和/或从可拆卸介质511被安装。

附图中的流程图和框图，图示了按照本发明各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，前述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

描述于本申请实施例中所涉及到的单元或模块可以通过软件的方式实现，也可以通过硬件的方式来实现。所描述的单元或模块也可以设置在处理器中，例如，可以描述为：一种处理器包括进程标识获取单元、应用标识获取单元、初始化单元、查询操作单元以及电量统计单元。其中，这些单元或模块的名称在某种情况下并不构成对该单元或模块本身的限定，例如，进程标识获取单元还可以被描述为“用于获取操作系统内至少一个进程标识符pid的单元”。

作为另一方面，本申请还提供了一种计算机可读存储介质，该计算机可读存储介质可以是上述实施例中前述装置中所包含的计算机可读存储介质；也可以是单独存在，未装配入设备中的计算机可读存储介质。计算机可读存储介质存储有一个或者一个以上程序，前述程序被一个或者一个以上的处理器用来执行描述于本申请的应用程序耗电量监测方法。

以上描述仅为本申请的较佳实施例以及对所运用技术原理的说明。本领域技术人员应当理解，本申请中所涉及的发明范围，并不限于上述技术特征的特定组合而成的技术方案，同时也应涵盖在不脱离前述发明构思的情况下，由上述技术特征或其等同特征进行任意组合而形成的其它技术方案。例如上述特征与本申请中公开的(但不限于)具有类似功能的技术特征进行互相替换而形成的技术方案。