CN113760081B - 基于业务的耗电处理方法和终端设备 - Google Patents

Abstract

本申请实施例提供一种基于业务的耗电处理方法和终端设备，该方法包括：当应用程序运行在后台时，获取应用程序执行的第一类型的业务的第一耗电信息，第一耗电信息包括：时长和/或耗电量；基于第一耗电信息，若检测到第一类型的业务为高耗电业务，则输出提示信息，高耗电业务为：耗电量大于或等于耗电量阈值，和/或，时长大于或等于时长阈值的业务，提示信息用于指示第一类型的业务为高耗电业务。本申请实施例中，终端设备可以以业务维度，提示用户应用程序中存在高耗电业务，进而用户可以关闭应用程序中的高耗电业务，并非关闭整个应用程序，能够降低终端设备的功耗，且能够保证应用程序运行在后台时用户可以使用应用程序中的功能。

Description

基于业务的耗电处理方法和终端设备

技术领域

本申请实施例涉及终端技术，尤其涉及一种基于业务的耗电处理方法和终端设备。

背景技术

用户在终端设备上可以安装各种应用程序，大量的应用程序的运行，导致终端设备的耗电量大，终端设备的续航时长短。

目前，终端设备的设置界面中可以显示终端设备中各应用程序的耗电情况，以及各应用程序的启动管理选项。为了减小终端设备的耗电量，提高终端设备的续航时长，用户可以在启动管理选项中，关闭耗电量大的应用程序的后台活动，即不允许耗电量大的应用程序运行在后台。

这种方式虽然能够减小终端设备的耗电量，但是当耗电量大的应用程序从前台运行切换至后台运行时，该应用程序停止运行，应用程序中的所有功能无法使用。

发明内容

本申请实施例提供一种基于业务的耗电处理方法和终端设备，用户可以关闭应用程序中的高耗电业务，应用程序运行在后台时，用户可以使用应用程序中除了高耗电业务之外的其他功能。

第一方面，本申请实施例提供一种基于业务的耗电处理方法，该方法可以应用于终端设备、也可以应用于终端设备中的芯片，下面以应用于终端设备为例对该方法进行描述。该方法中，当应用程序运行在后台时，终端设备获取所述应用程序执行的第一类型的业务的第一耗电信息，所述第一耗电信息包括：时长和/或耗电量；且基于所述第一耗电信息，若检测到第一类型的业务为高耗电业务，则输出提示信息，所述高耗电业务为：耗电量大于或等于耗电量阈值，和/或，时长大于或等于时长阈值的业务，所述提示信息用于指示所述第一类型的业务为高耗电业务。

本申请实施例中，终端设备可以针对业务进行高耗电提示，用户可以基于该提示关闭高耗电的业务的后台运行，而不是关闭整个应用程序，本申请实施例中并未采用一刀切的方式，关闭整个应用程序，而是关闭高耗电业务，更具针对性，能够提高用户体验。另外，用户关闭的高耗电业务，可以降低终端设备的耗电量，提高终端设备的续航时长。

在一种可能的实现方式中，终端设备可以基于所述应用程序执行的第一类型的业务时，使用应用程序框架层的服务的第一使用信息，获取所述第一耗电信息，所述服务用于所述应用程序执行所述第一类型的业务，所述第一使用信息包括：开始时间和结束时间。

终端设备在输出提示信息时，可以在所述终端设备的负一屏或下拉通知菜单中，显示包含有所述提示信息的提示框，以使得用户可以基于该提示信息，关闭高耗电业务。用户操作提示框，可以触发终端涉笔显示第一类型的业务的设置界面。

其一，所述第一类型的业务的设置界面包括：后台设置控件。当用户打开后台设置控件时，可以允许应用程序运行在后台时执行该第一类型的业务。当用户关闭后台设置控件时，以关闭应用程序运行在后台时执行该第一类型的业务，即应用程序运行在后台时，不执行该第一类型的业务。

其中，终端设备响应于所述用户关闭所述后台设置控件，将所述第一类型的业务设置为禁止在后台运行的业务。在该种场景下，当应用程序从前台运行切换至后台运行，停止执行所述第一类型的业务。

本申请实施例中，用户可以在第一类型的业务的设置界面上，关闭后台设置控件，以设置第一类型的业务为后台禁止运行的业务，进而在应用程序运行在后台时，不执行该第一类型的业务，可以降低终端设备的耗电量，提高终端设备的续航时长。

其二，所述第一类型的业务的设置界面显示有：所述第一类型的业务使用各资源的第二耗电信息。

其中，终端设备可以在应用程序运行在后台时，查询所述应用程序运行在后台时各资源的使用信息，所述使用信息包括：各资源的开始时间和结束时间；进而基于所述第一类型的业务的开始时间和结束时间，以及所述各资源的使用信息，获取所述第二耗电信息。

如上介绍了当应用程序运行在后台时，终端设备检测到应用程序中存在高耗电业务时，提示用户关闭高耗电业务的方法，在一种可能的实现方式中，终端设备获取第一耗电信息后，可以在应用程序的耗电界面显示该第一耗电信息，用户可以自主进入终端设备的设置界面，以关闭用户需要关闭的应用程序中的业务。

在该种实现方式中，终端设备的设置界面上显示有电池选项，终端设备响应于用户在所述终端设备的设置界面操作电池选项，可以显示耗电排行信息的界面。其中，所述耗电排行信息的界面包括：所述终端设备的硬件的耗电排行选项和软件的耗电排行选项，所述软件的耗电排行选项中包括：终端设备中各应用程序的耗电排行选项。

用户操作操作所述应用程序的耗电排行选项，终端设备显示所述应用程序的耗电界面。其中，所述应用程序的耗电界面包括：前台业务框和后台业务框，所述前台业务框中包括：所述应用程序运行在前台时各类型的业务的第一耗电信息，所述后台业务框中包括：所述应用程序运行在后台时各类型的业务的第一耗电信息，所述后台业务框中包括：所述第一类型的业务的选项，所述第一类型的业务的选项中包括所述第一类型的业务的第一耗电信息。

用户可以在应用程序的耗电界面上操作所述第一类型的业务的选项，终端设备可以显示所述第一类型的业务的设置界面。其中，所述第一类型的业务的设置界面可以参照上述实现方式中的相关描述，用户可以在第一类型的业务的设置界面中，设置第一类型的业务为禁止在后台运行的业务。

如此，用户可以自主操作终端设备的设置界面，也可以设置第一类型的业务为后台禁止运行的业务，进而在应用程序运行在后台时，不执行该第一类型的业务，可以降低终端设备的耗电量，提高终端设备的续航时长。

应注意，当用户设置第一类型的业务为后台禁止运行的业务后，当应用程序运行在后台时，终端设备可以停止获取第一类型的业务的第一耗电信息。若用户想要重新在后台运行第一类型的业务，即用户想要在后台使用第一类型的业务，可以通过如下两种方式设置第一类型的业务为允许在后台运行的业务：

其中，所述应用程序的耗电界面显示有所述第一类型的业务的选项，和/或，所述应用程序的启动管理的选项中包括所述第一类型的业务的选项。用户可以在应用程序的耗电界面，或者应用程序的启动管理的选项中，操作第一类型的业务的选项，终端设备可以显示所述第一类型的业务的设置界面。这样，用户可以在第一类型的业务的设置界面上打开所述后台设置控件，将所述第一类型的业务设置为允许在后台运行的业务。在该种实现方式中，在应用程序运行在后台时，可以执行该第一类型的业务，进而实现用户在后台使用该第一类型的业务，满足用户的需求，提高用户体验。

第二方面，本申请实施例提供一种基于业务的耗电处理方法，该方法中，当应用程序运行在后台时，终端设备获取所述应用程序执行的第一类型的业务的第一耗电信息，所述第一耗电信息包括：时长和/或耗电量。

在该种方法中，用户可以通过终端设备的设置界面查看第一类型的业务的第一耗电信息。其中，终端设备响应于用户在所述终端设备的设置界面操作电池选项，显示耗电排行信息的界面，所述耗电排行信息的界面包括：所述终端设备的硬件的耗电排行选项和软件的耗电排行选项，所述软件的耗电排行选项中包括：各应用程序的耗电排行选项。

终端设备响应于所述用户操作所述应用程序的耗电排行选项，显示所述应用程序的耗电界面，所述应用程序的耗电界面包括：前台业务框和后台业务框，所述前台业务框中包括：所述应用程序运行在前台时各类型的业务的第一耗电信息，所述后台业务框中包括：所述应用程序运行在后台时各类型的业务的第一耗电信息，所述后台业务框中包括：所述第一类型的业务的选项，所述第一类型的业务的选项中包括所述第一类型的业务的第一耗电信息。如此，用户可以在应用程序的耗电界面上看到第一类型的业务的第一耗电信息，用户可以关闭不需要在后台运行的业务。

其中，终端设备响应于检测到所述用户操作所述第一类型的业务的选项，显示所述第一类型的业务的设置界面。

所述第一类型的业务的设置界面，以及设置界面中包含的内容可以参照如上第一方面的相关描述，用户可以通过操作第一类型的业务的设置界面上的后台设置控件，设置第一类型的业务为禁止在后台运行的业务，可以参照如上第一方面的相关描述。

第三方面，本申请实施例提供一种基于业务的耗电处理装置。该基于业务的耗电处理装置可以为如上第一方面或第二方面中的终端设备，或者终端设备中的芯片，该基于业务的耗电处理装置包括：

耗电统计模块，用于当应用程序运行在后台时，获取所述应用程序执行的第一类型的业务的第一耗电信息，所述第一耗电信息包括：时长和/或耗电量；

输出模块，用于基于所述第一耗电信息，若检测到第一类型的业务为高耗电业务，则输出提示信息，所述高耗电业务为：耗电量大于或等于耗电量阈值，和/或，时长大于或等于时长阈值的业务，所述提示信息用于指示所述第一类型的业务为高耗电业务。

在一种可能的实现方式中，输出模块为显示模块。输出模块，具体用于在所述终端设备的负一屏或下拉通知菜单中，显示包含有所述提示信息的提示框。

在一种可能的实现方式中，输出模块，还用于响应于检测到用户操作所述提示框，显示所述第一类型的业务的设置界面。

在一种可能的实现方式中，所述第一类型的业务的设置界面包括：后台设置控件。应用程序耗电详情模块，用于响应于所述用户关闭所述后台设置控件，将所述第一类型的业务设置为禁止在后台运行的业务，且向后台任务管理系统同步禁止在后台运行的业务。

