CN114995972A - 应用程序的管理方法、装置、可读介质、电子设备及产品 - Google Patents

Abstract

本申请公开了一种应用程序的管理方法、装置、可读介质、电子设备及产品，所述方法包括：检测终端设备上安装的目标应用程序的运行状态；获取所述目标应用程序的保活概率，所述保活概率用于表示所述目标应用程序在切换至后台之后继续保持运行的概率；若根据所述运行状态确定所述目标应用程序被切换至后台，则根据所述目标应用程序的保活概率和所述终端设备的系统状态确定是否保持所述目标应用程序在后台运行；若确定需要保持所述目标应用程序在后台运行，则执行保持所述目标应用程序在后台运行的操作。本申请技术方案在目标应用程序再次被切换至前台时，可以快速进入目标应用程序，从而节省了应用程序切换的耗时，提高了应用程序间的切换效率。

Description

应用程序的管理方法、装置、可读介质、电子设备及产品

技术领域

本申请属于计算机技术领域，具体涉及一种应用程序的管理方法、装置、可读介质、电子设备及产品。

背景技术

终端设备是一种人们日常生活中常见的电子设备，可以用来进行通信、娱乐等活动，终端设备中往往可以安装多个应用程序(Application，APP)，多个应用程序之间可以切换。当从一个应用程序切换至另一应用程序时，前一个应用程序将被切换至后台，后一个应用程序被切换至前台，为了保证后一个应用程序的正常使用，此时通常将前一个应用程序关闭。那么，在这种情况下，当再次从后一个应用程序切回前一个应用程序时，由于前一个应用程序已被关闭，就需要重新启动前一个应用程序，才能重新进入前一个应用程序。如此，使得应用程序之间的切换耗时较多，十分不便。

发明内容

本申请的目的在于提供一种应用程序的管理方法、装置、可读介质、电子设备及产品，以优化相关技术中应用程序之间切换效率较低的问题。

本申请的其他特性和优点将通过下面的详细描述变得显然，或部分地通过本申请的实践而习得。

根据本申请实施例的一个方面，提供一种应用程序的管理方法，包括：

检测终端设备上安装的目标应用程序的运行状态；

获取所述目标应用程序的保活概率，所述保活概率用于表示所述目标应用程序在切换至后台之后继续保持运行的概率；

若根据所述运行状态确定所述目标应用程序被切换至后台，则根据所述目标应用程序的保活概率和所述终端设备的系统状态确定是否保持所述目标应用程序在后台运行；

若确定需要保持所述目标应用程序在后台运行，则执行保持所述目标应用程序在后台运行的操作。

根据本申请实施例的一个方面，提供一种应用程序的保活装置，包括：

程序状态检测模块，用于检测终端设备上安装的目标应用程序的运行状态；

数据获取模块，用于获取所述目标应用程序的保活概率，所述保活概率用于表示所述目标应用程序在切换至后台之后继续保持运行的概率；

判断模块，用于若根据所述运行状态确定所述目标应用程序被切换至后台，则根据所述目标应用程序的保活概率和所述终端设备的系统状态确定是否保持所述目标应用程序在后台运行；

保活模块，用于若确定需要保持所述目标应用程序在后台运行，则执行保持所述目标应用程序在后台运行的操作。

在本申请的一个实施例中，数据获取模块包括：

场景标识获取单元，用以获取所述目标应用程序中当前运行场景的标识信息；

匹配单元，用以根据所述当前运行场景的标识信息在应用程序保活概率列表中进行匹配，得到所述当前运行场景所对应的保活概率，所述应用程序保活概率列表中包含应用程序运行场景的标识信息与保活概率之间的关联关系；

保活概率获取单元，用以将所述当前运行场景所对应的保活概率作为所述目标应用程序的保活概率。

在本申请的一个实施例中，所述装置还包括：

概率列表获取模块，用于向服务器发送保活概率获取请求，以获取所述服务器针对所述保活概率获取请求反馈的所述应用程序保活概率列表。

在本申请的一个实施例中，所述装置还包括：

历史数据获取模块，用于获取所述终端设备上安装的应用程序的历史运行数据，所述历史运行数据包括所述应用程序处于各个运行场景时被切换至后台之后是否再次切换至前台运行的历史数据；

场景概率计算模块，用于根据所述历史运行数据计算所述应用程序处于所述各个运行场景的保活概率；

概率列表构建模块，用于将所述各个运行场景的标识信息与所述应用程序处于所述各个运行场景的保活概率建立关联关系，生成所述应用程序保活概率列表。

在本申请的一个实施例中，所述场景概率计算模块具体用于：

对所述历史运行数据进行统计处理，得到历史保活概率、各个运行场景的出现概率和各个运行场景的条件保活概率；所述历史保活概率表示所述应用程序需要保持后台运行的概率；所述各个运行场景的条件保活概率表示在保持所述应用程序处于后台运行时出现所述各个运行场景的概率；

根据所述历史保活概率、所述各个运行场景的出现概率和所述各个运行场景的条件保活概率计算所述应用程序处于所述各个运行场景的保活概率。

在本申请的一个实施例中，判断模块包括：

概率阈值确定单元，用于根据所述终端设备的系统状态确定保活概率阈值；

判断单元，用于当所述目标应用程序的保活概率大于所述保活概率阈值时，确定需要保持所述目标应用程序在后台运行；当所述目标应用程序的保活概率小于所述保活概率阈值时，确定不需要保持所述目标应用程序在后台运行。

在本申请的一个实施例中，所述概率阈值确定单元具体用于：

确定所述终端设备的系统状态所指示的系统空闲程度；

根据所述系统空闲程度确定所述保活概率阈值，其中，所述系统空闲程序与所述保活概率阈值呈负相关关系。

在本申请的一个实施例中，所述装置还包括：

系统状态检测模块，用于检测所述终端设备的当前系统状态；

异常处理模块，用于若所述当前系统状态指示所述终端设备出现性能异常，则停止执行保持所述目标应用程序在后台运行的操作。

在本申请的一个实施例中，所述装置还包括：

减负模块，用于若确定需要保持所述目标应用程序在后台运行，则执行以下至少一种操作：

根据所述目标应用程序中运行的进程标识，关闭除核心进程之外的其它进程，所述核心进程是用于维持所述目标应用程序在后台运行的进程；

降低所述目标应用程序所占用的内存；

限制所述目标应用程序的网络通讯。

在本申请的一个实施例中，所述装置还包括：

默认保活处理模块，用于若根据所述目标应用程序的保活概率和所述终端设备的系统状态确定不需要保持所述目标应用程序在后台运行，则根据所述终端设备的默认保活策略确定是否保持所述目标应用程序在后台运行。

在本申请的一个实施例中，所述默认保活处理模块具体用于：

检测所述目标应用程序是否为所述默认保活策略指示的应用程序白名单中的应用程序；

若所述目标应用程序是所述应用程序白名单中的应用程序，则执行保持所述目标应用程序在后台运行的操作；

若所述目标应用程序不是所述应用程序白名单中的应用程序，则不执行保持所述目标应用程序在后台运行的操作。

在本申请的一个实施例中，保活模块具体用于：

将所述目标应用程序的运行状态数据存储于内存中；

当检测到所述目标应用程序被切换至前台时，从所述内存获取所述运行状态数据，以根据所述运行状态数据恢复所述目标应用程序的运行状态。

根据本申请实施例的一个方面，提供一种计算机可读介质，其上存储有计算机程序，该计算机程序被处理器执行时实现如以上技术方案中的应用程序的管理方法。

根据本申请实施例的一个方面，提供一种电子设备，该电子设备包括：处理器；以及存储器，用于存储所述处理器的可执行指令；其中，所述处理器执行所述可执行指令使得所述电子设备执行如以上技术方案中的应用程序的管理方法。

根据本申请实施例的一个方面，提供一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行如以上技术方案中的应用程序的管理方法。

