CN118259738A - 用于控制Job执行的方法、系统和设备 - Google Patents

Abstract

本申请涉及用于控制Job执行的方法、系统和设备，所述方法包括：在设备灭屏的情况下，确定设备的Job状态中是否存在Job功耗异常，并且在确定其中存在Job功耗异常的情况下进一步确定所述Job功耗异常属于普通异常还是严重异常；在确定存在所述普通异常的情况下，拦截与所述普通异常相关联的Job执行流程并且响应于拦截解除条件而解除所述拦截；以及在确定存在所述严重异常的情况下，取消与所述严重异常相关联的Job执行流程。本申请的用于控制Job执行的方法能够在设备灭屏的情况下及时拦截或取消功耗异常的Job执行流程，从而有效地保证设备在灭屏期间正常待机。

Description

用于控制Job执行的方法、系统和设备

技术领域

本申请涉及信息技术领域，具体而言，涉及用于控制Job执行的方法、系统和设备。

背景技术

手机在灭屏状态下的表现与人的睡眠大体类似，当系统处于深度睡眠模式时，功耗会低很多；相反，当系统处于唤醒状态时，功耗会大很多，此时手机自然也就耗电快。通常，当按下电源键或者手机长时间未使用时，系统就会触发熄屏与休眠流程。随着业务需求的发展，手机终端的集成度越来越高，功能也越来越复杂，无论是硬件、底层设备驱动还是应用软件，在设计与实现时都需要充分考虑耗电影响。

在手机灭屏的情况下，存在如下的影响耗电的关键维度：是否有触发休眠动作、触发休眠后是否执行成功、是否频繁退出休眠状态、平台级的休眠状态、外围设备的耗电状态等。也就是说，手机在灭屏情况下的休眠态、工作态、空闲态表现对灭屏功耗均起到关键的影响，例如，Job执行策略设计不合理、运行逻辑出现异常，都会造成灭屏耗电不理想。

发明内容

本申请的实施例提供了一种用于控制Job执行的方法、系统和设备，用于在设备灭屏的情况下及时拦截或取消功耗异常的Job执行流程，从而有效地降低设备在灭屏期间的功耗，保障设备正常待机。

根据本申请的一方面，提供一种用于控制Job执行的方法，所述方法包括：在设备灭屏的情况下，确定所述设备的Job状态中是否存在Job功耗异常，并且在确定其中存在Job功耗异常的情况下进一步确定所述Job功耗异常属于普通异常还是严重异常；在确定存在所述普通异常的情况下，拦截与所述普通异常相关联的Job执行流程并且响应于拦截解除条件而解除所述拦截；以及在确定存在所述严重异常的情况下，取消与所述严重异常相关联的Job执行流程。

在本申请的一些实施例中，可选地，所述方法进一步包括：针对Job任务列表中的多个Job待执行流程，以时间T为周期标定执行Job的周期节点，并且将不同于所述周期节点的Job执行时间从原定时间延迟至与所述原定时间最靠近的周期节点，以实现多个Job执行时间的批量对齐。

在本申请的一些实施例中，可选地，所述Job任务列表中的多个Job待执行流程包括：经确定不存在Job功耗异常的Job执行流程以及经解除拦截后的Job执行流程。

在本申请的一些实施例中，可选地，所述方法进一步包括：将与所述拦截和所述取消相关的Job分别标识为异常功耗Job；响应于Job执行流程的开始事件和/或结束事件而获取Job执行流程的Job执行信息；以及获取所述Job执行信息中与所述异常功耗Job相关联的异常信息。

在本申请的一些实施例中，可选地，所述方法进一步包括：从云端获取黑名单信息，以供在确定是否存在Job功耗异常时或者在确定所述Job功耗异常属于普通异常还是严重异常时使用。

在本申请的一些实施例中，可选地，所述方法进一步包括：在获取到与Job功耗异常相关联的异常信息之后，将所述异常信息传送到所述云端，以用于更新所述黑名单信息。