在一种可能的实现方式中，应用程序，用于响应于所述应用程序从前台运行切换至后台运行，停止执行所述第一类型的业务。

在一种可能的实现方式中，耗电统计模块，具体用于基于所述应用程序执行的第一类型的业务时，使用应用程序框架层的服务的第一使用信息，获取所述第一耗电信息，所述服务用于所述应用程序执行所述第一类型的业务，所述第一使用信息包括：开始时间和结束时间。

在一种可能的实现方式中，所述第一类型的业务的设置界面显示有：所述第一类型的业务使用各资源的第二耗电信息。

在一种可能的实现方式中，耗电统计模块，还用于在获取所述应用程序执行的第一类型的业务的第一耗电信息时，查询所述应用程序运行在后台时各资源的使用信息，所述使用信息包括：各资源的开始时间和结束时间；基于所述第一类型的业务的开始时间和结束时间，以及所述各资源的使用信息，获取所述第二耗电信息。

在一种可能的实现方式中，输出模块，还用于：响应于用户在所述终端设备的设置界面操作电池选项，显示耗电排行信息的界面，所述耗电排行信息的界面包括：所述终端设备的硬件的耗电排行选项和软件的耗电排行选项，所述软件的耗电排行选项中包括：各应用程序的耗电排行选项。以及，

响应于所述用户操作所述应用程序的耗电排行选项，显示所述应用程序的耗电界面，所述应用程序的耗电界面包括：前台业务框和后台业务框，所述前台业务框中包括：所述应用程序运行在前台时各类型的业务的第一耗电信息，所述后台业务框中包括：所述应用程序运行在后台时各类型的业务的第一耗电信息，所述后台业务框中包括：所述第一类型的业务的选项，所述第一类型的业务的选项中包括所述第一类型的业务的第一耗电信息。以及，

响应于检测到所述用户操作所述第一类型的业务的选项，显示所述第一类型的业务的设置界面。

第四方面，本申请实施例提供一种终端设备，所述终端设备包括：处理器、存储器；所述收发器耦合至所述处理器；其中，存储器用于存储计算机可执行程序代码，程序代码包括指令；当处理器执行指令时，指令使所述终端设备执行如第一方面所提供的方法。

第五方面，本申请实施例提供一种终端设备，包括用于执行以上第一方面所提供的方法的单元、模块或电路。

第六方面，本申请实施例提供一种芯片，所述芯片上存储有计算机程序，在所述计算机程序被所述芯片执行时，实现如第一方面所提供的方法。

第七方面，本申请实施例提供一种包含指令的计算机程序产品，当其在计算机上运行时，使得计算机执行上述第一方面中的方法。

第八方面，本申请实施例提供一种计算机可读存储介质，所述计算机可读存储介质中存储有指令，当其在计算机上运行时，使得计算机执行上述第一方面中的方法。

本申请实施例第二方面和第八方面的实现原理和技术效果，可以参照上述第一方面的相关描述，在此不再赘述。

附图说明

图1为已有的终端设备的一种耗电排行界面的示意图；

图2为本申请实施例提供的应用程序的一种耗电详情界面的示意图；

图3为本申请实施例适用的终端设备的一种结构框图；

图4为本申请实施例提供的基于业务的耗电处理方法的一种流程示意图；

图5为本申请实施例提供的终端设备的一种界面示意图；

图6A为本申请实施例提供的场景一对应的时序示意图；

图6B为本申请实施例提供的场景二对应的时序示意图；

图6C为本申请实施例提供的场景三对应的时序示意图；

图7为本申请实施例提供的第一耗电信息和第二耗电信息的一种数据格式的示意图；

图8A为本申请实施例提供的终端设备的另一种界面示意图；

图8B为本申请实施例提供的终端设备的另一种界面示意图；

图9为本申请实施例提供的终端设备提示高耗电业务的一种界面示意图；

图10为本申请实施例提供的基于业务的耗电处理方法的一种流程示意图；

图11为本申请实施例提供的终端设备的另一种界面示意图；

图12为本申请实施例提供的终端设备的另一种界面示意图；

图13为本申请实施例提供的终端设备的另一种结构示意图。

具体实施方式

图1为已有的终端设备的一种耗电排行界面的示意图。参照图1中的a，用户可以点击终端设备的设置界面101中的“电池”选项10，触发终端设备显示“电池详情”界面102。参照图1中的b，界面102上可以显示终端设备的耗电排行信息，耗电排行信息中包括硬件的耗电排行选项11和软件的耗电排行选项12。硬件的耗电排行选项11中可以包括：屏幕的耗电选项、信号待机的耗电选项，以及蓝牙的耗电选项等，界面102中未示出。软件的耗电排行选项12中可以包括：终端设备中的各应用程序的耗电排行选项，图1中的b中以终端设备中的应用程序包括应用程序A、应用程序B和应用程序C为例进行说明。可选地，界面102可以示出各个应用程序的总耗电情况，如应用程序A50％，应用程序B30％，应用程序C20％，或者应用程序A4小时20分，应用程序B2小时40分，应用程序C2小时(界面102中未示出)。当用户点击应用程序A的耗电排行选项121时，终端设备可以显示应用程序A的耗电详情界面103。参照图1中的c，界面103上可以包括应用程序A的设置框1211、耗电分析框1212，以及结束运行控件1213。

设置框1211中可以包括：高耗电提醒选项12111和应用启动管理选项12112。若用户操作高耗电提醒选项12111，打开终端设备的高耗电提醒功能，则终端设备可以响应于检测到应用程序A的耗电量较高，显示提示信息，该提示信息用于提示用户应用程序A的耗电量较高。应用启动管理选项12112用于用户对应用程序A的启动方式进行管理。示例性的当用户点击界面103上的应用启动管理选项12112，终端设备可以显示界面104。参照图1中的d，界面104上显示有应用程序A的启动方式，包括自动管理和手动管理。手动管理中包括：允许自启动、允许关联启动和允许后台活动。其中，允许自启动指的是：应用程序A在开机或运行在后台时可以自启动。允许关联启动指的是：应用程序A可以被其他应用程序启动。允许后台活动指的是：应用程序A可以运行在后台。

耗电分析框1212中包括：应用程序A运行时的资源的使用信息，资源使用信息如可以包括：中央处理器(central processing unit，CPU)的总使用时长、CPU运行在后台的时长、全球定位系统(global positioning system，GPS)的使用时长，以及系统唤醒时长等。其中，CPU、GPS等均为终端设备中的资源。

结束运行控件1213用于触发终端设备停止运行应用程序A。

当应用程序A运行在前台时，用户真正需要使用该应用程序A中的功能，当应用程序A运行在后台时，用户可能不需要使用应用程序A中的功能，因此为了节省终端设备的耗电量，用户可以在界面103的应用启动管理选项12112中，设置应用程序A的启动方式为“不允许后台活动”。如用户点击界面103上的应用启动管理选项12112，且在界面104中关闭“允许后台活动”的控件，以设置应用程序A的启动方式为“不允许后台活动”。应用程序A的启动方式为“不允许后台活动”可以理解为：当应用程序A运行在后台时停止运行，也可以理解为：终端设备响应于检测到应用程序A运行在后台，控制应用程序A停止运行。

其中，用户设置应用程序A的启动方式为“不允许后台活动”，虽然能够减少应用程序A的高耗电，进而降低终端设备的耗电量，提高终端设备的续航时长，但当应用程序A运行在后台时，应用程序A停止运行，因此用户不能使用应用程序A中所有的功能。这种一刀切的应用程序的启动方式(即允许应用程序A运行在前台，但不允许应用程序A运行在后台)，用户体验差。

示例性的，若应用程序A为音频播放类应用程序，当应用程序A运行在前台时，终端设备可以通过应用程序A播放音频以及下载音频。因为用户设置应用程序A的启动方式为“不允许后台活动”，则当应用程序A从前台切换至后台运行后(如用户在终端设备上打开另一应用程序B)，该应用程序A停止运行，终端设备停止播放音频且停止下载音频，即用户无法在应用程序A运行至后台时收听音频以及下载音频。

关于已有的技术中，用户为什么关闭应用程序A在后台的运行，在此进行分析：参照界面103，耗电分析框1212中仅示出了应用程序A在运行时终端设备中各资源的使用时长，用户虽然知道应用程序A耗电，但在界面103上无法得到应用程序A在前台和后台运行过程中，具体是应用程序A的哪个功能的耗电量比较大(或者说用户在界面103上无法判断应用程序A中哪些耗电合理)，因此在保证应用程序A运行在前台时业务正常执行的前提下，为了减少应用程序A的耗电，用户只能设置应用程序A的启动方式为“不允许后台活动”，以减少应用程序A的耗电量，进而减少终端设备的耗电量。

既然用户在界面103上无法清楚地得到应用程序A在后台运行过程中，具体是应用程序A的哪个功能的耗电大，因此，本申请提供一种基于业务的耗电处理方法，终端设备可以获取应用程序A运行在前台和后台时每个类型的业务的时长和/或耗电量，进而在应用程序A的耗电详情界面上，显示该每个类型的业务的时长和/或耗电量，使得用户通过应用程序A的耗电详情界面，便可以清楚地得到应用程序A运行在前台和后台时每个类型的业务的时长和/或耗电量，进而可以关闭用户不需要使用的业务。本申请实施例一方面可以减少应用程序运行时的耗电量，进而减少终端设备的耗电量，提高终端设备的续航时长；另一方面用户可以正常使用应用程序A中需要使用的业务，能够提高用户体验。

应理解的是，下述实施例中以终端设备获取应用程序运行在后台时每个类型的业务的时长和/或耗电量，以及用户关闭应用程序运行在后台时的业务为例进行说明。

示例性的，本申请实施例提供的应用程序A的耗电详情界面可以如图2所示。图2中a可以与上述图1中的b相同，可以参照上述图1中的b的相关描述。当用户在界面102上点击应用程序A的耗电排行选项121时，终端设备可以显示应用程序A的耗电详情界面103A。参照图2中的b，界面103A中包括设置框1211、结束运行控件1213和耗电分析框1212A，设置框1211和结束运行控件1213可以参照上述图1中的相关描述。界面103A中的耗电分析框1212A与上述界面103上的耗电分析框1212不同。耗电分析框1212A中可以包括：前台业务框1212A1和后台业务框1212A2。其中，前台业务框1212A1中包括：应用程序A运行在前台时的各类型的业务的时长和/或耗电量，后台业务框1212A2中包括：应用程序A运行在后台时的各类型的业务的时长和/或耗电量，本申请实施例以及附图中均以“时长”为例进行说明。