在本申请实施例提供的技术方案中，当根据目标应用程序的运行状态确定目标应用程序被切换至后台时，根据目标应用程序的保活概率和终端设备的系统状态确定是否保持目标应用程序在后台运行，充分考虑了目标应用程序本身和终端设备系统负载对保持目标应用程序后台运行的影响，可以实现对不同应用程序保持后台运行的个性化需求，同时也避免保持应用程序后台运行而影响系统性能。若确定需要保持所述目标应用程序在后台运行，则无需关闭目标应用程序，而是执行保持所述目标应用程序在后台运行的操作，相当于延长了目标应用程序的运行时间；那么，在目标应用程序再次被切换至前台时，由于目标应用程序在运行中，就可以快速进入目标应用程序，从而节省了应用程序切换的耗时，提高了应用程序间的切换效率。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本申请。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本申请的实施例，并与说明书一起用于解释本申请的原理。显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1示意性地示出了应用本申请技术方案的示例性系统架构框图。

图2示意性地示出了一种应用本申请技术方案的系统架构框图。

图3示意性地示出了本申请一个实施例提供的应用程序的管理方法的流程图。

图4示意性地示出了本申请一个实施例提供的应用程序的管理方法的流程图。

图5示意性地示出了本申请一个实施例提供的应用程序的管理方法的流程图。

图6示意性地示出了本申请一个实施例提供的应用程序的管理方法的流程图。

图7示意性地示出了本申请实施例提供的应用程序的管理装置的结构框图。

图8示意性地示出了本申请一个实施例提供的应用程序的管理装置的结构框图。

图9示意性示出了适于用来实现本申请实施例的电子设备的计算机系统结构框图。

具体实施方式

现在将参考附图更全面地描述示例实施方式。然而，示例实施方式能够以多种形式实施，且不应被理解为限于在此阐述的范例；相反，提供这些实施方式使得本申请将更加全面和完整，并将示例实施方式的构思全面地传达给本领域的技术人员。

此外，所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多实施例中。在下面的描述中，提供许多具体细节从而给出对本申请的实施例的充分理解。然而，本领域技术人员将意识到，可以实践本申请的技术方案而没有特定细节中的一个或更多，或者可以采用其它的方法、组元、装置、步骤等。在其它情况下，不详细示出或描述公知方法、装置、实现或者操作以避免模糊本申请的各方面。

附图中所示的方框图仅仅是功能实体，不一定必须与物理上独立的实体相对应。即，可以采用软件形式来实现这些功能实体，或在一个或多个硬件模块或集成电路中实现这些功能实体，或在不同网络和/或处理器装置和/或微控制器装置中实现这些功能实体。

附图中所示的流程图仅是示例性说明，不是必须包括所有的内容和操作/步骤，也不是必须按所描述的顺序执行。例如，有的操作/步骤还可以分解，而有的操作/步骤可以合并或部分合并，因此实际执行的顺序有可能根据实际情况改变。

可以理解的是，当本申请以上实施例运用到具体产品或技术中时，相关数据的获取需要获得许可或者同意，且相关数据的收集、使用和处理需要遵守相关国家和地区的相关法律法规和标准。

图1示意性地示出了应用本申请技术方案的示例性系统架构框图。

如图1所示，系统架构100可以包括终端设备110、网络120和服务器130。终端设备110指一类具备丰富人机交互方式、拥有接入互联网能力、通常搭载各种操作系统、具有较强处理能力的设备，可以包括智能手机、平板电脑、笔记本电脑、智能语音交互设备、智能家电、车载终端、掌上游戏主机等等。服务器130可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云计算服务的云服务器。网络120可以是能够在终端设备110和服务器130之间提供通信链路的各种连接类型的通信介质，例如可以是有线通信链路或者无线通信链路。

根据实现需要，本申请实施例中的系统架构可以具有任意数目的终端设备、网络和服务器。例如，服务器130可以是由多个服务器设备组成的服务器群组。另外，本申请实施例提供的技术方案可以应用于终端设备110，也可以应用于服务器130，或者可以由终端设备110和服务器130共同实施，本申请对此不做特殊限定。

举例而言，本申请实施例提供的应用程序的管理方法由终端设备110执行。终端设备110检测自身安装的目标应用程序的运行状态，并获取目标应用程序的保活概率，保活概率用于表示目标应用程序在切换至后台之后继续保持运行的概率；终端设备110可以从服务器130获取目标应用程序的保活概率。接下来，若终端设备110根据运行状态确定目标应用程序被切换至后台，则根据保活概率和终端设备110的系统状态确定是否保持目标应用程序在后台运行。若确定需要保持目标应用程序在后台运行，则终端设备110执行保持目标应用程序在后台运行的操作。

在本申请的一个实施例中，本申请实施例提供的应用程序的管理方法由终端设备110和服务器130共同执行。终端设备110可以将目标应用程序的运行状态发送至服务器130，服务器130根据运行状态确定目标应用程序是否被切换至后台。或者，当终端设备110检测到目标应用程序是否被切换至后台时，向服务器130发送应用程序切换通知，以告知服务器130目标应用程序被切换至后台。当服务器130确定目标应用程序被切换至后台时，根据保活概率和终端设备110的系统状态确定是否保持目标应用程序在后台运行，并生成目标应用程序的运行指示发送至终端设备110。若该运行指示表示需要保持目标应用程序在后台运行，则终端设备110执行保持目标应用程序在后台运行的操作；若该运行指示表示不需要保持目标应用程序在后台运行，则终端设备110不执行保持目标应用程序在后台运行的操作。

图2示意性地示出了一种应用本申请技术方案的系统架构框图。如图2所示，该系统架构可以包括终端设备210、客户端220和服务器230。

终端设备210和服务器230的定义分别与图1所示系统架构中终端设备110和服务器130的定义相同，在此不再赘述。客户端220是指与服务器230相对应，为客户提供本地服务的应用程序，可以安装在终端设备110中。在本申请实施例中，客户端220可以是目标应用程序，也可以是与目标应用程序不同的其他应用程序。例如，目标应用程序为游戏应用程序，客户端220可以是游戏应用程序(或称为游戏客户端)，也可以是为游戏应用程序提供辅助服务的游戏助手应用程序(或称为游戏助手客户端)。

在本申请实施例中，客户端220或终端设备210向服务器230获取目标应用程序的保活概率，或者，服务器230周期性地向客户端220或终端设备210发送目标应用程序的保活概率。客户端220在终端设备210中运行时，实时检测目标应用程序的运行状态。当根据运行状态确定目标应用程序被切换至后台时，客户端220向终端设备210请求获取终端设备210的系统状态。然后客户端220根据目标应用程序的保活概率和终端设备210的系统状态确定目标应用程序是否需要在后台保持运行；若客户端220确定目标应用程序需要在后台保持运行，则向终端设备210发起保持运行的指示，使终端设备210保持目标应用程序在后台运行，避免终端设备210将客户端220关闭。

示例性的，终端设备210中安装有游戏客户端和通信客户端，下面以目标应用程序是游戏客户端为例说明本申请实施例的执行过程。在终端设备210中，首先，游戏客户端被启动，游戏客户端运行于终端设备210的前台；然后，通信客户端被启动，通信客户端运行于终端设备210的前台，游戏客户端被切换至终端设备210的后台。

当游戏客户端根据自身运行状态检测到被切换至后台时，获取终端设备210的系统状态，并根据终端设备210的系统状态和保活概率确定是否需要保持后台运行。其中，保活概率由终端设备210或游戏客户端向服务器230获取，且本申请实施例对保活概率的获取步骤和根据运行状态检测游戏客户端是否被切换至后台的步骤之间的顺序不做限定，即这两个步骤可以同步进行，也可以按顺序进行。终端设备210在向服务器230获取保活概率时，可以同时获取游戏客户端的保活概率和通信客户端的保活概率；当然，也可以仅获取被切换至后台的客户端的保活概率。游戏客户端在向服务器230获取保活概率时，可以仅获取游戏客户端自身的保活概率；当然，也可以同时获取通信客户端的保活概率，并将通信客户端的保活概率发送至终端设备210或通信客户端，以便后续对通信客户端是否保持后台运行进行判断。