在本申请的一些实施例中，可选地，所述设备的Job状态包括以下项中的一项或多项：所述设备中运行的多个应用触发Job的频率、所述设备中运行的单个应用触发Job的频率、所述设备中待执行的Job的类型。

在本申请的一些实施例中，可选地，所述拦截解除条件包括：所述设备亮屏且被解锁。

根据本申请的另一方面，提供一种用于控制Job执行的系统，所述系统包括：Job判定单元，其配置成：在设备灭屏的情况下，确定所述设备的Job状态中是否存在Job功耗异常，并且在确定其中存在Job功耗异常的情况下进一步确定所述Job功耗异常属于普通异常还是严重异常；Job拦截单元，其配置成：在经由所述Job判定单元确定存在所述普通异常的情况下，拦截与所述普通异常相关联的Job执行流程并且响应于拦截解除条件而解除所述拦截；以及Job查杀单元，其配置成：在经由所述Job判定单元确定存在所述严重异常的情况下，取消与所述严重异常相关联的Job执行流程。

在本申请的一些实施例中，可选地，所述系统进一步包括Job时延单元，其配置成：针对Job任务列表中的多个Job待执行流程，以时间T为周期标定执行Job的周期节点，并且将不同于所述周期节点的Job执行时间从原定时间延迟至与所述原定时间最靠近的周期节点，以实现多个Job执行时间的批量对齐。

在本申请的一些实施例中，可选地，所述Job任务列表中的多个Job待执行流程包括：经由所述Job判定单元确定不存在Job功耗异常的Job执行流程以及经由所述Job拦截单元解除拦截后的Job执行流程。

在本申请的一些实施例中，可选地，所述Job拦截单元进一步配置成将与所述拦截相关的Job标识为异常功耗Job；所述Job查杀单元进一步配置成将与所述取消相关的Job标识为异常功耗Job；并且所述系统进一步包括：监控Job模块，其配置成响应于Job执行流程的开始事件和/或结束事件而获取Job执行流程的Job执行信息；以及异常记录单元，其配置成从所述监控Job模块获取所述Job执行信息中与所述异常功耗Job相关联的异常信息。

在本申请的一些实施例中，可选地，所述系统进一步包括黑名单获取单元，其配置成从云端获取黑名单信息，以供所述Job判定单元在确定是否存在Job功耗异常时或者在确定所述Job功耗异常属于普通异常还是严重异常时使用；并且所述异常记录单元进一步配置成：在获取到与异常功耗Job相关联的异常信息之后，将所述异常信息传送到所述云端，以用于更新所述黑名单信息。

在本申请的一些实施例中，可选地，所述设备的Job状态包括以下项中的一项或多项：所述设备中运行的多个应用触发Job的频率、所述设备中运行的单个应用触发Job的频率、所述设备中待执行的Job的类型。

在本申请的一些实施例中，可选地，所述拦截解除条件包括：所述设备亮屏且被解锁。

根据本申请的又一方面，提供一种计算机可读存储介质，所述计算机可读存储介质中存储有指令，当所述指令由处理器执行时，使得所述处理器执行如上文中所述的任意一种用于控制Job执行的方法。

根据本申请的又一另外的方面，提供一种用于控制Job执行的设备，所述设备包括如上文中所述的任意一种用于控制Job执行的系统。

在本申请的一些实施例中，可选地，所述设备是手机。

本申请旨在通过优化手机灭屏条件下的Job执行策略来改善设备的异常耗电现象，提升用户的设备使用体验。

附图说明

从结合附图的以下详细说明中，将会使本申请的上述和其他目的及优点更加完整清楚，其中，相同或相似的要素采用相同的标号表示。

图1示出了根据本申请的一个实施例的用于控制Job执行的设备的系统架构示意图；

图2A至图2C分别示出了根据本申请的一个实施例的Job时延单元的时延策略与对照实施例的比较；

图3示出了根据本申请的一个实施例的用于控制Job执行的方法的一部分流程图；

图4示出了根据本申请的一个实施例的用于控制Job执行的方法的另一部分流程图。

