应用程序保活的管控方法、装置及存储介质和移动终端与流程

本申请实施例涉及应用管控技术领域，尤其涉及一种应用程序保活的管控方法、装置及存储介质和移动终端。

背景技术：

手机等移动终端中应用程序的种类和可实现的功能越来越多，为人们的生活和工作提供了便利，人们可以利用手机接打电话，还可以听音乐、观看视频、玩游戏等。但有些流氓应用程序为了保持自己可以一直运行，而通过一些保活方式自启动或者保持运行状态。相关技术中，对于应用程序保活的管控方法存在缺陷，需要改进。

技术实现要素：

本申请实施例提供一种应用程序保活的管控方法、装置及存储介质和移动终端，可以合理的管控应用程序的保活。

在第一方面，本申请实施例提供了一种应用程序保活的管控方法，包括：

获取请求设置前台服务的应用程序的应用信息；

按照预设前台服务设置策略基于所述应用信息，判断所述应用程序是否可以设置前台服务；

若否，则禁止所述应用程序设置前台服务，以禁止所述应用程序通过设置前台服务来进行保活。

在第二方面，本申请实施例提供了一种应用程序保活的管控装置，包括：

应用信息获取模块，用于获取请求设置前台服务的应用程序的应用信息；

前台服务设置判断模块，用于按照预设前台服务设置策略基于所述应用信息，判断所述应用程序是否可以设置前台服务；

前台服务设置禁止模块，用于若所述应用程序是否不可以设置前台服务，则禁止所述应用程序设置前台服务，以禁止所述应用程序通过设置前台服务来自启动。

第三方面，本申请实施例提供了一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现如第一方面所提供的应用程序保活的管控方法。

在第四方面，本申请实施例提供了一种移动终端，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行时实现如第一方面所提供的应用程序保活的管控方法。

本申请实施例通过获取请求设置前台服务的应用程序的应用信息，按照预设前台服务设置策略基于所述应用信息，判断所述应用程序是否可以设置前台服务，若判断结果为不可以，则禁止所述应用设置前台服务，以防止所述应用程序通过设置前台服务来进行保活，可以合理的管控应用程序的保活操作，避免由于一些流氓应用保活自己，而浪费移动终端的运行资源和电量，也提升了移动终端运行的流畅度。

附图说明

图1是本申请实施例提供的一种应用程序保活的管控方法的流程图；

图2是本申请实施例提供的另一种应用程序保活的管控方法的流程图；

图3是本申请实施例提供的另一种应用程序保活的管控方法的流程图；

图4是本申请实施例提供的一种应用程序保活的管控装置的结构示意图；

图5是本申请实施例提供的一种移动终端的结构示意图；

图6是本申请实施例提供的另一种移动终端的结构示意图。

具体实施方式

为了使本申请的目的、技术方案和优点更加清楚，下面结合附图对本申请具体实施例作进一步的详细描述。可以理解的是，此处所描述的具体实施例仅仅用于解释本申请，而非对本申请的限定。另外还需要说明的是，为了便于描述，附图中仅示出了与本申请相关的部分而非全部内容。在更加详细地讨论示例性实施例之前应当提到的是，一些示例性实施例被描述成作为流程图描绘的处理或方法。虽然流程图将各项操作(或步骤)描述成顺序的处理，但是其中的许多操作可以被并行地、并发地或者同时实施。此外，各项操作的顺序可以被重新安排。当其操作完成时所述处理可以被终止，但是还可以具有未包括在附图中的附加步骤。所述处理可以对应于方法、函数、规程、子例程、子程序等等。

图1给出了本申请实施例提供的一种应用程序保活的管控方法的流程图，本实施例的方法可以由应用程序保活的管控装置来执行，该装置可通过硬件和/或软件的方式实现，所述装置可作为移动终端一部分设置在所述移动终端的内部。本申请实施中所述的移动终端包括手机、平板电脑或者笔记本等设备。

如图1所示，本实施例提供的应用程序保活的管控方法包括以下步骤：

步骤101、获取请求设置前台服务的应用程序的应用信息。

