CN114168212A - 应用处理方法、装置、设备及计算机可读存储介质 - Google Patents

Abstract

本申请提供一种应用处理方法、装置、设备及计算机可读存储介质，该方法通过确定待保活应用是否已安装；若待保活应用已安装，则确定待保活应用是否已启动；若待保活应用已启动，则将待保活应用的当前状态、待保活应用的下一个状态和待保活应用的最差状态都设置为预设保活状态，预设保活状态根据保活的应用的状态确定，解决了现有技术仅是通过包名设置保活应用，无法准确地在应用的各个状态实现保活，效率及灵活性差。

Description

应用处理方法、装置、设备及计算机可读存储介质

技术领域

本发明涉及计算机技术领域，尤其涉及一种应用处理方法、装置、设备及计算机可读存储介质。

背景技术

应用保活技术是指保证一个应用在终端里面可以一直运行的技术，也就是只要终端在运行中，那么这个应用就会一直运行。在多种条件下，终端中的某些应用需要保活来实现功能的需要，例如监狱中的终端遇到越狱暴动突发事件，摄像头必须保持在开启的状态，即摄像应用需要始终处于保活状态。

现有的应用保活技术通常通过隐藏应用的关闭点，例如在最近任务栏，在应用列表中都没有桌面和状态栏的图标，或者里面的强制停止按钮置灰，保证应用不会再这些情况被关闭，这些方式都是通过单一的包名锁定保活应用的，需要在应用启动之前就设定好，该应用的包名必须提前制定好。

然而现有技术仅是通过包名设置保活应用，无法准确地在应用的各个状态实现保活，效率及灵活性差。

发明内容

本申请提供一种应用处理方法、装置、设备及计算机可读存储介质，从而解决现有技术仅是通过包名设置保活应用，无法准确地在应用的各个状态实现保活，效率及灵活性差的技术问题。

第一方面，本申请提供一种应用处理方法，包括：

确定待保活应用是否已安装；

若所述待保活应用已安装，则确定所述待保活应用是否已启动；

若所述待保活应用已启动，则将所述待保活应用的当前状态、所述待保活应用的下一个状态和所述待保活应用的最差状态都设置为预设保活状态。

这里，本申请实施例首先确定待保活应用是否安装以及是否启动的状态，对已经安装并且持续运行的应用，可以将该应用所有可能导致进程被意外清除的地方都进行保护，通过将待保活应用的当前状态、待保活应用的下一个状态和待保活应用的最差状态都设置为预设保活状态，预设保活状态可以是前台状态，从而，保证待保活应用在运行过程中的任何状态都不会被清除，准确地在应用的各个状态实现保活，提高了应用保活的效率及灵活性。

可选的，在所述确定所述待保活应用是否已启动之后，还包括：

若所述待保活应用未启动，则将所述待保活应用的最差状态设置为所述预设保活状态。

本申请实施例提供了尚未启动的待保活应用的保活方案，可以首先启动待保活应用，再将待保活应用的最差状态设置为预设保活状态，由于待保活应用之前还未启动，所以其当前状态和下一个状态都受到最差状态的控制，无需单独设置，即可实现待保活应用在运行过程中的任何状态都不会被清除，准确地在应用的各个状态实现保活，进一步地提高了应用保活的效率及灵活性。

可选的，在所述确定所述待保活应用是否已启动之后，还包括：

若所述待保活应用已启动，则将所述待保活应用的标识添加至预设白名单。

这里，本申请实施例可以将待保活应用添加至预设白名单，采用杀进程反向禁用，产生保活效果。在应用强制停止、最近任务栏删除最近任务、超级省电关闭一切应用等地方，其本质都是调用杀进程方法，本申请实施例的预设白名单中的应用不会被上述情况清理，进一步地保证了待保活应用保活的可靠性，提高了保活的效率、准确性及灵活性。

可选的，在所述将所述待保活应用的当前状态、所述待保活应用的下一个状态和所述待保活应用的最差状态都设置为预设保活状态之后，还包括：

将所述待保活应用的基本信息存储在永久性存储单元中，所述基本信息包括所述待保活应用的标识。

可选的，在所述确定待保活应用是否已安装之前，还包括：

根据所述永久性存储单元中存储的保活应用的基本信息，确定所述待保活应用，并获取所述待保活应用的当前状态、所述待保活应用的下一个状态和所述待保活应用的最差状态。