具体实施方式

出于简洁和说明性目的，本文主要参考其示范实施例来描述本申请的原理。但是，本领域技术人员将容易地认识到相同的原理可等效地应用于所有类型的用于控制Job执行的方法、系统和设备，并且可以在其中实施这些相同或相似的原理，任何此类变化不背离本申请的真实精神和范围。

下面将结合图1来描述本申请的一个实施例的用于控制Job执行的设备的系统架构。

图1示出了根据本申请的一个实施例的用于控制Job执行的设备的系统架构示意图。如图1所示，用于控制Job执行的设备端100可以与云端110互相通信。在一些实施例中，与设备端100所对应的设备可以是诸如手机之类的移动设备。云端110可以提供黑名单信息111，其中，黑名单信息111可以包括Job黑名单的配置信息，以用于评价Job是否存在功耗异常，并且在存在功耗异常的情况下，进一步用于判定异常功耗Job属于普通异常还是严重异常。

用于控制Job执行的设备可以包括用于控制Job执行的系统120和JobSchedulerService系统150。在本申请的一些实施例中，用于控制Job执行的系统120可以基于JobScheduler的省电机制来优化Job执行策略，因此本申请的一些实施例可以将用于控制Job执行的系统120称为JobScheduler功耗管控系统。用于控制Job执行的系统120与JobSchedulerService系统150之间可以通信地连接，从而系统120可以通过对JobSchedulerService系统150进行监控和管理而实现对Job执行流程的控制。本文中所述的“Job”可以是设备中的应用在运行过程中所要完成的任务，例如，Job可以是应用在设备中的更新任务。

用于控制Job执行的系统120可以包括策略控制模块130和监控Job模块140。其中，策略控制模块130与监控Job模块140之间可以通信地连接。监控Job模块140可以用于监控JobSchedulerService系统150，以通过对JobSchedulerService系统150的监控来获取关于Job执行的信息。

一方面，关于Job执行的信息可以包括设备的Job状态。可选地，设备的Job状态可以包括以下中的一项或多项：设备中运行的多个应用触发Job的频率、设备中运行的单个应用触发Job的频率、设备中待执行的Job的类型。

另一方面，关于Job执行的信息可以包括Job执行信息。监控Job模块140可以配置成响应于Job执行流程的开始事件和/或结束事件而获取Job执行流程的Job执行信息。对应于监控到开始事件和结束事件，监控Job模块140可以获取到相应Job执行流程的执行时长。相应地，Job执行信息可以是单次Job执行的时长。对应于不同类型的Job，开始事件和/或结束事件可以是不同的。可选地，开始事件可以是Job触发的设备条件，例如，可以是以下中的一个或多个：系统是否处于空闲状态、电池电量、磁盘空间、电池是否处于充电状态、应用设置某一特定时间后执行、漫游状态、wifi连接与否、数据网络状态、设备温度等。当设备满足这些状态，系统Job服务可以通知对应应用条件满足了，并且通知对应应用Job开始事件。结束事件可以是与所执行的Job相对应的事件，例如，在Job是应用在设备中的更新任务的情况下，结束事件可以是应用的当前更新已完成。

策略控制模块130可以至少部分地基于监控Job模块140所获取到的关于Job执行的信息而提供对Job执行流程的管控策略。在一些实施例中，策略控制模块130可以包括Job判定单元131、Job拦截单元135和Job查杀单元137。

Job判定单元131可以配置成：在设备灭屏的情况下，确定设备的Job状态中是否存在Job功耗异常。在一些实施例中，如果设备的Job状态中出现以下的一个或多个现象：多个应用的Job频繁触发、单个应用注册大量Job、单个应用频繁触发Job、和/或单个Job执行的时长过长，则Job判定单元131可以确定存在Job功耗异常。例如，当Job判定单元131确定设备的单个应用注册Job的次数超过阈值（例如，75）时，可以判定当前存在Job功耗异常；当Job判定单元131确定设备的单个应用频繁触发Job且相邻的两个Job间最小间隔周期小于阈值（例如，15分钟），可以判定当前存在Job功耗异常。