service是一种非可视化的后台运行逻辑，用于为应用提供后台运行服务，可以称为服务，例如后台音乐播放服务。service几乎都是在后台运行的，一直以来它都是默默地做着辛苦的工作。但是service的系统优先级还是比较低的，当系统出现内存不足情况时，就有可能会回收掉正在后台运行的service。如果希望service可以一直保持运行状态，而不会由于系统内存不足的原因导致被回收，就可以考虑使用前台service，那么系统会认为该服务是对用户可见的，并不会在内存不足时kill掉该服务或者该服务对应的应用程序前台service和普通service最大的区别就在于，它会一直有一个正在运行的图标在系统的状态栏显示，下拉状态栏后可以看到更加详细的信息，非常类似于通知的效果。这种设置前台服务保活应用程序的方式也会被一些流氓应用程序所利用，通过设置通知将该应用程序的某个服务设置为前台服务后，自己主动去清除通知，让用户无法感知，但系统又因为是前台服务，不会去清理它，导致该应用程序的进程保持常驻，从而实现该应用程序的保活。其中，所述应用程序的保活可以是应用程序关闭之后通过设置前台服务来自启动，也可以为应用程序在运行的过程中将某一个服务设置为前台服务而保持常驻运行，本申请实施例对此并不进行限制。

本实施例提供的技术方案可适用于应用程序通过设置前台服务来保活的应用场景。在检测到应用程序请求设置前台服务的事件被触发时，获取请求设置前台服务的应用程序的应用信息。

其中，所述检测到应用程序请求设置前台服务的事件被触发可以包括：检测到调用用于设置前台服务的设定函数的事件被触发，所述设定函数可以为startforeground函数。

所述应用信息可以包括应用的应用属性信息和/或应用设置信息和/或应用运行信息等。所述应用属性信息可以包括：用户标识(useridentifier，uid)、应用包名和进程标识(processidentifier，pid)等信息。所述应用设置信息可以包括：该应用是否设置为设定白名单中的成员，或者该应用的自启动开关是否设置为开启，或者该应用是否设置为用户的常用应用等。所述应用运行信息可以包括：该应用的使用频率、运行优先级或者应用类型等运行情况信息，或者该应用在运行过程中用户的反馈信息，或者该应用在运行过程中是否有对应的前台界面和/或在运行过程中设置前台服务的次数等。所述用户的反馈信息可以包括用户手动关闭该应用程序。

步骤102、按照预设前台服务设置策略基于所述应用信息，判断所述应用程序是否可以设置前台服务，若是，则执行步骤103，若否则执行步骤104。

按照预设前台服务设置策略基于所述应用属性信息和/或应用设置信息和/或应用运行信息，判断所述应用程序是否可以设置前台服务。若判断结果为所述应用程序可以设置前台服务，那么说明所述应用程序为正常应用程序，则可以控制执行为所述应用程序设置前台服务的操作，若判断结果为所述应用程序不可以设置前台服务，那么说明所述应用程序为流氓应用，则禁止所述应用程序设置前台服务。

步骤103、禁止所述应用程序设置前台服务，以禁止所述应用程序通过设置前台服务来进行保活。

其中，所述禁止所述应用程序设置前台服务的实现方式可以为禁止调用上述的设定函数来设置前台服务，或者禁止执行消除通知的操作，让用户知道有这么一个应用程序设置了前台服务，可由用户选择是否关闭该应用程序。在根据上述步骤102判断出应用程序为流氓应用后，通过禁止应用设置前台服务，可以实现禁止应用程序通过设置前台服务来进行保活。

步骤104、控制执行为所述应用程序设置前台服务的操作。

在某些实施方式中，还可以包括以下步骤：将所述应用程序的应用包名进行保存，作为拦截记录，并向用户展示所述拦截记录。

在某些实施方式中，还可以包括以下步骤：若所述应用程序为系统内置应用，则允许所述应用程序设置前台服务。

在某些实施方式中，还可以包括以下步骤：从服务器或者移动终端本地获取所述预设前台设置策略。

