CN108008979B - 终端唤醒的管理方法及其终端、存储介质 - Google Patents

Abstract

本申请公开了终端唤醒的管理方法及其终端、存储介质。其中，该方法包括：在灭屏时接收应用对电源锁的申请；获取根据终端的多个应用对电源锁的历史申请数据而确定的第一频繁申请应用集合；若所述应用在所述第一频繁申请应用集合中，则采用第一管理策略确定是否允许所述申请；以及若所述应用不在所述第一频繁申请应用集合中，则采用第二管理策略确定是否允许所述申请；其中，所述第一管理策略比第二管理策略对申请电源锁的限制程度高。上述方案，能够实现对频繁申请电源锁的应用进行管理，节约终端的功耗。

Description

终端唤醒的管理方法及其终端、存储介质

技术领域

本申请涉及智能设备领域，特别是涉及终端唤醒的管理方法及其终端、存储介质。

背景技术

手机、电脑等终端已成为人们生活所必不可少的物品。通常，该终端安装有各种应用，当终端在灭屏之后正常会进入待机模状态，待机可以有效降低电池使用达到提高续航的能力。但是当终端处于灭屏时，目前仍有很多唤醒方式。其中持有电源锁(WakeLock)就是一种唤醒方式，即，当应用持有电源锁之后则会唤醒该终端，即便是在灭屏的情况下该终端的处理器也会在工作。

目前，对于恶意长时间持有电源锁的应用，现已有方案进行管理，但是对于应用频繁持有电源锁的情况，仍没有管理方案，而这样的情况造成的电量消耗甚至比长时间持有电源锁但是次数少的更消耗终端的电量。

发明内容

本申请主要解决的技术问题是提供终端唤醒的管理方法及其终端、存储介质，能够实现对频繁申请电源锁的应用进行管理，节约终端的功耗。

为了解决上述问题，本申请第一方面提供了一种终端唤醒的管理方法，所述方法包括：

在灭屏时接收应用对电源锁的申请；其中，所述电源锁用于唤醒所述终端；

获取根据终端的多个应用对电源锁的历史申请数据而确定的第一频繁申请应用集合；

若所述应用在所述第一频繁申请应用集合中，则采用第一管理策略确定是否允许所述申请；以及

若所述应用不在所述第一频繁申请应用集合中，则采用第二管理策略确定是否允许所述申请；

其中，所述第一管理策略比第二管理策略对申请电源锁的限制程度高。

为了解决上述问题，本申请第二方面提供了一种对其唤醒进行管理的终端，包括存储器和处理器；

所述存储器存储有多个应用程序；

所述处理器用于运行至少一个所述应用程序，并且运行计算机指令以执行上述的方法。

为了解决上述问题，本申请第三方面提供了一种非易失性存储介质，存储有处理器可运行的计算机指令，所述计算机指令用于执行上述的方法。

上述方案中，终端预先根据应用对电源锁的历史申请数据确定得到频繁申请电源锁的一频繁申请应用集合，通过判断灭屏时申请电源锁的应用是否在频繁申请应用集合中，也即判断该应用是否为频繁申请应用，并根据判断结果采用不同的管理策略确定是否允许此次申请，由于当应用为频繁申请应用时采用的第一管理策略比不为频繁申请应用时采用的第二管理策略对申请电源锁的限制程度高，故可实现终端对频繁申请电源锁的应用进行管理，加强对该应用的申请电源锁的限制，进而节约终端的功耗，增加终端的续航能力，提高了用户的使用体验。

附图说明

图1是本申请终端唤醒的管理方法一实施例的流程示意图；

图2是本申请终端唤醒的管理方法另一实施例的流程示意图；

图3是本申请终端唤醒的管理方法再一实施例的部分流程示意图；

图4是本申请对其唤醒进行管理的终端一实施例的结构示意图；

图5是本申请非易失性存储介质一实施例的结构示意图。

具体实施方式

下面结合说明书附图，对本申请实施例的方案进行详细说明。

以下描述中，为了说明而不是为了限定，提出了诸如特定系统结构、接口、技术之类的具体细节，以便透彻理解本申请。

请参阅图1，图1是本申请终端唤醒的管理方法一实施例的流程图。本实施例中，该方法由如手机、电脑、笔记本等其处理器可运行应用程序的终端执行，具体包括以下步骤：

S11：终端在灭屏时接收应用对电源锁的申请。

当终端处于灭屏时，正常情况下处于待机状态。所述电源锁用于唤醒所述终端，即当该应用成功申请电源锁(即该应用持有电源锁)时，终端从待机状态被唤醒，终端的处理器处于工作状态，直至该应用释放电源锁，终端重新回到待机状态。

S12：终端获取根据终端的多个应用对电源锁的历史申请数据而确定的第一频繁申请应用集合。

该第一频繁申请应用集合为根据终端在第一设定时间内的多个应用对电源锁的历史申请数据确定的最频繁申请电源锁的至少一个应用。