设备的Job状态中出现功耗异常的现象会给灭屏下的设备带来功耗异常的损耗。例如，每当一个Job被Alarm触发后，会绑定应用的Job服务进程，并允许最长10分钟的Job执行时间，应用在这个执行期中会持有一个阻止CPU休眠的锁，以便能完整执行完逻辑。如果阻止CPU的锁太多、太频繁、太长就会导致设备在灭屏的情况下无法正常待机、电流偏高，进而出现功耗异常。

Job判定单元131可以通过对Job功耗异常进行分级判定来分别为Job执行流程中的普通异常和严重异常实施分级管控。在确定存在Job功耗异常的情况下，Job判定单元131可以进一步用于确定所述Job功耗异常属于普通异常还是严重异常。例如，在因单次Job执行时长超过阈值（例如，5分钟）而被Job判定单元131确定为异常功耗的Job的情况下，可以进一步定义Job执行时长超过5分钟而不足8分钟的Job功耗异常为普通异常，超过8分钟的Job功耗异常为严重异常。另外，还可以将Job功耗异常的普通异常定义为Job执行时长的总时长超过灭屏总时长10%，而将严重异常定义为Job执行时长的总时长超过灭屏总时长20%。

Job拦截单元135可以配置成：在经由Job判定单元131确定存在普通异常的情况下，拦截与普通异常相关联的Job执行流程。本文中所述的“拦截”指的是不允许当前触发该Job执行流程，对该Job执行流程进行延迟。Job拦截单元135可以进一步配置成响应于拦截解除条件而解除拦截。在一些实施例中，拦截解除条件可以包括：设备亮屏且该设备被解锁。例如，设备可以在用户按下设备的电源键或者其它触发设备亮屏的键时亮屏，并且在设备亮屏的情况下，若用户进一步输入解锁密码，则设备得到解锁。响应于设备亮屏且被解锁，设备可以从睡眠模式中被唤醒，此时与普通异常相关联的Job执行流程可以相应地被解除拦截。

在一些实施例中，Job拦截单元135可以进一步配置成将与普通异常相关联的Job标识为异常功耗Job，从而当经标识的异常功耗Job在被解除拦截之后，监控Job模块140可以获知到标识异常功耗Job的执行信息，以便为云端110中黑名单信息111的更新提供依据。

Job查杀单元137可以配置成：在经由Job判定单元131确定存在严重异常的情况下，取消与严重异常相关联的Job执行流程。当被Job判定单元131判定为严重异常时，可以理解为当前的Job执行流程对设备在灭屏下的功耗已经产生一定影响，此时可以执行Kill指令，以消除与严重异常相关联的Job执行流程对设备功耗的影响，减少后续的持续功耗产生。

在一些实施例中，Job查杀单元137可以进一步配置成将与严重异常相关联的Job标识为异常功耗Job。通过对与严重异常相关联的Job执行流程进行标识，监控Job模块140可以获知到标识异常功耗Job的执行信息，以便为云端110中黑名单信息111的更新提供依据。

在一些实施例中，策略控制模块130还可以包括异常记录单元139。异常记录单元139可以配置成从监控Job模块140获取Job执行信息中与异常功耗Job相关联的异常信息。异常信息可以包括Job执行流程中的Job使用频率、Job执行间隔周期、Job总执行时长，以便为后续Job异常判定提供数据支持。可选地，异常记录单元139进一步配置成：在获取到与异常功耗Job相关联的异常信息之后，将异常信息传送到云端110，以用于更新黑名单信息111。在一些实施例中，在获取到与异常功耗Job相关联的异常信息之后，异常记录单元139可以将其反馈到内部开发人员，以供内部开发人员分析所获得的异常信息是否有必要加入黑名单信息111。