这里，本申请实施例将所有的待保活应用的基本信息存储在永久性存储单元中，以便每次开机都能够从永久性存储单元中准确读取到所有需要保活的应用，因此在开机应用初始化的时候，就能够预先设置待保活应用的各项信息和参数，准确地在应用的各个状态实现保活，进一步地提高了待保活应用保活的效率和可靠性，提高了保活的灵活性。

第二方面，本申请实施例提供一种应用处理装置，包括：

第一确定模块，用于确定待保活应用是否已安装；

第二确定模块，用于若所述待保活应用已安装，则确定所述待保活应用是否已启动；

设置模块，用于若所述待保活应用已启动，则将所述待保活应用的当前状态、所述待保活应用的下一个状态和所述待保活应用的最差状态都设置为预设保活状态。

可选的，在第二确定模块所述确定所述待保活应用是否已启动之后，所述设置模块还用于：

若所述待保活应用未启动，则将所述待保活应用的最差状态设置为所述预设保活状态。

可选的，在所述设置模块将所述待保活应用的当前状态、所述待保活应用的下一个状态和所述待保活应用的最差状态都设置为预设保活状态之后之后，还包括：

添加模块，用于若所述待保活应用已启动，则将所述待保活应用的标识添加至预设白名单。

可选的，在所述第二确定模块确定待保活应用是否已安装之后，还包括：

存储模块，用于将所述待保活应用的基本信息存储在永久性存储单元中，所述基本信息包括所述待保活应用的标识。

可选的，在所述确定待保活应用是否已安装之前，还包括：

第三确定模块，用于根据所述永久性存储单元中存储的保活应用的基本信息，确定所述待保活应用，并获取所述待保活应用的当前状态、所述待保活应用的下一个状态和所述待保活应用的最差状态。

第三方面，本申请实施例提供一种应用处理设备，包括：至少一个处理器；以及与所述至少一个处理器通信连接的存储器；其中，所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行如第一方面或第一方面的可选方式所述的应用处理方法。

第四方面，本申请实施例提供一种计算机可读存储介质，计算机可读存储介质中存储有计算机执行指令，当计算机执行指令被处理器执行时用于实现如第一方面或第一方面的可选方式所述的应用处理方法。

本申请实施例提供的应用处理方法、装置、设备及计算机可读存储介质，其中该方法首先确定待保活应用是否安装以及是否启动的状态，对已经安装并且持续运行的应用，可以将该应用所有可能导致进程被意外清除的地方都进行保护，即通过将待保活应用的当前状态、待保活应用的下一个状态和待保活应用的最差状态都设置为预设保活状态，预设保活状态可以是前台状态，从而，保证待保活应用在运行过程中的任何状态都不会被清除，准确地在应用的各个状态实现保活，提高了应用保活的效率及灵活性。

附图说明

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

图1为本申请实施例提供的一种应用处理系统架构示意图；

图2为本申请实施例提供的一种应用处理方法的流程图；

图3为本申请实施例提供的另一种应用处理方法的流程图；

图4为本申请实施例提供的再一种应用处理方法的流程图；

图5为本申请实施例提供的又一种应用处理方法的流程图；

图6为本申请实施例提供的一种应用处理装置的结构示意图；

图7为本申请实施例提供的一种应用处理设备的结构示意图；

通过上述附图，已示出本公开明确的实施例，后文中将有更详细的描述。这些附图和文字描述并不是为了通过任何方式限制本公开构思的范围，而是通过参考特定实施例为本领域技术人员说明本公开的概念。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”及“第四”等(如果存在)是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

应用保活技术是指保证一个应用在终端里面可以一直运行的技术，也就是只要终端在运行中，那么这个应用就会一直运行。在多种条件下，终端中的某些应用需要保活来实现功能的需要，例如监狱中的终端遇到越狱暴动突发事件，摄像头必须保持在开启的状态，即摄像应用需要始终处于保活状态，需要使得某个应用突然在某个时间点，不管当前是否是运行状态，都要从此刻开始，只要终端运行，则一定会活跃。现有的应用保活技术通常通过隐藏应用的关闭点，例如在最近任务栏，在应用列表中都没有桌面和状态栏的图标，或者里面的强制停止按钮置灰，保证应用不会再这些情况被关闭，这些方式都是通过单一的包名锁定保活应用的，需要在应用启动之前就设定好，该应用的包名必须提前制定好。