示例性的，界面103A中，应用程序A运行在前台时的业务可以包括：基于IP的语音传输(voice over internet protocol，VoIP)音视频电话业务，该VoIP音视频电话业务的时长为1小时12分钟3秒。应用程序A运行在后台时的业务包括：音频播放业务、VoIP音视频电话业务以及其他业务等。其中，音频播放业务的时长为4分钟34秒，VoIP音视频电话业务的时长为12分钟3秒，其他业务的时长为1小时12分钟3秒。应理解，图2中以“VoIP音视频电话”表征VoIP音视频电话业务，以“音频播放”表征音频播放业务。

如此，参照图2中的b，用户可以在应用程序A的耗电详情界面上，清楚地得到应用程序A运行在前台和后台时每个类型的业务的时长，进而可以基于用户自己的需求，关闭应用程序运行在前台和后台时用户不需要使用的业务。示例性的，如用户不需要使用应用程序A运行在后台时的音频播放业务(即用户不希望应用程序A运行在后台时执行音频播放业务)，用户可以在界面103A上点击后台业务框1212A2中的“音频播放”的选项，终端设备可以显示界面104A，该界面104A为音频播放业务的设置界面。

参照图2中的c，界面104A上可以显示对后台的音频播放业务的设置选项104A1，该设置选项104A1中包括控件104A2。若用户打开该控件104A2，则当应用程序A运行在后台时，终端设备可以执行音频播放业务。若用户关闭控件104A2，则当应用程序A运行在后台时，终端设备不执行音频播放业务。示例性的，图2中的c中以用户关闭控件104A2为例，说明用户可以禁用应用程序运行在后台时的业务，可以减少应用程序A的耗电量，进而可以减少终端设备的耗电量。

在一种实施例中，界面104A中可以显示应用程序运行在后台时，执行音频播放业务的各资源的耗电分析框1212。应理解，界面104A中所示的耗电分析框1212表征的是音频播放业务的各资源的耗电信息，具体可以参照下述实施例中的“第二耗电信息”相关描述，上述图1中的耗电分析框1212表征的音频播放类应用程序使用各资源的耗电信息。应理解，图2中所示的终端设备的界面变化的具体实现方式，可以参照下述实施例的相关描述。

基于本申请实施例提供的业务的耗电处理方法，用户可以关闭不需要在后台执行的业务。示例性的，若应用程序A为音频播放类应用程序，当应用程序A运行在前台时，终端设备可以通过应用程序A播放音频以及下载音频。因为用户关闭应用程序A运行在后台时的音频播放业务，因此当应用程序A从前台运行切换至后台运行后，终端设备停止播放音频，但仍可以执行下载音频的业务。

在一种实施例中，终端设备可以但不限于为：手机、平板电脑、笔记本电脑、可穿戴设备、智能音箱等设置显示屏的电子设备。可选的，终端设备还可以为个人数字处理(personal digital assistant，PDA)、具有无线通信能力的手持设备、计算设备、虚拟现实(virtual reality，VR)终端设备、无人机设备、增强现实(augmented reality，AR)终端设备、智慧家庭中的智能家居和家电设备等。本申请实施例中对终端设备的形态不做限定。

本申请实施例中的术语释义：

应用程序A：表征终端设备中的任一应用程序，每一个应用程序运行于独立的进程。

应用程序A运行在前台：终端设备可以显示应用程序A的界面。示例性的，应用程序A为通话应用，通话应用运行在前台可以理解为：终端设备显示的界面为用户通话的界面。应用程序A运行在前台也可以称为：应用程序在前台运行。

应用程序A运行在后台：终端设备的界面显示其他应用程序的界面。在一种实施例中，该其他应用的界面上可以显示切换至应用程序A的图标。示例性的，应用程序A为通话应用，通话应用运行在后台可以理解为：终端设备显示其他应用程序的界面，且该其他应用程序的界面上显示有可以切换至通话应用的图标，用户点击该图标，终端设备可以显示通话应用的界面，使得通话应用从后台运行切换至前台运行。应用程序A运行在后台也可以称为：应用程序在后台运行。

业务：如音频播放、通话、定位、导航等。应用程序不同，应用程序执行的业务可能不同。示例性的，对于音频播放类应用程序，业务可以包括：音频播放，以及音频下载等。对于导航类应用程序，业务可以包括：音频播放，以及定位等。

应用程序框架层的服务：可以理解为应用程序层中的预定义的函数。示例性的，应用程序运行时需要执行音频播放业务，则终端设备可以调用应用程序框架层预定的、用于执行音频播放业务的服务，如mediaplayback，启动对应的播放器硬件，以播放音频。

终端设备的软件系统可以采用分层架构，事件驱动架构，微核架构，微服务架构，或云架构。本申请实施例以分层架构的Android系统为例，示例性说明终端设备的软件结构。图3为本申请实施例适用的终端设备的一种结构框图。分层架构将终端设备的软件系统分成若干个层，每一层都有清晰的角色和分工。层与层之间通过软件接口通信。在一些实施例中，参照图3，终端设备可以包括：应用程序层(applications)、应用程序框架层(application framework)以及内核层(kernel)。应理解，终端设备中的应用程序层、应用程序框架层、内核层(kernel)，以及其他层(如硬件抽象层等)具体的描述可以参照现有技术，下述对本申请实施例中使用到的各层进行说明。

应用程序层可以包括一系列应用程序包，应用程序层通过调用应用程序框架层所提供的应用程序接口(application programming interface，API)运行应用程序。应用程序包可以包括相机，图库，日历，通话，地图，导航，WLAN，蓝牙，音乐，视频，短信息等应用程序。图3中以应用程序表示应用程序包。参照图3，应用程序层还可以包括：应用程序耗电详情模块。其中，应用程序可以调用应用程序框架层提供的API，使用应用程序框架层提供的各种服务。应用程序耗电详情模块，用于基于耗电统计模块计算得到的应用程序运行在后台时各类型的业务的耗电信息，显示应用程序的耗电详情界面。在一种实施例中，耗电信息可以包括耗电量和/或使用时长。

应用程序框架层可以为应用程序层的应用程序提供API、编程框架以及多个服务。在一种实施例中，应用程序框架层包括一些预先定义的函数。参照图3，应用程序框架层可以包括：运行服务、后台任务管理系统、电池状态(buttery state)模块，以及耗电统计模块。其中，运行服务可以为应用程序提供各种服务，示例性的，服务可以包括但不限于：媒体播放mediaplayback、位置定位location、电话phonecall，以及数据同步datasync等服务。后台任务管理系统，用于对运行在后台的应用程序以及应用程序中的业务进行管理。耗电统计模块，用于统计应用程序运行在后台(和/或前台)时，应用程序中的各类型的业务的耗电信息。电池状态模块，用于统计各应用程序运行过程中各资源的使用信息，资源可以参照下述实施例中的相关描述。

内核层用于驱动硬件工作。内核层至少包含显示驱动，摄像头驱动，音频驱动，传感器驱动，马达驱动等，本申请实施例对此不做限制。示例性的，内核层可以采用马达驱动以驱动终端设备中的马达(硬件)运动，以使终端设备产生震动。参照图3，在一种实施例中，内核层可以包括资源服务，资源服务可以理解为硬件的驱动，用于驱动对应的硬件工作。示例性的，资源服务可以包括但不限于如下硬件的驱动：网络、GPS、音频audio、蓝牙bluetooth、CPU、液晶显示器(liquid crystal display，LCD)、WIFI、调制解调器modem，以及图形处理器(graphics processing unit，GPU)。应理解，图3中内核层中示出的硬件名称可以理解为该硬件对应的驱动。

参照图3，在一种实施例中，终端设备除了上述软件分层架构之外，还可以包括硬件模块。硬件模块中可以包括：网络、GPS、播放器、蓝牙、CPU、LCD、WIFI、modem，以及GPU等硬件设备。应理解，硬件模块中的一个硬件可以与上述资源服务中的一个硬件驱动相对应。示例性的，上述资源服务中的网络驱动和硬件模块中的网络对应，资源服务中的网络驱动可以驱动硬件模块中的网络工作，以为终端设备提供网络。

下述结合图3和图4，以应用程序为音频播放类应用程序为例，对上述图3中的各模块之间的交互进行说明。下面这几个实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例不再赘述。参照图4，在一种实施例中，本申请实施例提供的基于业务的耗电处理方法可以包括：

S401，应用程序运行在后台执行第一类型的业务时，应用程序调用应用程序框架层提供的API。

应用程序可以检测应用程序的运行状态，确定应用程序运行在前台还是后台，在一种实施例中，应用程序的运行状态可以为：前台或后台。在一种实施例中，应用程序可以查询应用程序的运行状态的记录，该运行状态记录中存储有应用程序的运行状态的标识，应用程序可以基于应用程序的运行状态的标识，确定应用程序的运行状态。示例性的，应用程序可以查询应用程序的运行状态application state的记录，若application state记录的运行状态的标识为“UI Application State Active”，表征应用程序运行在前台，若application state记录的运行状态的标识为“UI Application State Background”，表征应用程序运行在后台。

第一类型的业务可以包括但不限于为：音频播放业务、电话业务、数据下载和上传业务、导航业务等。应理解，第一类型可以为应用程序支持的任一类型。

基于上述所述，应用程序可以检测应用程序的运行状态，当应用程序运行在后台执行第一类型的业务时，应用程序可以调用应用程序框架层提供的API，以使得运行服务运行应用程序框架层中第一服务，执行第一类型的业务。应理解，应用程序运行在前台执行第一类型的业务时，也需要调用应用程序框架层提供的API，以运行应用程序框架层中第一服务，执行第一类型的业务，可以参照下述实施例以应用程序运行在后台为例的相关说明。

参照图4，S401可以理解为图3中所示的步骤(1)，步骤(1)可以理解为：应用程序在执行业务时，调用应用程序框架层提供的API。

应理解，本申请实施例中应用程序运行在后台时，可以执行至少一个类型的业务，本申请实施例中以第一类型的业务表征应用程序执行的每个类型的业务。

S402，运行服务运行第一服务。