黑名单信息111的提供有助于在策略执行期间减少判定需求。例如，Job判定单元131可以基于黑名单信息111中的Job黑名单直接确定当前的Job是否属于功耗异常的Job。对黑名单信息111的及时更新可以在一定程度上减少针对Job异常功耗判断的误差。例如，Job判定单元131基于当前的黑名单信息111作出的Job异常判定没有判断出某个Job属于异常功耗的Job，内部开发人员在研究分析经监控Job模块140获取到的Job执行流程信息后发现该Job应当属于异常功耗的Job，就可以将该Job上传大数据以添加到黑名单信息111中，从而Job判定单元131下一次面对同种类型的Job类型时，可以基于更新的黑名单信息111作出正确的判断。

在一些实施例中，策略控制模块130还可以包括黑名单获取单元138。黑名单获取单元138可以配置成从云端110获取黑名单信息，以供Job判定单元131在确定是否存在Job功耗异常时或者在确定所述Job功耗异常属于普通异常还是严重异常时使用。

在一些实施例中，策略控制模块130还可以包括Job时延单元133。Job时延单元133可以基于JobScheduler的省电机制进一步优化时延策略，以减少设备在灭屏情况下的功耗异常现象。例如，JobScheduler可以替代WakeLock和Alarm的作用，从操作层面将不是特别紧急的Job任务放到更合适的时机进行批量处理。本文可以将包括Job时延单元133的系统120称为JobScheduler功耗管控系统。

Job时延单元133基于JobScheduler的批量处理的原则进一步优化，可以配置成：针对Job任务列表中的多个Job待执行流程，以时间T为周期标定执行Job的周期节点，并且将不同于周期节点的Job执行时间从原定时间延迟至与所述原定时间最靠近的周期节点，以实现多个Job执行时间的批量对齐。也就是说，若执行Job的原定时间本身就与时间轴上标定的周期节点对齐，则可以不对该Job执行流程进行延迟；若执行Job的原定时间不与时间轴上标定的周期节点对齐，则可以将该Job执行时间延迟至原定时间后方最先出现的周期节点。在一些实施例中，时间周期T可以选自3min至10min中的任意值。例如，时间周期T可以是5min，相应地，Job对应的时延的范围可以是1min至4min。在一些实施例中，Job任务列表中的多个Job待执行流程包括：经由Job判定单元131确定不存在Job功耗异常的Job执行流程以及经由Job拦截单元135解除拦截后的Job执行流程。

接下来，将结合图2A至图2C来描述本申请一个实施例的Job时延单元133的时延策略。

图2A至图2C分别示出了根据本申请的一个实施例的Job时延单元133的时延策略与对照实施例的比较。其中，图2A和图2B分别是对照例，图2A示出了无JobScheduler机制的情况下对Job任务列表中的多个Job待执行流程的执行策略，图2B示出了在JobScheduler机制下对Job任务列表中的多个Job待执行流程的执行策略。图2C示出了本申请的一个实施例的Job时延单元133的时延策略，其中Job时延单元133的时延策略是在图2B的JobScheduler机制的基础上进一步优化所形成的策略。

如图2A至图2C所示，每个Job任务包含一个Alarm和一个Wakelock。在图2A所示的无JobScheduler机制下的执行策略中，对应于Job任务列表的执行时间轴，0至5 min期间有三个待执行的Job任务，5至8 min期间有两个待执行的Job任务，8至10 min期间有两个待执行的Job任务。在图2A所示的执行策略下，相应的待执行的Job任务分别在其原定的执行时间下触发执行。此时，设备因Job频发触发而容易出现异常功耗的现象。

在图2B所示的JobScheduler机制下的执行策略中，相邻的Job任务打包在一起，以便就近批量触发执行，即，0至5 min期间的三个待执行的Job任务打包在一起触发执行，5至8 min期间的两个待执行的Job任务打包在一起触发执行。相对于图2A所示的按照原定时间执行的策略，图2B的执行策略减少了Job任务触发的频率。