具体，终端预先统计其安装的多个应用(如终端安装的所有应用或者预设的需要监控的多个应用)在第一设定时间内的灭屏期间对电源锁的历史申请数据，例如包括以下的至少一种：申请电源锁的总次数、持有电源锁的总时长以及发生申请电源锁的灭屏次数。其中，该申请电源锁的总次数为在统计期间该应用申请电源锁的总次数；该持有电源锁的总时长为在统计期间该应用持有电源锁的总时间；该发生申请电源锁的灭屏次数为在统计期间的累计该应用申请电源锁的灭屏次数，例如，在1点到2点为一次灭屏，在2点10分到3点为另一次灭屏，如果在1点到2点之间应用申请了电源锁，则无论申请多少次电源锁均记为1，如果在2点10分到3点又申请了电源锁则记为2，如此累计该申请电源锁的灭屏次数。

终端预先根据统计的各应用的历史申请数据，按照设定选择规则从统计的多个应用中选择最频繁申请电源锁的至少一个应用，以组成该第一频繁申请应用集合。其中，该设定选择规则可以为按照每种历史申请数据的优先级从高至低对各应用进行排序，选择排序最前的若干个应用，例如，该历史申请数据及其优先级为：申请电源锁的总次数高于发生申请电源锁的灭屏次数高于持有电源锁的总时长。故，终端先按照总次数从大至小对应用进行排序；对于总次数相同的应用，则按照申请灭屏次数从大至小进行排序；对于总次数和申请灭屏次数均相同的应用，则按照总时长从长至短进行排序。又或者，该设定选择规则为按照历史申请数据的加权和从大至小对各应用进行排序，选择排序最前的若干个应用，例如，该历史申请数据及其权重为：申请电源锁的总次数(权重为40％)、持有电源锁的总时长(权重为35％)，发生申请电源锁的灭屏次数(权重为25％)。终端分别将每个应用的每种历史申请数据加权求和，具体如总次数为10，总时长为30分钟，灭屏次数为2，则该应用的加权求和为10*40％+30*35％+2*25％＝15，以各应用的和从大至小排序。

终端在接收到应用对电源锁的申请时，获取其预先确定的第一频繁申请应用集合，并判断该应用是否在该第一频繁申请应用集合中，根据不同判断结果执行下述S13或S14，其中，具体可通过查找第一频繁申请应用集合的应用名中是否存在与申请电源锁的应用名匹配来确定该应用是否在第一频繁申请集合中。

S13：若所述应用在所述第一频繁申请应用集合中，终端则采用第一管理策略确定是否允许所述申请。

S14：若所述应用不在所述第一频繁申请应用集合中，终端则采用第二管理策略确定是否允许所述申请。

终端预设有第一管理策略和第二管理策略，并根据该应用是否在第一频繁应用集合中，来确定采用哪一个管理策略来处理此次应用对电源锁的申请。其中，所述第一管理策略比第二管理策略对申请电源锁的限制程度高。例如，第一管理策略规定的应用在每次灭屏期间允许申请电源锁的次数低于第二管理策略规定的应用在每次灭屏期间允许申请的次数，又或者，第一管理策略规定的应用在每次灭屏期间允许申请电源锁的频率低于第二管理策略规定的对应频率。可以理解的是，对于不属于第一频繁应用集合的应用，可采用对该应用的申请电源锁不做限制，也即，该第二管理策略为直接允许该应用对电源锁的申请。

在一实施例中，该第一管理策略包括第一第三方管理策略和第一系统管理策略；第二管理策略包括第二第三方管理策略和第二系统管理策略。其中，第一第三方管理策略和第二第三方管理策略是对第三方应用的管理策略，第一系统管理策略和第二系统管理策略是对系统应用的管理策略。由于第三方应用和系统应用从性质上为不同的两种应用，故其对电源锁的申请也可采用不同的管理策略，具体，针对该两种应用的管理策略可根据两种应用对电源锁的申请需求确定。对应地，上述S13包括子步骤：若所述应用在所述第一频繁申请应用集合中且为第三方应用，则采用第一第三方管理策略确定是否允许所述申请；若所述应用在所述第一频繁申请应用集合中且为系统应用，则采用第一系统管理策略确定是否允许所述申请；上述S14包括子步骤：若所述应用不在所述第一频繁申请应用集合中且为第三方应用，则采用第二第三方管理策略确定是否允许所述申请；若所述应用不在所述频繁申请应用集合中且为系统应用，则采用第二系统管理策略确定是否允许所述申请。

本实施例中，终端预先根据应用对电源锁的历史申请数据确定得到频繁申请电源锁的一频繁申请应用集合，通过判断灭屏时申请电源锁的应用是否在频繁申请应用集合中，也即判断该应用是否为频繁申请应用，并根据判断结果采用不同的管理策略确定是否允许此次申请，由于当应用为频繁申请应用时采用的第一管理策略比不为频繁申请应用时采用的第二管理策略对申请电源锁的限制程度高，故可实现终端对频繁申请电源锁的应用进行管理，加强对该应用的申请电源锁的限制，进而节约终端的功耗，增加终端续航能力，提高了用户的使用体验。

