基于终端的唤醒锁控制方法、装置及终端与流程

本发明涉及终端技术领域，尤其涉及一种基于终端的唤醒锁控制装置、装置及终端。

背景技术：

安卓系统(Android)是目前终端上广泛使用的操作系统，通常用户会在终端上设置多个应用程序(Application，APP)。为了确保终端上设置的应用程序正常运行，安卓系统提供了唤醒锁(WakeLock)机制。终端上设置的应用程序可以向安卓系统申请唤醒锁，安卓系统为应用程序及其调用的服务分配唤醒锁，只要被持有唤醒锁的数量大于0，安卓系统就无法进入休眠状态，也就是说，只有当终端上设置的任一应用程序及其调用的服务都未持有唤醒锁时，安卓系统才能进入休眠状态。

为了阻止安卓系统进入休眠状态，有很多应用程序及其调用的服务存在不合理持有唤醒锁的情况，例如，游戏类应用程序在长时间后台运行时仍然持有唤醒锁、电子书类应用程序调用的更新服务长时间持有唤醒锁等等。由于应用程序及其调用的服务长时间不合理持有唤醒锁，使得灭屏待机电流从十几毫安提高到了几十毫安甚至100多毫安，这就会增加终端能耗，还会过多占用系统资源。

技术实现要素：

本发明实施例中提供了一种基于终端的唤醒锁控制方法、装置及终端，用于解决现有技术中存在的应用程序及其调用的服务长时间不合理持有唤醒锁导致的增加终端能耗，过多占用系统资源的问题。

第一方面，本发明实施例提供一种基于终端的唤醒锁控制方法，包括：

获取后台运行的第一应用程序；

判断所述第一应用程序是否符合预设筛选条件；

选取不符合所述预设筛选条件的第一应用程序，得到第二应用程序；

强制释放所述第二应用程序及其调用的服务持有的唤醒锁。

结合第一方面，在第一方面的第一种可能的实现方式中，所述预设筛选条件包括预设时长、预设应用场景名单和黑名单，判断所述第一应用程序是否符合预设筛选条件，具体包括：

统计所述第一应用程序的后台运行时长，判断所述第一应用程序的后台运行时长是否超过所述预设时长；

根据所述第一应用程序调用的接口确定所述第一应用程序的应用场景，将所述第一应用程序的应用场景与所述预设应用场景名单进行比对；以及，

将所述第一应用程序与所述黑名单比对；

确定后台运行时长超过预设时长、应用场景未保存在所述预设应用场景名单中且未保存在所述黑名单中的第一应用程序不符合所述预设筛选条件。

结合第一方面的第一种可能的实现方式，在第一方面的第二种可能的实现方式中，还包括：

确定后台运行时长小于预设时长、应用场景保存在所述预设应用场景名单中或者保存在所述黑名单中的第一应用程序符合所述预设筛选条件。

结合第一方面、第一方面的第一种可能的实现方式或者第一方面的第二种可能的实现方式，在第一方面的第三种可能的实现方式中，强制释放所述第二应用程序及其调用的服务持有的唤醒锁之前，还包括：

保存所述第二应用程序及其调用的服务持有的唤醒锁的特征信息，所述特征信息包括对应第二应用程序的标识；

强制释放所述第二应用程序及其调用的服务持有的唤醒锁之后，还包括：

将所述第二应用程序设置为代理锁状态。

结合第一方面的第三种可能的实现方式，在第一方面的第四种可能的实现方式中，还包括：

若接收到携带所述第二应用程序的标识的唤醒锁申请请求，则在包括所述第二应用程序的标识的特征信息中记录所述唤醒锁申请请求，不执行所述唤醒锁申请请求；

若接收到携带所述第二应用程序的标识的唤醒锁变更请求，则在包括所述第二应用程序的标识的特征信息中记录所述唤醒锁变更请求，不执行所述唤醒锁变更请求；

若接收到携带所述第二应用程序的标识的唤醒锁删除请求，则删除包括所述第二应用程序的标识的特征信息，不执行所述唤醒锁删除请求。

结合第一方面的第三种可能的实现方式，在第一方面的第五种可能的实现方式中，还包括：

判断所述第二应用程序是否符合强制恢复条件；