然而现有技术仅是通过包名设置保活应用，无法准确地在应用的各个状态实现保活，效率及灵活性差。

为了解决上述技术问题，本申请实施例提供一种应用处理方法、装置、设备及计算机可读存储介质，首先确定待保活应用是否安装以及是否启动的状态，对已经安装并且持续运行的应用，可以将该应用所有可能导致进程被意外清除的地方都进行保护，即通过将待保活应用的当前状态、待保活应用的下一个状态和待保活应用的最差状态都设置为预设保活状态，预设保活状态可以是前台状态，从而，保证待保活应用在运行过程中的任何状态都不会被清除，准确地在应用的各个状态实现保活，提高了应用保活的效率及灵活性。

可选的，图1为本申请实施例提供的一种应用处理系统架构示意图。在图1中，上述架构包括接收装置101、处理器102和显示装置103中至少一种。

可以理解的是，本申请实施例示意的结构并不构成对应用处理架构的具体限定。在本申请另一些可行的实施方式中，上述架构可以包括比图示更多或更少的部件，或者组合某些部件，或者拆分某些部件，或者不同的部件布置，具体可根据实际应用场景确定，在此不做限制。图2所示的部件可以以硬件，软件，或软件与硬件的组合实现。

在具体实现过程中，接收装置101可以是输入/输出接口，也可以是通信接口。

处理器102可以首先确定待保活应用是否安装以及是否启动的状态，对已经安装并且持续运行的应用，可以将该应用所有可能导致进程被意外清除的地方都进行保护，通过将待保活应用的当前状态、待保活应用的下一个状态和待保活应用的最差状态都设置为预设保活状态，预设保活状态可以是前台状态，从而，保证待保活应用在运行过程中的任何状态都不会被清除，准确地在应用的各个状态实现保活，提高了应用保活的效率及灵活性。

显示装置103可以用于对上述结果等进行显示。

显示装置还可以是触摸显示屏，用于在显示的上述内容的同时接收用户指令，以实现与用户的交互。

应理解，上述处理器可以通过处理器读取存储器中的指令并执行指令的方式实现，也可以通过芯片电路实现。

另外，本申请实施例描述的网络架构以及业务场景是为了更加清楚的说明本申请实施例的技术方案，并不构成对于本申请实施例提供的技术方案的限定，本领域普通技术人员可知，随着网络架构的演变和新业务场景的出现，本申请实施例提供的技术方案对于类似的技术问题，同样适用。

下面结合具体的实施例对本申请的技术方案进行详细的说明：

图2为本申请实施例提供的一种应用处理方法的流程图。本申请实施例的执行主体可以为图1中的处理器102，具体执行主体可以根据实际应用场景确定。如图2所示，该方法包括如下步骤：

S201：确定待保活应用是否已安装。

可选的，用户需要确定待保活应用，即指定需要进行保活的应用，最简洁的方式是给出相应的参数，可以通过packageName(包名)确定待保活应用。因为应用的名字、图标等可以重复，而包名终端中要求独一无二。可以更加准确地确定待保活应用。

可选的，通过包名可以在Package Manager Service(包管理服务)中对Application Info(应用程序信息)进行查找，对于已经安装了的应用，则可以通过packageName匹配到对应的Application Info，若未通过packageName匹配到对应的Application Info，则确定未安装待保活应用。

S202：若待保活应用已安装，则确定待保活应用是否已启动。

可选的，通过Application Info在Activity Manager service中通过getProcessRecordLocked方法搜索，是否有已经启动的对应进程ProcessRecord(进程记录表)。如果该应用被启动则一定会有ProcessRecord，从而确定待保活应用是否已启动。

可选的，在终端的任务管理器中通过应用名称确定待保活应用是否已启动。

S203：若待保活应用已启动，则将待保活应用的当前状态、待保活应用的下一个状态和待保活应用的最差状态都设置为预设保活状态。

这里，需要说明的是，系统对应用进行清理自动杀掉，是否杀掉，主要是通过应用的实时参数来判断。

可选的，应用的实时参数包括待保活应用的当前状态、待保活应用的下一个状态和待保活应用的最差状态，上述参数的状态包括在前台即用户正在使用、仅可见即被状态栏所覆盖、刚到后台即由此应用跳转到别的应用、在后台一段时间了和在后台很久了的状态，应用处于在后台一段时间了和在后台很久了的状态容易被系统清理杀掉，而在前台状态不会被系统清理杀掉，预设保活状态可以为在前台状态。

