CN108647127B - 应用耗电监控方法及装置 - Google Patents

Abstract

本发明公开了一种应用耗电监控方法及装置，属于终端技术领域。该方法包括：在自应用切换至后台运行起的两个时间点，分别确定应用对处理器的已占用时长，得到第一时长和第二时长；当第一时长和第二时长的差值大于预设阈值时，确定应用在后台耗电异常，并获取应用在之后的第二预设时长内的运行数据；根据该运行数据获取应用的耗电异常原因，或者将该运行数据发送给服务器，由服务器获取应用的耗电异常原因，该耗电异常原因是指应用在第二预设时长内调用的调用次数大于预设次数和/或执行时长大于第三预设时长的调用栈。本发明能够及时检测出应用在后台的耗电异常现象，并能够分析出引起耗电异常的原因，便于有效解决应用的后台耗电问题。

Description

应用耗电监控方法及装置

技术领域

本发明涉及终端技术领域，特别涉及一种应用耗电监控方法及装置。

背景技术

随着终端技术的发展，能够在终端中安装的且功能多样的应用也大量涌现，因此，用户在使用终端时，通常会在终端中安装多种应用，以满足用户的娱乐、学习或出行等诸多需求。

实际应用中，用户经常会将暂不使用的应用切换至后台运行，当需要使用时再切换回前台运行。但是，有些应用在后台运行的过程中可能会耗电异常，继而导致终端待机时长较短，影响用户的使用。

因此，目前亟需一种能够对后台运行的应用的耗电情况进行检测的方法，以解决后台运行的应用的耗电异常问题，进而提高终端的使用性能。

发明内容

本发明实施例提供了一种应用耗电监控方法及装置，可以用于解决相关技术中存在的终端中的有些应用在后台运行过程中耗电异常，继而导致终端待机时长较短的问题。所述技术方案如下：

一方面，提供了一种应用耗电监控方法，所述方法包括：

在自应用切换至后台运行起的两个时间点，分别确定所述应用对处理器的已占用时长，得到第一时长和第二时长，所述两个时间点相距第一预设时长；

当所述第一时长和所述第二时长的差值大于预设阈值时，确定所述应用在后台耗电异常，并获取所述应用在当前时间点之后第二预设时长内的运行数据；

根据所述运行数据获取所述应用的耗电异常原因，或者，将所述运行数据发送给服务器，由所述服务器根据所述运行数据获取所述应用的耗电异常原因；

其中，所述耗电异常原因是指所述应用在所述第二预设时长内调用的至少一个目标调用栈，所述至少一个目标调用栈是指调用次数大于预设次数和/或执行时长大于第三预设时长的调用栈。

一方面，提供了一种应用耗电监控装置，所述装置包括：

确定模块，用于在自应用切换至后台运行起的两个时间点，分别确定所述应用对处理器的已占用时长，得到第一时长和第二时长，所述两个时间点相距第一预设时长；

第一获取模块，用于当所述第一时长和所述第二时长的差值大于预设阈值时，确定所述应用在后台耗电异常，并获取所述应用在当前时间点之后第二预设时长内的运行数据；

第二获取模块，用于根据所述运行数据获取所述应用的耗电异常原因，或者，将所述运行数据发送给服务器，由所述服务器根据所述运行数据获取所述应用的耗电异常原因；

其中，所述耗电异常原因是指所述应用在所述第二预设时长内调用的至少一个目标调用栈，所述至少一个目标调用栈是指调用次数大于预设次数和/或执行时长大于第三预设时长的调用栈。

一方面，提供了一种终端，所述终端包括处理器和存储器，所述存储器中存储有至少一条指令、至少一段程序、代码集或指令集，所述指令、所述程序、所述代码集或所述指令集由所述处理器加载并执行以实现上述应用耗电监控方法。

一方面，提供了一种计算机可读存储介质，其特征在于，所述存储介质中存储有至少一条指令、至少一段程序、代码集或指令集，所述指令、所述程序、所述代码集或所述指令集由处理器加载并执行以实现上述应用耗电监控方法。

一方面，提供了一种应用耗电监控方法，所述方法包括：

接收终端发送的所述终端中的应用在后台运行第二预设时长内的运行数据，所述运行数据是所述终端根据自所述应用切换至后台运行起的两个时间点对处理器的已占用时长，确定所述应用在后台耗电异常时开始获取的，所述两个时间点相距第一预设时长；

根据所述运行数据，获取所述应用的耗电异常原因，所述耗电异常原因是指所述应用在所述第二预设时长内调用的至少一个目标调用栈，所述至少一个目标调用栈是指调用次数大于预设次数和/或执行时长大于第三预设时长的调用栈。

一方面，提供了一种应用耗电监控装置，所述装置包括：

接收模块，用于接收终端发送的所述终端中的应用在后台运行第二预设时长内的运行数据，所述运行数据是所述终端根据自所述应用切换至后台运行起的两个时间点对处理器的已占用时长，确定所述应用在后台耗电异常时开始获取的，所述两个时间点相距第一预设时长；

获取模块，用于根据所述运行数据，获取所述应用的耗电异常原因，所述耗电异常原因是指所述应用在所述第二预设时长内调用的至少一个目标调用栈，所述至少一个目标调用栈是指调用次数大于预设次数和/或执行时长大于第三预设时长的调用栈。

一方面，提供了一种服务器，所述服务器包括处理器和存储器，所述存储器中存储有至少一条指令、至少一段程序、代码集或指令集，所述指令、所述程序、所述代码集或所述指令集由所述处理器加载并执行以实现上述应用耗电监控方法。

一方面，提供了一种计算机可读存储介质，其特征在于，所述存储介质中存储有至少一条指令、至少一段程序、代码集或指令集，所述指令、所述程序、所述代码集或所述指令集由处理器加载并执行以实现上述应用耗电监控方法。

本发明实施例提供的技术方案带来的有益效果是：

本发明实施例中，对于切换至后台运行的应用，终端可以根据该应用在自切换至后台起的两个时间点分别对处理器的已占用时长，检测该应用在后台是否耗电异常，并可以在该应用在后台耗电异常时，根据该应用的运行数据获取该应用的耗电异常原因，或者将该运行数据发送给服务器，由服务器根据该运行数据获取该应用的耗电异常原因。其中，耗电异常原因是指该应用在后台运行过程中调用的调用次数较多和/或执行时长较长的调用栈，能够反映该应用在后台频繁执行或执行时间较长的具体任务，因此这些任务即为导致该应用在后台异常耗电的原因。如此，终端不仅可以及时检测到应用在后台的耗电异常现象，还可以在检测到该应用在后台耗电异常时，通过获取该应用的后台运行数据分析该应用的耗电异常原因，以便根据该耗电异常原因有效解决该应用的后台耗电问题，实现对应用的优化，进而提高终端的使用性能。

附图说明

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

图1是本发明实施例提供的一种应用耗电监控系统的示意图；

图2是本发明实施例提供的一种应用耗电监控方法的流程图；

图3是本发明实施例提供的一种在文件处理功能中打开的数据文件的示意图；

图4是本发明实施例提供的另一种应用耗电监控方法的流程图；

图5是本发明实施例提供的一种应用耗电监控装置的结构示意图；

图6是本发明实施例提供的另一种应用耗电监控装置的结构示意图；

图7是本发明实施例提供的一种终端700的结构示意图；

图8是本发明实施例提供的一种服务器800的结构示意图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚，下面将结合附图对本发明实施方式作进一步地详细描述。

在对本发明实施例进行详细地解释说明之前，先对本发明实施例的应用场景予以说明。

本发明实施例提供的应用耗电监控方法应用于对在终端后台运行的应用的耗电情况进行监控的场景中。具体地，在应用切换至后台运行后，可以监控应用在后台的耗电情况，进而检测该应用在后台是否耗电异常，并可以在该应用在后台耗电异常时，获取该应用的后台运行数据，然后根据该后台运行数据获取引起该应用在后台耗电异常的具体原因。