图2B所示出的针对Job待执行流程的执行策略基于JobScheduler机制批量触发执行相邻的Job任务，而图2C所示出的Job时延单元133的时延策略是对图2B所示出的JobScheduler机制下的执行策略的进一步优化。如图2C所示，在Job时延单元133的时延策略下，按照T=5分钟的时间周期在Job任务列表的执行时间轴上标定执行Job的周期节点，将不同于5*n分钟（n=1、2、3……）的周期节点的Job执行时间从原定时间延迟至与原定时间最靠近的周期节点，以实现多个Job执行时间的批量对齐。也就是说，基于Job时延单元133的时延策略，可以将对应于图2A所示出的原定时间在0至5 min期间的三个待执行的Job任务延迟到5 min的周期节点以进行批量执行；以及将对应于图2A所示出的原定时间在5至10min期间的三个待执行的Job任务延迟到10 min的周期节点以进行批量执行。

相对于图2B所示的就近打包触发执行的策略，图2C的时延策略提出了执行Job任务的周期节点的概念，进一步减少了Job任务触发的频率。在设备灭屏正常待机时，其中的电流在20mA左右。若此时设备经历1次Job触发执行的唤醒，则设备的电流将升至20mA至150mA。假定1次Job触发执行会持续1-5秒的时间，则设备在该触发执行下会额外消耗2至3分钟的待机电量，而Job执行的最长周期可能是10分钟。也就是说，Job任务触发频率的减少可以大大降低设备在待机条件下的功耗，批量处理Job（1个Job和批量处理多个Job电流时差不多）或尽可能减少Job触发数量可以改善设备的功耗。基于图2C的Job时延单元133的时延策略采用了线性退避算法，使得Job任务列表中的Job待执行流程可以在相对固定的周期节点处批量触发，从而有效地避免Job任务的频繁触发执行，大大节省设备在待机情况下的功耗。

接下来，将结合图3和图4来描述本申请一个实施例的用于控制Job执行的方法。图3和图4中所示出的用于控制Job执行的方法可以通过图1中所示出的用于控制Job执行的设备的系统架构来实现。

图3示出了根据本申请的一个实施例的用于控制Job执行的方法的一部分流程图。如图3所示，用于控制Job执行的方法包括步骤S310至S380。其中，步骤S310为开始步骤，即，进入步骤S310后，用于控制Job执行的方法即可以开始执行。在一些实施例中，设备灭屏可以是进入步骤S310的触发条件。在设备100是手机的情况下，当用户按下手机的电源键时或者当用户不使用手机的时间达到阈值时间时，用于控制Job执行的方法即进入开始步骤S310。

在步骤S320中，从云端110获取黑名单信息111中的Job黑名单。例如，可以通过系统120中的黑名单获取单元138来获取来自云端110的黑名单信息111。在步骤S320之后，进一步执行步骤S330。

在步骤S330中，确定设备的Job状态中是否存在Job功耗异常。例如，可以通过系统120中的Job判定单元131使用经步骤S320所获取到的黑名单信息111来判断设备的Job状态中是否存在Job功耗异常。在一些实施例中，设备的Job状态包括以下项中的一项或多项：设备中运行的多个应用触发Job的频率、设备中运行的单个应用触发Job的频率、设备中待执行的Job的类型。在确定存在Job功耗异常的情况下，进一步执行步骤S340；并且在确定不存在Job功耗异常的情况下，进一步执行步骤S380。

在步骤S340中，确定步骤S330中所确定的Job功耗异常是否属于普通异常。在一些实施例中，可以通过系统120中的Job判定单元131使用经步骤S320所获取到的黑名单信息111来判断该Job功耗异常是否属于普通异常。在确定存在普通异常的情况下，进一步执行步骤S360。在确定不存在普通异常的情况下，可以默认为存在严重异常，即可进一步执行步骤S350。

在步骤S350中，取消与严重异常相关联的Job执行流程。在一些实施例中，可以通过系统120中的Job查杀单元137来取消相应的Job执行流程。在一些实施例中，在取消与严重异常相关联的Job执行流程的同时，还可以将该Job执行流程标定为标识为异常功耗Job或者严重异常功耗Job，以便于监控Job模块140和异常记录单元139的识别。