在某些实施方式中，在按照预设前台服务设置策略基于所述应用信息，判断所述应用程序是否可以设置前台服务之前，还可以包括以下步骤：判断所述应用程序请求设置为前台服务的目标服务是否满足第二设定条件，若是，则确定所述应用程序可以将所述目标服务设置为前台服务；若否，则按照预设前台服务设置策略基于所述应用信息，判断所述应用程序是否可以设置前台服务或者确定所述应用程序不可以将所述目标服务设置为前台服务。所述第二设定条件可以为所述目标服务的服务名称在预设的服务白名单中，或者所述目标服务的服务类型为设定服务类型，例如支付服务类型等。

本实施例提供的方法，通过获取请求设置前台服务的应用程序的应用信息，按照预设前台服务设置策略基于所述应用信息，判断所述应用程序是否可以设置前台服务，若判断结果为不可以，则禁止所述应用设置前台服务，以防止所述应用程序通过设置前台服务来进行保活，可以合理的管控应用程序的保活操作，避免由于一些流氓应用保活自己，而浪费移动终端的运行资源和电量以及流量，也提升了移动终端运行的流畅度。

图2给出了本申请实施例提供的另一种应用程序保活的管控方法的流程图，如图2所示，本实施例提供的方法包括以下步骤：

步骤201、获取请求设置前台服务的应用程序的应用信息。

步骤202、按照第一预设前台服务设置策略，基于所述应用程序的应用设置信息，判断所述应用程序是否可以设置前台服务。若是，则执行步骤203，若否则执行步骤204。

在某些实施方式中，该步骤202可以包括：若所述应用程序在设定白名单中，则确定所述应用程序可以设置前台服务，否则，确定所述应用程序不可以设置前台服务；或者，若所述应用程序的自启动开关开启，则确定所述应用程序可以设置前台服务，否则，确定所述应用程序不可以设置前台服务。若所述应用程序在设定白名单中，说明该应用程序为正常应用，则可确定该应用程序可以设置前台服务，否则，说明该应用程序为流氓应用，则确定该应用不可以设置前台服务；若所述应用程序的自启动开关开启，说明该应用程序为可以自启动和进行适时保活的正常应用，则可确定该应用程序可以设置前台服务，否则，说明该应用程序为流氓应用，则确定该应用不可以设置前台服务。其中，可以将用户常用或者比较基础的应用程序设置在白名单中，例如，将微信应用设置在白名单中，而将游戏应用不设置在白名单中。

可选的，还包括以下步骤：从服务器或者移动终端本地获取所述预设白名单。进一步的，所述预设白名单可以实时更新，例如，在接收到用户的更新指令时，更新所述预设白名单，或者在检测到满足更新条件的目标应用程序时，将目标应用程序添加至预设白名单中，所述更新条件可以包括目标应用由用户启动的次数达到设定启动次数时添加至预设白名单，或者自启动次数大于设定启动次数时，从预设白名单中删除。

可选的，在确定所述应用程序可以设置前台服务之后，还可以包括：判断所述应用程序在设置前台服务之后，系统是否发出相应通知；若否，则将所述应用程序列入黑名单，后续不允许所述应用程序设置前台服务。一般，若应用程序在设置前台服务之后，会在状态栏中显示相应通知，若系统未发出通知，那么说明是流氓应用为了不让用户知道其偷偷的在运行而将通知清除了，那么可以将该应用程序添加至黑名单中。

步骤203、禁止所述应用程序设置前台服务，以禁止所述应用程序通过设置前台服务来进行保活。

步骤204、控制执行为所述应用程序设置前台服务的操作。

本实施例提供的方法，通过获取请求设置前台服务的应用程序的应用信息，按照第一预设前台服务设置策略基于所述应用程序的应用设置信息，判断所述应用程序是否可以设置前台服务，若判断结果为不可以，则禁止所述应用设置前台服务，以防止所述应用程序通过设置前台服务来进行保活，可以合理的管控应用程序的保活操作，避免由于一些流氓应用保活自己，而浪费移动终端的运行资源和电量以及流量，也提升了移动终端运行的流畅度。

图3给出了本申请实施例提供的另一种应用程序保活的管控方法的流程图，如图3所示，本实施例提供的方法包括以下步骤：