当游戏客户端确定需要保持在后台运行时，终端设备210发起保持运行的指示，使终端设备210保持游戏客户端在后台运行，也就是通信客户端运行于终端设备210前台时，游戏客户端继续在终端设备210的后台保持运行。这样，当游戏客户端再次被切换至前台时，可以快速进入游戏客户端，而无需重新启动，方便了客户端之间的切换，节省切换耗时，提高切换效率。

当游戏客户端再次被切换至前台时，通信客户端被切换至后台，此时通信客户端作为目标应用程序，那么通信客户端或终端设备210可以通过本申请实施例提供的应用程序的管理方法确定是否保持通信客户端在后台运行。

下面结合具体实施方式对本申请提供的应用程序的管理方法做出详细说明。

图3示意性地示出了本申请一个实施例提供的应用程序的管理方法的流程图，如图3所示，该方法包括步骤310至步骤340，具体如下：

步骤310、检测终端设备上安装的目标应用程序的运行状态。

具体的，目标应用程序可以是终端设备上安装的任一个应用程序。相对于服务器而言，终端设备上安装的应用程序又称为客户端，例如，终端设备中的游戏应用程序也可以称为游戏客户端，音乐应用程序也可以称为音乐客户端。

目标应用程序的运行状态记录了目标应用程序当前时刻是处于终端设备的前台，还是处于终端设备的后台。终端设备的前台是指可以与终端设备使用者进行交互的页面、可视化页面等；当目标应用程序处于终端设备的前台时，表明终端设备当前显示的是目标应用程序。终端设备的后台是指程序数据运行页面，该页面一般无法对终端设备使用者进行可视化显示，但是可以对系统管理员等程序管理人员进行可视化显示；当目标应用程序处于终端设备的后台时，表明终端设备当前显示的不是目标应用程序。

在本申请的一个实施例中，目标应用程序的运行状态可以通过一状态标识来表示，即，将目标应用程序处于终端设备的前台设置一前台状态标识，将目标应用程序处于终端设备的后台设置一后台状态标识。例如，当目标应用程序处于终端设备的前台，状态标识设为1；当目标应用程序处于终端设备的后台时，状态标识设为0。这样，通过状态标识的变化，就可以检测出目标应用程序运行状态的变化。

步骤320、获取目标应用程序的保活概率，保活概率用于表示目标应用程序在切换至后台之后继续保持运行的概率。

具体的，保活概率表示目标应用程序在切换至后台之后继续保持运行的概率。一般的，目标应用程序在切换至后台之后继续保持运行这一操作又称为保活操作，故而保活概率也就是对目标应用程序进行保活操作的概率。

目标应用程序在切换至后台之后继续保持运行，是为了使目标应用程序在切换至后台之后又切回前台时，能够快速进入目标应用程序。因此，目标应用程序的保活概率实际上也反映了目标应用程序在切换至后台之后又切回前台的概率。一般的，目标应用程序在切换至后台之后又切回前台的概率越大，目标应用程序的保活概率也就越大；反之亦然。

在本申请的一个实施例中，本申请技术方案由终端设备执行，终端设备可以根据目标应用程序的历史运行数据计算得到目标应用程序的保活概率；终端设备也可以向服务器发送保活概率获取请求，然后由服务器根据该保活概率获取请求向终端设备反馈应用程序的保活概率。

在本申请的一个实施例中，目标应用程序的保活概率可以根据目标应用程序的程序标识来获取，程序标识是可以用以区分不同应用程序的标识信息，例如，程序标识可以是应用程序的应用ID(Application ID，APP ID)。可以预先将各个应用程序的程序标识对该应用程序对应的保活概率建立关联关系列表，在获取目标应用程序的保活概率时，根据目标应用程序的程序标识查询该关联关系列表，就可以得到目标应用程序的保活概率。

步骤330、若根据运行状态确定目标应用程序被切换至后台，则根据目标应用程序的保活概率和终端设备的系统状态确定是否保持目标应用程序在后台运行。

具体的，目标应用程序的运行状态反映了目标应用程序是否被切换至后台，例如，通过状态标识的变化可以确定目标应用程序是否被切换至后台，示例性的，状态标识从1变为0，可以确定目标应用程序由前台切换至后台；状态标识从0变为1，可以确定目标应用程序由后台切换至前台。

当确定目标应用程序被切换至后台时，获取终端设备的系统状态，然后根据终端设备的系统状态和目标应用程序的保活概率确定是否保持目标应用程序在后台运行，也就是根据系统状态和保活概率确定是否对目标应用程序进行保活操作。

在本申请的一个实施例中，终端设备的系统状态主要体现终端设备当前运行的负载量，或者体现终端设备系统的忙碌或空闲程度。终端设备的系统状态可以根据终端设备的CPU(Central Processing Unit，中央处理器)、GPU(Graphics Processing Unit，图形处理器)、内存、网络等方面的使用情况来表示。

当终端设备的系统较为忙碌时，终端设备可能无法提供足够的资源来保持目标应用程序在后台运行，或者，保持目标应用程序在后台运行将导致前台运行的应用程序的运行性能下降，这种情况下就不适合保持目标应用程序在后台运行。因此，可以先通过终端设备的系统状态确定是否保持目标应用程序在后台运行。当终端设备的系统状态表示系统较为忙碌时，可以认为不需要保持目标应用程序在后台运行。当终端设备的系统状态表示系统较为空闲时，可以进一步根据目标应用程序的保活概率确定是否保持目标应用程序在后台运行。例如，在终端设备的系统状态表示系统较为空闲时，对于保活概率较小的目标应用程序(如保活概率小于预设概率阈值)，可以认为不需要保持目标应用程序在后台运行；对于保活概率较大的目标应用程序(如保活概率大于预设概率阈值)，可以认为需要保持目标应用程序在后台运行。

在本申请的一个实施例中，可以先根据保活概率初步判断是否保持目标应用程序在后台运行，然后结合终端设备的系统状态进一步判断是否保持目标应用程序在后台运行。例如，当保活概率小于或等于预设阈值时，确定无需保持目标应用程序在后台运行。当保活概率大于预设概率阈值时，若终端设备的系统状态指示系统较为空闲，则确定保持目标应用程序在后台运行；若终端设备的系统状态指示系统较为繁忙，则无需保持目标应用程序在后台运行。

步骤340、若确定需要保持目标应用程序在后台运行，则执行保持目标应用程序在后台运行的操作。

具体的，当根据前述步骤确定需要保持目标应用程序在后台运行时，执行保持目标应用程序在后台运行的操作，也就是使目标应用程序被切换至后台之后，继续保持运行。

在本申请实施例提供的技术方案中，当根据目标应用程序的运行状态确定目标应用程序被切换至后台时，根据目标应用程序的保活概率和终端设备的系统状态确定是否保持目标应用程序在后台运行，充分考虑了目标应用程序本身和终端设备系统负载对保持目标应用程序后台运行的影响，可以实现对不同应用程序保持后台运行的个性化需求，同时也避免保持应用程序后台运行而影响系统性能。若确定需要保持所述目标应用程序在后台运行，则无需关闭目标应用程序，而是执行保持所述目标应用程序在后台运行的操作，相当于延长了目标应用程序的运行时间；那么，在目标应用程序再次被切换至前台时，由于目标应用程序在运行中，就可以快速进入目标应用程序，从而节省了应用程序切换的耗时，提高了应用程序间的切换效率。

图4示意性地示出了本申请一个实施例提供的应用程序的管理方法的流程图，本实施例是对上述实施例的进一步细化。如图4所示，本申请实施例提供的应用程序的管理方法包括步骤401至步骤410，具体如下：