可选的，通过一个参数名为adj(程序级别关键值)的控制，实现待保活应用的当前状态、待保活应用的下一个状态和待保活应用的最差状态的转换。

可选的，这个参数与进程号绑定，每一个进程都有一个ProcessRecord。ProcessRecord中包含待保活应用的当前状态、待保活应用的下一个状态和待保活应用的最差状态三个参数，待保活应用的当前状态可以表示为curadj，待保活应用的下一个状态可以表示为setadj，待保活应用的最差状态可以表示为maxadj。

可选的，若待保活应用在终端中属于预置型的保活应用，在待保活应用初始化的时候，即启动进程的时候，将待保活应用的最差状态设为预设保活状态，无论状态栏在启动之后怎么变化，都会是前台应用，不被系统杀死，实现了保活。

可选的，在确定待保活应用是否已启动之后，还包括：若待保活应用未启动，则将待保活应用的最差状态设置为预设保活状态。

这里，本申请实施例提供了尚未启动的待保活应用的保活方案，可以首先启动待保活应用，再将待保活应用的最差状态设置为预设保活状态，由于待保活应用之前还未启动，所以其当前状态和下一个状态都受到最差状态的控制，无需单独设置，即可实现待保活应用在运行过程中的任何状态都不会被清除，准确地在应用的各个状态实现保活，进一步地提高了应用保活的效率及灵活性。

可选的，对于已经启动的应用，将待保活应用的当前状态、待保活应用的下一个状态和待保活应用的最差状态都设置为预设保活状态，保证了应用在各个状态都不会被清理，实现了保活。

本申请实施例首先确定待保活应用是否安装以及是否启动的状态，对已经安装并且持续运行的应用，可以将该应用所有可能导致进程被意外清除的地方都进行保护，通过将待保活应用的当前状态、待保活应用的下一个状态和待保活应用的最差状态都设置为预设保活状态，预设保活状态可以是前台状态，保证待保活应用在运行过程中的任何状态都不会被清除，准确地在应用的各个状态实现保活，提高了应用保活的效率及灵活性。

可选的，本申请实施例还将待保活应用的标识添加至预设白名单，通过白名单实现杀进程反向禁用，图3为本申请实施例提供的另一种应用处理方法的流程图，如图3所示，该方法包括：

S301：确定待保活应用是否已安装。

S302：若待保活应用已安装，则确定待保活应用是否已启动。

S303：若待保活应用已启动，则将待保活应用的当前状态、待保活应用的下一个状态和待保活应用的最差状态都设置为预设保活状态。

其中，步骤S301-S303与上述步骤S201-S203的实现方式相同，此处不再赘述。

S304：将待保活应用的标识添加至预设白名单。

可选的，将待保活应用的标识可以是应用的包名、应用的名称等。

可选的，预设白名单可以存储在终端中，也可以存储在云服务器。

可选的，存储在预设白名单中的待保活应用不会被系统清理。

这里，本申请实施例可以将待保活应用添加至预设白名单，采用杀进程反向禁用，产生保活效果，在应用强制停止、最近任务栏删除最近任务、超级省电关闭一切应用等地方，其本质都是调用杀进程方法，本申请实施例的预设白名单中的应用不会被上述情况清理，进一步地保证了待保活应用保活的可靠性，提高了保活的效率、准确性及灵活性。

可选的，本申请实施例还可以将待保活应用的基本信息存储在永久性存储单元中，图4为本申请实施例提供的再一种应用处理方法的流程图，如图4所示，该方法包括：

S401：确定待保活应用是否已安装。

S402：若待保活应用已安装，则确定待保活应用是否已启动。

S403：若待保活应用已启动，则将待保活应用的当前状态、待保活应用的下一个状态和待保活应用的最差状态都设置为预设保活状态。

其中，步骤S401-S403与上述步骤S201-S203的实现方式相同，此处不再赘述。

S404：将待保活应用的基本信息存储在永久性存储单元中，基本信息包括所述待保活应用的标识。

可选的，上述永久性存储单元可以是数据库、contentprovider、systemPerportes、文件、网络或者服务器等。