在步骤S360中，拦截与普通异常相关联的Job执行流程。在步骤S360之后，可以进一步执行步骤S370。在一些实施例中，可以通过系统120中的Job拦截单元135来拦截相应的Job执行流程。在一些实施例中，在拦截与严重异常相关联的Job执行流程的同时，还可以将该Job执行流程标定为标识为异常功耗Job或者普通异常功耗Job，以便于监控Job模块140和异常记录单元139的识别。

在步骤S370中，响应于拦截解除条件而解除经步骤S360的拦截操作。在一些实施例中，可以通过系统120中的Job拦截单元135来解除对相应的Job执行流程的拦截。在一些实施例中，拦截解除条件包括：设备亮屏且被解锁。一旦对Job执行流程的管控被解除，即可恢复正常Job。

在步骤S380中，延迟对齐Job任务列表中的多个Job待执行流程。在一些实施例中，可以采用系统120中的Job时延单元133来实现对Job任务列表中的多个Job待执行流程的执行时间进行对齐延迟操作。在一些实施例中，可以通过如下的方式来实现延迟对齐的操作：针对Job任务列表中的多个Job待执行流程，以时间T为周期标定执行Job的周期节点，并且将不同于周期节点的Job执行时间从原定时间延迟至与原定时间最靠近的周期节点，以实现多个Job执行时间的批量对齐。可选地，Job任务列表中的多个Job待执行流程包括：经确定不存在Job功耗异常的Job执行流程以及经解除拦截后的Job执行流程。

图4示出了根据本申请的一个实施例的用于控制Job执行的方法的另一部分流程图。在一些实施例中，图4中所示出的一部分方法可以与图3中所示出的一部分方法同时进行，也可以按照需要选择性地进行。如图4所示，用于控制Job执行的方法还可以包括步骤S410至S430。

在步骤S410中，监控Job执行流程的Job执行信息。在一些实施例中，可以通过系统120的监控Job模块140来监控相应的Job执行信息。可选地，Job执行信息可以包括Job使用频率、Job执行的间隔周期、和/或Job的总执行时长。

在步骤S420中，获取经步骤S410所监控到的Job执行信息中的异常信息。在一些实施例中，可以通过系统120的异常记录单元139来获取相应的异常信息。其中，异常信息可以在步骤S350和/或步骤S360中进行标识。例如，异常信息可以通过如下的标识方式来获得：经由Job拦截单元135和/或Job查杀单元137将与拦截和取消相关的Job分别标识为异常功耗Job；经由监控Job模块140响应于Job执行流程的开始事件和/或结束事件而获取Job执行流程的Job执行信息；以及经由异常记录单元139获取到Job执行信息中与异常功耗Job相关联的异常信息。

在步骤S430中，在获取到与Job功耗异常相关联的异常信息之后，将异常信息传送到云端110，以用于更新黑名单信息111。在一些实施例中，可以通过系统120的异常记录单元139来上传相应的异常信息。

根据本申请的另一方面，提供一种计算机可读存储介质，其中存储有指令，当所述指令由处理器执行时，使得所述处理器执行如上文所述的任意一种用于控制Job执行的方法。本申请中所称的计算机可读介质包括各种类型的计算机存储介质，可以是通用或专用计算机能够存取的任何可用介质。举例而言，计算机可读介质可以包括RAM、ROM、EPROM、E²PROM、寄存器、硬盘、可移动盘、CD-ROM或其他光盘存储器、磁盘存储器或其他磁存储设备、或者能够用于携带或存储具有指令或数据结构形式的期望的程序代码单元并能够由通用或专用计算机、或者通用或专用处理器进行存取的任何其他临时性或者非临时性介质。如本文所使用的盘通常磁性地复制数据，而碟则用激光来光学地复制数据。上述的组合也应当包括在计算机可读介质的保护范围之内。示例性存储介质耦合到处理器以使得该处理器能从/向该存储介质读写信息。在替换方案中，存储介质可以被整合到处理器。处理器和存储介质可驻留在ASIC中。ASIC可驻留在用户终端中。在替换方案中，处理器和存储介质可作为分立组件驻留在用户终端中。