步骤401、检测终端设备上安装的目标应用程序的运行状态。

具体的，运行状态的检测与前述实施例中步骤310相同，在此不再赘述。

步骤402、向服务器发送保活概率获取请求，以获取服务器针对保活概率获取请求反馈的应用程序保活概率列表。

具体的，保活概率获取请求用以向服务器请求获取目标应用程序的保活概率，保活概率获取请求可以是终端设备向服务器发送的，也可以是客户端向服务器发送的。服务器在接收到保活概率获取请求后，针对该请求返回应用程序保活概率列表，应用程序保活概率列表包含了应用程序运行场景的标识信息与保活概率之间的关联关系。

应用程序运行于终端设备时，会有多个运行场景，一个运行场景对应于应用程序的一种功能页面。例如，对于游戏应用程序，有游戏大厅场景、装备设置场景、双人对战场景、多人对战场景等；对于视频应用程序，有应用程序首页场景、视频播放场景、视频详细信息场景、账户登录场景等。运行场景的标识信息则用于唯一标识该运行场景，不同运行场景之间的标识信息不同。

对于同一个目标应用程序，当在运行场景下被切换至后台时，再切回前台的概率是不同的。例如，对于游戏应用程序，一般在双人对战场景切换至后台又切回前台的概率，可能大于在游戏大厅场景切换至后台又切回前台的概率。因此，不同的运行场景具有不同的保活概率，将运行场景的标识信息与保活概率之间建立关联关系，就形成了应用程序保活概率列表。

在本申请实施例中，通过对目标应用程序进行场景划分，为目标应用程序的每一个运行场景设置一保活概率，可以使后续获得的目标应用程序的保活概率更加精确，进而可以提高判断是否保持目标应用程序在后台运行的准确性和精度。

在本申请的一个实施例中，应用程序保活概率列表的生成过程包括：获取终端设备上安装的应用程序的历史运行数据，历史运行数据包括应用程序处于各个运行场景时被切换至后台之后是否再次切换至前台运行的历史数据；根据历史运行数据计算应用程序处于各个运行场景的保活概率；将各个运行场景的标识信息与应用程序处于各个运行场景的保活概率建立关联关系，生成应用程序保活概率列表。

具体而言，就是通过终端设备上应用程序的历史运行数据来计算应用程序各运行场景的保活概率，进而将各运行场景的标识信息与保活概率建立关联关系，形成应用程序保活概率列表。

应用程序的历史运行数据包括应用程序处于各个运行场景时被切换至后台之后是否再次切换至前台运行的历史数据，即包括：应用程序处于各个运行场景时被切换至后台之后再次切换至前台运行的历史数据，以及，应用程序处于各个运行场景时被切换至后台之后未切换至前台运行的历史数据。

在本申请的一个实施例中，由于保持应用程序后台运行，是为了使应用程序再次切换至前台时更加方便，因此，当应用程序处于某运行场景时被切换至后台之后再次切换至前台运行时，可以认为这种情况下需要保持该运行场景在后台运行。为便于描述，将各个运行场景时被切换至后台之后再次切换至前台运行的历史数据简称为各个运行场景的保活数据，将各个运行场景时被切换至后台之后未切换至前台运行的历史数据简称为各个运行场景的非保活数据，将保持运行场景在后台运行简称为对运行场景保活。

那么，一个运行场景对应的保活概率可以是该运行场景的保活数据在该运行场景的应用程序的历史运行数据中的比例。例如，某游戏应用程序共有100条历史运行数据，其中游戏大厅场景对应的保活数据共有30条，则游戏大厅场景对应的保活概率为30％。

在本申请的一个实施例中，各运行场景对应的保活概率的计算方式可以是：对历史运行数据进行统计处理，得到历史保活概率、各个运行场景的出现概率和各个运行场景的条件保活概率；根据历史保活概率、各个运行场景的出现概率和各个运行场景的条件保活概率计算应用程序处于各个运行场景的保活概率。

历史保活概率表示应用程序需要保持后台运行的概率，相当于应用程序的历史运行数据中，保活数据所占比例。例如，某游戏应用程序共有100条历史运行数据，其中有80条数据为切换至后台之后再次切换至前台运行的数据，则该游戏应用程序的历史保活概率为80％。

各个运行场景的出现概率就是指应用程序运行时出现对应运行场景的概率，相当于应用程序的历史运行数据中，各个运行场景所对应数据的占比。例如，某游戏应用程序共有100条历史运行数据，其中有40条数据为游戏大厅场景对应的数据，则游戏大厅场景的出现概率为40％。

各个运行场景的条件保活概率表示在保持应用程序处于后台运行时出现各个运行场景的概率，相当于在应用程序的保活数据中，各个运行场景的数据所占的比例。例如，某游戏应用程序的保活数据为80条数据，其中游戏大厅场景对应的数据为30条，则游戏大厅场景的条件保活概率为37.5％。

在得到上述三个参数后，根据下式计算各个运行场景对应的保活概率：

其中，P(A)为应用程序的历史保活概率；P(Ci)为运行场景Ci的出现概率；P(Ci|A)为运行场景Ci的条件保活概率；P(A|Ci)为运行场景Ci对应的保活概率。

在本申请的一个实施例中，在根据历史运行数据计算各运行场景的保活概率时，可能出现根据上述公式计算所得的保活概率和实际保活概率相差较大的情况，则说明运行场景的划分粒度较粗，应对运行场景进一步细分，得到更加精确的数据。例如，对于游戏大厅场景，可以进一步根据游戏市场进一步细分为：刚进入游戏的场景、完成1个对局的场景、完成2个对局的场景等。这些细分场景各自对应的保活概率可能相差较大，若统一计算，则容易造成较大误差。

例如，在上述实施例中给出的游戏应用程序的历史运行数据中，将进入游戏的场景、完成1个对局的场景和完成2个对局的场景统一作为游戏大厅场景，根据上述公式计算得到游戏大厅场景的保活概率为75％。而对于进入游戏的场景，其对应的历史数据有10条，而保活数据实际上只有1条，则该场景的实际保活概率为10％。显然，实际保活概率10％与计算所得保活概率75％相差较大，因此，需要对游戏大厅场景进一步细分。

步骤403、获取目标应用程序中当前运行场景的标识信息。

具体的，当前运行场景是指目标应用程序被切换至后台时的运行场景，当前运行场景是对目标应用程序进行运行场景划分后得到的各个运行场景中的一种。

步骤404、根据当前运行场景的标识信息在应用程序保活概率列表中进行匹配，得到当前运行场景所对应的保活概率。

步骤405、将当前运行场景所对应的保活概率作为目标应用程序的保活概率。

具体的，在得到当前运行场景的标识信息后，根据该标识信息在应用程序保活概率列表中匹配，找到应用程序保活概率列表中该标识信息对应的保活概率，就得到了当前运行场景所对应的保活概率，且当前运行场景所对应的保活概率就是目标应用程序的保活概率。

步骤406、若根据运行状态确定目标应用程序被切换至后台，则根据终端设备的系统状态确定保活概率阈值。

具体的，在检测到目标应用程序被切换至后台时，要根据应用程序的保活概率判断是否对目标应用程序保活，在首先要确定保活概率阈值。在本申请实施例中，根据终端设备的系统状态来设置保活概率阈值，也就是说，终端设备的系统状态不同，相应的保活概率阈值也不同。

在本申请的一个实施例中，终端设备的系统状态指示了终端设备的系统空闲程度，那么，可以根据系统空闲程度确定保活概率阈值。一般的，系统空闲程序与保活概率阈值呈负相关关系。也就是说，系统空闲程序越高，对应的保活概率阈值越小。这也表明，终端设备的系统空闲程序越高，越能够保持较多的应用程序在后台运行。

示例性的，将终端设备的系统空闲程度划分为10级，其中，第1级表示系统空闲程序最高，第10级表示系统空闲程度最低。系统空闲程度与保活概率阈值的关系如下表1所示。