第一服务与第一类型的业务具有第一映射关系。示例性的，音频播放业务与mediaplayback服务具有第一映射关系，当音频播放类应用程序运行在后台执行音频播放业务时，第一服务为mediaplayback服务，运行服务可以响应于应用程序调用API，运行mediaplayback服务。

在一种实施例中，第一服务与第一类型的业务具有第一映射关系。针对不同的操作系统，用于指示第一类型的业务对应的第一服务的方式不同，下述对当前主流的安卓操作系统和iOS操作系统进行详细描述：

针对安卓操作系统来说，安卓操作系统中包括前台服务和后台服务，前台服务的优先级高于后台服务。当应用程序从前台运行切换至后台运行时，因为后台服务的优先级低，因此后台服务不运行，前台服务可以通过“前台服务类型”指定后台运行的业务的服务。示例性的，前台服务可以对应用程序的第一类型的业务标注“服务标签”，该服务标签用于指示应用程序执行第一类型的业务时的第一服务。在一种实施例中，前台服务可以将第一类型的业务对应的“服务标签”传入API，作为API中的参数。这样，运行服务响应于应用程序调用API，可以基于API中的“服务标签”参数，确定使用运行服务中的哪个服务。

示例性的，如，音频播放业务的服务标签为“mediaplayback”，则应用程序可以调用应用程序框架层提供的API，运行服务可以获取音频播放业务对应的服务为“mediaplayback”，进而使用运行服务中的mediaplayback服务。

示例性的，下表一为“前台服务类型”对应的描述(可以理解为功能描述或业务描述)：

表一

针对iOS操作系统来说，iOS系统通过执行后台模式background modes(即表二中的Xcode background modes)来指定后台运行的业务的服务(UI background modesvalue)，并执行后台运行的业务。

示例性的，表二为后台模式对应的服务，以及描述(可以理解为功能描述或业务描述)：

表二

S403，运行服务使用第一资源的驱动，驱动第一资源。

运行服务可以控制第一资源工作，以执行第一类型的业务。第一服务与第一资源具有第二映射关系。运行服务可以基于第一服务，以及第二映射关系，确定第一资源。示例性的，当音频播放类应用程序运行在后台执行音频播放业务时，运行服务运行mediaplayback服务，mediaplayback服务与播放器(资源)具有第二映射关系，则运行服务使用与播放器的audio驱动，驱动第一资源(播放器)，执行音频播放业务。

在一种实施例中，应用程序在后台运行音频播放业务，除了使用audio驱动，驱动播放器(硬件)播放音频外，还可以同时使用多种其他资源的驱动，来驱动对应的硬件，如使用CPU驱动以驱动CPU、使用网络驱动以驱动网络等。

参照图4，S403中“运行服务使用第一资源的驱动”，可以理解为图3中所示的步骤(2)。

S404，耗电统计模块获取第一类型的业务的第一耗电信息，以及使用的各资源的第二耗电信息。

在一种实施例中，运行服务可以检测其中的第一服务的第一使用信息，进而向耗电统计模块发送第一使用信息(如图3中的步骤(3))。其中，第一使用信息可以包括：第一服务使用的开始时间和结束时间。第一服务使用的开始时间可以表征：第一类型的业务的开始时间Ttask_start，第一服务使用的结束时间可以表征：第一类型的业务的结束时间Ttask_end。据此，耗电统计模块可以基于第一使用信息，获取第一类型的业务的第一耗电信息。第一耗电信息可以包括：第一类型的业务的时长和/或耗电量。示例性的，第一使用信息中可以包括：mediaplayback服务的开始时间和结束时间。

在一种实施例中，资源服务可以检测第一类型的业务的执行过程中各资源的第二使用信息，进而向耗电统计模块发送第二使用信息(如图3中的步骤(4A))。应理解，第一类型的业务的执行过程中使用的各资源可以理解为：第一类型的业务的执行过程中使用的硬件资源，如上图3所示的硬件模块中的资源。

因为一个资源的运行(可以理解为工作)是由其对应的资源驱动驱动的，因此应用程序在执行第一类型的业务的过程中使用的各资源的使用时长，与各资源对应的资源驱动的时长相等。其中，第二使用信息可以包括：各资源使用的开始时间Tresource_start和结束时间Tresource_end。示例性的，第二使用信息包括：播放器的使用开始时间和结束时间。据此，耗电统计模块可以基于第二使用信息，获取应用程序运行在后台时使用的各资源的第二耗电信息。第二耗电信息可以包括：应用程序运行在后台时使用的各资源的使用时长和/或耗电量。

应理解，后台任务管理系统可以获取应用程序的运行状态，具体可以参照应用程序获取应用程序的运行状态的相关描述。在一种实施例中，后台任务管理系统可以向耗电统计模块同步应用程序的运行状态，以使得耗电统计模块获取应用程序的运行状态。示例性的，后台任务管理系统检测到应用程序从前台运行切换至后台运行时，可以向耗电统计模块同步应用程序的运行状态为“后台运行”，如此，耗电统计模块可以获取应用程序的运行状态为“后台运行”。

在一种实施例中，耗电统计模块可以基于应用程序的运行状态，当应用程序运行在后台时，基于第一使用信息，获取第一类型的业务的第一耗电信息，以及基于第二使用信息，获取应用程序运行在后台执行第一类型的业务时使用的各资源的第二耗电信息。

在一种实施例中，耗电统计模块若基于应用程序的运行状态，确定应用程序运行在后台时，可以向运行服务发送第一请求。运行服务可以响应于第一请求，向耗电统计模块发送使用信息，该使用信息中包括应用程序运行在后台时执行各类型的业务的信息，该使用信息中包括如上第一使用信息。同理的，耗电统计模块若基于应用程序的运行状态，确定应用程序运行在后台时，可以向资源服务发送第二请求。运行服务可以响应于第二请求，向耗电统计模块发送应用程序执行各类型的业务时使用各资源信息，该各资源的信息中包括第二使用信息。

在一种实施例中，当应用程序运行在后台时，耗电统计模块可以从电池状态模块中查询应用程序执行各类型的业务时使用各资源的信息，该各资源的信息中包括第二使用信息(如图3中的步骤(4))。

应注意，耗电统计模块基于第一使用信息获取第一耗电信息，以及基于第二使用信息获取第二耗电信息，可以参照图6A-图6C的相关描述。

S405，应用程序耗电详情模块在耗电统计模块中查询第一耗电信息和第二耗电信息。

参照图1，因为已有的耗电统计模块仅获取了应用程序A在运行过程中各资源的耗电信息，因此应用程序耗电详情模块调用耗电查询接口，只能查询到应用程序A在运行过程中各资源的耗电信息，据此，在已有的界面103上，终端设备仅能显示应用程序A在运行过程中各资源的耗电信息。

本申请实施例中，因为耗电统计模块可以获取第一耗电信息和第二耗电信息，因此应用程序耗电详情模块调用耗电查询接口，可以查询到第一耗电信息和第二耗电信息，进而显示如上界面103A。在一种实施例中，上述的耗电查询接口可以称为第一接口，应用程序耗电详情模块调用第一接口，可以查询到第一耗电信息和第二耗电信息。本申请实施例中可以在耗电统计模块中新增第二接口，其中，应用程序耗电详情模块调用第一接口，可以查询到第一耗电信息，应用程序耗电详情模块调用第二接口，可以查询到第二耗电信息。

其中，应用程序耗电详情模块在耗电统计模块中查询第一耗电信息和第二耗电信息的过程，可以理解为图3中的步骤(5)。

S406，应用程序耗电详情模块根据第一耗电信息和第二耗电信息，显示应用程序的耗电详情界面，应用程序耗电详情界面包括第一耗电信息。

在一种实施例中，第一耗电信息和第二耗电信息可以显示在同一界面上，或者不同的界面上，下述以第一耗电信息和第二耗电信息显示在不同的界面为例进行说明。

其中，应用程序耗电详情模块可以基于第一耗电信息，显示包含有第一耗电信息的界面，如界面103A所示，后台业务框1212A2中包括第一耗电信息。应理解，界面103A上可以显示应用程序运行在后台时执行的多个类型的业务的第一耗电信息。

示例性的，当用户点击界面103A上显示的任一类型的业务的选项，终端设备的界面上可以显示包含有第二耗电信息的界面，如界面104A中的耗电分析框1212所示。示例性的，以应用程序为音频播放类应用程序，且用户点击音频播放的选项为例，界面104A中可以包括：应用程序运行在后台时，执行音频播放业务使用的CPU资源的使用时长和/或耗电量、以及GPS资源的使用时长和/或耗电量等，应理解，本申请实施例中在图中以使用时长为例进行说明。

如此，在本申请实施例中，用户可以在应用程序的耗电详情界面上，清楚地看到后台业务的时长和/或耗电量，进而便于用户关闭不需要使用的业务，以降低终端设备的耗电量。

在一种实施例中，为了减少终端设备的耗电量，用户可以关闭应用程序在后台运行中不需要使用的业务。因此，在上述S406之后还可以包括：

S407，后台任务管理系统响应于检测到用户关闭第一类型的业务的后台运行，存储第一类型的业务的后台启动方式。

示例性的，参照图5中的a(即界面104A)，用户可以关闭控件104A2，以关闭音频播放业务的后台运行，也可以理解为：用户触发终端设备禁止应用程序在后台运行时执行音频播放业务。相应的，第一类型的业务(音频播放业务)的后台启动方式从“允许后台活动”修改为“不允许后台活动”。

在一种实施例中，应用程序耗电详情模块可以检测用户对应用程序耗电详情界面的操作，进而可以响应于用户选择禁止第一类型的业务的后台运行，可以向后台任务管理系统同步第一类型的业务的启动方式，如此，后台任务管理系统可以存储该第一类型的业务的启动方式为“不允许后台活动”。S407可以为上图3中的步骤(6)。

在一种实施例中，终端设备中可以存储有不同应用程序在后台运行时不允许活动的业务的标识，这样，终端设备可以基于在后台运行的应用程序，以及该应用程序中不允许活动的业务的标识，确定是否在后台执行对应的业务。

S408，后台任务管理系统响应于检测到应用程序运行在后台，禁止执行第一类型的业务。

因为用户在应用程序耗电详情界面上关闭第一类型的业务的后台运行，则当该应用程序运行在后台时，后台任务管理系统禁止执行第一类型的业务(即不执行第一类型的业务)。在一种实施例中，当应用程序从前台运行切换至后台运行时，后台任务管理系统可以基于业务的类型，若确定该类型的业务为禁止在后台运行的业务，则后台任务管理系统可以向应用程序发送停止后台运行的消息，以通知应用程序不执行该第一类型的业务。