若确定所述第二应用程序符合强制恢复条件，则根据包括所述第二应用程序的标识的特征信息，强制恢复所述第二应用程序及其调用的服务持有的唤醒锁；

取消所述第二应用程序的代理锁状态。

结合第一方面的第五种可能的实现方式，在第一方面的第六种可能的实现方式中，所述强制恢复条件包括前台运行或者被调用，判断所述第二应用程序是否符合强制恢复条件，具体包括：

监控所述第二应用程序是否转换为前台运行或者所述第二应用程序是否被调用；

若监控到所述第二应用程序转换为前台运行或者所述第二应用程序被调用，则确定所述第二应用程序符合所述强制恢复条件。

结合第一方面的第六种可能的实现方式，在第一方面的第七种可能的实现方式中，还包括：

若监控到所述第二应用程序未转换为前台运行且所述第二应用程序未被调用，则确定所述第二应用程序不符合所述强制恢复条件。

第二方面，本发明实施例提供一种基于终端的唤醒锁控制装置，包括：

获取模块，用于获取后台运行的第一应用程序；

第一判断模块，用于判断所述第一应用程序是否符合预设筛选条件；

选取模块，用于选取不符合所述预设筛选条件的第一应用程序，得到第二应用程序；

释放模块，用于强制释放所述第二应用程序及其调用的服务持有的唤醒锁。

结合第二方面，在第二方面的第一种可能的实现方式中，所述预设筛选条件包括预设时长、预设应用场景名单和黑名单，所述第一判断模块，用于判断所述第一应用程序是否符合预设筛选条件，具体用于：

统计所述第一应用程序的后台运行时长，判断所述第一应用程序的后台运行时长是否超过所述预设时长；

根据所述第一应用程序调用的接口确定所述第一应用程序的应用场景，将所述第一应用程序的应用场景与所述预设应用场景名单进行比对；以及，

将所述第一应用程序与所述黑名单比对；

确定后台运行时长超过预设时长、应用场景未保存在所述预设应用场景名单中且未保存在所述黑名单中的第一应用程序不符合所述预设筛选条件。

结合第二方面的第一种可能的实现方式，在第二方面的第二种可能的实现方式中，还包括：

确定模块，用于确定后台运行时长小于预设时长、应用场景保存在所述预设应用场景名单中或者保存在所述黑名单中的第一应用程序符合所述预设筛选条件。

结合第二方面、第二方面的第一种可能的实现方式或者第二方面的第二种可能的实现方式，在第二方面的第三种可能的实现方式中，还包括：

保存模块，用于在所述释放模块强制释放所述第二应用程序及其调用的服务持有的唤醒锁之前，保存所述第二应用程序及其调用的服务持有的唤醒锁的特征信息，所述特征信息包括对应第二应用程序的标识；以及，

设置模块，用于在所述释放模块强制释放所述第二应用程序及其调用的服务持有的唤醒锁之后，将所述第二应用程序设置为代理锁状态。

结合第二方面的第三种可能的实现方式，在第二方面的第四种可能的实现方式中，还包括处理模块，用于：

若接收到携带所述第二应用程序的标识的唤醒锁申请请求，则在包括所述第二应用程序的标识的特征信息中记录所述唤醒锁申请请求，不执行所述唤醒锁申请请求；

若接收到携带所述第二应用程序的标识的唤醒锁变更请求，则在包括所述第二应用程序的标识的特征信息中记录所述唤醒锁变更请求，不执行所述唤醒锁变更请求；

若接收到携带所述第二应用程序的标识的唤醒锁删除请求，则删除包括所述第二应用程序的标识的特征信息，不执行所述唤醒锁删除请求。

结合第二方面的第三种可能的实现方式，在第二方面的第五种可能的实现方式中，还包括：

第二判断模块，用于判断所述第二应用程序是否符合强制恢复条件；

恢复模块，用于若确定所述第二应用程序符合强制恢复条件，则根据包括所述第二应用程序的标识的特征信息，强制恢复所述第二应用程序及其调用的服务持有的唤醒锁；

取消模块，用于取消所述第二应用程序的代理锁状态。

结合第二方面的第五种可能的实现方式，在第二方面的第六种可能的实现方式中，所述强制恢复条件包括前台运行或者被调用，所述第二判断模块，用于判断所述第二应用程序是否符合强制恢复条件，具体用于：