步骤301、获取请求设置前台服务的应用程序的应用信息。

步骤302、按照第二预设前台服务设置策略，基于所述应用程序的应用运行信息，判断所述应用程序是否可以设置前台服务，若是，则执行步骤303，若否则执行步骤304。

在某些实施方式中，该步骤302可以包括：若所述应用程序的设定属性满足第一设定条件，则确定所述应用程序可以设置前台服务，否则，确定所述应用程序不可以设置前台服务，所述设定属性包括使用频率、运行优先级和类型中的至少一项；或者，若所述应用程序为无前台界面的应用程序且设置前台服务的次数大于设定次数，则确定所述应用程序不可以设置前台服务，否则，确定所述应用程序可以设置前台服务。其中，所述第一设定条件可以包括使用频率大于设定频率，运行优先级大于设定优先级，应用类型为设定类型中的至少一项。在使用频率大于设定频率时，说明该应用程序为用户经常使用的应用，是正常应用。示例性的，所述设定类型可以为日历、拍摄类型等。

可选的，在确定所述应用程序可以设置前台服务之后，还包括：判断所述应用程序在设置前台服务之后，系统是否发出通知；若否，则将所述应用程序列入黑名单，后续不允许所述应用程序设置前台服务。

步骤303、禁止所述应用程序设置前台服务，以禁止所述应用程序通过设置前台服务来进行保活。

步骤304、控制执行为所述应用程序设置前台服务的操作。

本实施例提供的方法，通过获取请求设置前台服务的应用程序的应用信息，按照第二预设前台服务设置策略基于所述应用程序的应用运行信息，判断所述应用程序是否可以设置前台服务，若判断结果为不可以，则禁止所述应用设置前台服务，以防止所述应用程序通过设置前台服务来进行保活，可以合理的管控应用程序的保活操作，避免由于一些流氓应用保活自己，而浪费移动终端的运行资源和电量以及流量，也提升了移动终端运行的流畅度。

图4为本申请实施例提供的一种应用程序保活的管控装置的结构示意图，该装置可由软件和/或硬件实现，集成在移动终端中。如图4所示，该装置包括应用信息获取模块41、前台服务设置判断模块42和前台服务设置禁止模块43。

所述应用信息获取模块41，用于获取请求设置前台服务的应用程序的应用信息；

所述前台服务设置判断模块42，用于按照预设前台服务设置策略基于所述应用信息，判断所述应用程序是否可以设置前台服务；

所述前台服务设置禁止模块43，用于若所述应用程序是否不可以设置前台服务，则禁止所述应用程序设置前台服务，以禁止所述应用程序通过设置前台服务来自启动。

本实施例提供的应用程序保活的管控装置，通过获取请求设置前台服务的应用程序的应用信息，按照预设前台服务设置策略基于所述应用信息，判断所述应用程序是否可以设置前台服务，若判断结果为不可以，则禁止所述应用设置前台服务，以防止所述应用程序通过设置前台服务来进行保活，可以合理的管控应用程序的保活操作，避免由于一些流氓应用保活自己，而浪费移动终端的运行资源和电量，也提升了移动终端运行的流畅度。

可选的，所述前台服务设置判断模块包括：

第一前台服务设置判断单元，用于按照第一预设前台服务设置策略，基于所述应用程序的应用设置信息，判断所述应用程序是否可以设置前台服务。

可选的，所述前台服务设置判断模块包括：

第二前台服务设置判断单元，用于按照第二预设前台服务设置策略，基于所述应用程序的应用运行信息，判断所述应用程序是否可以设置前台服务。

可选的，所述第一前台服务设置判断单元具体用于：

若所述应用程序在设定白名单中，则确定所述应用程序可以设置前台服务，否则，确定所述应用程序不可以设置前台服务；或者，

若所述应用程序的自启动开关开启，则确定所述应用程序可以设置前台服务，否则，确定所述应用程序不可以设置前台服务。

可选的，所述第二前台服务设置判断单元具体用于：

若所述应用程序的设定属性满足第一设定条件，则确定所述应用程序可以设置前台服务，否则，确定所述应用程序不可以设置前台服务，所述设定属性包括使用频率、运行优先级和类型中的至少一项；或者，