示例性的，参照图5中的b和c，用户打开音频播放类应用程序播放音频，当音频播放类应用程序运行在前台时，终端设备可以执行音频播放业务，图5中的c中以数字表征终端设备播放的音频。参照图5中的d，当音频播放类应用程序从前台运行切换至后台运行时，因为用户禁止音频播放业务在后台运行，因此终端设备不执行音频播放业务，即终端设备不播放音频。

应理解，S408可以理解为图3中的步骤(7)。

本申请实施例中，当应用程序运行在后台时，终端设备可以获取应用程序中各类型的业务的耗电信息，进而在界面上显示应用程序运行在后台时各类型的业务的耗电信息，用户在应用程序的耗电详情界面上可以清楚地得到应用程序运行在后台时每个类型的业务的耗电信息，进而便于用户关闭应用程序中不需要使用的业务，或者关闭应用程序中耗电量较大的业务。本申请实施例中以形象的方式，使得用户直观地看到应用程序在运行过程中每个类型的业务的耗电信息，在提高用户体验的同时，终端设备还可以基于用户对特定类型的业务的关闭操作，在应用程序运行在后台时不执行该业务，进而降低终端设备的耗电量，提高终端设备的续航时长。

如上介绍了终端设备中各模块之间交互实现本申请实施例提供的基于业务的耗电处理方法，下述结合三种可能的场景，说明S404中耗电统计模块获取第一耗电信息和第二耗电信息的过程：

场景一：终端设备运行一个应用程序，且该应用程序执行一个类型的业务。示例性的，该场景一可以为：用户打开音频播放类应用程序(一个应用程序)，且终端设备执行音频播放业务(一个类型的业务)。本申请实施例对音频播放类应用程序执行音频播放业务时的运行状态不做限制，可以为前台运行或后台运行，或在前台运行和后台运行之间切换。耗电统计模块获取前台运行时音频播放业务的第一耗电信息和第二耗电信息，与获取后台运行时音频播放业务的第一耗电信息和第二耗电信息的方式相同，下述实施例中以音频播放类应用程序在后台运行时，执行音频播放业务为例进行说明。

应理解，终端设备在后台执行音频播放业务的过程中，需要使用CPU、播放器和GPS，而资源服务中的CPU资源驱动CPU工作，audio驱动用于驱动播放器工作，GPS驱动用于驱动GPS工作。CPU的使用时长可以等于CPU驱动的时长时长，播放器的使用时长可以等于audio驱动的使用时长，GPS的使用时长可以等于GPS驱动的使用时长，因此下述以CPU资源、audio资源表征播放器，以GPS资源表征GPS为例进行说明。

在一种实施例中，耗电统计模块可以响应于音频播放类应用程序开始执行音频播放业务，开始统计第一耗电信息和第二耗电信息。示例性的，在9:00时，音频播放类应用程序开始执行音频播放业务，耗电统计模块记录音频播放业务的开始时间为9:00。

在一种实施例中，耗电统计模块可以响应于如下至少一个条件，结算一次第一耗电信息和第二耗电信息。结算可以理解为获取与上一次结算到本次结算期间的第一耗电信息和第二耗电信息。至少一个条件可以包括：一项业务停止(如音频播放类应用程序停止执行音频播放业务)、业务前后台切换(音频播放类应用程序切换至后台运行(或切换至前台运行))、周期性结算。可以理解地，结算起始点为一项业务开始时，周期性结算可以为固定时间点结算，如整点触发结算，比如1:00结算，2：00结算。

示例性的，周期性结算的周期为1h，在9:00时，音频播放类应用程序在前台执行音频播放业务，9:30时，音频播放类应用程序切换至后台运行，耗电统计模块可以结算9:00-9:30这一时间段内，音频播放类应用程序运行在前台执行音频播放业务的第一耗电信息和第二耗电信息。当时间到10:00时，因为9:00-10:00为一周期，耗电统计模块可以结算9:30-10:00这一时间段内，音频播放类应用程序运行在后台执行音频播放业务的第一耗电信息和第二耗电信息。当时间到10:30时，音频播放类应用程序停止执行音频播放业务，则耗电统计模块可以结算10:00-10:30这一时间段内，音频播放类应用程序运行在后台执行音频播放业务的第一耗电信息和第二耗电信息。

在一种实施例中，耗电统计模块可以存储有9:00-9:30、9:30-10:00，以及10:00-10:30每个时间段内的第一耗电信息和第二耗电信息。

图6A中以音频播放类应用程序运行在后台，开始执行音频播放业务到停止执行音频播放业务均在一个周期“9:00-10:00”为例进行说明：

图6A为本申请实施例提供的场景一对应的时序示意图。参照图6A，音频播放业务的开始时间为Ttask1_start，音频播放业务的结束时间为Ttask1_end。终端设备在执行音频播放业务的过程中使用了CPU资源、audio资源和GPS资源。

其中，运行服务可以获取第一使用信息，即音频播放业务的开始时间为Ttask1_start，音频播放业务的结束时间为Ttask1_end，以向耗电统计模块发送该第一使用信息。据此，耗电统计模块可以基于第一使用信息，即音频播放业务的开始时间和结束时间，获取音频播放业务的第一耗电信息，如，音频播放业务的时长为Ttask1_end-Ttask1_start。

在一种实施例中，资源服务可以获取第二使用信息，即audio资源使用的开始时间为Tresource1_start和结束时间为Tresource1_end，以及GPS资源使用的开始时间为Tresource2_start和结束时间为Tresource2_end，进而向耗电统计模块发送该第二使用信息。其中，因为终端设备开始执行音频播放业务，即需要使用CPU资源，因此音频播放业务的开始时间、结束时间，与CPU资源使用的开始时间、结束时间分别相同。

其中，耗电统计模块可以基于第二使用信息，获取音频播放业务执行过程中各资源的第二耗电信息。其中，终端设备在后台执行音频播放业务时，耗电统计模块可以获取CPU资源的使用时长为：Ttask1_end-Ttask1_start，audio资源的使用时长为：Tresource1_end-Tresource1_start，GPS资源的使用时长为：Tresource2_end-Tresource2_start。

在一种实施例中，电池状态模块中可以记录并存储有各应用程序在运行过程中各资源的使用信息(第二使用信息)，现有电池状态模块中记录的各资源的使用信息以应用程序的维度统计，没有以业务的维度进行统计。其中，耗电统计模块可以在10：00时，从电池状态模块中，查询音频播放类应用程序在9:00-10:00这一结算周期内的第二使用信息(包括各资源的开始时间和结束时间)。因此，耗电统计模块可以基于查询到的CPU资源、audio资源和GPS资源的第二使用信息，获取第二耗电信息，可以参照上述的相关说明。

以CPU资源举例，耗电统计模块可以在10：00时，从电池状态模块中，查询音频播放类应用程序在9:00-10:00这一结算周期内的CPU资源的使用时长是40分钟。在一种实施例中，电池状态模块中可以存储音频播放类应用程序在9:00-10:00这一结算周期内的CPU资源的使用情况，据此，耗电统计模块可以基于从电池状态模块中查询到的CPU资源的使用时长，得到音频播放类应用程序在9:00-10:00这一结算周期内的CPU资源的使用时长是40分钟。图6A所示场景中，音频播放类应用程序只有一个业务，即音频播放业务在运行，所以音频播放类应用程序的CPU资源的使用时长为音频播放业务的CPU资源的使用时长，如9:00-10:00期间音频播放业务的CPU资源的使用时长是40分钟。假设，音频播放业务9:00-9:20在前台运行，9:20-10:00在后台运行，10:15退出运行，那么可以在9:20从电池状态模块中获取9:00-9:20期间CPU资源的使用时长为15分钟作为音频播放业务前台运行期间CPU资源的使用时长，10：00从电池状态模块中获取9:20-10:00期间CPU资源的使用时长为25分钟作为音频播放业务后台运行9:20-10:00期间CPU资源的使用时长，10:15从电池状态模块中获取10:00-10:15期间CPU资源的使用时长为5分钟，作为音频播放业务后台运行10:00-10:15期间CPU资源的使用时长。此时若查询音频播放业务的耗电信息，可以为前台运行20分钟，后台运行55分钟，后台运行期间CPU资源的时长为30分钟。

可以理解地，第二耗电信息中一部分信息可以参考图6A，如audio资源的使用时长为：Tresource1_end-Tresource1_start，GPS资源的使用时长为：Tresource2_end-Tresource2_start；第二耗电信息的另一部分可以使用从电池状态模块中获取，比如CPU资源的使用时长从电池状态模块获取为40分钟。

参照图6A，该音频播放类应用程序除了音频播放业务以外没有执行其他业务，则音频播放业务在9:00-10:00这段时间内CPU资源的使用时长是40分钟。CPU资源在9:00-10：00这段时间内其他20分钟可能处于休眠，或者服务于操作系统。

在一种实施例中，耗电统计模块可以基于各资源的使用时长，获取各资源的耗电量。其中，耗电统计模块中可以存储有各资源的使用时长和耗电量的映射关系，耗电统计模块可以基于该映射关系，以及各资源的使用时长，获取各资源的耗电量。示例性的，CPU使用1分钟对应的耗电量为a，则CPU使用3分钟的耗电量为3a。

在一种实施例中，耗电统计模块中可以存储有各资源的耗电因子，耗电统计模块可以将资源的耗电因子乘以对应的资源的使用时长的结果作为资源的耗电量。耗电因子可以理解为：单位时间内资源的耗电量。

在一种实施例中，电池状态模块不仅可以记录和存储各资源的开始时间、结束时间，还可以记录资源使用过程中资源的运行频率。

以CPU为例，CPU的运行频率不同或CPU的核数不同，在相同的使用时长下CPU的耗电量不同。以CPU的运行频率为例，在该实施例中，耗电统计模块中可以存储有CPU各运行频率下的耗电量，进而在耗电统计模块查询到第二使用信息时，可以基于CPU运行在各运行频率下的时长，以及各运行频率对应的耗电量，获取CPU的耗电量。示例性的，CPU在使用时长中，1-2分钟的运行频率为b，2-4分钟的运行频率为c，且运行频率为b时CPU使用1分钟的耗电量为a，运行频率为c时CPU使用1分钟的耗电量为d，则CPU的耗电量为(a+2d)。