监控所述第二应用程序是否转换为前台运行或者所述第二应用程序是否被调用；

若监控到所述第二应用程序转换为前台运行或者所述第二应用程序被调用，则确定所述第二应用程序符合所述强制恢复条件。

结合第二方面的第六种可能的实现方式，在第二方面的第七种可能的实现方式中，所述第二判断模块，还用于：

若监控到所述第二应用程序未转换为前台运行且所述第二应用程序未被调用，则确定所述第二应用程序不符合所述强制恢复条件。

第三方面，本发明实施例提供一种终端，包括：

第一处理器，用于获取后台运行的第一应用程序；

第二处理器，用于判断所述第一应用程序是否符合预设筛选条件；选取不符合所述预设筛选条件的第一应用程序，得到第二应用程序；强制释放所述第二应用程序及其调用的服务持有的唤醒锁。

结合第三方面，在第三方面的第一种可能的实现方式中，所述预设筛选条件包括预设时长、预设应用场景名单和黑名单，所述第二处理器，用于判断所述第一应用程序是否符合预设筛选条件，具体用于：

统计所述第一应用程序的后台运行时长，判断所述第一应用程序的后台运行时长是否超过所述预设时长；

根据所述第一应用程序调用的接口确定所述第一应用程序的应用场景，将所述第一应用程序的应用场景与所述预设应用场景名单进行比对；以及，

将所述第一应用程序与所述黑名单比对；

确定后台运行时长超过预设时长、应用场景未保存在所述预设应用场景名单中且未保存在所述黑名单中的第一应用程序不符合所述预设筛选条件。

结合第三方面的第一种可能的实现方式，在第三方面的第二种可能的实现方式中，所述第二处理器，还用于：

确定后台运行时长小于预设时长、应用场景保存在所述预设应用场景名单中或者保存在所述黑名单中的第一应用程序符合所述预设筛选条件。

结合第三方面、第三方面的第一种可能的实现方式或者第三方面的第二种可能的实现方式，在第三方面的第三种可能的实现方式中，所述第二处理器，还用于：

在强制释放所述第二应用程序及其调用的服务持有的唤醒锁之前，保存所述第二应用程序及其调用的服务持有的唤醒锁的特征信息，所述特征信息包括对应第二应用程序的标识；以及，

在强制释放所述第二应用程序及其调用的服务持有的唤醒锁之后，将所述第二应用程序设置为代理锁状态。

结合第三方面的第三种可能的实现方式，在第三方面的第四种可能的实现方式中，所述第二处理器，还用于：

若接收到携带所述第二应用程序的标识的唤醒锁申请请求，则在包括所述第二应用程序的标识的特征信息中记录所述唤醒锁申请请求，不执行所述唤醒锁申请请求；

若接收到携带所述第二应用程序的标识的唤醒锁变更请求，则在包括所述第二应用程序的标识的特征信息中记录所述唤醒锁变更请求，不执行所述唤醒锁变更请求；

若接收到携带所述第二应用程序的标识的唤醒锁删除请求，则删除包括所述第二应用程序的标识的特征信息，不执行所述唤醒锁删除请求。

结合第三方面的第三种可能的实现方式，在第三方面的第五种可能的实现方式中，所述第二处理器，还用于：

判断所述第二应用程序是否符合强制恢复条件；

若确定所述第二应用程序符合强制恢复条件，则根据包括所述第二应用程序的标识的特征信息，强制恢复所述第二应用程序及其调用的服务持有的唤醒锁；

取消所述第二应用程序的代理锁状态。

结合第三方面的第五种可能的实现方式，在第三方面的第六种可能的实现方式中，所述强制恢复条件包括前台运行或者被调用，所述第二处理器，用于判断所述第二应用程序是否符合强制恢复条件，具体用于：

监控所述第二应用程序是否转换为前台运行或者所述第二应用程序是否被调用；

若监控到所述第二应用程序转换为前台运行或者所述第二应用程序被调用，则确定所述第二应用程序符合所述强制恢复条件。

结合第三方面的第六种可能的实现方式，在第三方面的第七种可能的实现方式中，所述第二处理器，还用于：