实际应用中，应用的后台耗电异常问题一般都是因开发人员在开发该应用时设计不成熟导致的，比如可能是由开发人员在实现该应用的某些功能时未考虑到后台耗电问题所导致的。本发明实施例中，通过在检测到该应用在后台耗电异常时，获取该应用在后台的运行数据，并根据该运行数据获取引起该应用在后台耗电异常的具体原因，可以便于开发人员根据该耗电异常的具体原因有针对性地解决该应用的耗电异常问题，从而有效地对该应用进行优化。

接下来对本发明实施例的系统架构进行说明。

本发明实施例提供的应用耗电监控方法可以应用于终端中，也可以应用于由终端和服务器组成的应用耗电监控系统中，接下来对该应用耗电监控系统进行详细介绍。

图1是本发明实施例提供的一种应用耗电监控系统的示意图，如图1所示，该系统包括终端10和服务器20，终端10和服务器20之间可以通过有线网络或无线网络进行通信。

其中，终端10安装有应用，并可以根据用户的操作将当前正在前台运行的应用切换至后台运行。服务器20可以接收终端10发送的数据，并可以根据实际需要对接收的数据进行处理。实际应用中，终端10可以为手机、平板电脑或计算机等电子设备。服务器20可以为应用的后台服务器，也可以为专门用于检测各个应用的后台耗电情况以及分析耗电异常原因的服务器，本发明实施例对此不做限定。

需要说明的是，基于图1所示的系统，本发明实施例提供的应用耗电监控方法可以通过以下两种方式实现：

第一种实现方式：由终端10分析应用在后台的耗电异常原因。

终端10用于在安装的任一应用切换至后台运行起的两个时间点，分别确定该应用对处理器的已占用时长，得到第一时长和第二时长，这两个时间点相距第一预设时长；当该第一时长和该第二时长的差值大于预设阈值时，确定该应用在后台耗电异常，并获取该应用在当前时间点之后第二预设时长内的运行数据；根据该运行数据获取该应用的耗电异常原因；将该应用的耗电异常原因发送给服务器20。其中，该耗电异常原因是指该应用在该第二预设时长内调用的至少一个目标调用栈，该至少一个目标调用栈是指调用次数大于预设次数和/或执行时长大于第三预设时长的调用栈。

第二种实现方式：由服务器20分析应用在后台的耗电异常原因。

终端10用于在安装的任一应用切换至后台运行起的两个时间点，分别确定该应用对处理器的已占用时长，得到第一时长和第二时长，这两个时间点相距第一预设时长；当该第一时长和该第二时长的差值大于预设阈值时，确定该应用在后台耗电异常，并获取该应用在当前时间点之后第二预设时长内的运行数据；将该运行数据发送给服务器20。

服务器20用于对根据该运行数据获取该应用的耗电异常原因，其中，该耗电异常原因是指该应用在该第二预设时长内调用的至少一个目标调用栈，该至少一个目标调用栈是指调用次数大于预设次数和/或执行时长大于第三预设时长的调用栈。

进一步地，服务器20获取该用的耗电异常原因之后，还可以将该耗电异常原因发送给终端10。

图2是本发明实施例提供的一种应用耗电监控方法的流程图，该方法的执行主体可以为终端。参见图2，该方法包括：

步骤201：终端在自应用切换至后台运行起的两个时间点，分别确定该应用对处理器的已占用时长，得到第一时长和第二时长，这两个时间点相距第一预设时长。

其中，该应用可以为终端安装的任一应用。这两个时间点可以包括第一时间点和第二时间点，第一时间点可以为该应用切换至后台运行的时间点或者该应用切换至后台运行之后的任一时间点，第二时间点为第一时间点之后且与第一时间点相距第一预设时长的时间点。

其中，该第一预设时长为预先设置的两个时间点的相距时长，且该第一预设时长可以由用户设置，也可以由终端默认设置，本发明实施例对此不做限定。例如，该第一预设时长可以为5分钟、8分钟或10分钟等。

其中，处理器是指该终端的运算中心和控制中心，例如该处理器可以为CPU(Central Processing Unit，中央处理器)。应用对处理器的已占用时长是从终端启动开始累计得到的，在任一时间点该应用对处理器的已占用时长是指从终端启动开始到当前时间点为止的时间范围内处理器分配给该应用的总处理时长，即在该时间范围内处理器处理该应用进程的总时长。

需要说明的是，应用在切换至后台运行之后，耗电主要是通过对处理器的占用产生的，因此本发明实施例中，为了监控该应用在后台的耗电情况，可以在该应用切换至后台运行之后任意相距第一预设时长的两个时间点，分别确定该应用对处理器的已占用时长，以根据该应用在这两个时间点对处理器的已占用时长，确定该应用在该第一预设时长的耗电情况。

具体的，步骤201的实现过程可以包括：在该应用切换至后台运行时，确定该应用对处理器的已占用时长，得到第一时长，当该应用在后台运行的时长达到第一预设时长时，再次确定该应用对处理器的已占用时长，得到第二时长。或者，在该应用切换至后台运行的任一时刻，确定该应用对处理器的已占用时长，得到第一时长，然后在与该任一时刻相距第一预设时长的时刻，再次确定该应用对处理器的已占用时长，得到第二时长。

进一步地，本发明实施例中，还可以先确定该应用已占用处理器的时间片，然后将该应用已占用处理器的时间片确定为该应用对处理器的已占用时长。其中，在任一时间点该应用已占用处理器的时间片是指到该任一时间点为止处理器已为该应用分配了多少个时间片，时间片是指操作系统预先将处理器的时间划分成的长短相同的微小时间区间。例如，时间片的单位可以为Jiffies，Jiffies是指一个代表时间的变量，其单位为1/HZ，HZ表示每秒钟的最小时间间隔的数量。

具体地，确定该应用对处理器的已占用时长的操作可以包括：确定该应用分别在用户态(User Mode)和核心态(Kernel Mode)的已运行时长；根据该应用分别在用户态和核心态的已运行时长，确定该应用对该处理器的已占用时长。

其中，用户态和核心态是处理器的两种状态。用户态一般用于执行用户程序，用户程序是指非操作系统程序，比如非操作系统提供的定位程序等。核心态一般用于执行操作系统程序。用户态和核心态的主要差别在于：当应用在用户态运行时，应用进程所能访问的内存空间和对象受到限制，其所占的处理时机是可被抢占的；当应用在核心态运行时，应用进程能访问所有的内存空间和对象，且所占的处理时机是不允许被抢占的。实际应用中，运行在用户态的应用不能直接访问操作系统内核数据结构和程序，当通过处理器运行一个应用时，该应用大部分时间是运行在用户态下的，当该应用需要操作系统帮助完成某些在用户态下没有权利和能力完成的工作时，就会切换到在内核态下运行。因此，本发明实施例中，可以根据该应用分别在用户态和核心态的已运行时长，确定该应用对该处理器的已占用时长。

具体地，在确定得到该应用在用户态和核心态的已运行时长之后，可以将该应用分别在用户态和核心态的已运行时长进行相加，得到该应用对该处理器的已占用时长。

具体地，确定该应用分别在用户态和核心态的已运行时长的操作可以包括：调用系统信息接口，通过该系统信息接口获取该应用的进程信息；从该进程信息中获取该应用在用户态的已运行时长，并从该进程信息中获取该应用在核心态的已运行时长。

其中，该应用的进程信息包括从终端启动开始累计的处理器对该应用进程的处理信息，具体可以包括该应用分别在用户态和核心态的已运行时长。该系统信息接口用于获取系统信息，实际应用中，该系统信息接口可以通过插件或代码等形式实现，例如，该系统信息接口可以为函数代码“/proc/<pid>/stat”。

进一步地，本发明实施例中，还可以确定该应用分别在用户态和核心态已占用处理器的时间片，然后将该应用分别在用户态和核心态已占用处理器的时间片进行相加，得到该应用已占用处理器的时间片，并将该应用已占用处理器的时间片作为该应用对处理器的已占用时长。

例如，假设终端在这两个时间点中的一个时间点通过系统信息接口“/proc/<pid>/stat”获取的该应用的进程信息如下所示：

Shamu:/proc/6966$cat stat