表1系统空闲程度与保活概率阈值关系表

系统空闲程度	保活概率阈值
		1	5％
2	15％
		3	25％
4	35％
		5	45％
6	55％
		7	65％
8	75％
		9	85％
10	95％

示例性的，根据表1所示，若系统空闲程度为6级，则保活概率阈值为55％。

在确定保活概率阈值后，判断目标应用程序的保活概率与保活概率阈值的大小，若目标应用程序的保活概率大于保活概率阈值，则执行步骤407-408；若目标应用程序的保活概率小于保活概率阈值，则执行步骤409-410。可以理解，目标应用程序的保活概率等于保活概率阈值的情况，可以归类到保活概率大于保活概率阈值和保活概率小于保活概率阈值这两种情况中的任一种。

步骤407、当目标应用程序的保活概率大于保活概率阈值时，确定需要保持目标应用程序在后台运行。

步骤408、若确定需要保持目标应用程序在后台运行，则执行保持目标应用程序在后台运行的操作。

具体的，当目标应用程序的保活概率大于保活概率阈值时，则说明需要对目标应用程序保活，故而执行保持目标应用程序在后台运行的操作。

在本申请实施例中，实现了以下情况对目标应用程序的保活：系统空闲程度较高，但保活概率较低的目标应用程序；以及，系统空闲程度较低，但保活概率较高的目标应用程序。

例如，当系统空闲程度为1级时，只要目标应用程序的保活概率大于5％，就可以对该目标应用程序保活。这是因为，当系统空闲程度较高时，说明系统当前可使用资源较为充足，在此情况下，保持目标应用程序在后台运行并不会影响到在终端设备前台运行的应用程序的性能，同时还可以提高应用程序间的切换效率，没有必要将切换至后台的目标应用程序关闭。

又例如，当系统空闲程度为10级时，只有在目标应用程序的保活概率大于95％时，才对该目标应用程序保活。这是因为，当系统空闲程度较低时，说明系统资源已被大部分占用，此时若随意将切换至后台的目标应用程序保活，可能导致终端设备前台运行的应用程序的性能受到影响，故而提高应用程序的保活要求，即提高保活概率阈值。那么，当目标应用程序具有较高的保活概率时，表明该目标应用程序在被切换至后台之后，有极大可能会被重新切换至前台，为了方便应用程序之间的切换，此时可以对该目标应用程序保活。

由此可见，本申请实施例提供的应用程序的管理方法，在对目标应用程序保活时，综合考虑了终端设备的系统资源使用情况和目标应用程序被切换至后台之后又重新切回前台这两个方面的影响，既能保证在保持目标应用程序在后台运行的情况下不影响终端设备前台运行的应用程序的性能，又能提高应用程序的切换效率。

在本申请的一个实施例中，若确定需要保持目标应用程序在后台运行，则执行以下至少一种操作：根据目标应用程序中运行的进程标识，关闭除核心进程之外的其它进程；降低目标应用程序所占用的内存；限制目标应用程序的网络通讯。

具体而言，目标应用程序的核心进程是用于维持目标应用程序在后台运行的进程，关闭除核心进程外的其他进程，也就是关闭目标应用程序的不必要进程(或线程)。一般的，目标应用程序中的进程是否为核心进程可以通过特定标识来识别，例如，核心进程具有第一标识，非核心进程具有第二标识。例如，当确定保持游戏应用程序在后台运行时，可以将数据采集、辅助线程等非核心线程暂停，降低CPU、GPU负载。

降低应用程序所占用的内存，也就是将目标应用程序切换到后台时不再使用的内存释放，降低目标应用程序整体使用的内存量。

限制目标应用程序的网络通讯，也就是除一些必要的网络通讯外，停止目标应用程序在后台时的不必要网络通讯。例如，除维护网络连接的心跳包、用于游戏场景更新的资源下载等网络通讯外，停止游戏应用程序在后台的其他网络通讯。网络通讯是否必要，也可以通过设置标识来识别。

根据以上技术方案，在确定需要对目标应用程序保活时，通过执行上述至少一种操作，来降低目标应用程序本身的负载，也就减少了保持目标应用程序在后台运行所需的系统资源，从而减轻为了保持目标应用程序在后台运行的系统负担。

在本申请的一个实施例中，在确定需要保持目标应用程序在后台运行时，对目标应用程序保活的一种操作是：将目标应用程序的运行状态数据存储于内存中；当检测到目标应用程序被切换至前台时，从内存获取运行状态数据，以根据运行状态数据恢复目标应用程序的运行状态。

具体的，在确定需要保持目标应用程序在后台运行时，并非直接保持目标应用程序在后台运行，针对内存空间较为充足的终端设备，可以将目标应用程序的运行状态数据存储于内存中。内存数据的恢复速度较快，这样，在检测到目标应用程序再次被切换至前台时，可以从内存中获取对应的运行状态数据，快速恢复目标应用程序被切换前的运行状态，这样就可以快速进入目标应用程序，避免重新加载目标应用程序的较长耗时。

步骤409、当目标应用程序的保活概率小于保活概率阈值时，确定不需要保持目标应用程序在后台运行。

步骤410、限制目标应用程序在后台运行。

具体的，当目标应用程序的保活概率小于保活概率阈值时，表明该目标应用程序被切换至后台之后，不太可能再被切换至前台，那么为了节省系统资源，可以认为不需要保持该目标应用程序在后台运行，也就是限制该目标与应用程序在后台运行，例如，关闭该目标应用程序的进程。

图5示意性地示出了本申请一个实施例提供的应用程序的管理方法的流程图，本实施例是对上述实施例的进一步优化。如图5所示，本申请实施例提供的应用程序的管理方法包括步骤501至步骤512，具体如下：

步骤501、检测终端设备上安装的目标应用程序的运行状态。

步骤502、向服务器发送保活概率获取请求，以获取服务器针对保活概率获取请求反馈的应用程序保活概率列表。

步骤503、获取目标应用程序中当前运行场景的标识信息。

步骤504、根据当前运行场景的标识信息在应用程序保活概率列表中进行匹配，得到当前运行场景所对应的保活概率。

步骤505、将当前运行场景所对应的保活概率作为目标应用程序的保活概率。

步骤506、若根据运行状态确定目标应用程序被切换至后台，则根据终端设备的系统状态确定保活概率阈值。

步骤507、当目标应用程序的保活概率大于保活概率阈值时，确定需要保持目标应用程序在后台运行。

步骤508、若确定需要保持目标应用程序在后台运行，则执行保持目标应用程序在后台运行的操作。

其中，步骤501至步骤508与前述实施例中的步骤401至步骤408相同，在此不再赘述。

步骤509、当目标应用程序的保活概率小于保活概率阈值时，根据所述终端设备的默认保活策略确定是否保持所述目标应用程序在后台运行。

具体的，当根据终端设备的系统状态和目标应用程序的保活概率确定无需对目标应用程序进行保活时，此时可以进一步根据终端设备的默认保活策略判断是否对目标应用程序保活。

在本申请的一个实施例中，终端设备的默认保活策略通过应用程序白名单实施，即，在应用程序白名单中的应用程序，是需要保活的应用程序；应用程序白名单之外的应用程序，是不需要保活的应用程序。那么，目标应用程序是否保活的判断过程为：检测目标应用程序是否为默认保活策略指示的应用程序白名单中的应用程序；若目标应用程序是应用程序白名单中的应用程序，则返回步骤508；若应用程序不是应用程序白名单中的应用程序，则执行步骤510。

在本申请的一个实施例中，默认保活策略还可以根据应用程序的类型设置，例如，对于播放音乐、语音通话或地图导航等类型的应用程序，实行保操作，对于其他类型的应用程序，不进行保活操作。

步骤510、限制目标应用程序在后台运行。

步骤511、检测终端设备的当前系统状态。