若监控到所述第二应用程序未转换为前台运行且所述第二应用程序未被调用，则确定所述第二应用程序不符合所述强制恢复条件。

由以上技术方案可见，本发明实施例提供一种基于终端的唤醒锁控制方法、装置及终端，获取后台运行的第一应用程序；判断所述第一应用程序是否符合预设筛选条件；选取不符合所述预设筛选条件的第一应用程序，得到第二应用程序；强制释放所述第二应用程序及其调用的服务持有的唤醒锁。该方案中，首先判断后台运行的第一应用程序是否符合预设筛选条件，然后选取不符合预设筛选条件的第一应用程序，得到第二应用程序，最后强制释放第二应用程序及其调用的服务持有的唤醒锁，从而可以有效控制后台运行的第一应用程序及其调用的服务持有的唤醒锁，避免后台运行且不符合预设筛选条件的第一应用程序及其调用的服务长时间不合理持有唤醒锁，进而减少终端能耗，节省系统资源。

附图说明

构成本申请的一部分的说明书附图用来提供对本发明的进一步理解，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：

图1是本发明实施例中一种基于终端的唤醒锁控制方法的流程图；

图2是本发明实施例中S12的流程图；

图3是本发明实施例中另一种基于终端的唤醒锁控制方法的流程图；

图4是本发明实施例中再一种基于终端的唤醒锁控制方法的流程图；

图5是本发明实施例中一种基于终端的唤醒锁控制装置的流程图；

图6是本发明实施例中一种终端的结构示意图。

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

具体实施方式

为了解决现有技术中存在的应用程序及其调用的服务长时间不合理持有唤醒锁导致的增加终端能耗，过多占用系统资源的问题，本发明实施例提供一种基于终端的唤醒锁控制方法，该方法可以应用在终端中，流程如图1所示，具体包括以下步骤：

S11：获取后台运行的第一应用程序。

终端上通常会设置很多应用程序，这些应用程序可能是在前台运行，也可能是在后台运行，由于前台运行的应用程序是当前用户正在使用的应用程序，前台运行的应用程序及其调用的服务持有的唤醒锁是属于合理持有唤醒锁的情况，这些唤醒锁是不能被强制释放的，因此，本实施例针对的是后台运行的应用程序，后台运行的应用程序定义为第一应用程序，第一应用程序可以是一个或多个。

S12：判断第一应用程序是否符合预设筛选条件。

预设筛选条件是根据实际需要预先设定的，在获取终端上后台运行的第一应用程序后，可以判断第一应用程序是否符合预设筛选条件。

S13：选取不符合预设筛选条件的第一应用程序，得到第二应用程序。

第一应用程序中可能会有符合预设筛选条件的，也可能会有不符合预设筛选条件的，选取不符合预设筛选条件的第一应用程序作为第二应用程序。

S14：强制释放第二应用程序及其调用的服务持有的唤醒锁。

终端上设置的应用程序在运行的过程中，会调用很多服务，此时应用程序及其调用的服务均可能持有唤醒锁。

由于第二应用程序是在后台运行的，并且不符合预设筛选条件，也就是说第二应用程序及其调用的服务器持有的唤醒锁是属于不合理持有唤醒锁的情况，因此，可以强制释放第二应用程序及其调用的服务持有的唤醒锁。

该方案中，首先判断后台运行的第一应用程序是否符合预设筛选条件，然后选取不符合预设筛选条件的第一应用程序，得到第二应用程序，最后强制释放第二应用程序及其调用的服务持有的唤醒锁，从而可以有效控制后台运行的第一应用程序及其调用的服务持有的唤醒锁，避免后台运行且不符合预设筛选条件的第一应用程序及其调用的服务长时间不合理持有唤醒锁，进而减少终端能耗，节省系统资源。

具体的，预设筛选条件的设置方式有很多种，下面以包括预设时长、预设应用场景名单和黑名单为例进行说明，上述S12中的判断第一应用程序是否符合预设筛选条件的实现过程，如图2所示，具体包括以下步骤：

S121：统计第一应用程序的后台运行时长，判断第一应用程序的后台运行时长是否超过预设时长。