本申请在设备灭屏的情况下，采用Job异常的分级管控对Job 资源的时长和频率进行异常识别与分析，以便通过尽可能减少Job触发数量来改善设备在灭屏条件下的功耗。在针对Job异常进行分级管控期间，本申请对Job异常数据进行监控并进行大数据上报，以便更新用于判定Job异常的黑名单配置，从而为Job异常决策提供快速而准确的判定。另外，本申请还采用了Job时延线性退避算法，以便通过尽可能批量处理Job来改善设备在灭屏条件下的功耗。

以上仅为本申请的具体实施方式，但本申请的保护范围并不局限于此。本领域的技术人员可以根据本申请所披露的技术范围想到其他可行的变化或替换，此等变化或替换皆涵盖于本申请的保护范围之中。在不冲突的情况下，本申请的实施方式及实施方式中的特征还可以相互组合。本申请的保护范围以权利要求的记载为准。

Claims (10)

1.一种用于控制Job执行的方法，其特征在于，所述方法包括：

在设备灭屏的情况下，确定所述设备的Job状态中是否存在Job功耗异常，并且在确定其中存在Job功耗异常的情况下进一步确定所述Job功耗异常属于普通异常还是严重异常；

在确定存在所述普通异常的情况下，拦截与所述普通异常相关联的Job执行流程并且响应于拦截解除条件而解除所述拦截；以及

在确定存在所述严重异常的情况下，取消与所述严重异常相关联的Job执行流程。

2.根据权利要求1所述的方法，其特征在于，所述方法进一步包括：

针对Job任务列表中的多个Job待执行流程，以时间T为周期标定执行Job的周期节点，并且将不同于所述周期节点的Job执行时间从原定时间延迟至与所述原定时间最靠近的周期节点，以实现多个Job执行时间的批量对齐。

3.根据权利要求2所述的方法，其特征在于，所述Job任务列表中的多个Job待执行流程包括：经确定不存在Job功耗异常的Job执行流程以及经解除拦截后的Job执行流程。

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

将与所述拦截和所述取消相关的Job分别标识为异常功耗Job；

响应于Job执行流程的开始事件和/或结束事件而获取Job执行流程的Job执行信息；以及

获取所述Job执行信息中与所述异常功耗Job相关联的异常信息。

5.根据权利要求4所述的方法，其特征在于，所述方法进一步包括：

从云端获取黑名单信息，以供在确定是否存在Job功耗异常时或者在确定所述Job功耗异常属于普通异常还是严重异常时使用。

6.根据权利要求5所述的方法，其特征在于，所述方法进一步包括：

在获取到与Job功耗异常相关联的异常信息之后，将所述异常信息传送到所述云端，以用于更新所述黑名单信息。

7.根据权利要求1所述的方法，其特征在于，所述设备的Job状态包括以下项中的一项或多项：所述设备中运行的多个应用触发Job的频率、所述设备中运行的单个应用触发Job的频率、所述设备中待执行的Job的类型。

8.一种用于控制Job执行的系统，其特征在于，所述系统包括：

Job判定单元，其配置成：在设备灭屏的情况下，确定所述设备的Job状态中是否存在Job功耗异常，并且在确定其中存在Job功耗异常的情况下进一步确定所述Job功耗异常属于普通异常还是严重异常；

Job拦截单元，其配置成：在经由所述Job判定单元确定存在所述普通异常的情况下，拦截与所述普通异常相关联的Job执行流程并且响应于拦截解除条件而解除所述拦截；以及

Job查杀单元，其配置成：在经由所述Job判定单元确定存在所述严重异常的情况下，取消与所述严重异常相关联的Job执行流程。

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

10.一种用于控制Job执行的设备，其特征在于，所述设备包括如权利要求8所述的系统。