具体的，本步骤在步骤508之后，即在执行保持目标应用程序在后台运行的操作后，检测终端设备的当前系统状态，以便根据终端设备的系统状态实时调整对目标应用程序的保活策略。

步骤512、判断当前系统状态是否指示终端设备出现性能异常，若是，则进入步骤510；若否，则返回步骤511。

具体的，当前系统状态指示终端设备出现性能异常时，不对目标应用程序进行保活，即限制目标应用程序在后台运行。终端设备的性能异常如温度过高、前台运行的应用程序出现性能瓶颈(如卡顿、响应变慢等)、系统资源占用快速增加等。

图6示意性地示出了本申请一个实施例提供的应用程序的管理方法的流程图，在本申请实施例中，以游戏客户端610、游戏服务器620和终端设备630为例来说明本申请实施例提供的应用程序的管理方法的实施例过程。

如图6所示，该方法包括：

S0、游戏服务器620定期在后台离线计算各个运行场景对应的保活概率。

具体的，定期可以是每天、每周或其他设定时长等，如游戏服务器620每天凌晨计算保活概率。游戏服务器620可以计算终端设备630上按照的多个应用程序的保活概率，每个应用程序对应多个运行场景。并且，游戏服务器620将运行场景的标识信息与对应的保活概率之间建立关联关系，得到应用程序保活概率列表。可选的，可以针对每个应用程序构建一个应用程序保活概率列表，也可以针对所有的应用程序构建一个应用程序保活概率列表。

本步骤中各个运行场景对应的保活概率的计算方式可以参考前述实施例中步骤420中的相关描述，在此不再赘述。

S1、游戏客户端610启动时，向终端设备630发起请求，确认终端设备630当前系统是否支持保活功能。

具体的，终端设备630当前系统是指终端设备630当前所配置的系统，对于一些系统来说，可能不支持应用程序保活功能，即无法执行保持应用程序在后台运行的操作，则这种情况无法对游戏客户端610进行保活操作。

S2、终端设备630接收到游戏客户端610发起的请求后，向游戏客户端610返回是否支持保活功能的消息。

S3、当终端设备630支持保活功能时，游戏客户端610向游戏服务器620发送保活概率获取请求。

具体的，游戏客户端610向游戏服务器620发起请求，用以获取应用程序保活概率列表。

S4、游戏服务器620响应游戏客户端610的请求，返回应用程序保活概率列表。

具体的，游戏服务器620将前述步骤计算所得到的应用程序保活概率列表返回至游戏客户端610。

S5、当游戏客户端610被切换到后台时，游戏客户端610向终端设备630请求当前系统状态。

具体的，本步骤通过检测游戏客户端610的运行状态来确定游戏客户端610是否被切换至后台，具体可参考前述实施例中步骤310相同，在此不再赘述。

同时，游戏客户端610向终端设备630请求获取终端设备630的系统状态，以便后续根据终端设备630的系统状态判断是否保持游戏客户端610在后台运行。

S6、终端设备630接收到游戏客户端610的请求后，向游戏客户端610返回当前系统状态。

具体的，终端设备630的系统状态包括CPU、GPU、内存、网络等使用情况，可以参考前文描述，在此不再赘述。

S7、游戏客户端610根据当前运行场景对应的保活概率及终端设备630的系统状态确定是否需要进行保活，向终端设备630下发保活指示。

具体的，游戏客户端610根据当前运行场景在前述步骤所获得的应用程序保活概率列表中进行匹配，得到当前运行场景所对应的保活概率。在确定保活概率之后，游戏客户端610根据终端设备630的系统状态所指示的系统空闲程度确定保活概率阈值，然后根据保活概率与保活概率阈值之间的大小关系，判断是否需要保活，具体过程可以参考前文相关步骤的描述，在此不再赘述。

保活指示用以指示终端设备630是否对游戏客户端610保活，其可以指示终端设备630对游戏客户端610保活，也可以指示终端设备630不对游戏客户端610保活。也就是说，无论判断是否保活，均需将判断结果告知终端设备630。

S8、终端设备630确定对游戏客户端610的保活策略。

具体的，当保活指示是对游戏客户端610保活时，终端设备630执行保持游戏客户端610在后台运行的操作；当保活指示是不对游戏客户端610保活时，终端设备630将按照默认保活策略确定是否对游戏客户端610保活。具体过程可以参考前文相关步骤的描述，在此不再赘述。

S9、游戏客户端610记录当前运行场景的实际保活情况并上报游戏服务器620。

具体的，当前运行场景的实际保活情况，是指游戏客户端610在当前运行场景被切换至后台之后，是否又被切换至前台。若游戏客户端610在当前运行场景被切换至后台之后又被切换至前台，则当前运行场景的实际保活情况是需要保活；若游戏客户端610在当前运行场景被切换至后台之后未被切换至前台，则当前运行场景的实际保活情况是无需保活。将当前运行场景的实际保活情况上报游戏服务器620，以便游戏服务器620实时更新该运行场景对应的保活概率。

S10、游戏服务器620对游戏客户端610上报的数据进行记录和整合后响应游戏客户端610。

具体的，游戏服务器620接收到游戏客户端610上报的数据后，对该数据进行记录和整合，然后反馈游戏客户端610相关消息，表明已对游戏客户端610上报的数据进行了记录或其他操作。

S11、终端设备630实时检测系统状态，当出现性能异常时，向游戏客户端610发送停止保活请求。

具体的，在对游戏客户端610进行后台保活之后，终端设备630实时检测系统状态，当系统状态指示终端设备630出现性能异常时，如温度过高、前台运行应用程序出现性能瓶颈等，需要停止游戏客户端610的后台操作，故而向游戏客户端610发送停止保活请求。

S12、游戏客户端610收到停止保活请求后，响应请求，并停止后台运行。

本申请实施例提供的技术方案通过运行场景的保活概率和终端设备630的系统状态来判断是否对游戏客户端610保活，同时在确定保活时适当降低游戏客户端610在后台的资源消耗，实现了客户端使用体验和系统资源消耗之间的平衡。

应当注意，尽管在附图中以特定顺序描述了本申请中方法的各个步骤，但是，这并非要求或者暗示必须按照该特定顺序来执行这些步骤，或是必须执行全部所示的步骤才能实现期望的结果。附加的或备选的，可以省略某些步骤，将多个步骤合并为一个步骤执行，以及/或者将一个步骤分解为多个步骤执行等。

以下介绍本申请的装置实施例，可以用于执行本申请上述实施例中的应用程序的管理方法。图7示意性地示出了本申请实施例提供的应用程序的管理装置的结构框图。如图7所示，本申请实施例提供的应用程序的管理装置包括：

程序状态检测模块710，用于检测终端设备上安装的目标应用程序的运行状态；

数据获取模块720，用于获取所述目标应用程序的保活概率，所述保活概率用于表示所述目标应用程序在切换至后台之后继续保持运行的概率；

判断模块730，用于若根据所述运行状态确定所述目标应用程序被切换至后台，则根据所述目标应用程序的保活概率和所述终端设备的系统状态确定是否保持所述目标应用程序在后台运行；

保活模块740，用于若确定需要保持所述目标应用程序在后台运行，则执行保持所述目标应用程序在后台运行的操作。

在本申请的一个实施例中，数据获取模块720包括：

场景标识获取单元，用以获取所述目标应用程序中当前运行场景的标识信息；

匹配单元，用以根据所述当前运行场景的标识信息在应用程序保活概率列表中进行匹配，得到所述当前运行场景所对应的保活概率，所述应用程序保活概率列表中包含应用程序运行场景的标识信息与保活概率之间的关联关系；

保活概率获取单元，用以将所述当前运行场景所对应的保活概率作为所述目标应用程序的保活概率。

在本申请的一个实施例中，所述装置还包括：

概率列表获取模块，用于向服务器发送保活概率获取请求，以获取所述服务器针对所述保活概率获取请求反馈的所述应用程序保活概率列表。

在本申请的一个实施例中，所述装置还包括：