请参阅图2，图2是本申请终端唤醒的管理方法另一实施例的流程图。同理于上一实施例，本实施例方法由终端执行。另外，本实施例方法针对第三方应用和系统应用实现不同的管理策略，具体包括以下步骤：

S21：终端在灭屏时接收应用对电源锁的申请。

其中，S21的描述请参阅上一实施例S11的说明，在此不做赘述。

S22：终端判断所述应用是否为系统应用，以及判断应用是否在第一频繁申请应用集合。若应用为第三方应用(即应用不为系统应用)且在第一频繁申请应用集合，则采用第一第三方管理策略确定是否允许所述申请，也即执行S231-S233；若应用为第三方应用且不在第一频繁申请应用集合，则采用第二第三方管理策略确定是否允许所述申请，也即执行S241-S244；若应用为系统应用且在第一频繁申请应用集合，则采用第一系统管理策略确定是否允许所述申请，也即执行S234-S236；若应用为系统应用且不在第一频繁申请应用集合，则采用第二系统管理策略确定是否允许所述申请，也即执行S243。

其中，终端可根据应用的名称或者其他属性信息确定其为第三方应用或者系统应用。另外，终端获取根据终端的多个应用对电源锁的历史申请数据而确定的第一频繁申请应用集合，并判断应用是否在第一频繁申请应用集合。

上述两个判断的先后顺序可根据情况进行调整，例如，可先判断应用是否为系统应用，若是系统应用，则继续判断该系统应用是否在第一频繁申请应用集合中；若不是系统应用，也即是第三方应用，则也继续对第三方应用是否在第一频繁申请应用集合中。具体地，该第一频繁申请应用集合可包括第一频繁申请第三方应用子集和第一频繁申请系统应用子集。该第一频繁申请第三方应用子集包括根据在第一设定时间内各第三方应用在灭屏时对电源锁的历史申请数据确定的频繁申请电源锁的前若干个第三方应用。当判断该应用为第三方应用时，则继续判断该应用是否在第一频繁申请第三方应用子集。第一频繁申请系统应用子集包括根据在第一设定时间内各系统应用在灭屏时对电源锁的历史申请数据确定的频繁申请电源锁的前若干个系统应用。当判断该应用为系统应用时，则继续判断该应用是否在第一频繁申请系统应用子集。当然，该第一频繁申请应用集合也可不分上述两个子集，也即该集合不管应用类型直接按照频繁申请电源锁的顺序选择前若干个应用，无论判断出应用为第三方应用还是系统应用，均继续利用同一集合判断该应用是否在该集合中。

另外，终端也可以先判断应用是否在第一频繁申请应用集合中，再判断该应用是否为系统应用。

S231:终端判断所述应用是否为常用类应用。若是，则执行S232；否则执行S233。

其中，所述常用类应用由用户预先设置，或者由终端根据所述应用的属性或者历史使用情况预先确定的。

本实施例中，若应用为第三方应用，且该应用在上述第一频繁申请应用集合中，则终端继续判断该应用是否为常用类应用，其中，终端可根据判断该应用的名称或其他属性是否与常用类应用的一致，确定应用是否为常用类应用。

S232：若所述应用在本次灭屏期间的申请电源锁的次数不超过第一设定次数，则允许所述申请，否则不允许所述申请。

本实施例中，若应用为第三方应用，且该应用在上述第一频繁申请应用集合中，且应用为常用类应用，则确定该应用每次灭屏可申请电源锁的次数为第一设定次数。故终端获取其之前记录的该应用在本次灭屏期间的申请次数，并判断该应用在本次灭屏期间的申请次数是否超过第一设定次数，若不超过，则允许应用申请电源锁，此时应用持有电源锁，终端因此被唤醒，直至应用释放该电源锁；若超过，则不再允许应用申请电源锁，此时终端不会被该应用唤醒。

S233：若所述终端当前处于充电状态，则允许所述申请，否则不允许所述申请。

本实施例中，若应用为第三方应用，且该应用在上述第一频繁申请应用集合中，且应用不为常用类应用，则确定该终端仅可在充电状态可申请电源锁。故，终端检测当前是否处于充电状态，若是，则允许应用申请电源锁，此时应用持有电源锁，终端因此被唤醒，直至应用释放该电源锁；若否，则不允许应用申请电源锁，此时终端不会被该应用唤醒。

S241：终端判断所述应用是否在第二频繁申请应用集合中。若是，则执行S242，否则执行S243。

其中，所述第二频繁申请应用集合为根据终端在第二设定时间内的多个应用对电源锁的历史申请数据确定的最频繁申请电源锁的至少一个应用，上述第一设定时间短于或长于所述第二设定时间。例如，该第一设定时间为12小时，第二设定时间为7天。