6966(com.tencent.mtt)$399 399 0 0 -1 1077936448 530978 3639 2392 411242 20692 6 2 20 0 139 0 41 41312 2373185536 61469 4294967295 1 1 0 0 0 04612 4096 34040 4294967295 0 0 17 2 0 0 0 0 0 0 0 0 0 0 0 0 0

Shamu:/proc/6966$

其中，上述进程信息中的第二行中的第14个参数为11242，第15个参数为20692。11242是指该应用在用户态运行的时间，即在用户态已占用处理器的时间片，单位为Jiffies；20692是指该应用在核心态运行的时间，即在核心态已占用处理器的时间片。因此，在该时间点该应用对处理器的已占用时长(第一时长)＝11242+20692＝31934(Jiffies)。

进一步地，确定得到第一时长和第二时长之后，还可以计算该第一时长和第二时长的差值，并将该第一时长和第二时长的差值与预设阈值进行比较，来判断该应用是否在后台耗电异常。

其中，该第一时长和第二时长的差值可以指示该应用在该第一预设时长内对处理器的占用时长，该预设阈值为预先设置的该应用在该第一预设时长内对处理器的占用时长的上限值。当该第一时长和第二时长的差值大于该预设阈值时，表示该应用在后台耗电较多，进而可以确定该应用在后台耗电异常，当该第一时长和第二时长的差值小于或等于该预设阈值时，表示该应用在后台耗电较少，进而可以确定该应用在后台耗电正常。

实际应用中，该预设阈值可以由开发人员根据经验设置，也可以由终端默认设置，本发明实施例对此不做限定。例如，在一个实现方式中，可以由开发人员参考该终端厂商的后台耗电评判标准进行设置。

步骤202：当该第一时长和该第二时长的差值大于预设阈值时，终端确定该应用在后台耗电异常，并获取该应用在当前时间点之后第二预设时长内的运行数据。

也即是，当确定该应用在后台耗电异常时，可以开始获取该应用在后台运行的运行数据，直至获取时长达到该第二预设时长时停止获取，以得到该应用在该第二预设时长内的运行数据。

其中，该第二预设时长为预先设置的获取该应用的后台运行数据的时长，实际应用中，该第二预设时长可以由用户预先设置，也可以由终端默认设置，本发明实施例对此不做限定。

其中，该运行数据可以指示该应用在该第二预设时长内都有哪些线程在运行，以及每个线程里都在做哪些事情。具体地，该运行数据可以包括每个目标线程执行的方法组成的调用栈、以及每个目标线程执行的方法中每个方法的执行时长和/或调用次数。其中，目标线程是指该应用在该第二预设时长内运行的线程。

进一步地，该运行数据还可以包括该应用在该第二预设时长内运行的所有目标线程和所有目标线程中每个线程执行的方法，以详细展示该应用在该第二预设时长内运行了哪些线程，以及每个线程执行了哪些方法。进一步地，该运行数据还可以包括每个方法的时间占比，每个方法的时间占比是指该方法的执行时长占该所有目标线程执行的所有方法的总执行时长的百分比，以通过时间占比更为清晰地展示各个方法的执行时长的大小。

需要说明的是，对于每个目标线程而言，每个目标线程执行的方法还可以在该目标线程中调用其他方法，使得该目标线程在执行完该当前方法之后继续执行当前方法调用的下一个方法，这样依次调用的多个方法即可构成一条方法链，且每条方法链可以用调用栈表示，也即是，调用栈由依次调用的多个方法构成。而且，每个调用栈可以实质指示该应用执行的一个具体任务，从而根据该应用在该第二预设时长内的所有目标线程调用的调用栈，能够确定出该应用在该第二预设时长内执行了哪些任务，即该应用在该预设时长内具体做了哪些事情。

具体地，获取该应用在当前时间点之后第二预设时长内的运行数据的操作可以包括：调用性能分析功能，通过该性能分析功能获取该应用在该第二预设时长内的运行数据。

其中，该性能分析功能用于获取任一应用的运行数据，以根据获取的运行数据分析应用的性能。实际应用中，该性能分析功能可以通过程序、插件或代码等形式实现。例如，该性能分析功能可以为Method Profiling(方法分析)，Method Profiling是第三方供应商为开发者提供的一款性能分析工具，主要用于获取任一应用在特定时间段内的运行数据，以根据获取的运行数据分析该应用的性能瓶颈或界面流畅度等性能问题。

在一个实施例中，通过性能分析功能获取该应用在该第二预设时长内的运行数据可以包括：当确定该应用在后台耗电异常时，调用该性能分析功能的开始接口，通过该开始接口开始获取该应用的在后台的运行数据；当获取时间达到该第二预设时长时，调用该性能分析功能的停止接口，通过该停止接口停止获取该应用在后台的运行数据；在停止获取该应用在后台的运行数据之后，该性能分析功能即可在终端的指定内存中生成数据文件，且该数据文件包括该应用在该第二预设时长内的运行数据。

在一个实施例中，当该性能分析功能为Method Profiling时，该性能分析功能的开始接口可以为函数代码“Debug.startMethodTracing”，该性能分析功能的停止接口可以为函数代码“Debug.stopMethodTracing”，该数据文件可以为跟踪(Trace)文件等。

例如，以该性能分析功能为Method Profiling为例，当确定该应用在后台耗电异常时，调用“Debug.startMethodTracing”开始获取该应用的在后台的运行数据，当获取时间达到该第二预设时长时，调用“Debug.stopMethodTracing”停止获取该应用在后台的运行数据，以在终端的指定内存中生成一个Trace文件，且该Trace文件包括该应用在该第二预设时长内的运行数据。

示例的，通过Method Profiling生成的Trace文件的数据内容可以如下所示：

1 *version

2 3

3 data-file-overflow＝false

4 clock＝dual

5 elapsed-time-usec＝900939

6 num-method-calls＝203844

7 clock-call-overhead-nsec＝2014

8 vm＝art

9 pid＝3212

10 *threads

11 3212——>main

12 3218——>Jit.thread.pool.worker.thread.0

13 3219——>Signal.Catcher

14 3221——>JDWP

15 3222——>ReferenceQueueDaemon

16 3223——>FinalizerDaemon

17 3224——>FinalizerWatchdogDaemon

18 3225——>HeapTaskDaemon

19 3229——>Binder:3212_1

20 3232——>Binder:3212_2

21 3242——>Profile Saver

……

42 *methods

43 0x1934——>java.lang.BootClassLoader——>getInstance——>()Liava/lang/BootClassLoader；——>ClassLoader.java

44 0x21c4——>java.lang.BootClassLoader——>findClass——>(Ljava/lang/String；)Ljava/lang/Class；——>ClassLoader.java

45 0x21c0——>java.lang.BootClassLoader——>loadClass——>(Ljava/lang/String；z)Ljava/lang/Class；——>ClassLoader.java

46 0x21b4——>java.lang.ClassLoader——>findLoadedClass>(Ljava/lang/String；z)Ljava/lang/Class；——>ClassLoader.java

47 0x21ac——>java.lang.ClassLoader——>loadClass——>(Ljava/lang/String；)Ljava/lang/Class；——>ClassLoader.java

48 0x21b0——>java.lang.ClassLoader——>loadClass——>(Ljava/lang/String；z)Ljava/lang/Class；——>ClassLoader.java

49 0x221c——>java.lang.ClassNotFoundException——><init>——>(Ljava/lang/String；)V——>ClassNotFoundException.java

50 0x21c8——>java.lang.ClassNotFoundException——><init>——>(Ljava/lang/String；Ljava/lang/Throwable；)V——>ClassNotFoundException.java

51 0x2220——>java.lang.ClassNotFoundException——>getCause——>()Java/lang/Throwable；—>ClassNotFoundException.java

52 0x2c38——>java.lang.RuntimeException——><init>——>(Ljava/lang/String；)V——>RuntimeException.java

53 0x3328——>java.lang.ThreadGroup——>add—>(Ljava/lang/Thread；)V——>ThreadGroup.java

54 0x32f8——>java.lang.ThreadGroup——>addUnstarted——>()V—>ThreadGroup.java