在一种实施例中，第二使用信息中可以还可以包括：CPU的核数。耗电统计模块中可以存储有各核数的CPU在各运行频率下的耗电量，进而在耗电统计模块查询到第二使用信息时，可以基于各核数的CPU在使用时长中，运行在各运行频率下的时长，以及各核数的CPU在各运行频率下的耗电量，获取CPU的耗电量。示例性的，CPU在使用时长中，CPU的核数为4，且1-2分钟的运行频率为b，2-4分钟的运行频率为c，已知核数为4的CPU运行频率为b时CPU使用1分钟的耗电量为a，核数为4的CPU运行频率为c时CPU使用1分钟的耗电量为d，则CPU的耗电量为(a+2d)。

应理解，对于终端设备中的WIFI资源和modem资源，耗电统计模块可以采用数据包的使用量，来表征WIFI资源的耗电量和modem资源的耗电量。示例性的，当音频播放类应用程序运行在后台时，电池状态模块可以统计WIFI资源数据包的使用量，进而耗电统计模块可以在电池状态模块中查询得到WIFI资源数据包的使用量，以将WIFI资源数据包的使用量作为WIFI资源的耗电信息。

如此，耗电统计模块可以获取第一耗电信息以及第二耗电信息，其中，第一耗电信息中可以包括音频播放业务的时长和/或耗电量，第二耗电信息中可以包括音频播放业务执行过程中的各资源的使用时长和/或耗电量。在一种实施例中，音频播放业务的耗电量可以为音频播放业务执行过程中的各资源的耗电量的总和。

场景二：终端设备运行一个应用程序，且该一个应用程序执行多个类型的业务(下述以两个类型的业务为例进行说明)。示例性的，该场景二可以为：用户打开音频播放类应用程序(一个应用程序)，且执行音频下载业务以及音频播放业务(两个类型的业务)。本申请实施例中对应用程序执行音频下载业务以及音频播放业务时的运行状态不做限制，下述实施例中以应用程序在后台执行音频下载业务以及音频播放业务为例进行说明。

应理解，终端设备在后台执行音频下载业务时，需要使用CPU资源、GPS资源，以及WIFI资源，其中GPS资源用于获取终端设备的位置，WIFI资源用于下载音频。终端设备在后台执行音频播放业务的过程中，需要使用CPU资源、audio资源和GPS资源。其中GPS资源用于获取终端设备的位置，audio资源用于播放音频。由于音频播放类应用程序在后台运行，终端设备执行音频下载业务以及音频播放业务时，使用的CPU资源、GPS资源重叠，重叠的部分需要分摊到音频播放类应用程序的音频下载业务和音频播放业务中，具体参照下述的相关描述。

应理解，图6B中以音频播放类应用程序运行在后台，开始执行音频播放业务到停止执行音频播放业务，以及开始执行音频下载业务到停止执行音频下载业务，均在“9:00-10:00”为例进行说明：

图6B为本申请实施例提供的场景二对应的时序示意图。参照图6B，音频播放业务的开始时间为Ttask1_start，音频播放业务的结束时间为Ttask1_end，音频下载业务的开始时间为Ttask2_start，音频下载业务的结束时间为Ttask2_end。其中，耗电统计模块可以基于来自运行服务的第一使用信息，即音频播放业务的开始时间和结束时间，以及音频下载业务的开始时间和结束时间，获取第一耗电信息。如，耗电统计模块可以获取音频播放业务的时长为：Ttask1_end-Ttask1_start，音频下载业务的时长为：Ttask2_end-Ttask2_start。

在一种实施例中，耗电统计模块可以基于来自资源服务的第二使用信息，获取第二耗电信息。第二使用信息可以包括：audio资源使用的开始时间为Tresource1_start，结束时间为Tresource1_end，GPS资源使用的开始时间为Tresource2_start，结束时间为Tresource2_end，WIFI资源使用的开始时间为Tresource3_start，结束时间为Tresource3_end。

其中，终端设备在后台执行音频下载业务以及音频播放业务的过程中，使用的CPU资源有重叠。其中，终端设备在后台执行音频下载业务单独使用CPU资源的时长为：Ttask2_end-Ttask1_end，终端设备在后台执行音频播放业务单独使用CPU资源的时长为：Ttask2_start-Ttask1_start，音频下载业务和音频播放业务共用CPU资源的时长为：Ttask1_end-Ttask2_start。因此，参照平均分摊的机制，终端设备在后台执行音频下载业务时，耗电统计模块可以获取CPU资源的使用时长为：(Ttask1_end-Ttask2_start)/2+Ttask2_end-Ttask1_end。终端设备在后台执行音频播放业务时，耗电统计模块可以获取CPU资源的使用时长为：(Ttask1_end-Ttask2_start)/2+Ttask2_start-Ttask1_start。

因为WIFI资源未重叠，因此终端设备在后台执行音频下载业务，WIFI资源的使用时长为：Tresource3_end-Tresource3_start。应注意，终端设备在后台执行音频下载业务以及音频播放业务的过程中，使用的GPS资源有重叠，因为GPS资源的使用时长为：Tresource2_end-Tresource2_start，但终端设备在后台执行音频下载业务时或者终端设备在后台执行音频播放业务时，均未单独使用GPS资源，因此终端设备在后台执行音频下载业务时，GPS资源的使用时长为：(Tresource2_end-Tresource2_start)/2。

同理的，终端设备在后台执行音频播放业务时，耗电统计模块可以获取CPU的使用时长为：(Ttask1_end-Ttask2_start)/2+Ttask2_start-Ttask1_start，GPS资源的使用时长为：(Tresource2_end-Tresource2_start)/2。

在一种实施例中，对于一个结算周期来说，耗电统计模块可以在10：00时，从电池状态模块中，查询音频播放类应用程序在9:00-10:00这一结算周期内的第二使用信息，第二使用信息可以参照图6A中的相关描述。

例如，耗电统计模块从电池状态模块获取到Ttask2_start-Ttask1_start期间CPU资源的使用时长A1，Ttask2_start-Ttask1_start期间的CPU资源的使用时长A2，Ttask2_end-Ttask1_end期间的CPU的使用时长A3。A1，A2，A3分别小于等于Ttask2_start-Ttask1_start，Ttask2_start-Ttask1_start，Ttask2_end-Ttask1_end。因此终端设备在后台执行音频下载业务时CPU资源的使用时长为A1+A2/2，终端设备在后台执行音频播放业务时CPU资源的使用时长为A3+A2/2。Audio资源，GPS资源，WIFI资源可以类似处理。

图6B的场景中，因为音频播放类应用程序执行音频下载业务和音频播放业务，耗电统计模块在获取到第二使用信息后，可以将音频下载业务和音频播放业务共用的资源分配至音频下载业务和音频播放业务中。示例性的，以CPU资源为例，音频播放类应用程序在9:00-10:00中，使用CPU资源的时间为：9:00-10:00。耗电统计模块可以按照平均分摊的机制，获取音频下载业务使用的CPU资源为：(Ttask1_end-Ttask2_start)/2+Ttask2_end-Ttask1_end，音频播放业务使用的CPU资源为：(Ttask1_end-Ttask2_start)/2+Ttask2_start-Ttask1_start，可以参照上述的相关描述。

耗电统计模块获取音频播放业务以及音频下载业务的耗电量，以及获取各资源的耗电量可以参照上述图6A中的相关描述。

场景三：终端设备运行N个应用程序，且该N个应用程序执行多个类型的业务，其中，N为大于等于1的整数。下述以N为2，且每个应用程序执行一个类型的业务为例进行说明。示例性的，该场景三可以为：用户打开音频播放类应用程序和视频播放类应用程序(两个应用程序)，音频播放类应用程序执行音频播放业务，视频播放类应用程序执行视频下载业务(两个类型的业务)。

本申请实施例中对音频播放类应用程序执行音频播放业务，以及视频播放类应用程序执行视频下载业务时的运行状态不做限制，下述实施例中以音频播放类应用程序在后台执行音频下载业务，以及视频播放类应用程序在后台执行视频下载业务为例进行说明。应理解，本申请实施例也可以适用于音频播放类应用程序在前台执行音频播放业务，视频播放类应用程序在后台执行视频下载业务的场景中，可以参照下述图6C的相关说明。

在一种实施例中，由于多个应用程序在后台运行，终端设备执行业务时，使用的资源会重叠，重叠的部分需要分摊到各个应用程序，具体参照下述的相关描述。图6C为本申请实施例提供的场景三对应的时序示意图。图6C中以音频播放类应用程序运行在后台，开始执行音频播放业务到停止执行音频播放业务，在在一个结算周期“9:00-10:00”，以及视频播放类应用程序运行在后台，开始执行视频下载业务到停止执行视频下载业务在一个结算周期“9:00-10:00”为例进行说明：

参照图6C，音频播放业务的开始时间为Ttask1_start，音频播放业务的结束时间为Ttask1_end，视频下载业务的开始时间为Ttask3_start，视频下载业务的结束时间为Ttask3_end。其中，耗电统计模块可以获取音频播放业务的时长为：Ttask1_end-Ttask1_start，视频下载业务的时长为：Ttask3_end-Ttask3_start。

终端设备在执行音频播放业务的过程中，使用了audio资源和GPS资源，其中，audio资源使用的开始时间为Tresource1_start，结束时间为Tresource1_end，GPS资源使用的开始时间为Tresource2_start，结束时间为Tresource2_end。终端设备在执行视频下载业务的过程中，使用了GPS资源以及WIFI资源，其中，WIFI资源使用的开始时间为Tresource3_start，结束时间为Tresource3_end，GPS资源使用的开始时间为Tresource4_start，结束时间为Tresource4_end。

对于终端设备在后台同时执行音频播放业务，以及视频下载业务的过程中，CPU资源以及GPS资源的使用重叠，下述以CPU资源为例，讲述音频播放类应用程序和视频播放类应用程序分摊CPU资源的过程，GPS资源(任一使用重叠的资源)在多个应用程序中的分摊，可以参照CPU资源的相关描述。

参照图6C，音频播放类应用程序独自使用CPU的时长为：Ttask3_start–Ttask1_start。音频播放类应用程序和视频播放类应用程序共用CPU的时长为：Ttask1_end–Ttask3_start。按照平均分摊的机制，共用CPU的时长分摊至音频播放类应用程序中的时长可以为(Ttask1_end–Ttask3_start)/2。如此，对于音频播放类应用程序来说，CPU的使用时长为：(Ttask3_start–Ttask1_start)+(Ttask1_end–Ttask3_start)/2。audio资源的使用时长为：Tresource1_end-Tresource1_start。同理的，参照平均分摊的机制，在音频播放类应用程序中，GPS资源的使用时长为：(Tresource4_start-Tresource2_start)+(Tresource2_end-Tresource4_start)/2。