在一实施例中，该第二设定时间大于一天。类似在S12中对获取第一频发申请应用集合的描述，终端预先统计其安装的多个应用(如终端安装的所有应用或者预设的需要监控的多个应用)在灭屏期间对电源锁的历史申请数据，例如包括以下的至少一种：申请电源锁的总次数、持有电源锁的总时长以及发生申请电源锁的灭屏次数。终端预先在设定更新时间时，根据之前的第二设定时间中统计的每天各应用的历史申请数据，按照设定选择规则从统计的多个应用中选择在之前的第二设定时间内每天最频繁申请电源锁的设定数据个应用作为当天频繁申请应用；统计在第二设定时间内每个当天频繁申请应用的出现次数，并按照该出现次数从大至小对当天频繁申请应用进行排序，选择该排序前若干个应用组成第二频繁申请应用集合。在一应用场景中，该第二设定时间为7天，设定更新时间为每天零时。

同理于第一频繁申请应用集合，该第二频繁申请应用集合也可分为包括第二频繁申请第三方应用子集和第二频繁申请系统应用子集，该两个第二子集类似于上述两个第一子集。由于本步骤是在确定应用为第三方应用时执行的，故本步骤S241具体为判断所述应用是否在第二频繁申请第三方应用子集中。对于下述步骤S234是在确定应用为系统应用时执行的，故本步骤S234具体为判断所述应用是否在第二频繁申请系统应用子集中。

S242：终端判断所述应用是否为常用类应用。若是，则执行S243，否则执行S244。

其中，所述常用类应用由用户预先设置，或者由终端根据所述应用的属性或者历史使用情况预先确定的。

本实施例中，若应用为第三方应用，且该应用不在上述第一频繁申请应用集合但在第二频繁应用集合中，则终端继续判断该应用是否为常用类应用，其中，终端可根据判断该应用的名称或其他属性是否与常用类应用的一致，确定应用是否为常用类应用。

S243：终端直接允许所述申请。

本实施例中，若应用属于以下其中一种情况：1、应用为第三方应用、且不在上述第一频繁申请应用集合但在第二频繁申请应用集合中、且为常用类应用，2、应用为系统应用且不在第一频繁申请应用集合中，3、应用为第三方应用，且该应用同时不在上述第一频繁申请应用集合和第二频繁申请应用集合中；则不限制该应用申请电源锁，也即允许该应用无条件申请电源锁，此时应用持有电源锁，终端因此被唤醒，直至应用释放该电源锁。

S244：若所述应用在本次灭屏期间的申请电源锁的次数不超过第二设定次数，则终端允许所述申请，否则不允许所述申请。

本实施例中，若应用为第三方应用，且该应用不在上述第一频繁申请应用集合但在第二频繁申请应用集合中，且该应用不为常用类应用，则确定该应用每次灭屏可申请电源锁的次数为第二设定次数。故终端获取其之前记录的该应用在本次灭屏期间的申请次数，并判断该应用在本次灭屏期间的申请次数是否超过第二设定次数，若不超过，则允许应用申请电源锁，此时应用持有电源锁，终端因此被唤醒，直至应用释放该电源锁；若超过，则不再允许应用申请电源锁，此时终端不会被该应用唤醒。

可以理解的是，在其他实施例中，当终端在上述S241判断应用在第二频繁申请应用集合中时，可不执行S242-S243，直接执行S244，也即若应用为第三方应用，且该应用不在上述第一频繁申请应用集合但在第二频繁申请应用集合中，则执行上述S244。

S234：终端判断所述应用是否在第二频繁申请应用集合中。若是，则执行S235，否则执行S236。

具体，S234的描述请参阅上述S241的说明，在此不做赘述。

S235：若所述应用在本次灭屏期间的申请电源锁的次数不超过第三设定次数，则终端允许所述申请，否则不允许所述申请。

本实施例中，若应用为系统应用，且该应用同时在上述第一频繁申请应用集合和第二频繁申请应用集合中，则确定该应用每次灭屏可申请电源锁的次数为第三设定次数。故终端获取其之前记录的该应用在本次灭屏期间的申请次数，并判断该应用在本次灭屏期间的申请次数是否超过第三设定次数，若不超过，则允许应用申请电源锁，此时应用持有电源锁，终端因此被唤醒，直至应用释放该电源锁；若超过，则不再允许应用申请电源锁，此时终端不会被该应用唤醒。

S236：若所述应用在本次灭屏期间的申请电源锁的次数不超过第四设定次数，则允许所述申请，否则不允许所述申请。

本实施例中，若应用为系统应用，且该应用在上述第一频繁申请应用集合但不在第二频繁申请应用集合中，则确定该应用每次灭屏可申请电源锁的次数为第四设定次数。故终端获取其之前记录的该应用在本次灭屏期间的申请次数，并判断该应用在本次灭屏期间的申请次数是否超过第四设定次数，若不超过，则允许应用申请电源锁，此时应用持有电源锁，终端因此被唤醒，直至应用释放该电源锁；若超过，则不再允许应用申请电源锁，此时终端不会被该应用唤醒。