历史数据获取模块，用于获取所述终端设备上安装的应用程序的历史运行数据，所述历史运行数据包括所述应用程序处于各个运行场景时被切换至后台之后是否再次切换至前台运行的历史数据；

场景概率计算模块，用于根据所述历史运行数据计算所述应用程序处于所述各个运行场景的保活概率；

概率列表构建模块，用于将所述各个运行场景的标识信息与所述应用程序处于所述各个运行场景的保活概率建立关联关系，生成所述应用程序保活概率列表。

在本申请的一个实施例中，所述场景概率计算模块具体用于：

对所述历史运行数据进行统计处理，得到历史保活概率、各个运行场景的出现概率和各个运行场景的条件保活概率；所述历史保活概率表示所述应用程序需要保持后台运行的概率；所述各个运行场景的条件保活概率表示在保持所述应用程序处于后台运行时出现所述各个运行场景的概率；

根据所述历史保活概率、所述各个运行场景的出现概率和所述各个运行场景的条件保活概率计算所述应用程序处于所述各个运行场景的保活概率。

在本申请的一个实施例中，判断模块730包括：

概率阈值确定单元，用于根据所述终端设备的系统状态确定保活概率阈值；

判断单元，用于当所述目标应用程序的保活概率大于所述保活概率阈值时，确定需要保持所述目标应用程序在后台运行；当所述目标应用程序的保活概率小于所述保活概率阈值时，确定不需要保持所述目标应用程序在后台运行。

在本申请的一个实施例中，所述概率阈值确定单元具体用于：

确定所述终端设备的系统状态所指示的系统空闲程度；

根据所述系统空闲程度确定所述保活概率阈值，其中，所述系统空闲程序与所述保活概率阈值呈负相关关系。

在本申请的一个实施例中，所述装置还包括：

系统状态检测模块，用于检测所述终端设备的当前系统状态；

异常处理模块，用于若所述当前系统状态指示所述终端设备出现性能异常，则停止执行保持所述目标应用程序在后台运行的操作。

在本申请的一个实施例中，所述装置还包括：

减负模块，用于若确定需要保持所述目标应用程序在后台运行，则执行以下至少一种操作：

根据所述目标应用程序中运行的进程标识，关闭除核心进程之外的其它进程，所述核心进程是用于维持所述目标应用程序在后台运行的进程；

降低所述目标应用程序所占用的内存；

限制所述目标应用程序的网络通讯。

在本申请的一个实施例中，所述装置还包括：

默认保活处理模块，用于若根据所述目标应用程序的保活概率和所述终端设备的系统状态确定不需要保持所述目标应用程序在后台运行，则根据所述终端设备的默认保活策略确定是否保持所述目标应用程序在后台运行。

在本申请的一个实施例中，所述默认保活处理模块具体用于：

检测所述目标应用程序是否为所述默认保活策略指示的应用程序白名单中的应用程序；

若所述目标应用程序是所述应用程序白名单中的应用程序，则执行保持所述目标应用程序在后台运行的操作；

若所述目标应用程序不是所述应用程序白名单中的应用程序，则不执行保持所述目标应用程序在后台运行的操作。

在本申请的一个实施例中，保活模块740具体用于：

将所述目标应用程序的运行状态数据存储于内存中；

当检测到所述目标应用程序被切换至前台时，从所述内存获取所述运行状态数据，以根据所述运行状态数据恢复所述目标应用程序的运行状态。

本申请各实施例中提供的应用程序的保活装置的具体细节已经在对应的方法实施例中进行了详细的描述，此处不再赘述。

图8示意性地示出了本申请一个实施例提供的应用程序的管理装置的结构框图，如图8所示，该装置包括：游戏客户端810、游戏服务器820和终端设备830。

游戏客户端810包括：服务器通讯模块811、场景识别模块812、保活策略模块813和终端交互模块814。

服务器通讯模块811用于与游戏服务器820通讯，从游戏服务器820获取应用程序保活概率列表，同时，将游戏客户端810的历史运行数据上报给游戏服务器820，以供游戏服务器820计算各运行场景的保活概率。

场景识别模块812用于识别各运行场景的标识信息，特别是当游戏客户端810切换到后台时，识别当前运行场景的标识信息。

保活策略模块813用于根据当前运行场景的标识信息在应用程序保活概率列表进行匹配，以确定当前运行场景对应的保活概率；还用于根据当前运行场景对应的保活概率和终端设备830的系统状态判断是否需要对当前运行场景保活(也就是保持游戏客户端810在后台运行)。

进一步的，保活策略模块813还用于适当降低游戏客户端810在后台运行时的负载，如降低关闭非核心进程、降低内存、限制网络通讯等。

进一步的，保活策略模块813还用于在接收到终端设备830发送的停止保活请求(或接收到终端设备830发送的系统性能异常信息)时，停止保活，主动退出游戏客户端810的运行。

终端交互模块814用于与终端设备830进行通信，如获取终端设备830的系统状态，下发当前运行场景的保活指示，接收终端设备830系统状态异常信息，并通知保活策略模块813停止保活。

游戏服务器820包括：数据存储模块821、客户端通讯模块822和保活概率计算模块823。

数据存储模块821用于接收游戏客户端810的服务器通讯模块811上报的数据，并存储，以供其他模块使用。

客户端通讯模块822用于根据游戏客户端810的请求，下发应用程序保活概率列表给游戏客户端810。

保活概率计算模块823用于根据存储模块的数据，计算各运行场景对应的保活概率，形成应用程序保活概率列表。

终端设备830包括：游戏交互模块831、异常监测模块832和后台进程管理模块833。

游戏交互模块831用于响应游戏客户端810的连接请求，并在游戏客户端810运行过程中保持连接，接收游戏客户端810下发的保活指示，并通知后台进程管理模块833进行保活，同时将保活结果通知游戏客户端810。

异常检测模块用于检测终端设备830的系统状态，当出现温度过高、负载过重、内存紧张等异常情况时通知游戏客户端810停止后台保活。

后台进程管理模块833用于根据游戏交互模块831的保活指示对切换到后台的游戏进程进行保活操作。

图9示意性地示出了用于实现本申请实施例的电子设备的计算机系统结构框图。

需要说明的是，图9示出的电子设备的计算机系统900仅是一个示例，不应对本申请实施例的功能和使用范围带来任何限制。

如图9所示，计算机系统900包括中央处理器901(Central Processing Unit，CPU)，其可以根据存储在只读存储器902(Read-Only Memory，ROM)中的程序或者从存储部分908加载到随机访问存储器903(Random Access Memory，RAM)中的程序而执行各种适当的动作和处理。在随机访问存储器903中，还存储有系统操作所需的各种程序和数据。中央处理器901、在只读存储器902以及随机访问存储器903通过总线904彼此相连。输入/输出接口905(Input/Output接口，即I/O接口)也连接至总线904。

以下部件连接至输入/输出接口905：包括键盘、鼠标等的输入部分906；包括诸如阴极射线管(Cathode Ray Tube，CRT)、液晶显示器(Liquid Crystal Display，LCD)等以及扬声器等的输出部分907；包括硬盘等的存储部分908；以及包括诸如局域网卡、调制解调器等的网络接口卡的通信部分909。通信部分909经由诸如因特网的网络执行通信处理。驱动器910也根据需要连接至输入/输出接口905。可拆卸介质911，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器910上，以便于从其上读出的计算机程序根据需要被安装入存储部分908。

特别地，根据本申请的实施例，各个方法流程图中所描述的过程可以被实现为计算机软件程序。例如，本申请的实施例包括一种计算机程序产品，其包括承载在计算机可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信部分909从网络上被下载和安装，和/或从可拆卸介质911被安装。在该计算机程序被中央处理器901执行时，执行本申请的系统中限定的各种功能。