第一应用程序的后台运行时长是第一应用程序从前台运行转为后台运行的时长，若第一应用程序长时间在后台运行，那么可以考虑强制释放该第一应用程序及其调用的服务持有的唤醒锁。因此，对于后台运行的第一应用程序，可以统计其后台运行时长，然后判断第一应用程序的后台运行时长是否超过预设时长。

预设时长可以根据实际需要进行设定，例如，可以设定为3分钟、5分钟、10分钟等等。

S122：根据第一应用程序调用的接口确定第一应用程序的应用场景，将第一应用程序的应用场景与预设应用场景名单进行比对。

第一应用程序在前台运行或者后台运行期间可能调用安卓系统的接口，可以根据第一应用程序调用的接口确定第一应用程序的应用场景，例如音频播放、下载等等，有些应用场景是非常重要的，中断后会影响用户体验，因此，可以获取重要的应用场景，得到预设应用场景名单。

在确定第一应用程序的应用场景后，将第一应用程序的应用场景与预设应用场景名单进行比对，确定第一应用程序的应用场景是否保存在预设应用场景名单中。

S123：将第一应用程序与黑名单比对。

终端上设置的应用程序中有些是非常重要的，强制释放其持有的唤醒锁，会严重用户体验，因此，可以预先获取这些重要的应用程序，得到黑名单，黑名单中的应用程序是不允许强制释放持有的唤醒锁的。将第一应用程序与黑名单进行比对，确定第一应用程序是否保存在该黑名单中。

需要说明的是，S121、S122和S123之间并没有严格的先后顺序，例如，可以先执行S121再执行S122在执行S123，也可以先执行S121再执行S123再执行S122，也可以通知执行S121、S122和S123。

S124：确定后台运行时长超过预设时长、应用场景未保存在预设应用场景名单中且未保存在黑名单中的第一应用程序不符合预设筛选条件。

同时，还可以确定后台运行时长小于预设时长、应用场景保存在预设应用场景名单中或者保存在黑名单中的第一应用程序符合预设筛选条件。

可以强制释放不符合预设筛选条件的第一应用程序(也就是第二应用程序)及其调用的服务持有的唤醒锁，保留预设筛选条件的第一应用程序及其调用的服务持有的唤醒锁。

本发明实施例还提供另一种基于终端的唤醒锁控制方法，该方法的流程如图3所示，在如图1所示的方法的基础上，还包括：

S15：保存第二应用程序及其调用的服务持有的唤醒锁的特征信息，特征信息包括对应第二应用程序的标识。

在强制释放第二应用程序及其调用的服务持有的唤醒锁之前，还可以保存第二应用程序及其调用的服务持有的唤醒锁的特征信息，这些特征信息中包括第二应用程序的标识，以表示该特征信息与第二应用程序有关，这些唤醒锁的特征信息可以包括绑定信息、标签信息、标记信息等等。

S16：将第二应用程序设置为代理锁状态。

在强制释放第二应用程序及其调用的服务持有的唤醒锁之后，还可以将第二应用程序设置为代理锁状态。由于第二应用程序为代理锁状态，若接收到针对第二应用程序及其调用的服务申请、变更、删除唤醒锁的请求，只是改变相应的特征信息，并不具体执行对应的请求，例如：

若接收到携带第二应用程序的标识的唤醒锁申请请求，则在包括第二应用程序的标识的特征信息中记录唤醒锁申请请求，不执行唤醒锁申请请求；

若接收到携带第二应用程序的标识的唤醒锁变更请求，则在包括第二应用程序的标识的特征信息中记录唤醒锁变更请求，不执行唤醒锁变更请求；

若接收到携带第二应用程序的标识的唤醒锁删除请求，则删除包括第二应用程序的标识的特征信息，不执行唤醒锁删除请求。

本发明实施例还提供再一种基于终端的唤醒锁控制方法，该方法的流程如图4所示，在图3的基础上，还包括：

S17：判断第二应用程序是否符合强制恢复条件。

当第二应用程序在后台运行且不符合预设筛选条件时，强制释放第二应用程序及其调用的服务持有的唤醒锁，相应地，当第二应用程序的运行状态改变时，就需要强制恢复第二应用程序及其调用的服务持有的唤醒锁。

这时需要判断第二应用程序是否符合强制恢复条件。强制恢复条件可以根据实际需要进行设定。