55 0x14c——>java.nio.DirectByteBuffer——>getInt——>(J)I——>DirectByteBuffer.java

56 0x13c——>java.nio.DirectByteBuffer——>getShort——>(J)S——>Direct ByteBuffer.java

57 0x138——>java.nio.DirectByteBuffer——>ix——>(I)J——>DirectByteBuffer.java

58 0x2610——>java.nio.DirectByteBuffer——>getCharUnchecked——>(I)C——>DirectByteBuffer.java

59 0x148——>java.nio.DirectByteBuffer——>getInt——>(I)I——>DirectByteBuffer.java

60 0x130——>java.nio.DirectByteBuffer——>getShort——>(I)S——>DirectByteBuffer.java

上述数据内容中的43-60行示出了该应用在该预设时长内运行的所有目标线程、每个目标线程调用的方法和每个目标线程中调用的方法构成的方法链，每个方法链可以指示一个调用栈，也即是，上述数据内容中的43-60相当于目标调用栈列表。

步骤203：终端根据该运行数据，获取该应用的耗电异常原因。

也即是，终端可以对该运行数据进行分析，得到该应用的耗电异常原因。其中，该耗电异常原因是指该应用在该第二预设时长内调用的至少一个目标调用栈，该至少一个目标调用栈是指调用次数大于预设次数和/或执行时长大于第三预设时长的调用栈。

其中，该预设次数和第三预设时长可以预先设置，具有可以由技术人员根据经验进行设置，也可以由终端默认设置，本发明实施例对此不做限定。

具体地，当该运行数据包括每个目标线程执行的方法组成的调用栈、以及每个目标线程执行的方法中每个方法的执行时长和/或调用次数时，步骤203可以通过以下步骤2031-2033实现：

步骤2031：对每个目标线程执行的方法组成的调用栈、以及每个目标线程执行的方法中每个方法的执行时长和/或调用次数进行统计，得到所有目标线程调用的方法构成的调用栈中每个调用栈的调用次数和/或执行时长。

具体地，可以对每个目标线程执行的方法组成的调用栈、以及每个目标线程执行的方法中每个方法的执行时长进行统计，得到所有目标线程调用的方法构成的调用栈中每个调用栈的执行时长；或者，可以对每个目标线程执行的方法组成的调用栈、以及每个目标线程执行的方法中每个方法的调用次数进行统计，得到所有目标线程调用的方法构成的调用栈中每个调用栈的调用次数；或者，也可以对每个目标线程执行的方法组成的调用栈、以及每个目标线程执行的方法中每个方法的执行时长和调用次数进行统计，得到所有目标线程调用的方法构成的调用栈中每个调用栈的调用次数和执行时长。

其中，每个调用栈的执行时长是指构成该调用栈的每个方法的执行时长的总和。具体地，对于该应用在该第二预设时长内运行的所有目标线程中的每个目标线程，可以确定该目标线程中执行的所有方法构成的至少一个调用栈，对于该至少一个调用栈中的每个调用栈，确定每个调用栈的调用次数，或者，也可以确定构成该调用栈的所有方法中每个方法的执行时长，将构成每个调用栈的所有方法的执行时长进行相加，得到每个调用栈的执行时长。

步骤2032：根据所有目标线程调用的方法构成的调用栈中每个调用栈的调用次数和/或执行时长，从所有目标线程调用的方法构成的调用栈中确定至少一个目标调用栈，该至少一个目标调用栈是指调用次数大于预设次数和/或执行时长大于第三预设时长的调用栈。

也即是，可以将所有目标线程调用的方法构成的调用栈中调用次数大于预设次数的调用栈确定为该至少一个目标调用栈，或者将所有目标线程调用的方法构成的调用栈中执行时长大于第三预设时长的调用栈确定为该至少一个目标调用栈，或者将所有目标线程调用的方法构成的调用栈中调用次数大于预设次数且执行时长大于第三预设时长的调用栈确定为该至少一个目标调用栈。

步骤2033：将该至少一个目标调用栈，确定为该应用的耗电异常原因。

该应用在该第二预设时长内运行的所有目标线程调用的全部调用栈实质上可以指示该应用在该第二预设时长内执行了哪些任务，即该应用在该第二预设时长内具体做了哪些事情。由于该至少一个目标调用栈是该应用在该第二预设时长内运行的所有目标线程调用的所有调用栈中调用次数较多和/或执行时长较长的调用栈，即频繁调用和/或占用时间较长的调用栈，因此该至少一个目标调用栈也就指示了该应用在该第二预设时长内频繁执行的任务和/或占用时间较长的任务，这些任务就是导致该应用在后台耗电较多的原因，因此可以将该至少一个目标调用栈确定为该应用的耗电异常原因。

实际应用中，得到该运行数据之后，还可以通过数据分析功能对该运行数据进行分析，得到该应用的耗电异常原因。其中，该数据分析功能可以通过程序、插件、脚本或代码等形式实现，本发明实施例对此不做限定。例如，本发明实施例中，可以运行技术人员预先编程的脚本，通过该脚本对该运行数据进行分析，得到该应用的耗电异常原因。

进一步地，当通过性能分析功能生成了一个包括该运行数据的数据文件时，还可以通过该数据分析功能打开该数据文件，并对该数据文件进行分析。其中，该数据分析功能用于打开该数据文件，并对该数据文件进行分析处理。实际应用中，该文件处理功能可以为DDMS(Dalvik Debug Monitor Service，Dalvik虚拟机调试监控服务)等。

以该性能分析功能为Method Profiling、该数据文件为通过Method Profiling生成的Trace文件为例，得到该数据文件之后，可以通过DDMS打开该Trace文件，并对该Trace文件进行分析。示例的，将Trace文件通过DDMS打开之后所显示的内容可以如图3所示。

进一步地，在根据该运行数据获取到该应用的耗电异常原因之后，该终端还可以将该耗电异常原因展示给终端用户，由终端用户根据该耗电异常原因有效解决该应用的后台耗电问题，提高终端的使用性能。或者，也可以将该应用的耗电异常原因发送给服务器，通过服务器将该耗电异常原因展示给该应用的开发人员，如此可以提高开发人员发现问题和解决问题的效率，使得开发人员能够根据该耗电异常原因有针对性地解决该应用在后台的耗电异常问题，进而有效地对该应用进行优化，提高用户体验。

其中，该服务器可以为该应用的后台服务器，也可以为专门用于对各种应用的耗电情况进行监控和分析的服务器，本发明实施例对此不做限定。在一个实施例中，终端可以将该至少一个目标调用栈存储在一个调用栈列表中，并将该调用栈列表作为该耗电异常原因发送给服务器。在一个示例中，该调用栈列表可以如下所示：

Java.lang.String.charAt(I)C

Java.lang.String.equals(Ljava.lang.Object；)Z

Java.util.HashMap.get(Ljava.lang.Object；)Ljava.lang.Object；

Org.chromium.base.WebStatus.a(Ljava.lang.String；)Lorg.chromlum.base.WebSt atus；

Org.chromium.base.WebStatus.a(Ljava.lang.String；I)V

Com.tencent.smtt.webkit.WebViewChromiumExtension.didFinishLoad(JLjava.l ang.String；Z)V

Org.chromium.base.SystemMessageHandler.nativeDoRunLoopOnce(JJ)V

Org.chromium.base.SystemMessageahandler.handleMessage(Landroid.os.Messa ge；)V

Android.os.Handler.dispatchMessage(Landroid.os.Nessage；)V

上述表中记录了9个目标调用栈，这9个目标调用栈即为引起该应用在后台耗电异常的原因，也即是，该应用在后台的耗电异常是因频繁调用了和/或较长时间地执行了这9个目标调用栈所导致的。

实际应用中，应用在后台的耗电问题一般都是由于开发人员设计不够成熟导致的，例如，假设一个应用具有在界面上定时刷新数据的逻辑，但是当该应用切换至后台时，该应用的刷新逻辑并没有停止，这就会导致该应用在后台持续耗电。本发明实施例中，通过在检测到该应用在后台耗电异常时，采集该应用的后台运行数据，并对该后台运行数据进行分析，可以得出该应用的耗电异常原因是在后台执行了该刷新逻辑，如此，开发人员即可方便地根据该耗电异常原因针对性地删除该应用在后台运行的刷新逻辑，从而可以实现对该应用的优化，提高了用户体验。