本实施例中，所述第一设定次数可设定为小于所述第二设定次数，第三设定次数可设定为小于第一设定次数和第二设定次数。在一应用场景中，该第一设定次数为2、第二设定次数为4、第三设定次数为1。所述第四设定次数可设定为当天平均每个灭屏期间中所述电源锁的申请次数，或者为第二设定时间中每天平均每个灭屏期间中所述电源锁的申请次数n。该n＝(SumA/2A)/avgScreenOff。其中，SumA为该应用在第二设定时间A内申请电源锁的总次数，avgScreenOff为每天平均的灭屏次数。在一应用场景中，第二设定时间为7天，Sum7为140次，avgScreenOf为5次，则n＝(Sum7/14)/avgScreenOff＝2。

可以理解的是，在其他实施例中，终端也可不对应用进行第三方应用和系统应用的区分，也即，终端在接收到应用对电源锁的申请时，并判断应用是否在第一频繁申请集合中，若在，则执行S231-S233或者执行S234-S236；若否，则执行S241-S244或者仅执行S243。当然，第一管理策略和第二管理策略并不限于上述所提及的方式，可根据实际需求，进行具体调整。

请参阅图3，图3是本申请终端唤醒的管理方法再一实施例的部分流程图。本实施例方法除包括图1或图2所示的步骤外，还包括预先确定上述第一频繁申请应用集合，具体包括以下步骤：

S31：终端记录在灭屏时每个应用对所述电源锁的申请次数以及持有时间。

其中，该持有时间是指应用从成功申请电源锁至释放电源锁之间的时间段。

在另一实施例中，终端并非记录所有灭屏时候发生的电源锁的历史申请数据，终端可判断灭屏时间超过第三设定时间时，才记录所述终端在灭屏时每个应用对所述电源锁的申请次数以及使用时间。在一应用场景中，该第三设定时间为1分钟。例如，当终端灭屏超过1分钟后，每当有应用申请电源锁，则记录申请电源锁的应用名，如果该应用在历史记录中已出现，则将历史记录中将对应该应用名的申请次数加一，并将成功申请的开始时间记录下来。当应用释放电源锁的时候，记录该应用的申请结束时间，并将申请结束时间与申请开始时间之差(本次持有电源锁的时长)累计到该应用名对应的总持有时长之中。

S32：终端在满足设定条件时，统计之前的第一设定时间之间每个应用的历史申请数据。

其中，所述历史申请数据包括以下的至少一种：上述申请电源锁的总次数、上述持有电源锁的总时长以及上述发生申请电源锁的灭屏次数。

所述设定条件包括以下至少一种：终端电量剩余设定电量、灭屏累计时间超过第四设定时间、每天设定时间点。在一应用场景中，该设定设定电量为50％的电量；第四设定时间为8个小时，设定时间点为零时。

S33：终端按照每种历史申请数据的优先级或者所述历史申请数据的权重和对所述应用进行排序，并取排序的前若干个应用组成所述第一频繁申请应用集合。

具体可参阅上述实施例S12步骤的相应描述。

例如，该第一设定时间为12个小时。当终端触发上述设定条件的时候，终端首先统计从当前时间到12个小时之前这段时间内的唤醒事件并记录这段时间内的灭屏次数、按照应用名区分统计每个应用的申请电源锁的总次数、持有电源锁的总时长以及发生申请电源锁的灭屏次数。终端按照申请锁的总次数(若两个应用间的总次数相差在设定比例内，则可认为该两个应用的总次数相同，例如，设定比例为30％，一个应用持锁100次，另一个应用持锁120次，则可认为总次数相同)、发生申请电源锁的灭屏次数、持有电源锁的总时长的优先级从高至低对应用进行排序，得到最近12小时最频繁申请电源锁的应用列表，按照系统应用额第三方应用分别从列表中取出前5的应用分别组成第一频繁申请第三方应用子集和第一频繁申请系统应用子集。其中，系统应用不包括终端的操作系统，如安卓(android)操作系统。

若本实施例方法包括图2所示步骤，则该方法还包括预先确定第二频繁申请应用集合，具体可如图2所示实施例中S241中所述确定该第二频繁申请应用集合。

例如，该第二设定时间为7天，设定更新时间为每天零时。终端在每天零时(如本步骤上述获取第一频繁申请应用集合方式)记录昨天0点到24点最频繁申请电源锁的前5个应用，并更新最近7天的第二频繁申请应用列表，更新方法为：当获取昨天最频繁申请电源锁的前5个应用之后，终端取从昨天开始前7天每天获取的5个应用，按照出现的天数从大至小排序(例如，A应用在7天内出现2次，而B应用出现3次，则认为B的排名比A靠前即是更频繁唤醒手机的应用)，分别取系统应用和第三方应用的列表中前10个应用(如果少于10个则全取)以组成第二频繁申请第三方应用子集和第二频繁申请系统应用子集。