若所述应用程序为无前台界面的应用程序且设置前台服务的次数大于设定次数，则确定所述应用程序不可以设置前台服务，否则，确定所述应用程序可以设置前台服务。

可选的，所述装置还可以包括：

预设前台设置策略获取模块，用于从服务器或者移动终端本地获取所述预设前台设置策略；和/或，

预设白名单获取模块，用于从服务器或者移动终端本地获取所述预设白名单。

可选的，所述装置还可以包括：

通知发出判断模块，用于在确定所述应用程序可以设置前台服务之后，判断所述应用程序在设置前台服务之后，系统是否发出通知；

黑名单添加模块，用于若未发出通知，则将所述应用程序列入黑名单，后续不允许所述应用程序设置前台服务。

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

前台服务设置模块，用于判断所述应用程序请求设置为前台服务的目标服务是否满足第二设定条件，若是，则确定所述应用程序可以将所述目标服务设置为前台服务。

本申请实施例还提供一种包含计算机可执行指令的存储介质，所述计算机可执行指令在由计算机处理器执行时用于执行一种应用程序保活的管控方法，该方法包括：

获取请求设置前台服务的应用程序的应用信息；

按照预设前台服务设置策略基于所述应用信息，判断所述应用程序是否可以设置前台服务；

若否，则禁止所述应用程序设置前台服务，以禁止所述应用程序通过设置前台服务来进行保活。

存储介质——任何的各种类型的存储器设备或存储设备。术语“存储介质”旨在包括：安装介质，例如cd-rom、软盘或磁带装置；计算机系统存储器或随机存取存储器，诸如dram、ddrram、sram、edoram，兰巴斯(rambus)ram等；非易失性存储器，诸如闪存、磁介质(例如硬盘或光存储)；寄存器或其它相似类型的存储器元件等。存储介质可以还包括其它类型的存储器或其组合。另外，存储介质可以位于程序在其中被执行的第一计算机系统中，或者可以位于不同的第二计算机系统中，第二计算机系统通过网络(诸如因特网)连接到第一计算机系统。第二计算机系统可以提供程序指令给第一计算机用于执行。术语“存储介质”可以包括可以驻留在不同位置中(例如在通过网络连接的不同计算机系统中)的两个或更多存储介质。存储介质可以存储可由一个或多个处理器执行的程序指令(例如具体实现为计算机程序)。

当然，本申请实施例所提供的一种包含计算机可执行指令的存储介质，其计算机可执行指令不限于如上所述的应用程序保活的管控操作，还可以执行本申请任意实施例所提供的应用程序保活的管控方法中的相关操作。

本申请实施例提供了一种移动终端，该移动终端中可集成本申请实施例提供的应用程序保活的管控装置。图5为本申请实施例提供的一种移动终端的结构示意图。移动终端500可以包括：存储器501，处理器502及存储在存储器501上并可在处理器502运行的计算机程序，所述处理器502执行所述计算机程序时实现如本申请实施例所述的应用程序保活的管控方法。

本申请实施例提供的移动终端，可以合理的管控应用程序的保活操作，防止流氓应用程序通过设置前台服务来进行保活，而浪费移动终端的运行资源和电量，也提升了移动终端运行的流畅度。

图6为本申请实施例提供的另一种移动终端的结构示意图，如图6所示，该移动终端可以包括：存储器601、中央处理器(centralprocessingunit，cpu)602(又称处理器，以下简称cpu)、所述存储器601，用于存储可执行程序代码；所述处理器602通过读取所述存储器601中存储的可执行程序代码来运行与所述可执行程序代码对应的程序，以用于执行：获取请求设置前台服务的应用程序的应用信息；按照预设前台服务设置策略基于所述应用信息，判断所述应用程序是否可以设置前台服务；若否，则禁止所述应用程序设置前台服务，以禁止所述应用程序通过设置前台服务来进行保活。

所述移动终端还包括：外设接口603、rf(radiofrequency，射频)电路605、音频电路606、扬声器611、电源管理芯片608、输入/输出(i/o)子系统609、触摸屏612、其他输入/控制设备610以及外部端口604，这些部件通过一个或多个通信总线或信号线607来通信。