可选的，由于永久性存储单元中预存了待保活应用，在在确定待保活应用是否已安装之前，还包括：根据永久性存储单元中存储的保活应用的基本信息，确定待保活应用，并获取待保活应用的当前状态、待保活应用的下一个状态和待保活应用的最差状态。从而可以在开机时对应用进行保活。

这里，本申请实施例将所有的待保活应用的基本信息存储在永久性存储单元中，以便每次开机都能够从永久性存储单元中准确读取到所有需要保活的应用，因此在开机应用初始化的时候，就能够预先设置待保活应用的各项信息和参数，准确地在应用的各个状态实现保活，进一步地提高了待保活应用保活的效率和可靠性，提高了保活的灵活性。

可选的，图5为本申请实施例提供的又一种应用处理方法的流程图，如图5所示，该方法包括：S501：设置待保活应用，确认待保活应用已经安装；若待保活应用已经安装，则进入步骤S502：确认待保活应用是否启动；若待保活应用启动，则进入步骤S503：修改初始化参数，保活成功，上述初始化参数为待保活应用的当前状态、待保活应用的下一个状态和待保活应用的最差状态，上述修改初始化参数可以理解为将待保活应用的当前状态、待保活应用的下一个状态和待保活应用的最差状态都设置为预设保活状态，例如前台状态；若待保活应用未启动，则进入步骤S5030：启动应用，启动应用之后进入步骤S503：修改初始化参数，保活成功，这里的修改初始化参数可以理解为将待保活应用的最差状态设置为预设保活状态。

此外，本申请实施例还包括S5010：重启手机；S5020：确认待保活应用已经安装成功；之后进入步骤S503：修改初始化参数，保活成功，此时可以只修改待保活应用的最差状态参数。

本申请实施例实现了对正在运行的应用实现了全方位的保活，可以动态修改待保活应用的参数，还可以根据静态的重启手机时预存的待保活应用进行保活，实现了保活的准确、可靠。

图6为本申请实施例提供的一种应用处理装置的结构示意图，如图6所示，本申请实施例的装置包括：第一确定模块601、第二确定模块602和设置模块603。这里的应用处理装置可以是上述处理器102本身，或者是实现处理器102的功能的芯片或者集成电路。这里需要说明的是，第一确定模块601、第二确定模块602和设置模块603的划分只是一种逻辑功能的划分，物理上两者可以是集成的，也可以是独立的。

其中，第一确定模块601，用于确定待保活应用是否已安装；

第二确定模块602，用于若待保活应用已安装，则确定待保活应用是否已启动；

设置模块603，用于若待保活应用已启动，则将待保活应用的当前状态、待保活应用的下一个状态和待保活应用的最差状态都设置为预设保活状态。

可选的，在第二确定模块602确定待保活应用是否已启动之后，设置模块603还用于：

若待保活应用未启动，则将待保活应用的最差状态设置为预设保活状态。

可选的，在第二确定模块602确定待保活应用是否已启动之后，上述装置还包括：

添加模块604，用于若待保活应用已启动，则将待保活应用的标识添加至预设白名单。

可选的，在设置模块603将待保活应用的当前状态、待保活应用的下一个状态和待保活应用的最差状态都设置为预设保活状态之后之后，上述装置还包括：

存储模块605，用于将待保活应用的基本信息存储在永久性存储单元中，基本信息包括待保活应用的标识。

可选的，在确定待保活应用是否已安装之前，上述装置还包括：

第三确定模块606，用于根据永久性存储单元中存储的保活应用的基本信息，确定待保活应用，并获取待保活应用的当前状态、待保活应用的下一个状态和待保活应用的最差状态。

图7为本申请实施例提供的一种应用处理设备的结构示意图。本文所示的部件、它们的连接和关系、以及它们的功能仅仅作为示例，并且不限制本文中描述的和/或者要求的本申请的实现。

如图7所示，该应用处理设备包括：处理器701和存储器702，各个部件利用不同的总线互相连接，并且可以被安装在公共主板上或者根据需要以其它方式安装。处理器701可以对在应用处理设备内执行的指令进行处理，包括存储在存储器中或者存储器上以在外部输入/输出装置(诸如，耦合至接口的显示设备)上显示的图形信息的指令。在其它实施方式中，若需要，可以将多个处理器和/或多条总线与多个存储器和多个存储器一起使用。图7中以一个处理器701为例。