上述方法实施例，终端预先根据应用对电源锁的历史申请数据确定得到频繁申请电源锁的一频繁申请应用集合，通过判断灭屏时申请电源锁的应用是否在频繁申请应用集合中，也即判断该应用是否为频繁申请应用，并根据判断结果采用不同的管理策略确定是否允许此次申请，由于当应用为频繁申请应用时采用的第一管理策略比不为频繁申请应用时采用的第二管理策略对申请电源锁的限制程度高，故可实现终端对频繁申请电源锁的应用进行管理，加强对该应用的申请电源锁的限制，进而节约终端的功耗，增加终端的续航能力，提高了用户的使用体验。

请参阅图4，图4是本申请对其唤醒进行管理的终端一实施例的结构示意图。本实施例中，该终端40包括存储器41、处理器42以及通信电路43和显示屏44。其中，终端40的各个组件可通过信号线如总线或若干条分别处理器和各组件的导线耦合在一起，以实现终端40的每个组件之间是实现相互连接，或者实现除处理器外的其他组件均连接于该处理器42。

通信电路43用于与其他设备实现通信，具体可包括发送器和接收器。

显示屏44用于响应处理器42的显示指令实现显示。

存储器41用于存储多个应用程序(简称为应用)、处理器42执行的计算机指令以及处理器42在处理过程中的数据，其中，该存储器41包括非易失性存储部分，用于存储上述计算机指令。在另一实施例中，该存储器41可仅作为处理器42的内存而缓存该处理器42执行的计算机指令，该计算机指令实际存储于终端之外设备中，处理器42通过与外部设备连接，通过调用外部存储的计算机指令，以执行相应处理。