参照图6C，视频播放类应用程序独自使用CPU的时长为：Ttask3_end–Ttask1_end。按照平均分摊的机制，共用CPU的时长分摊至视频播放类应用程序中的时长可以为(Ttask1_end–Ttask3_start)/2，与共用CPU的时长分摊至视频播放类应用程序中的时长相同。如此，对于视频播放类应用程序来说，CPU的使用时长为：(Ttask3_end–Ttask1_end)+(Ttask1_end–Ttask3_start)/2。WIFI资源的使用时长为：Tresource3_end-Tresource3_start。同理的，参照平均分摊的机制，在视频播放类应用程序中，GPS资源的使用时长为：(Tresource4_end-Tresource2_end)+(Tresource2_end-Tresource4_start)/2。

耗电统计模块获取音频播放业务以及视频下载业务的耗电量，以及获取各资源的耗电量可以参照上述图6A中的相关描述。

应注意，本申请实施例中，按照平均分摊的机制，耗电统计模块将重叠的资源分配至不同的应用程序中后，若在同一应用程序中执行多个业务时资源使用也有重叠，耗电统计模块可以基于上述图6B中的相关描述，将同一应用程序中多个业务中重叠的资源分摊至不同的业务中，以获取不同应用程序中各业务使用的资源的时长和/或耗电量。

在一种实施例中，参照电池状态模块的相关说明，电池状态模块中可以存储各应用程序执行各类型的业务的第二使用信息。如此，耗电统计模块可以从电池状态模块中，查询得到音频播放类应用程序在“9:00-10:00”的第二使用信息，以及视频播放类应用程序“9:00-10:00”的第二使用信息。因为图6C中音频播放类应用程序中只有一个音频播放业务，视频播放类应用程序中只有一个视频下载业务，因此从电池状态模块中得到音频播放类应用程序在“9:00-10:00”的第二使用信息可以视为音频播放业务的第二使用信息，视频播放类应用程序“9:00-10:00”的第二使用信息可以视为视频下载业务的第二使用信息。

对于一个结算周期来说，耗电统计模块可以在10:00，可以基于音频播放类应用程序的第二使用信息，得到音频播放类应用程序的第二耗电信息，且可以基于视频播放类应用程序的第二使用信息，得到视频播放类应用程序的第二耗电信息，可以参照如上图6A中的相关描述。在一种实施例中，若音频播放类应用程序中运行至少两个类型的业务时，耗电统计模块可以基于如上图6B中描述的方法，获取音频播放类应用程序中每个类型的业务的第二耗电信息。

综上述，耗电统计模块可以获取在后台运行时，各应用程序中不同类型的业务的第一耗电信息，以及终端设备在执行不同类型的业务的过程中各资源的第二耗电信息。终端设备可以存储第一耗电信息，以及第二耗电信息。在一种实施例中，终端设备存储第一耗电信息和第二耗电信息的数据结构可以参照图7所示。应理解，图7中仅示出了应用程序运行在后台时的第一耗电信息和第二耗电信息的数据结构，应用程序运行在前台时的第一耗电信息和第二耗电信息的数据结构与图7中后台的数据结构相同。可以理解地，终端设备存储的第一耗电信息和第二耗电信息可以按照每次结算的信息存储，比如从应用程序开始运行至切换到后台期间的耗电信息，后台运行到每次周期性结算的触发时间点期间的耗电信息，周期性结算的触发时间点到应用程序退出运行期间的耗电信息等，每次结算触发条件产生时间点之间的耗电信息都分别存储下来，后续用户除了可以查看每个业务的耗电情况，还可以查看每小时的耗电情况，应用程序前后台的耗电情况。

应理解，图7中示出了各应用程序运行在后台时的耗电信息，且以应用程序A为例，示出了应用程序中每个类型的业务的耗电信息的数据格式，其他应用程序中每个类型的业务的耗电信息可以参照应用程序A。应注意的是，示例性的，如应用程序A中音频播放业务中未使用GPS资源，则图7中所示的应用程序A中音频播放业务对应的GPS使用时长可以为0秒。换句话说，终端设备中可以存储每个应用程序的每个类型的业务中所有资源的耗电信息(包括业务使用的资源和未使用的资源的耗电信息，其中未使用的资源的使用时长为0秒，耗电量为0mAh)。

本申请实施例中，耗电计算模块可以基于运行在后台的应用程序中各类型的业务的使用信息，得到各类型的业务的第一耗电信息，以及各资源的第二耗电信息，进而使得终端设备可以在应用程序的耗电详情界面中显示第一耗电信息和第二耗电信息，使得用户可以直观看到应用程序运行在后台终端设备执行了什么业务以及每个类型的业务的耗电信息，有利于用户关闭不需要使用的业务，以降低终端设备的耗电量，提高终端设备的续航时长。

若用户选择禁止音频播放业务的后台运行，则当音频播放类应用程序运行在后台时，终端设备不执行音频播放业务。相应的，耗电统计模块不会获取音频播放业务的第一耗电信息，在一种实施例中，终端设备也不会在应用程序的耗电详情界面上显示音频播放业务的第一耗电信息。若用户重新允许音频播放业务的后台运行，需要重新打开控件104A2，使得音频播放类应用程序运行在后台时，终端设备可以执行音频播放业务。

下述通过两种可能的实现方式对用户重新打开音频播放业务的后台运行进行说明，终端设备中可以包括如下两种可能的实现方式中的至少一种：

第一种方式：

在一种实施例中，用户禁止音频播放业务的后台运行(即将音频播放业务后台禁用)后，终端设备可以在音频播放类应用程序的耗电详情界面103A的耗电分析框1212A中，显示音频播放业务的选项。图8A中的a为用户将音频播放业务后台禁用后，任一次音频播放类应用程序运行在后台时的耗电详情界面801，因为音频播放业务在后台禁止运行，因此该耗电详情界面801中音频播放业务的时长为0分钟。

若用户需要打开音频播放业务的后台运行，即用户希望允许音频播放业务重新在后台运行，则用户可以点击界面801中音频播放的选项，终端设备的界面跳转至802，界面802可以参照界面104A的相关描述。参照8A中的b和c，用户可以在界面802上，打开控件104A2，以打开音频播放业务的后台运行，使得音频播放类应用程序运行在后台时，终端设备可以执行音频播放业务。

第二种方式：

用户将音频播放业务后台禁用后，音频播放类应用程序的耗电详情界面103A中不包括有音频播放业务的选项，此时用户无法打开控件104A2，来打开音频播放业务的后台运行。

在一种实施例中，终端设备可以在应用启动管理界面中显示后台禁用的音频播放业务。参照图8B中的a，用户可以点击终端设备的设置界面101中的“应用”选项20，终端设备可以显示“应用管理”的界面803。参照图8B中的b，界面803中显示有应用管理的选项、应用启动管理的选项，以及其他选项。用户点击应用启动管理的选项，终端设备可以显示应用启动管理界面804。参照图8B中的c，界面804中显示有终端设备中的各应用程序的启动管理选项。

其中，终端设备在音频播放类应用程序的启动管理选项中，显示有后台禁用的音频播放业务的选项，用户点击音频播放业务的选项，可以触发终端设备显示界面802。参照图8B中的d，用户可以在界面802上，打开控件104A2，以打开音频播放业务的后台运行，使得音频播放类应用程序运行在后台时，终端设备可以执行音频播放业务。

应理解，如上两种方式为示例说明，本申请实施例对用户重新允许音频播放业务在后台运行的方式不做限制。

在一种实施例中，因为耗电统计模块可以获取应用程序在后台运行过程中，每个类型的业务的时长和/或耗电量，因此当某个业务耗电量高或者使用时长长时，耗电统计模块还可以提示用户存在高耗电的业务，便于用户基于自己的需求及时关闭高耗电的业务。

耗电统计模块中可以存储耗电量阈值和时长阈值。当应用程序在后台运行时，耗电统计模块可以获取每个类型的业务的时长和/或耗电量，若耗电统计模块检测到存在第一类型的业务的耗电量大于耗电量阈值，和/或第一类型的业务的时长大于时长阈值，可以向应用程序耗电详情模块发送提示指示，该提示指示中可以包括目标应用程序的标识以及第一类型的业务的标识。应理解，目标应用程序为存在高耗电业务的应用程序，第一类型的业务为高耗电业务。其中，目标应用程序的标识可以为应用程序的名称，如“音频播放类应用程序”，第一类型的标识可以为：第一类型的名称，如“音频播放类业务”。

应用程序耗电详情模块接收到来自耗电统计模块的提示指示时，可以输出提示信息，该提示信息用于提示用户，目标应用程序中存在高耗电的业务。在一种实施例中，高耗电业务可以为：耗电量大于耗电量阈值，和/或，目标业务的时长大于时长阈值的业务。

在一种实施例中，应用程序耗电详情模块可以在终端设备的负一屏或下拉通知菜单中输出提示信息，下述以终端设备在下拉通知菜单中输出提示信息为例进行说明。参照图9中的a，终端设备在下拉通知菜单中输出的提示信息中可以包括：“发现高耗电应用”、“音频播放类应用程序正在后台进行音频播放，点击查看详情”的文字信息，以及“忽略此应用”等文字信息。当用户点击“音频播放类应用程序正在后台进行音频播放，点击查看详情”的文字信息时，终端设备的界面跳转至界面802，参照图9中的b所示。用户可以在界面802上，关闭控件104A2，以关闭音频播放业务的后台运行，使得音频播放类应用程序运行在后台时，终端设备不执行音频播放业务。应理解的是，终端设备输入提示信息还可以采用语音提示等方式，如上显示输出提示信息的方式为示例说明。应理解的是，终端设备还可以在用户观看的界面上或者其他位置输出提示信息，以上以负一屏或下拉通知菜单为示例说明。

本申请实施例中，因为耗电统计模块可以在应用程序的运行过程中，获取每个类型的业务的时长和/或耗电量，因此终端设备可以针对业务进行高耗电提示，进而用户可以基于该提示，关闭应用程序中的高耗电的业务，而不是关闭整个应用程序，即本申请实施例中并未采用一刀切的方式，关闭整个应用程序，而是关闭用户不需要运行的业务，更具针对性，能够提高用户体验。另外，用户关闭的高耗电业务，可以降低终端设备的耗电量，提高终端设备的续航时长。