存储器702作为一种非瞬时计算机可读存储介质，可用于存储非瞬时软件程序、非瞬时计算机可执行程序以及模块，如本申请实施例中的应用处理设备的方法对应的程序指令/模块(例如，附图6所示的第一确定模块601、第二确定模块602和设置模块603或者第一确定模块601、第二确定模块602、设置模块603、添加模块604、存储模块605和第三确定模块606)。处理器701通过运行存储在存储器702中的非瞬时软件程序、指令以及模块，从而执行服务器的各种功能应用以及数据处理，即实现上述方法实施例中的应用处理设备的方法。

应用处理设备还可以包括：输入装置703和输出装置704。处理器701、存储器702、输入装置703和输出装置704可以通过总线或者其他方式连接，图7中以通过总线连接为例。

输入装置703可接收输入的数字或字符信息，以及产生与应用处理设备的用户设置以及功能控制有关的键信号输入，例如触摸屏、小键盘、鼠标、或者多个鼠标按钮、轨迹球、操纵杆等输入装置。输出装置704可以是应用处理设备的显示设备等输出设备。该显示设备可以包括但不限于，液晶显示器(LCD)、发光二极管(LED)显示器和等离子体显示器。在一些实施方式中，显示设备可以是触摸屏。

本申请实施例的应用处理设备，可以用于执行本申请上述各方法实施例中的技术方案，其实现原理和技术效果类似，此处不再赘述。

本申请实施例还提供一种计算机可读存储介质，该计算机可读存储介质中存储有计算机执行指令，计算机执行指令被处理器执行时用于实现上述任一所述的应用处理方法。

在本申请所提供的几个实施例中，应该理解到，所揭露的系统，装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本公开的其它实施方案。本申请旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本公开的真正范围和精神由下面的权利要求书指出。

应当理解的是，本公开并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本公开的范围仅由所附的权利要求书来限制。

Claims (10)

1.一种应用处理方法，其特征在于，包括：

确定待保活应用是否已安装；

若所述待保活应用已安装，则确定所述待保活应用是否已启动；

若所述待保活应用已启动，则将所述待保活应用的当前状态、所述待保活应用的下一个状态和所述待保活应用的最差状态都设置为预设保活状态。

2.根据权利要求1所述的方法，其特征在于，在所述确定所述待保活应用是否已启动之后，还包括：

若所述待保活应用未启动，则将所述待保活应用的最差状态设置为所述预设保活状态。

3.根据权利要求1或2所述的方法，其特征在于，在所述确定所述待保活应用是否已启动之后，还包括：

若所述待保活应用已启动，则将所述待保活应用的标识添加至预设白名单。

4.根据权利要求1所述的方法，其特征在于，在所述将所述待保活应用的当前状态、所述待保活应用的下一个状态和所述待保活应用的最差状态都设置为预设保活状态之后，还包括：

将所述待保活应用的基本信息存储在永久性存储单元中，所述基本信息包括所述待保活应用的标识。

5.根据权利要求4所述的方法，其特征在于，在所述确定待保活应用是否已安装之前，还包括：

根据所述永久性存储单元中存储的保活应用的基本信息，确定所述待保活应用，并获取所述待保活应用的当前状态、所述待保活应用的下一个状态和所述待保活应用的最差状态。

6.一种应用处理装置，其特征在于，包括：

第一确定模块，用于确定待保活应用是否已安装；

第二确定模块，用于若所述待保活应用已安装，则确定所述待保活应用是否已启动；

设置模块，用于若所述待保活应用已启动，则将所述待保活应用的当前状态、所述待保活应用的下一个状态和所述待保活应用的最差状态都设置为预设保活状态。

7.根据权利要求6所述的装置，其特征在于，在所述第二确定模块确定所述待保活应用是否已启动之后，所述设置模块还用于：

若所述待保活应用未启动，则将所述待保活应用的最差状态设置为所述预设保活状态。

8.根据权利要求6或7所述的装置，其特征在于，在所述第二确定模块确定所述待保活应用是否已启动之后，还包括：

添加模块，用于若所述待保活应用已启动，则将所述待保活应用的标识添加至预设白名单。

9.一种应用处理设备，其特征在于，包括：

至少一个处理器；以及

与所述至少一个处理器通信连接的存储器；其中，

所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行权利要求1至5任一项所述的方法。

10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储有计算机执行指令，所述计算机执行指令被处理器执行时用于实现如权利要求1至5任一项所述的应用处理方法。

Images