处理器42控制该终端40的操作，处理器42还可以称为CPU(Central ProcessingUnit，中央处理单元)。处理器42可能是一种集成电路芯片，具有信号的处理能力。处理器42还可以是通用处理器、数字信号处理器(DSP)、专用集成电路(ASIC)、现成可编程门阵列(FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。

在本实施例中，处理器42用于运行存储器存储的至少应用程序，并通过调用存储器41存储的计算机指令，执行如下操作：

在灭屏时接收应用对电源锁的申请；其中，所述电源锁用于唤醒所述终端；该灭屏可以指终端的显示屏44灭屏且终端进入休眠状态。

获取根据多个应用对电源锁的历史申请数据而确定的第一频繁申请应用集合；

若所述应用在所述第一频繁申请应用集合中，则采用第一管理策略确定是否允许所述申请；以及

若所述应用不在所述第一频繁申请应用集合中，则采用第二管理策略确定是否允许所述申请；

其中，所述第一管理策略比第二管理策略对所述电源锁的申请限制程度高。

第一可选地，所述第一管理策略包括第一第三方管理策略和第一系统管理策略；所述第二管理策略包括第二第三方管理策略和第二系统管理策略；

处理器42执行所述若所述应用在所述第一频繁申请应用集合中，则采用第一管理策略确定是否允许所述申请，包括：若所述应用在所述第一频繁申请应用集合中且为第三方应用，则采用第一第三方管理策略确定是否允许所述申请；若所述应用在所述第一频繁申请应用集合中且为系统应用，则采用第一系统管理策略确定是否允许所述申请；

处理器42执行所述若所述应用不在所述第一频繁申请应用集合中，则采用第二管理策略确定是否允许所述申请，包括：若所述应用不在所述第一频繁申请应用集合中且为第三方应用，则采用第二第三方管理策略确定是否允许所述申请；若所述应用不在所述频繁申请应用集合中且为系统应用，则采用第二系统管理策略确定是否允许所述申请。

基于上述第一可选，所述第一频繁申请应用集合可为根据终端在第一设定时间内的多个应用对电源锁的历史申请数据确定的最频繁申请电源锁的至少一个应用；

处理器42执行所述采用第一第三方管理策略确定是否允许所述申请，可具体包括：判断所述应用是否为常用类应用，其中，所述常用类应用由用户预先设置，或者由终端根据所述应用的属性或者历史使用情况预先确定的；若是，则若所述应用在本次灭屏期间的申请电源锁的次数不超过第一设定次数，则允许所述申请，否则不允许所述申请；若否，则若所述终端当前处于充电状态，则允许所述申请，否则不允许所述申请；

处理器42执行所述采用第二第三方管理策略确定是否允许所述申请，可具体包括：判断所述应用是否在第二频繁申请应用集合中；其中，所述第二频繁申请应用集合为根据终端在第二设定时间内的多个应用对电源锁的历史申请数据确定的最频繁申请电源锁的至少一个应用，所述第一设定时间短于或长于所述第二设定时间；若是，则若所述应用在本次灭屏期间的申请电源锁的次数不超过第二设定次数，则允许所述申请，否则不允许所述申请；若否，则直接允许所述申请；

所述第一设定次数小于所述第二设定次数。

进一步地，在判断所述应用在所述第二频繁申请应用集合中时，处理器42在执行所述若所述应用在本次灭屏期间的申请电源锁的次数不超过第二设定次数，则允许所述申请，否则不允许所述申请之前，还用于：判断所述应用是否为所述常用类应用；若是，则直接允许所述申请；若否，则执行所述若所述应用在本次灭屏期间的申请电源锁的次数不超过第二设定次数，则允许所述申请，否则不允许所述申请的步骤；

另外，处理器42还可用于：在设定更新时间时，获取之前的第二设定时间内每天的最频繁申请电源锁的设定数目个应用作为当天频繁申请应用；统计在所述之前的第二设定时间内每个当天频繁申请应用的出现次数，并按照统计的出现次数从大至小对所述应用进行排序，取排序的前若干个应用组成所述第二频繁申请应用集合。

基于上述第一可选，所述第一频繁申请应用集合可为根据终端在第一设定时间内的多个应用对电源锁的历史申请数据确定的最频繁申请电源锁的至少一个应用；

处理器42执行所述采用第一系统管理策略确定是否允许所述申请，可具体包括：判断所述应用是否在第二频繁申请应用集合中；其中，所述第二频繁申请应用集合为根据终端在第二设定时间内的多个应用对电源锁的历史申请数据确定的最频繁申请电源锁的至少一个应用，所述第一设定时间短于或长于所述第二设定时间；若在第二频繁申请应用集合中，则若所述应用在本次灭屏期间的申请电源锁的次数不超过第三设定次数，则允许所述申请，否则不允许所述申请；若不在第二频繁申请应用集合中，则若所述应用在本次灭屏期间的申请电源锁的次数不超过第四设定次数，则允许所述申请，否则不允许所述申请；

处理器42执行所述采用第二系统管理策略确定是否允许所述申请，可具体包括：直接允许所述申请。

进一步地，所述第四设定次数为当天或在所述第二设定时间内每天平均每个灭屏期间中所述电源锁的申请次数。

第二可选地，处理器42还用于：记录所述终端在灭屏时每个应用对所述电源锁的申请次数以及持有时间；在满足设定条件时，统计之前的第一设定时间之间每个应用的历史申请数据，其中，所述历史申请数据包括以下的至少一种：申请电源锁的总次数、持有电源锁的总时长以及发生申请电源锁的灭屏次数；按照每种历史申请数据的优先级从高至低和对所述应用进行排序或者根据所述历史申请数据的权重和从大至小对所述应用进行排序，并取排序的前若干个应用组成所述第一频繁申请应用集合。

基于上述第二可选，处理器42执行所述记录所述终端在灭屏时每个应用对所述电源锁的申请次数以及持有时间可具体包括：当所述灭屏时间超过第三设定时间时，记录所述终端在灭屏时每个应用对所述电源锁的申请次数以及持有时间；

基于上述第二可选，所述设定条件包括以下至少一种：终端的电量剩余至设定电量、灭屏累计时间超过第四设定时间、每天设定时间点。

可以理解的是，在其他实施例中，该终端可不包括上述通信电路43。

在另一实施例中，该终端的处理器42还用于执行上述实施例的方法。

请参阅图5，本申请还提供一种非易失性存储介质的实施例，该非易失性存储介50存储有处理器可运行的计算机指令51，该计算机指令51用于执行上述实施例中的方法。在一应用场景，该存储介质50可为如图4所示的存储器41。

上述方案，终端预先根据应用对电源锁的历史申请数据确定得到频繁申请电源锁的一频繁申请应用集合，通过判断灭屏时申请电源锁的应用是否在频繁申请应用集合中，也即判断该应用是否为频繁申请应用，并根据判断结果采用不同的管理策略确定是否允许此次申请，由于当应用为频繁申请应用时采用的第一管理策略比不为频繁申请应用时采用的第二管理策略对申请电源锁的限制程度高，故可实现终端对频繁申请电源锁的应用进行管理，加强对该应用的申请电源锁的限制，例如可达到降低灭屏时应用持锁唤醒终端的次数，进而节约终端的功耗，增加终端的续航能力，提高了用户的使用体验。

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

Claims (10)

1.一种终端唤醒的管理方法，其特征在于，所述方法包括：

在灭屏时接收应用对电源锁的申请；其中，所述电源锁用于唤醒所述终端；

获取根据所述终端在第一设定时间内的多个应用对电源锁的历史申请数据而确定的第一频繁申请应用集合；

若所述应用在所述第一频繁申请应用集合中且为第三方应用，则判断所述应用是否为常用类应用，并采用第一第三方管理策略确定是否允许所述申请；其中，所述常用类应用由用户预先设置，或者由终端根据所述应用的属性或者历史使用情况预先确定的；以及

若所述应用不在所述第一频繁申请应用集合中且为所述第三方应用，则判断所述应用是否在第二频繁申请应用集合中，并采用第二第三方管理策略确定是否允许所述申请；其中，所述第二频繁申请应用合集为根据终端在第二设定时间内的多个应用对电源锁的历史申请数据确定的最频繁申请电源锁的至少一个应用，所述第一设定时间短于或长于所述第二设定时间；

其中，所述第一第三方管理策略比所述第二第三方管理策略对申请所述电源锁的限制程度高。

2.根据权利要求1所述的方法，其特征在于，第一管理策略包括所述第一第三方管理策略和第一系统管理策略；第二管理策略包括所述第二第三方管理策略和第二系统管理策略；所述方法还包括：

若所述应用在所述第一频繁申请应用集合中且为系统应用，则采用第一系统管理策略确定是否允许所述申请；

若所述应用不在所述第一频繁申请应用集合中且为系统应用，则采用第二系统管理策略确定是否允许所述申请。

3.根据权利要求1所述的方法，其特征在于，所述第一频繁申请应用集合为根据终端在第一设定时间内的多个应用对电源锁的历史申请数据确定的最频繁申请电源锁的至少一个应用；

所述若所述应用在所述第一频繁申请应用集合中且为第三方应用，则判断所述应用是否为常用类应用，并采用第一第三方管理策略确定是否允许所述申请，包括：

若是，则若所述应用在本次灭屏期间的申请电源锁的次数不超过第一设定次数，则允许所述申请，否则不允许所述申请；

若否，则若所述终端当前处于充电状态，则允许所述申请，否则不允许所述申请；

所述若所述应用不在所述第一频繁申请应用集合中且为所述第三方应用，则判断所述应用是否在第二频繁申请应用集合中，并采用第二第三方管理策略确定是否允许所述申请，包括：

若是，则若所述应用在本次灭屏期间的申请电源锁的次数不超过第二设定次数，则允许所述申请，否则不允许所述申请；

若否，则直接允许所述申请；

其中，所述第一设定次数小于所述第二设定次数。

4.根据权利要求3所述的方法，其特征在于，在判断所述应用在所述第二频繁申请应用集合中时，在所述若所述应用在本次灭屏期间的申请电源锁的次数不超过第二设定次数，则允许所述申请，否则不允许所述申请之前，还包括：

判断所述应用是否为所述常用类应用；

若是，则直接允许所述申请；

若否，则执行所述若所述应用在本次灭屏期间的申请电源锁的次数不超过第二设定次数，则允许所述申请，否则不允许所述申请的步骤；

所述方法还包括：

在设定更新时间时，获取之前的第二设定时间内每天的最频繁申请电源锁的设定数目个应用作为当天频繁申请应用；

统计在所述之前的第二设定时间内每个所述当天频繁申请应用的出现次数，并按照统计的出现次数从大至小对所述应用进行排序，取排序的前若干个应用组成所述第二频繁申请应用集合。

5.根据权利要求2所述的方法，其特征在于，所述第一频繁申请应用集合为根据终端在第一设定时间内的多个应用对电源锁的历史申请数据确定的最频繁申请电源锁的至少一个应用；

所述采用第一系统管理策略确定是否允许所述申请，包括：

判断所述应用是否在第二频繁申请应用集合中；其中，所述第二频繁申请应用集合为根据终端在第二设定时间内的多个应用对电源锁的历史申请数据确定的最频繁申请电源锁的至少一个应用，所述第一设定时间短于或长于所述第二设定时间；

若是，则若所述应用在本次灭屏期间的申请电源锁的次数不超过第三设定次数，则允许所述申请，否则不允许所述申请；

若否，则若所述应用在本次灭屏期间的申请电源锁的次数不超过第四设定次数，则允许所述申请，否则不允许所述申请；

所述采用第二系统管理策略确定是否允许所述申请，包括：

直接允许所述申请。

6.根据权利要求5所述的方法，其特征在于，所述第四设定次数为当天或在所述第二设定时间内每天平均每个灭屏期间中所述电源锁的申请次数。

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

记录所述终端在灭屏时每个应用对所述电源锁的申请次数以及持有时间；

在满足设定条件时，统计之前的第一设定时间之间每个应用的历史申请数据，其中，所述历史申请数据包括以下的至少一种：申请电源锁的总次数、持有电源锁的总时长以及发生申请电源锁的灭屏次数；

按照每种历史申请数据的优先级从高至低对所述应用进行排序或者根据所述历史申请数据的权重和从大至小对所述应用进行排序，并取排序的前若干个应用组成所述第一频繁申请应用集合。

8.根据权利要求7所述的方法，其特征在于，所述记录所述终端在灭屏时每个应用对所述电源锁的申请次数以及持有时间，包括：

当所述灭屏时间超过第三设定时间时，记录所述终端在灭屏时每个应用对所述电源锁的申请次数以及持有时间；

所述设定条件包括以下至少一种：所述终端的电量剩余至设定电量、灭屏累计时间超过第四设定时间、每天设定时间点。

9.一种对其唤醒进行管理的终端，其特征在于，包括存储器和处理器；

所述存储器存储有多个应用程序；

所述处理器用于运行至少一个所述应用程序，并且运行计算机指令以执行权利要求1至8任一项所述的方法。

10.一种非易失性存储介质，其特征在于，存储有处理器可运行的计算机指令，所述计算机指令用于执行权利要求1至8任一项所述的方法。

Images