应理解的是，如上实施例中，以应用程序运行在后台为例，说明了终端设备获取和显示应用程序中各类型的业务的第一耗电信息和第二耗电信息的技术方案，本申请实施例提供的基于业务的耗电处理方法也可以应用在应用程序运行在前台的场景中，终端设备可以获取并显示应用程序运行在前台时各类型的业务的第一耗电信息和第二耗电信息，具体实现方式可以参照上述实施例的相关描述。应注意，在应用程序运行在前台的场景中，上述后台任务管理系统可以替换为“前台任务管理系统”，应用程序运行在后台可以替换为应用程序运行在前台。示例性的，终端设备可以在应用程序运行在前台时，获取以及显示应用程序中各类型的业务的耗电信息，如图2中的界面103A中的前台业务框1212A1所示。

如上所述，终端设备中可以包括：应用程序、运行服务、资源服务、耗电统计模块、应用程序耗电详情模块、电池状态模块，以及后台任务管理系统，如此终端设备可以实现本申请实施例提供的基于业务的耗电处理方法。在一种实施例中，参照图10，本申请实施例提供的基于业务的耗电处理方法可以包括：

S1001，当应用程序运行在后台时，获取所述应用程序执行的第一类型的业务的第一耗电信息，所述第一耗电信息包括：时长和/或耗电量。

S1002，基于所述第一耗电信息，若检测到第一类型的业务为高耗电业务，则输出提示信息。

S1001可以参照如上S404，以及图6A-图6C中的相关描述。

S1002可以参照图9的相关描述。

在一种实施例中，当终端设备输出提示信息时，用户可以点击查看高耗电应用的耗电情况，参照图9中的b，在图9中的b中还可以显示关闭控件104A2，用户可以操作关闭控件104A2，以将高耗电的业务(如音频播放业务)设置为音频播放类应用程序在后台运行时禁止运行的业务。如此，后续音频播放类应用程序运行时，当音频播放类应用程序切换至后台运行时，终端设备不播放音频，可以参照图5中的相关描述。可选地，用户可以点击查看高耗电应用的耗电情况，可以先显示图2的b或者图12的a，如果用户选择查看音频播放业务，可以再显示图2的c或者图9的b或者图12的b。

在一种实施例中，因为终端设备可以获取不同周期内，第一类型的业务的第一耗电信息和第二耗电信息，因此，终端设备可以显示不同结算周期内第一类型的业务的第一耗电信息和第二耗电信息。相应的，上述图2中的b可以替换为图11中的a，图2中的c可以替换为图11中的b。

参照图11中的a，后台业务中，音频播放业务在9：00-10：00这一结算周期内的使用时长为3分钟，在10：00-11：00这一结算周期内的使用时长为1分钟。应理解，后台业务中的VOIP音视频电话和其他业务，以及前台业务中VOIP音视频电话的也可以参照音频播放业务显示。参照图11中的b，应用程序执行音频播放业务时使用各资源的时长可以为：在9：00-10：00这一结算周期内，CPU使用时长为3分钟，GPS使用时长为0分钟。在10：00-11：00这一结算周期内的CPU使用时长为0.5分钟，GPS使用时长为1秒。

可以理解的是，本申请实施例中以结算周期为1h为例进行说明，结算周期还可以为一天(参照图12所示，一天可以为昨天的某一时刻至今天的某一时刻，该时刻可以为0:00)、一周、一月等，本申请实施例对此不作限制，也未一一画图示出。

结合图2，图11，图12，终端设备中提供电池耗电信息查询的界面102，当用户在界面102中选择应用程序A的耗电信息时，终端设备则提供界面103A，当用户在界面103A中选择音频播放业务的耗电信息时，终端设备则提供界面104A。本申请实施例中，终端设备可以在应用程序的运行过程中，获取每个类型的业务的时长和/或耗电量，因此终端设备可以针对业务进行高耗电提示，进而用户可以基于该提示，关闭应用程序中的高耗电的业务，而不是关闭整个应用程序，能够提高用户体验。另外，用户关闭的高耗电业务，可以降低终端设备的耗电量，提高终端设备的续航时长。

需要说明的是，以上模块可以为单独设立的元件，也可以集成在某一个芯片中实现，此外，也可以以程序代码的形式存储于存储器中，由某一个处理元件调用并执行以上模块的功能。此外这些模块全部或部分可以集成在一起，也可以独立实现。例如，以上这些模块可以是被配置成实施以上方法的一个或多个集成电路，例如：一个或多个专用集成电路(application specific integrated circuit，ASIC)，或，一个或多个微处理器(digitalsignal processor，DSP)，或，一个或者多个现场可编程门阵列(field programmable gatearray，FPGA)等。再如，这些模块可以集成在一起，以片上系统(system-on-a-chip，SOC)的形式实现。

图13为本申请实施例提供的终端设备的结构示意图。图13所示的终端设备可以为上述实施例中的第一设备或第二设备。如图13所示，该终端设备可以包括：处理器1301(例如CPU)、存储器1302、收发器1303；收发器1303耦合至处理器1301，处理器1301控制收发器1303的收发动作；存储器1302可能包含高速随机存取存储器(random-access memory，RAM)，也可能还包括非易失性存储器(non-volatile memory，NVM)，例如至少一个磁盘存储器，存储器1302中可以存储各种指令，以用于完成各种处理功能以及实现本申请各实施例中所述的方法步骤。可选的，本申请涉及的终端设备还可以包括：电源1304、通信总线1305、通信端口1306以及显示器1307。收发器1303可以集成在终端设备的收发信机中，也可以为终端设备上独立的收发天线＝。通信总线1305用于实现元件之间的通信连接。显示器1307用于显示终端设备的用户界面。上述通信端口1306用于实现终端设备与其他外设之间进行连接通信。

在本申请实施例中，上述存储器1302用于存储计算机可执行程序代码，程序代码包括指令；当处理器1301执行指令时，指令使终端设备的处理器1301执行上述方法实施例中终端设备的处理动作，使收发器1303执行上述方法实施例中终端设备的收发动作，其实现原理和技术效果类似，在此不再赘述。

在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行计算机程序指令时，全部或部分地产生按照本申请实施例的流程或功能。计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，DVD)、或者半导体介质(例如固态硬盘Solid State Disk(SSD))等。

本文中的术语“多个”是指两个或两个以上。本文中术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，本文中字符“/”，一般表示前后关联对象是一种“或”的关系；在公式中，字符“/”，表示前后关联对象是一种“相除”的关系。

可以理解的是，在本申请的实施例中涉及的各种数字编号仅为描述方便进行的区分，并不用来限制本申请的实施例的范围。

可以理解的是，在本申请的实施例中，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请的实施例的实施过程构成任何限定。

Claims (10)

1.一种基于业务的耗电处理方法，其特征在于，应用于终端设备，所述方法包括：

当应用程序运行在后台时，所述应用程序执行第一类型的业务时，根据服务的第一使用信息获取第一耗电信息，所述服务用于所述应用程序执行所述第一类型的业务，所述第一使用信息包括：所述服务的开始时间和结束时间，所述第一耗电信息包括：时长和/或耗电量；

基于所述第一耗电信息，若检测到第一类型的业务为高耗电业务，则输出提示信息，所述高耗电业务为：耗电量大于或等于耗电量阈值，和/或，时长大于或等于时长阈值的业务，所述提示信息用于指示所述第一类型的业务为高耗电业务；

响应于检测到用户基于所述输出提示信息的触发操作，显示所述第一类型的业务的设置界面；所述第一类型的业务的设置界面包括：后台设置控件；

响应于所述用户关闭所述后台设置控件，将所述第一类型的业务设置为禁止在后台运行的业务。

2.根据权利要求1所述的方法，其特征在于，所述输出提示信息，包括：

在所述终端设备的负一屏或下拉通知菜单中，显示包含有所述提示信息的提示框。

3.根据权利要求2所述的方法，其特征在于，所述显示包含有所述提示信息的提示框之后，还包括：

响应于检测到用户操作所述提示框，显示所述第一类型的业务的设置界面。

4.根据权利要求1所述的方法，其特征在于，所述方法还包括：

响应于所述应用程序从前台运行切换至后台运行，停止执行所述第一类型的业务。

5.根据权利要求1-4中任一项所述的方法，其特征在于，所述服务为应用程序框架层的服务。

6.根据权利要求1、3-4中任一项所述的方法，其特征在于，所述第一类型的业务的设置界面显示有：所述第一类型的业务使用各资源的第二耗电信息。

7.根据权利要求6所述的方法，其特征在于，所述获取所述应用程序执行的第一类型的业务的第一耗电信息时，还包括：

查询所述应用程序运行在后台时各资源的使用信息，所述使用信息包括：使用各资源的开始时间和结束时间；

基于所述第一类型的业务的开始时间和结束时间，以及所述各资源的使用信息，获取所述第二耗电信息。

8.根据权利要求1-4、7中任一项所述的方法，其特征在于，所述获取所述应用程序执行的第一类型的业务的第一耗电信息之后，还包括：

响应于用户在所述终端设备的设置界面操作电池选项，显示耗电排行信息的界面，所述耗电排行信息的界面包括：所述终端设备的硬件的耗电排行选项和软件的耗电排行选项，所述软件的耗电排行选项中包括：各应用程序的耗电排行选项；

响应于所述用户操作所述应用程序的耗电排行选项，显示所述应用程序的耗电界面，所述应用程序的耗电界面包括：前台业务框和后台业务框，所述前台业务框中包括：所述应用程序运行在前台时各类型的业务的第一耗电信息，所述后台业务框中包括：所述第一类型的业务的选项，所述第一类型的业务的选项中包括所述第一类型的业务的第一耗电信息；

响应于检测到所述用户操作所述第一类型的业务的选项，显示所述第一类型的业务的使用各资源的第二耗电信息。

9.一种终端设备，其特征在于，包括：存储器、处理器；

所述处理器用于与所述存储器耦合，读取并执行所述存储器中的指令，以实现权利要求1-8中任一项所述的方法。

10.一种计算机可读存储介质，其特征在于，所述计算机存储介质存储有计算机指令，当所述计算机指令被计算机执行时，使得所述计算机执行权利要求1-8中任一项所述的方法。

Images