S18：若确定第二应用程序符合强制恢复条件，则根据包括第二应用程序的标识的特征信息，强制恢复第二应用程序及其调用的服务持有的唤醒锁。

S19：取消第二应用程序的代理锁状态。

由于在强制释放第二应用程序及其调用的服务持有的唤醒锁时，保存了这些唤醒锁的特征信息，那么在确定第二应用程序符合强制恢复条件时，可以根据包括第二应用程序的标识的特征信息强制恢复第二应用程序及其调用的服务持有的唤醒锁，并取消第二应用程序的代理锁状态。

其中，强制恢复条件的设置可以有多种方式，下面以包括前台运行或者被调用为例进行说明上述S17中的判断第二应用程序是否符合强制恢复条件的实现过程，具体为：监控第二应用程序是否转换为前台运行或者第二应用程序是否被调用；若监控到第二应用程序转换为前台运行或者第二应用程序被调用，则确定第二应用程序符合强制恢复条件；若监控到第二应用程序未转换为前台运行且第二应用程序未被调用，则确定第二应用程序不符合强制恢复条件。

通过上述过程就可以确定第二应用程序是否符合强制恢复条件，进而确定是否强制恢复第二应用程序及其调用的服务持有的唤醒锁。

基于同一发明构思，本申请实施例还提供一种基于终端的唤醒锁控制装置，该装置与如图1所示的基于终端的唤醒锁控制方法对应，该装置的结构如图5所示，包括：

获取模块51，用于获取后台运行的第一应用程序；

第一判断模块52，用于判断第一应用程序是否符合预设筛选条件；

选取模块53，用于选取不符合预设筛选条件的第一应用程序，得到第二应用程序；

释放模块54，用于强制释放第二应用程序及其调用的服务持有的唤醒锁。

该方案中，首先判断后台运行的第一应用程序是否符合预设筛选条件，然后选取不符合预设筛选条件的第一应用程序，得到第二应用程序，最后强制释放第二应用程序及其调用的服务持有的唤醒锁，从而可以有效控制后台运行的第一应用程序及其调用的服务持有的唤醒锁，避免后台运行且不符合预设筛选条件的第一应用程序及其调用的服务长时间不合理持有唤醒锁，进而减少终端能耗，节省系统资源。

具体的，预设筛选条件包括预设时长、预设应用场景名单和黑名单，第一判断模块52，用于判断第一应用程序是否符合预设筛选条件，具体用于：

统计第一应用程序的后台运行时长，判断第一应用程序的后台运行时长是否超过预设时长；

根据第一应用程序调用的接口确定第一应用程序的应用场景，将第一应用程序的应用场景与预设应用场景名单进行比对；以及，

将第一应用程序与黑名单比对；

确定后台运行时长超过预设时长、应用场景未保存在预设应用场景名单中且未保存在黑名单中的第一应用程序不符合预设筛选条件。

可选的，上述装置还包括：

确定模块，用于确定后台运行时长小于预设时长、应用场景保存在预设应用场景名单中或者保存在黑名单中的第一应用程序符合预设筛选条件。

可选的，上述装置还包括：

保存模块，用于在释放模块强制释放第二应用程序及其调用的服务持有的唤醒锁之前，保存第二应用程序及其调用的服务持有的唤醒锁的特征信息，特征信息包括对应第二应用程序的标识；以及，

设置模块，用于在释放模块强制释放第二应用程序及其调用的服务持有的唤醒锁之后，将第二应用程序设置为代理锁状态。

可选的，上述装置还包括处理模块，用于：

若接收到携带第二应用程序的标识的唤醒锁申请请求，则在包括第二应用程序的标识的特征信息中记录唤醒锁申请请求，不执行唤醒锁申请请求；

若接收到携带第二应用程序的标识的唤醒锁变更请求，则在包括第二应用程序的标识的特征信息中记录唤醒锁变更请求，不执行唤醒锁变更请求；

若接收到携带第二应用程序的标识的唤醒锁删除请求，则删除包括第二应用程序的标识的特征信息，不执行唤醒锁删除请求。

可选的，上述装置还包括：

第二判断模块，用于判断第二应用程序是否符合强制恢复条件；

恢复模块，用于若确定第二应用程序符合强制恢复条件，则根据包括第二应用程序的标识的特征信息，强制恢复第二应用程序及其调用的服务持有的唤醒锁；