本发明实施例中，对于切换至后台运行的应用，终端可以根据该应用在自切换至后台起的两个时间点分别对处理器的已占用时长，检测该应用在后台是否耗电异常，并可以在该应用在后台耗电异常时，获取该应用的运行数据，然后根据该运行数据获取该应用的耗电异常原因。其中，耗电异常原因是指该应用在后台运行过程中调用的调用次数较多和/或执行时长较长的调用栈，能够反映该应用在后台频繁执行或执行时间较长的具体任务，因此这些任务即为导致该应用在后台异常耗电的原因。如此，终端不仅可以及时检测到应用在后台的耗电异常现象，还可以在检测到该应用在后台耗电异常时，通过获取该应用的后台运行数据分析该应用的耗电异常原因，以便根据该耗电异常原因有效解决该应用的后台耗电问题，实现对应用的优化，进而提高终端的使用性能。

图4是本发明实施例提供的另一种应用耗电监控方法的流程图，该方法由终端和服务器交互实现。参见图4，该方法包括：

步骤401：终端在自应用切换至后台运行起的两个时间点，分别确定该应用对处理器的已占用时长，得到第一时长和第二时长，这两个时间点相距第一预设时长。

具体地，步骤401的实现过程可以参考上述步骤201的相关描述，本发明实施例在此不再赘述。

步骤402：当该第一时长和该第二时长的差值大于预设阈值时，终端确定该应用在后台耗电异常，并获取该应用在当前时间点之后第二预设时长内的运行数据。

具体地，步骤402的实现过程可以参考上述步骤202的相关描述，本发明实施例在此不再赘述。

步骤403：终端将该运行数据发送给服务器。

其中，该服务器可以为该应用的后台服务器，也可以为专门用于对各种应用的耗电情况进行检测和分析的服务器，本发明实施例对此不做限定。

进一步地，该终端还可以先检测该终端的网络状态，当检测到该终端处于与无线局域网连接的网络状态时，再执行将该运行数据发送给服务器的步骤，当检测到该终端未处于与无线局域网连接的网络状态时，则不将该运行数据发送给服务器，如此可以实现仅在与无线局域网连接的网络状态向服务器上报数据，从而可以避免该终端的流量损失。

具体地，当检测到该终端未处于与无线局域网连接的网络状态时，不将该运行数据发送给服务器包括：当检测到该终端未处于与无线局域网连接的网络状态时，将该运行数据存储在本地，当后续检测到该终未处于与无线局域网连接的网络状态时，再从本地存储空间中获取该运行数据，并将该运行数据发送给服务器。如此，不仅可以避免该终端的流量损失，还可以避免遗漏上报该运行数据。

实际应用中，该无线局域网可以为WIFI(WIreless-Fidelity，无线保真)网络或蓝牙网络，当然也可以为其他无线局域网，本发明实施例对此不做限定。

步骤404：服务器接收该运行数据，并根据该运行数据获取该应用的耗电异常原因。

也即是，服务器可以对该运行数据进行分析，得到该应用的耗电异常原因。其中，该耗电异常原因是指该应用在第二预设时长内调用的至少一个目标调用栈，该至少一个目标调用栈是指调用次数大于预设次数和/或执行时长大于第三预设时长的调用栈。

需要说明的是，与上述图2所述的实施例不同之处在于，本发明实施例在获取到该运行数据之后，无需由终端自身对该运行数据进行分析，而是可以将该运行数据发送给服务器，由该服务器对该运行数据进行分析。如此，可以减少终端的运算量，避免对终端的处理资源的占用，提高终端的处理效率。而且，由于服务器的处理资源一般要远远多于终端的处理资源，因此通过将该运行数据发送给服务器，由该服务器对该运行数据进行分析，还可以提高分析效率。

具体地，服务器根据该运行数据获取该应用的耗电异常原因的方法，与上述终端对该运行数据进行分析，得到该应用的耗电异常原因的方法相同，区别仅在于执行主体不同，因此步骤404的具体实现过程可以参考上述步骤203的相关描述，本发明实施例在此不再赘述。

服务器根据该运行数据获取该应用的耗电异常原因之后，可以将该耗电异常原因反馈给该应用的开发人员，以使开发人员根据该耗电异常原因针对性的解决该应用的耗电异常问题。或者，服务器根据该运行数据获取该应用的耗电异常原因之后，也可以将该耗电异常问题发送给该终端，由该终端向终端用户展示该应用的耗电异常问题，进而使得终端用户根据该耗电异常原因针对性的解决该应用的耗电异常问题。

进一步地，对于该服务器而言，如果每个终端在检测到该应用在后台耗电异常时，都将该应用的运行数据上报给服务器，则服务器接收的和需要处理的数据量将会相当庞大，这样可能会影响该服务器的处理性能。本发明实施例中，为了提高服务器的处理性能，服务器还可以仅接收部分终端发送的该运行数据，通过对该部分终端发送的该运行数据进行分析，得到该应用的耗电异常原因，进而将该应用的耗电异常原因反馈给开发人员，由开发人员对该应用进行优化。

例如，以该服务器为该应用的后台服务器为例，对于所有安装了该应用的终端，该服务器可以通过仅启动部分终端中该应用的耗电异常检测和运行数据上报的功能，控制该部分终端在将该应用切换至后台运行时，对该应用进行耗电异常检测，并在检测到该应用在后台耗电异常时，将该应用的后台运行数据上报给服务器。

本发明实施例中，对于切换至后台运行的应用，终端可以根据该应用在自切换至后台起的两个时间点分别对处理器的已占用时长，检测该应用在后台是否耗电异常，并可以在该应用在后台耗电异常时，获取该应用的运行数据，然后将该运行数据发送给服务器，由服务器根据该运行数据获取该应用的耗电异常原因。其中，耗电异常原因是指该应用在后台运行过程中调用的调用次数较多和/或执行时长较长的调用栈，能够反映该应用在后台频繁执行或执行时间较长的具体任务，因此这些任务即为导致该应用在后台异常耗电的原因。如此，终端不仅可以及时检测到应用在后台的耗电异常现象，还可以在检测到该应用在后台耗电异常时，将应用的运行数据发送给服务器，使得服务器能够根据该运行数据获取该应用的耗电异常原因，进而便于根据该耗电异常原因有效解决该应用的后台耗电问题，实现对应用的优化，提高终端的使用性能。

图5是本发明实施例提供的一种应用耗电监控装置的结构示意图，参见图5，该装置包括：

确定模块501，用于在自应用切换至后台运行起的两个时间点，分别确定该应用对处理器的已占用时长，得到第一时长和第二时长，该两个时间点相距第一预设时长；

第一获取模块502，用于当该第一时长和该第二时长的差值大于预设阈值时，确定该应用在后台耗电异常，并获取该应用在当前时间点之后第二预设时长内的运行数据；

第二获取模块503，用于根据该运行数据获取该应用的耗电异常原因，或者，将该运行数据发送给服务器，由该服务器根据该运行数据获取该应用的耗电异常原因；

其中，该耗电异常原因是指该应用在第二预设时长内调用的至少一个目标调用栈，该至少一个目标调用栈是指调用次数大于预设次数和/或执行时长大于第三预设时长的调用栈。

可选地，第一获取模块502具体用于：

调用性能分析功能，通过该性能分析功能获取该应用在该第二预设时长内的运行数据。

可选地，该运行数据包括每个目标线程执行的方法组成的调用栈、以及该每个目标线程执行的方法中每个方法的执行时长和/或调用次数，该目标线程为该应用在该第二预设时长内运行的线程；

第二获取模块503具体用于：

对该每个目标线程执行的方法组成的调用栈、以及该每个目标线程执行的方法中每个方法的执行时长和/或调用次数进行统计，得到所有该目标线程调用的方法组成的调用栈中每个调用栈的调用次数和/或执行时长；