应该理解的是，图示移动终端600仅仅是移动终端的一个范例，并且移动终端600可以具有比图中所示出的更多的或者更少的部件，可以组合两个或更多的部件，或者可以具有不同的部件配置。图中所示出的各种部件可以在包括一个或多个信号处理和/或专用集成电路在内的硬件、软件、或硬件和软件的组合中实现。

下面就本实施例提供的用于管控应用程序保活的移动终端进行详细的描述，该移动终端以手机为例。

存储器601，所述存储器601可以被cpu602、外设接口603等访问，所述存储器601可以包括高速随机存取存储器，还可以包括非易失性存储器，例如一个或多个磁盘存储器件、闪存器件、或其他易失性固态存储器件。

外设接口603，所述外设接口603可以将设备的输入和输出外设连接到cpu502和存储器601。

i/o子系统609，所述i/o子系统609可以将设备上的输入输出外设，例如触摸屏612和其他输入/控制设备610，连接到外设接口603。i/o子系统609可以包括显示控制器6091和用于控制其他输入/控制设备610的一个或多个输入控制器6092。其中，一个或多个输入控制器6092从其他输入/控制设备610接收电信号或者向其他输入/控制设备610发送电信号，其他输入/控制设备610可以包括物理按钮(按压按钮、摇臂按钮等)、拨号盘、滑动开关、操纵杆、点击滚轮。值得说明的是，输入控制器6092可以与以下任一个连接：键盘、红外端口、usb接口以及诸如鼠标的指示设备。

触摸屏612，所述触摸屏612是用户终端与用户之间的输入接口和输出接口，将可视输出显示给用户，可视输出可以包括图形、文本、图标、视频等。

i/o子系统609中的显示控制器6091从触摸屏612接收电信号或者向触摸屏612发送电信号。触摸屏612检测触摸屏上的接触，显示控制器6091将检测到的接触转换为与显示在触摸屏612上的用户界面对象的交互，即实现人机交互，显示在触摸屏612上的用户界面对象可以是运行游戏的图标、联网到相应网络的图标等。值得说明的是，设备还可以包括光鼠，光鼠是不显示可视输出的触摸敏感表面，或者是由触摸屏形成的触摸敏感表面的延伸。

rf电路605，主要用于建立手机与无线网络(即网络侧)的通信，实现手机与无线网络的数据接收和发送。例如收发短信息、电子邮件等。具体地，rf电路605接收并发送rf信号，rf信号也称为电磁信号，rf电路605将电信号转换为电磁信号或将电磁信号转换为电信号，并且通过该电磁信号与通信网络以及其他设备进行通信。rf电路605可以包括用于执行这些功能的已知电路，其包括但不限于天线系统、rf收发机、一个或多个放大器、调谐器、一个或多个振荡器、数字信号处理器、codec(coder-decoder，编译码器)芯片组、用户标识模块(subscriberidentitymodule，sim)等等。

音频电路606，主要用于从外设接口603接收音频数据，将该音频数据转换为电信号，并且将该电信号发送给扬声器611。

扬声器611，用于将手机通过rf电路605从无线网络接收的语音信号，还原为声音并向用户播放该声音。

电源管理芯片608，用于为cpu602、i/o子系统及外设接口603所连接的硬件进行供电及电源管理。

上述实施例中提供的应用程序保活的管控装置、存储介质及移动终端可执行本申请任意实施例所提供的应用程序保活的管控方法，具备执行该方法相应的功能模块和有益效果。未在上述实施例中详尽描述的技术细节，可参见本申请任意实施例所提供的应用程序保活的管控方法。

上述仅为本申请的较佳实施例及所运用的技术原理。本申请不限于这里所述的特定实施例，对本领域技术人员来说能够进行的各种明显变化、重新调整及替代均不会脱离本申请的保护范围。因此，虽然通过以上实施例对本申请进行了较为详细的说明，但是本申请不仅仅限于以上实施例，在不脱离本申请构思的情况下，还可以包括更多其他等效实施例，而本申请的范围由权利要求的范围决定。