取消模块，用于取消第二应用程序的代理锁状态。

具体的，强制恢复条件包括前台运行或者被调用，第二判断模块，用于判断第二应用程序是否符合强制恢复条件，具体用于：

监控第二应用程序是否转换为前台运行或者第二应用程序是否被调用；

若监控到第二应用程序转换为前台运行或者第二应用程序被调用，则确定第二应用程序符合强制恢复条件。

可选的，第二判断模块，还用于：

若监控到第二应用程序未转换为前台运行且第二应用程序未被调用，则确定第二应用程序不符合强制恢复条件。

基于同一发明构思，本申请实施例还提供一种终端，该装置与如图1的基于终端的唤醒锁控制方法对应，该装置的结构如图6所示，包括：

第一处理器61，用于获取后台运行的第一应用程序；

第二处理器62，用于判断第一应用程序是否符合预设筛选条件；选取不符合预设筛选条件的第一应用程序，得到第二应用程序；强制释放第二应用程序及其调用的服务持有的唤醒锁。

该方案中，首先判断后台运行的第一应用程序是否符合预设筛选条件，然后选取不符合预设筛选条件的第一应用程序，得到第二应用程序，最后强制释放第二应用程序及其调用的服务持有的唤醒锁，从而可以有效控制后台运行的第一应用程序及其调用的服务持有的唤醒锁，避免后台运行且不符合预设筛选条件的第一应用程序及其调用的服务长时间不合理持有唤醒锁，进而减少终端能耗，节省系统资源。

具体的，预设筛选条件包括预设时长、预设应用场景名单和黑名单，第二处理器62，用于判断第一应用程序是否符合预设筛选条件，具体用于：

统计第一应用程序的后台运行时长，判断第一应用程序的后台运行时长是否超过预设时长；

根据第一应用程序调用的接口确定第一应用程序的应用场景，将第一应用程序的应用场景与预设应用场景名单进行比对；以及，

将第一应用程序与黑名单比对；

确定后台运行时长超过预设时长、应用场景未保存在预设应用场景名单中且未保存在黑名单中的第一应用程序不符合预设筛选条件。

可选的，第二处理器62，还用于：

确定后台运行时长小于预设时长、应用场景保存在预设应用场景名单中或者保存在黑名单中的第一应用程序符合预设筛选条件。

可选的，第二处理器62，还用于：

在强制释放第二应用程序及其调用的服务持有的唤醒锁之前，保存第二应用程序及其调用的服务持有的唤醒锁的特征信息，特征信息包括对应第二应用程序的标识；以及，

在强制释放第二应用程序及其调用的服务持有的唤醒锁之后，将第二应用程序设置为代理锁状态。

可选的，第二处理器62，还用于：

若接收到携带第二应用程序的标识的唤醒锁申请请求，则在包括第二应用程序的标识的特征信息中记录唤醒锁申请请求，不执行唤醒锁申请请求；

若接收到携带第二应用程序的标识的唤醒锁变更请求，则在包括第二应用程序的标识的特征信息中记录唤醒锁变更请求，不执行唤醒锁变更请求；

若接收到携带第二应用程序的标识的唤醒锁删除请求，则删除包括第二应用程序的标识的特征信息，不执行唤醒锁删除请求。

可选的，第二处理器62，还用于：

判断第二应用程序是否符合强制恢复条件；

若确定第二应用程序符合强制恢复条件，则根据包括第二应用程序的标识的特征信息，强制恢复第二应用程序及其调用的服务持有的唤醒锁；

取消第二应用程序的代理锁状态。

具体的，强制恢复条件包括前台运行或者被调用，第二处理器62，用于判断第二应用程序是否符合强制恢复条件，具体用于：

监控第二应用程序是否转换为前台运行或者第二应用程序是否被调用；

若监控到第二应用程序转换为前台运行或者第二应用程序被调用，则确定第二应用程序符合强制恢复条件。

可选的，第二处理器62，还用于：

若监控到第二应用程序未转换为前台运行且第二应用程序未被调用，则确定第二应用程序不符合强制恢复条件。

以上是本发明的核心思想，为了使本领域技术人员更好地理解本发明方案，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清除、完整地描述，显然，所述描述的实施例仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。