根据所有该目标线程调用的方法组成的调用栈中每个调用栈的调用次数和/或执行时长，从所有该目标线程调用的方法组成的调用栈中确定该至少一个目标调用栈；

将该至少一个目标调用栈，确定为该应用的耗电异常原因。

可选地，第二获取模块503具体用于：

将该运行数据发送给服务器，由该服务器根据该运行数据获取该应用的耗电异常原因；

接收该服务器发送的该耗电异常原因。

可选地，确定模块501包括：

第一确定单元，用于确定该应用分别在用户态和核心态的已运行时长；

第二确定单元，用于根据该应用分别在用户态和核心态的已运行时长，确定该应用对该处理器的已占用时长。

可选地，第一确定单元具体用于：

调用系统信息接口，通过该系统信息接口获取该应用的进程信息；

从该进程信息中获取该应用在用户态的已运行时长，并从该进程信息中获取该应用在核心态的已运行时长。

本发明实施例中，对于切换至后台运行的应用，终端可以根据该应用在自切换至后台起的两个时间点分别对处理器的已占用时长，检测该应用在后台是否耗电异常，并可以在该应用在后台耗电异常时，获取该应用的运行数据，然后根据该运行数据获取该应用的耗电异常原因。其中，耗电异常原因是指该应用在后台运行过程中调用的调用次数较多和/或执行时长较长的调用栈，能够反映该应用在后台频繁执行或执行时间较长的具体任务，因此这些任务即为导致该应用在后台异常耗电的原因。如此，终端不仅可以及时检测到应用在后台的耗电异常现象，还可以在检测到该应用在后台耗电异常时，通过获取该应用的后台运行数据分析该应用的耗电异常原因，以便根据该耗电异常原因有效解决该应用的后台耗电问题，实现对应用的优化，进而提高终端的使用性能。

图6是本发明实施例提供的另一种应用耗电监控装置，参见图6，该装置包括：

接收模块601，用于接收终端发送的该终端中的应用在后台运行第二预设时长内的运行数据，该运行数据是该终端根据自该应用切换至后台运行起的两个时间点对处理器的已占用时长，确定该应用在后台耗电异常时开始获取的，该两个时间点相距第一预设时长；

获取模块602，用于根据该运行数据，获取该应用的耗电异常原因，该耗电异常原因是指该应用在第二预设时长内调用的至少一个目标调用栈，该至少一个目标调用栈是指调用次数大于预设次数和/或执行时长大于第三预设时长的调用栈。

可选地，该运行数据包括每个目标线程执行的方法组成的调用栈、以及该每个目标线程执行的方法中每个方法的执行时长和/或调用次数，该目标线程为该应用在该第二预设时长内运行的线程；

获取模块602具体用于：

对该每个目标线程执行的方法组成的调用栈、以及该每个目标线程执行的方法中每个方法的执行时长和/或调用次数进行统计，得到所有该目标线程调用的方法组成的调用栈中每个调用栈的调用次数和/或执行时长；

根据所有该目标线程调用的方法组成的调用栈中每个调用栈的调用次数和/或执行时长，从所有该目标线程调用的方法组成的调用栈中确定至少一个目标调用栈；

将该至少一个目标调用栈，确定为该应用的耗电异常原因。

可选地，该装置还包括：

发送模块，用于将该耗电异常原因发送给该终端。

本发明实施例中，对于切换至后台运行的应用，终端可以根据该应用在自切换至后台起的两个时间点分别对处理器的已占用时长，检测该应用在后台是否耗电异常，并可以在该应用在后台耗电异常时，获取该应用的运行数据，然后将该运行数据发送给服务器，由服务器根据该运行数据获取该应用的耗电异常原因。其中，耗电异常原因是指该应用在后台运行过程中调用的调用次数较多和/或执行时长较长的调用栈，能够反映该应用在后台频繁执行或执行时间较长的具体任务，因此这些任务即为导致该应用在后台异常耗电的原因。如此，服务器可以根据终端发送的运行数据获取终端中该应用的耗电异常原因，进而便于根据该耗电异常原因有效解决该应用的后台耗电问题，实现对应用的优化，提高终端的使用性能。

需要说明的是：上述实施例提供的应用耗电监控装置在对应用的耗电情况进行检测时，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将装置的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。另外，上述实施例提供的应用耗电监控装置与应用耗电监控方法实施例属于同一构思，其具体实现过程详见方法实施例，这里不再赘述。

图7是本发明实施例提供的一种终端700的结构示意图。该终端700可以是：智能手机、平板电脑、MP3播放器(Moving Picture Experts Group Audio Layer III，动态影像专家压缩标准音频层面3)、MP4(Moving Picture Experts Group Audio Layer IV，动态影像专家压缩标准音频层面4)播放器、笔记本电脑或台式电脑。终端700还可能被称为用户设备、便携式终端、膝上型终端、台式终端等其他名称。

通常，终端700包括有：处理器701和存储器702。

处理器701可以包括一个或多个处理核心，比如4核心处理器、8核心处理器等。处理器701可以采用DSP(Digital Signal Processing，数字信号处理)、FPGA(Field－Programmable Gate Array，现场可编程门阵列)、PLA(Programmable Logic Array，可编程逻辑阵列)中的至少一种硬件形式来实现。处理器701也可以包括主处理器和协处理器，主处理器是用于对在唤醒状态下的数据进行处理的处理器，也称处理器(CentralProcessing Unit，中央处理器)；协处理器是用于对在待机状态下的数据进行处理的低功耗处理器。在一些实施例中，处理器701可以在集成有GPU(Graphics Processing Unit，图像处理器)，GPU用于负责显示屏所需要显示的内容的渲染和绘制。一些实施例中，处理器701还可以包括AI(Artificial Intelligence，人工智能)处理器，该AI处理器用于处理有关机器学习的计算操作。

存储器702可以包括一个或多个计算机可读存储介质，该计算机可读存储介质可以是非暂态的。存储器702还可包括高速随机存取存储器，以及非易失性存储器，比如一个或多个磁盘存储设备、闪存存储设备。在一些实施例中，存储器702中的非暂态的计算机可读存储介质用于存储至少一个指令，该至少一个指令用于被处理器701所执行以实现本申请中方法实施例提供的应用耗电监控方法。

在一些实施例中，终端700还可选包括有：外围设备接口703和至少一个外围设备。处理器701、存储器702和外围设备接口703之间可以通过总线或信号线相连。各个外围设备可以通过总线、信号线或电路板与外围设备接口703相连。具体地，外围设备包括：射频电路704、触摸显示屏705、摄像头706、音频电路707、定位组件708和电源709中的至少一种。

外围设备接口703可被用于将I/O(Input/Output，输入/输出)相关的至少一个外围设备连接到处理器701和存储器702。在一些实施例中，处理器701、存储器702和外围设备接口703被集成在同一芯片或电路板上；在一些其他实施例中，处理器701、存储器702和外围设备接口703中的任意一个或两个可以在单独的芯片或电路板上实现，本实施例对此不加以限定。

射频电路704用于接收和发射RF(Radio Frequency，射频)信号，也称电磁信号。射频电路704通过电磁信号与通信网络以及其他通信设备进行通信。射频电路704将电信号转换为电磁信号进行发送，或者，将接收到的电磁信号转换为电信号。可选地，射频电路704包括：天线系统、RF收发器、一个或多个放大器、调谐器、振荡器、数字信号处理器、编解码芯片组、用户身份模块卡等等。射频电路704可以通过至少一种无线通信协议来与其它终端进行通信。该无线通信协议包括但不限于：城域网、各代移动通信网络(2G、3G、4G及5G)、无线局域网和/或WiFi(Wireless Fidelity，无线保真)网络。在一些实施例中，射频电路704还可以包括NFC(Near Field Communication，近距离无线通信)有关的电路，本申请对此不加以限定。