需要说明的是，本申请实施例所示的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(Erasable Programmable Read Only Memory，EPROM)、闪存、光纤、便携式紧凑磁盘只读存储器(Compact Disc Read-Only Memory，CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本申请中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本申请中，计算机可读信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：无线、有线等等，或者上述的任意合适的组合。

附图中的流程图和框图，图示了按照本申请各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图或流程图中的每个方框、以及框图或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

应当注意，尽管在上文详细描述中提及了用于动作执行的设备的若干模块或者单元，但是这种划分并非强制性的。实际上，根据本申请的实施方式，上文描述的两个或更多模块或者单元的特征和功能可以在一个模块或者单元中具体化。反之，上文描述的一个模块或者单元的特征和功能可以进一步划分为由多个模块或者单元来具体化。

通过以上的实施方式的描述，本领域的技术人员易于理解，这里描述的示例实施方式可以通过软件实现，也可以通过软件结合必要的硬件的方式来实现。因此，根据本申请实施方式的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM，U盘，移动硬盘等)中或网络上，包括若干指令以使得一台计算设备(可以是个人计算机、服务器、触控终端、或者网络设备等)执行根据本申请实施方式的方法。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本申请的其它实施方案。本申请旨在涵盖本申请的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本申请的一般性原理并包括本申请未公开的本技术领域中的公知常识或惯用技术手段。

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

Claims (16)

1.一种应用程序的管理方法，其特征在于，包括：

检测终端设备上安装的目标应用程序的运行状态；

获取所述目标应用程序的保活概率，所述保活概率用于表示所述目标应用程序在切换至后台之后继续保持运行的概率；

若根据所述运行状态确定所述目标应用程序被切换至后台，则根据所述目标应用程序的保活概率和所述终端设备的系统状态确定是否保持所述目标应用程序在后台运行；

若确定需要保持所述目标应用程序在后台运行，则执行保持所述目标应用程序在后台运行的操作。

2.根据权利要求1所述的应用程序的管理方法，其特征在于，获取所述目标应用程序的保活概率，包括：

获取所述目标应用程序中当前运行场景的标识信息；

根据所述当前运行场景的标识信息在应用程序保活概率列表中进行匹配，得到所述当前运行场景所对应的保活概率，所述应用程序保活概率列表中包含应用程序运行场景的标识信息与保活概率之间的关联关系；

将所述当前运行场景所对应的保活概率作为所述目标应用程序的保活概率。

3.根据权利要求2所述的应用程序的管理方法，其特征在于，在根据所述当前运行场景的标识信息在应用程序保活概率列表中进行匹配之前，所述方法还包括：

向服务器发送保活概率获取请求，以获取所述服务器针对所述保活概率获取请求反馈的所述应用程序保活概率列表。

4.根据权利要求2所述的应用程序的管理方法，其特征在于，在获取所述目标应用程序的保活概率之前，所述方法还包括：

获取所述终端设备上安装的应用程序的历史运行数据，所述历史运行数据包括所述应用程序处于各个运行场景时被切换至后台之后是否再次切换至前台运行的历史数据；

根据所述历史运行数据计算所述应用程序处于所述各个运行场景的保活概率；

将所述各个运行场景的标识信息与所述应用程序处于所述各个运行场景的保活概率建立关联关系，生成所述应用程序保活概率列表。

5.根据权利要求4所述的应用程序的管理方法，其特征在于，根据所述历史运行数据计算所述应用程序处于所述各个运行场景的保活概率，包括：

对所述历史运行数据进行统计处理，得到历史保活概率、各个运行场景的出现概率和各个运行场景的条件保活概率；所述历史保活概率表示所述应用程序需要保持后台运行的概率；所述各个运行场景的条件保活概率表示在保持所述应用程序处于后台运行时出现所述各个运行场景的概率；

根据所述历史保活概率、所述各个运行场景的出现概率和所述各个运行场景的条件保活概率计算所述应用程序处于所述各个运行场景的保活概率。

6.根据权利要求1所述的应用程序的管理方法，其特征在于，根据所述目标应用程序的保活概率和所述终端设备的系统状态确定是否保持所述目标应用程序在后台运行，包括：

根据所述终端设备的系统状态确定保活概率阈值；

当所述目标应用程序的保活概率大于所述保活概率阈值时，确定需要保持所述目标应用程序在后台运行；

当所述目标应用程序的保活概率小于所述保活概率阈值时，确定不需要保持所述目标应用程序在后台运行。

7.根据权利要求6所述的应用程序的管理方法，其特征在于，根据所述终端设备的系统状态确定保活概率阈值，包括：

确定所述终端设备的系统状态所指示的系统空闲程度；

根据所述系统空闲程度确定所述保活概率阈值，其中，所述系统空闲程序与所述保活概率阈值呈负相关关系。

8.根据权利要求1所述的应用程序的管理方法，其特征在于，在执行保持所述目标应用程序在后台运行的操作之后，所述方法还包括：

检测所述终端设备的当前系统状态；

若所述当前系统状态指示所述终端设备出现性能异常，则停止执行保持所述目标应用程序在后台运行的操作。

9.根据权利要求1所述的应用程序的管理方法，其特征在于，所述方法还包括：

若确定需要保持所述目标应用程序在后台运行，则执行以下至少一种操作：

根据所述目标应用程序中运行的进程标识，关闭除核心进程之外的其它进程，所述核心进程是用于维持所述目标应用程序在后台运行的进程；

降低所述目标应用程序所占用的内存；

限制所述目标应用程序的网络通讯。

10.根据权利要求1所述的应用程序的管理方法，其特征在于，所述方法还包括：

若根据所述目标应用程序的保活概率和所述终端设备的系统状态确定不需要保持所述目标应用程序在后台运行，则根据所述终端设备的默认保活策略确定是否保持所述目标应用程序在后台运行。

11.根据权利要求10所述的应用程序的管理方法，其特征在于，根据所述终端设备的默认保活策略确定是否保持所述目标应用程序在后台运行，包括：

检测所述目标应用程序是否为所述默认保活策略指示的应用程序白名单中的应用程序；

若所述目标应用程序是所述应用程序白名单中的应用程序，则执行保持所述目标应用程序在后台运行的操作；

若所述目标应用程序不是所述应用程序白名单中的应用程序，则不执行保持所述目标应用程序在后台运行的操作。

12.根据权利要求1-11任一项所述的应用程序的管理方法，其特征在于，执行保持所述目标应用程序在后台运行的操作，包括：

将所述目标应用程序的运行状态数据存储于内存中；

当检测到所述目标应用程序被切换至前台时，从所述内存获取所述运行状态数据，以根据所述运行状态数据恢复所述目标应用程序的运行状态。

13.一种应用程序的管理装置，其特征在于，包括：

程序状态检测模块，用于检测终端设备上安装的目标应用程序的运行状态；

数据获取模块，用于获取所述目标应用程序的保活概率，所述保活概率用于表示所述目标应用程序在切换至后台之后继续保持运行的概率；

判断模块，用于若根据所述运行状态确定所述目标应用程序被切换至后台，则根据所述目标应用程序的保活概率和所述终端设备的系统状态确定是否保持所述目标应用程序在后台运行；

保活模块，用于若确定需要保持所述目标应用程序在后台运行，则执行保持所述目标应用程序在后台运行的操作。

14.一种计算机可读介质，其上存储有计算机程序，其特征在于，该计算机程序被处理器执行时实现权利要求1至12中任意一项所述的应用程序的管理方法。

15.一种电子设备，其特征在于，包括：

处理器；以及

存储器，用于存储所述处理器的可执行指令；

其中，所述处理器执行所述可执行指令使得所述电子设备执行权利要求1至12中任意一项所述的应用程序的管理方法。

16.一种计算机程序产品，其特征在于，所述计算机程序产品包括计算机程序，所述计算机程序存储在计算机可读存储介质中，电子设备的处理器从所述计算机可读存储介质读取并执行所述计算机程序，使得所述电子设备执行如权利要求1至12中任一项所述的应用程序的管理方法。

Images