显示屏705用于显示UI(User Interface，用户界面)。该UI可以包括图形、文本、图标、视频及其它们的任意组合。当显示屏705是触摸显示屏时，显示屏705还具有采集在显示屏705的表面或表面上方的触摸信号的能力。该触摸信号可以作为控制信号输入至处理器701进行处理。此时，显示屏705还可以用于提供虚拟按钮和/或虚拟键盘，也称软按钮和/或软键盘。在一些实施例中，显示屏705可以为一个，设置终端700的前面板；在另一些实施例中，显示屏705可以为至少两个，分别设置在终端700的不同表面或呈折叠设计；在再一些实施例中，显示屏705可以是柔性显示屏，设置在终端700的弯曲表面上或折叠面上。甚至，显示屏705还可以设置成非矩形的不规则图形，也即异形屏。显示屏705可以采用LCD(LiquidCrystal Display，液晶显示屏)、OLED(Organic Light-Emitting Diode,有机发光二极管)等材质制备。

摄像头组件706用于采集图像或视频。可选地，摄像头组件706包括前置摄像头和后置摄像头。通常，前置摄像头设置在终端的前面板，后置摄像头设置在终端的背面。在一些实施例中，后置摄像头为至少两个，分别为主摄像头、景深摄像头、广角摄像头、长焦摄像头中的任意一种，以实现主摄像头和景深摄像头融合实现背景虚化功能、主摄像头和广角摄像头融合实现全景拍摄以及VR(Virtual Reality，虚拟现实)拍摄功能或者其它融合拍摄功能。在一些实施例中，摄像头组件706还可以包括闪光灯。闪光灯可以是单色温闪光灯，也可以是双色温闪光灯。双色温闪光灯是指暖光闪光灯和冷光闪光灯的组合，可以用于不同色温下的光线补偿。

音频电路707可以包括麦克风和扬声器。麦克风用于采集用户及环境的声波，并将声波转换为电信号输入至处理器701进行处理，或者输入至射频电路704以实现语音通信。出于立体声采集或降噪的目的，麦克风可以为多个，分别设置在终端700的不同部位。麦克风还可以是阵列麦克风或全向采集型麦克风。扬声器则用于将来自处理器701或射频电路704的电信号转换为声波。扬声器可以是传统的薄膜扬声器，也可以是压电陶瓷扬声器。当扬声器是压电陶瓷扬声器时，不仅可以将电信号转换为人类可听见的声波，也可以将电信号转换为人类听不见的声波以进行测距等用途。在一些实施例中，音频电路707还可以包括耳机插孔。

定位组件708用于定位终端700的当前地理位置，以实现导航或LBS(LocationBased Service，基于位置的服务)。定位组件708可以是基于美国的GPS(GlobalPositioning System，全球定位系统)、中国的北斗系统、俄罗斯的格雷纳斯系统或欧盟的伽利略系统的定位组件。

电源709用于为终端700中的各个组件进行供电。电源709可以是交流电、直流电、一次性电池或可充电电池。当电源709包括可充电电池时，该可充电电池可以支持有线充电或无线充电。该可充电电池还可以用于支持快充技术。

在一些实施例中，终端700还包括有一个或多个传感器710。该一个或多个传感器710包括但不限于：加速度传感器711、陀螺仪传感器712、压力传感器713、指纹传感器714、光学传感器715以及接近传感器716。

加速度传感器711可以检测以终端700建立的坐标系的三个坐标轴上的加速度大小。比如，加速度传感器711可以用于检测重力加速度在三个坐标轴上的分量。处理器701可以根据加速度传感器711采集的重力加速度信号，控制触摸显示屏705以横向视图或纵向视图进行用户界面的显示。加速度传感器711还可以用于游戏或者用户的运动数据的采集。

陀螺仪传感器712可以检测终端700的机体方向及转动角度，陀螺仪传感器712可以与加速度传感器711协同采集用户对终端700的3D动作。处理器701根据陀螺仪传感器712采集的数据，可以实现如下功能：动作感应(比如根据用户的倾斜操作来改变UI)、拍摄时的图像稳定、游戏控制以及惯性导航。

压力传感器713可以设置在终端700的侧边框和/或触摸显示屏705的下层。当压力传感器713设置在终端700的侧边框时，可以检测用户对终端700的握持信号，由处理器701根据压力传感器713采集的握持信号进行左右手识别或快捷操作。当压力传感器713设置在触摸显示屏705的下层时，由处理器701根据用户对触摸显示屏705的压力操作，实现对UI界面上的可操作性控件进行控制。可操作性控件包括按钮控件、滚动条控件、图标控件、菜单控件中的至少一种。

指纹传感器714用于采集用户的指纹，由处理器701根据指纹传感器714采集到的指纹识别用户的身份，或者，由指纹传感器714根据采集到的指纹识别用户的身份。在识别出用户的身份为可信身份时，由处理器701授权该用户执行相关的敏感操作，该敏感操作包括解锁屏幕、查看加密信息、下载软件、支付及更改设置等。指纹传感器714可以被设置终端700的正面、背面或侧面。当终端700上设置有物理按键或厂商Logo时，指纹传感器714可以与物理按键或厂商Logo集成在一起。

光学传感器715用于采集环境光强度。在一个实施例中，处理器701可以根据光学传感器715采集的环境光强度，控制触摸显示屏705的显示亮度。具体地，当环境光强度较高时，调高触摸显示屏705的显示亮度；当环境光强度较低时，调低触摸显示屏705的显示亮度。在另一个实施例中，处理器701还可以根据光学传感器715采集的环境光强度，动态调整摄像头组件706的拍摄参数。

接近传感器716，也称距离传感器，通常设置在终端700的前面板。接近传感器716用于采集用户与终端700的正面之间的距离。在一个实施例中，当接近传感器716检测到用户与终端700的正面之间的距离逐渐变小时，由处理器701控制触摸显示屏705从亮屏状态切换为息屏状态；当接近传感器716检测到用户与终端700的正面之间的距离逐渐变大时，由处理器701控制触摸显示屏705从息屏状态切换为亮屏状态。

本领域技术人员可以理解，图7中示出的结构并不构成对终端700的限定，可以包括比图示更多或更少的组件，或者组合某些组件，或者采用不同的组件布置。

图8是本发明实施例提供的一种服务器800的结构示意图，该服务器800可因配置或性能不同而产生比较大的差异，可以包括一个或一个以上处理器(central processingunits，CPU)801和一个或一个以上的存储器802，其中，所述存储器802中存储有至少一条指令，所述至少一条指令由所述处理器801加载并执行以实现上述各个方法实施例提供的应用耗电监控方法。当然，该服务器800还可以具有有线或无线网络接口、键盘以及输入输出接口等部件，以便进行输入输出，该服务器800还可以包括其他用于实现设备功能的部件，在此不做赘述。

在示例性实施例中，还提供了一种计算机可读存储介质，例如包括指令的存储器，上述指令可由上述终端或服务器中的处理器执行以完成上述实施例中的应用耗电监控方法。例如，所述计算机可读存储介质可以是ROM、随机存取存储器(RAM)、CD-ROM、磁带、软盘和光数据存储设备等。

本领域普通技术人员可以理解实现上述实施例的全部或部分步骤可以通过硬件来完成，也可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，上述提到的存储介质可以是只读存储器，磁盘或光盘等。

以上所述仅为本发明的较佳实施例，并不用以限制本发明，凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (12)

1.一种应用耗电监控方法，其特征在于，所述方法包括：

在自应用切换至后台运行起的两个时间点，分别确定所述应用对处理器的已占用时长，得到第一时长和第二时长，所述两个时间点相距第一预设时长；

当所述第一时长和所述第二时长的差值大于预设阈值时，确定所述应用在后台耗电异常，并获取所述应用在当前时间点之后第二预设时长内的运行数据；

根据所述运行数据获取所述应用的耗电异常原因，或者，将所述运行数据发送给服务器，由所述服务器根据所述运行数据获取所述应用的耗电异常原因；

其中，所述耗电异常原因是指所述应用在所述第二预设时长内调用的至少一个目标调用栈，所述至少一个目标调用栈是指调用次数大于预设次数和/或执行时长大于第三预设时长的调用栈；

所述运行数据包括每个目标线程执行的方法组成的调用栈、以及所述每个目标线程执行的方法中每个方法的执行时长和/或调用次数，所述目标线程为所述应用在所述第二预设时长内运行的线程；所述根据所述运行数据获取所述应用的耗电异常原因，包括：

对所述每个目标线程执行的方法组成的调用栈、以及所述每个目标线程执行的方法中每个方法的执行时长和/或调用次数进行统计，得到所有所述目标线程调用的方法组成的调用栈中每个调用栈的调用次数和/或执行时长，每个调用栈指示应用执行的一个具体任务，每个调用栈的执行时长是指构成所述每个调用栈的每个方法的执行时长的总和；

根据所有所述目标线程调用的方法组成的调用栈中每个调用栈的调用次数和/或执行时长，从所有所述目标线程调用的方法组成的调用栈中确定所述至少一个目标调用栈；将所述至少一个目标调用栈，确定为所述应用的耗电异常原因。

2.如权利要求1所述的方法，其特征在于，所述获取所述应用在当前时间点之后第二预设时长内的运行数据，包括：

调用性能分析功能，通过所述性能分析功能获取所述应用在所述第二预设时长内的运行数据。

3.如权利要求1或2所述的方法，其特征在于，所述将所述运行数据发送给服务器，由所述服务器根据所述运行数据获取所述应用的耗电异常原因，包括：

将所述运行数据发送给服务器，由所述服务器根据所述运行数据获取所述应用的耗电异常原因；

接收所述服务器发送的所述耗电异常原因。

4.如权利要求1或2所述的方法，其特征在于，所述确定所述应用对处理器的已占用时长，包括：

确定所述应用分别在用户态和核心态的已运行时长；

根据所述应用分别在用户态和核心态的已运行时长，确定所述应用对所述处理器的已占用时长。

5.如权利要求4所述的方法，其特征在于，所述确定所述应用分别在用户态和核心态的已运行时长，包括：

调用系统信息接口，通过所述系统信息接口获取所述应用的进程信息；

从所述进程信息中获取所述应用在用户态的已运行时长，并从所述进程信息中获取所述应用在核心态的已运行时长。

6.一种应用耗电监控方法，其特征在于，所述方法包括：

接收终端发送的所述终端中的应用在后台运行第二预设时长内的运行数据，所述运行数据是所述终端根据自所述应用切换至后台运行起的两个时间点对处理器的已占用时长，确定所述应用在后台耗电异常时开始获取的，所述两个时间点相距第一预设时长；

根据所述运行数据，获取所述应用的耗电异常原因，所述耗电异常原因是指所述应用在所述第二预设时长内调用的至少一个目标调用栈，所述至少一个目标调用栈是指调用次数大于预设次数和/或执行时长大于第三预设时长的调用栈；

所述运行数据包括每个目标线程执行的方法组成的调用栈、以及所述每个目标线程执行的方法中每个方法的执行时长和/或调用次数，所述目标线程为所述应用在所述第二预设时长内运行的线程；所述根据所述运行数据，获取所述应用的耗电异常原因，包括：

对所述每个目标线程执行的方法组成的调用栈、以及所述每个目标线程执行的方法中每个方法的执行时长和/或调用次数进行统计，得到所有所述目标线程调用的方法组成的调用栈中每个调用栈的调用次数和/或执行时长，每个调用栈指示应用执行的一个具体任务，每个调用栈的执行时长是指构成所述每个调用栈的每个方法的执行时长的总和；

根据所有所述目标线程调用的方法组成的调用栈中每个调用栈的调用次数和/或执行时长，从所有所述目标线程调用的方法组成的调用栈中确定所述至少一个目标调用栈；将所述至少一个目标调用栈，确定为所述应用的耗电异常原因。

7.如权利要求6所述的方法，其特征在于，所述根据所述运行数据，获取所述应用的耗电异常原因之后，还包括：

将所述耗电异常原因发送给所述终端。

8.一种应用耗电监控装置，其特征在于，所述装置包括：

确定模块，用于在自应用切换至后台运行起的两个时间点，分别确定所述应用对处理器的已占用时长，得到第一时长和第二时长，所述两个时间点相距第一预设时长；

第一获取模块，用于当所述第一时长和所述第二时长的差值大于预设阈值时，确定所述应用在后台耗电异常，并获取所述应用在当前时间点之后第二预设时长内的运行数据；

第二获取模块，用于根据所述运行数据获取所述应用的耗电异常原因，或者，将所述运行数据发送给服务器，由所述服务器根据所述运行数据获取所述应用的耗电异常原因；

其中，所述耗电异常原因是指所述应用在所述第二预设时长内调用的至少一个目标调用栈，所述至少一个目标调用栈是指调用次数大于预设次数和/或执行时长大于第三预设时长的调用栈；

所述运行数据包括每个目标线程执行的方法组成的调用栈、以及所述每个目标线程执行的方法中每个方法的执行时长和/或调用次数，所述目标线程为所述应用在所述第二预设时长内运行的线程；所述第二获取模块具体用于：

对所述每个目标线程执行的方法组成的调用栈、以及所述每个目标线程执行的方法中每个方法的执行时长和/或调用次数进行统计，得到所有所述目标线程调用的方法组成的调用栈中每个调用栈的调用次数和/或执行时长，每个调用栈指示应用执行的一个具体任务，每个调用栈的执行时长是指构成所述每个调用栈的每个方法的执行时长的总和；

根据所有所述目标线程调用的方法组成的调用栈中每个调用栈的调用次数和/或执行时长，从所有所述目标线程调用的方法组成的调用栈中确定所述至少一个目标调用栈；将所述至少一个目标调用栈，确定为所述应用的耗电异常原因。

9.一种应用耗电监控装置，其特征在于，所述装置包括：

接收模块，用于接收终端发送的所述终端中的应用在后台运行第二预设时长内的运行数据，所述运行数据是所述终端根据自所述应用切换至后台运行起的两个时间点对处理器的已占用时长，确定所述应用在后台耗电异常时开始获取的，所述两个时间点相距第一预设时长；

获取模块，用于根据所述运行数据，获取所述应用的耗电异常原因，所述耗电异常原因是指所述应用在所述第二预设时长内调用的至少一个目标调用栈，所述至少一个目标调用栈是指调用次数大于预设次数和/或执行时长大于第三预设时长的调用栈；

所述运行数据包括每个目标线程执行的方法组成的调用栈、以及所述每个目标线程执行的方法中每个方法的执行时长和/或调用次数，所述目标线程为所述应用在所述第二预设时长内运行的线程；所述获取模块具体用于：

对所述每个目标线程执行的方法组成的调用栈、以及所述每个目标线程执行的方法中每个方法的执行时长和/或调用次数进行统计，得到所有所述目标线程调用的方法组成的调用栈中每个调用栈的调用次数和/或执行时长，每个调用栈指示应用执行的一个具体任务，每个调用栈的执行时长是指构成所述每个调用栈的每个方法的执行时长的总和；

根据所有所述目标线程调用的方法组成的调用栈中每个调用栈的调用次数和/或执行时长，从所有所述目标线程调用的方法组成的调用栈中确定所述至少一个目标调用栈；将所述至少一个目标调用栈，确定为所述应用的耗电异常原因。

10.一种终端，其特征在于，所述终端包括处理器和存储器，所述存储器中存储有至少一条指令、至少一段程序、代码集或指令集，所述指令、所述程序、所述代码集或所述指令集由所述处理器加载并执行以实现如权利要求1-5任一项所述的应用耗电监控方法。

11.一种服务器，其特征在于，所述终端包括处理器和存储器，所述存储器中存储有至少一条指令、至少一段程序、代码集或指令集，所述指令、所述程序、所述代码集或所述指令集由所述处理器加载并执行以实现如权利要求6-7任一项所述的应用耗电监控方法。

12.一种计算机可读存储介质，其特征在于，所述存储介质中存储有至少一条指令、至少一段程序、代码集或指令集，所述指令、所述程序、所述代码集或所述指令集由处理器加载并执行以实现如权利要求1-5或6-7任一项所述的应用耗电监控方法。

Images