CN113885944A - 应用程序后台保活的方法、装置和电子设备 - Google Patents

Abstract

本申请实施例提供了一种应用程序后台保活的方法、装置和电子设备，终端设备可以基于切换至后台运行的第一应用程序和运行在前台的第二应用程序的第一关联度，为第一应用程序设置后台保活时长，当第一关联度较小时，第一应用程序的后台保活时长较短，终端设备可以很快挂起第一应用程序，减少第一应用程序的进程对内存的占用，空出的内存可以分配给其他后台保活时长较长的应用程序使用。当第一关联度较大时，第一应用程序的后台保活时长较长，这样当第一应用程序重新切换至前台运行时，终端设备可以在内存中启动第一应用程序，启动效率高，能耗小。

Description

应用程序后台保活的方法、装置和电子设备

技术领域

本申请实施例涉及终端技术，尤其涉及一种应用程序后台保活的方法、装置和电子设备。

背景技术

终端设备中可以安装多个应用程序，用户在使用终端设备的过程中，可以在多个应用程序中进行切换。示例性的，用户使用社交类应用程序一段时间后，可以将社交类应用程序切换至后台，在前台使用视频播放类应用程序。

应用程序运行至后台时，终端设备可以记录应用程序运行在后台的时间。若应用程序运行在后台的时长大于预设时长，则终端设备将该应用程序挂起，即应用程序死亡。

目前，对于所有的应用程序来说，运行在后台的预设时长相同。对于用户经常使用的应用程序来说，应用程序切换至后台后容易被挂起。这样，当用户经常使用的应用程序切换至前台时，终端设备需要重启该应用程序，效率低且能耗大。

发明内容

本申请实施例提供一种应用程序后台保活的方法、装置和电子设备，可以适配于应用程序进行后台保活处理，提高用户体验。

第一方面，本申请实施例提供一种应用程序后台保活的方法，该方法的执行主体可以为终端设备或者终端设备中的芯片，下述以执行主体为终端设备为例进行说明。该方法中，当运行在前台的第一应用程序切换至后台运行时，即终端设备响应于检测到第一应用程序切换至后台运行，终端设备可以基于终端设备中的第一关联度模型，获取所述第一应用程序与运行在前台的第二应用程序的第一关联度。

在一种实施例中，终端设备可以将第一应用程序的标识和第二应用程序的标识输入至第一关联度模型，第一关联度模型可以输出第一应用程序与运行在前台的第二应用程序的第一关联度。其中，所述第一关联度模型是基于所述终端设备所属的用户使用应用程序的第一数据得到的，可以参照第一方面的下述的相关描述。

终端设备可以根据所述第一关联度，获取所述第一应用程序的第一后台保活时长。在一种实施例中，关联度和后台保活时长具有映射关系，终端设备可以基于第一关联度，以及该映射关系，得到第一应用程序的第一后台保活时长。其中，终端设备可以根据所述第一后台保活时长，对所述第一应用程序进行后台保活处理。

本申请实施例中，不同的切换至后台运行的应用程序，应用程序的后台保活时长不同，或者说，相同的后台运行的应用程序，在前台运行的应用程序不同的情况下，切换至后台运行的应用程序的后台保活时长不同。

因此，本申请实施例中，终端设备可以基于切换至后台运行的第一应用程序和运行在前台的第二应用程序的第一关联度，为第一应用程序设置后台保活时长，当第一关联度较小时，第一应用程序的后台保活时长较短，终端设备可以很快挂起第一应用程序，减少第一应用程序的进程对内存的占用，空出的内存可以分配给其他后台保活时长较长的应用程序使用。当第一关联度较大时，第一应用程序的后台保活时长较长，这样当第一应用程序重新切换至前台运行时，终端设备可以在内存中启动第一应用程序，启动效率高，能耗小。

在一种可能的实现方式中，终端设备响应于检测到第一应用程序切换至后台运行，可以将所述第一应用程序的进程缓存在内存中。

具体的，终端设备根据所述第一后台保活时长，对所述第一应用程序进行后台保活处理，可以为：终端设备响应于检测到得到第一应用程序的第一后台保活时长，可以启动定时器，所述计时器的时长为所述第一后台保活时长。

其中，若所述计时器未完成计时之前检测到所述第一应用程序切换至前台运行，则终端设备在所述内存中启动所述第一应用程序的进程，以启动所述第一应用程序。或者，若所述计时器完成计时所述第一应用程序仍处于后台运行，则终端设备挂起所述内存中的所述的第一应用程序的进程，以关闭所述第一应用程序。

如此，对于不同的应用程序，终端设备可以基于用户的使用习惯，对运行在后台的应用程序进行后台保活处理，能够适配于用户的习惯。

下述对终端设备基于终端设备所属的用户使用应用程序的第一数据，训练得到第一关联度模型的过程进行说明：

方式1：

所述第一数据包括：运行在前台的应用程序的顺序，以及应用程序运行在后台的时长。具体的，所述第一数据包括：运行在前台的应用程序的顺序，顺序可以以运行在前台的应用程序的标识进行排序，如应用程序A-应用程序B，应用程序运行在后台的时长可以包括：应用程序的标识，以及应用程序运行在后台的时长的映射关系。其中，电子设备在使用过程中，可以采集第一数据，进而将所述第一数据作为训练数据，更新初始关联度模型，得到所述第一关联度模型。

其一，所述初始关联度模型是基于不同用户使用应用程序的数据得到的。具体的，训练设备可以将不同用户使用应用程序的数据作为训练数据，训练得到初始关联度模型，且将初始关联度模型预置在终端设备中。终端设备可以将终端设备所属的用户使用应用程序的第一数据，输入初始关联度模型，更新训练初始关联度模型，得到第一关联度模型。

其二，初始关联度模型是终端设备基于所述用户使用应用程序的第二数据得到的，所述第二数据的采集时间早于所述第一数据的采集时间。其中，终端设备可以将第二数据作为训练数据，在训练更新预置在终端设备中的关联度模型，进而得到初始关联度模型。

也就是说，训练设备可以将不同用户使用应用程序的数据，作为训练数据，基于网络模型的基本框架，训练得到关联度模型(可以称为初始关联度模型)，预置在终端设备中。终端设备可以基于用户使用应用程序的数据，不断更新训练关联度模型。

示例性的。终端设备可以基于用户使用应用程序的第二数据，更新训练关联度模型，得到初始关联度模型，终端设备可以持续基于用户使用应用程序的第一数据，更新训练初始关联度模型，得到第一关联度模型。

下述对终端设备更新初始关联度模型进行说明：

在初始关联度模型未更新之前，终端设备可以响应于检测到所述第一应用程序切换至后台运行，基于所述初始关联度模型，获取所述第一应用程序与运行在前台的第二应用程序的第二关联度，进而根据所述第二关联度，获取所述第一应用程序的第二后台保活时长，终端设备根据所述第二后台保活时长，对所述第一应用程序进行后台保活处理，可以参照上述第一关联度模型的相关描述。

其中，终端设备可以响应于所述第一数据的采集时长达到预设时长，将采集的所述第一数据作为所述训练数据；或者，终端设备可以响应于所述第二关联度大于或等于预设关联度，将采集的所述第一数据作为所述训练数据；或者，终端设备可以响应于所述第二后台保活时长大于或等于预设后台保活时长，将采集的所述第一数据作为所述训练数据。

本申请实施例中，因为终端设备可以基于用户自己使用应用程序的第一数据训练得到第一关联度模型，因此终端设备根据第一关联度模型得到的第一保活时长，更为适配于用户使用应用程序的习惯。

方式2：

在一种可能的实现方式中，所述第一数据还包括：应用程序切换至后台运行的时间戳。也就是说，终端设备在采集第一数据时，还可以记录应用程序切换至后台运行的时间戳。

在该种实施例中，终端设备在基于第一数据，更新初始关联度模型，得到的第一关联度模型，可以得到对应时刻的第一应用程序与运行在前台的第二应用程序的第一关联度。示例性的，终端设备响应于检测到第一应用程序切换至后台运行，可以基于所述第一关联度模型和当前时刻，获取所述第一关联度。

示例性的，终端设备可以将当前时刻，第一应用程序的标识，以及第二应用程序的标识输入至第一关联度模型，第一关联度模型可以输出第一应用程序与运行在前台的第二应用程序的第一关联度。

本申请实施例中，终端设备训练的第一关联度模型与时间戳相关，因此终端设备根据第一关联度模型得到的应用程序之间的关联度，可以与用户使用应用程序的时间相关，能够更加适配于用户的习惯。

在一种可能的实现方式中，为了减少终端设备的计算量，终端设备可以在基于关联度模型，得到第一应用程序和所述第二应用程序的所述第一关联度后，可以记录在所述第一关联度模型下，所述第一应用程序和所述第二应用程序的所述第一关联度，进而在相同的条件下(如第一应用程序运行在后台，且前台运行的为第二应用程序)，终端设备可以查询记录，得到第一应用程序和所述第二应用程序的所述第一关联度。

或者，在一种实施例中，第三应用程序下载安装后用户还未使用，终端设备并未基于用户使用第三应用程序的数据，训练更新关联度模型。因此，在该种实施例中，终端设备响应于检测到第三应用程序切换至后台运行、前台运行的为所述第二应用程序，且所述第一关联度模型还未更新，将所述第一关联度作为所述第三应用程序和所述第二应用程序的关联度，所述第三应用程序与所述第一应用程序为同一类型的应用程序。

也就是说，终端设备可以将与第三应用程序相同类型的第一应用程序与第二应用程序之间的关联度，作为所述第三应用程序和所述第二应用程序的关联度，不仅可以减少终端设备的计算量，还可以避免终端设备未基于用户使用第三应用程序的数据，更新关联度模型，造成的无法得到第三应用程序和所述第二应用程序的关联度的问题。

第二方面，本申请实施例提供一种应用程序后台保活的装置，该装置可以包括：活动管理服务AMS、进程管理模块，以及模型训练模块。

其中，活动管理服务AMS，用于：

响应于检测到第一应用程序切换至后台运行，基于第一关联度模型，获取所述第一应用程序与运行在前台的第二应用程序的第一关联度，所述第一关联度模型是基于终端设备所属的用户使用应用程序的第一数据得到的；根据所述第一关联度，获取所述第一应用程序的第一后台保活时长，且向进程管理模块同步所述第一后台保活时长。

所述进程管理模块，用于根据所述第一后台保活时长，对所述第一应用程序进行后台保活处理。

在一种可能的实现方式中，进程管理模块，还用于当第一应用程序切换至后台运行时，将所述第一应用程序的进程缓存在内存中。

进程管理模块，还用于：

启动计时器，所述计时器的时长为所述第一后台保活时长，若所述计时器未完成计时之前检测到所述第一应用程序切换至前台运行，则进程管理模块在所述内存中启动所述第一应用程序的进程，以启动所述第一应用程序，若所述计时器完成计时所述第一应用程序仍处于后台运行，则进程管理模块挂起所述内存中的所述的第一应用程序的进程，以关闭所述第一应用程序。

在一种可能的实现方式中，所述第一数据包括：运行在前台的应用程序的顺序，以及应用程序运行在后台的时长。数据采集模块，用于采集所述第一数据。

模型训练模块，用于将所述第一数据作为训练数据，更新初始关联度模型，得到所述第一关联度模型。

其中，数据采集模块可以为模型训练模块或AMS。

在一种可能的实现方式中，所述初始关联度模型是基于所述用户使用应用程序的第二数据得到的，所述第二数据的采集时间早于所述第一数据的采集时间。或者，

所述初始关联度模型是基于不同用户使用应用程序的数据得到的。

在一种可能的实现方式中，AMS，还用于：

响应于检测到所述第一应用程序切换至后台运行，基于所述初始关联度模型，获取所述第一应用程序与运行在前台的第二应用程序的第二关联度。以及，

根据所述第二关联度，获取所述第一应用程序的第二后台保活时长。

相应的，进程管理模块，还用于根据所述第二后台保活时长，对所述第一应用程序进行后台保活处理。

在一种可能的实现方式中，模型训练模块，具体用于响应于所述第一数据的采集时长达到预设时长，将采集的所述第一数据作为所述训练数据。或者，

模型训练模块，具体用于响应于所述第二关联度大于或等于预设关联度，将采集的所述第一数据作为所述训练数据。或者，

模型训练模块，具体用于响应于所述第二后台保活时长大于或等于预设后台保活时长，将采集的所述第一数据作为所述训练数据。

在一种可能的实现方式中，所述第一数据还包括：应用程序切换至后台运行的时间戳。AMS，具体用于基于所述第一关联度模型和当前时刻，获取所述第一关联度。

在一种可能的实现方式中，AMS，还用于：

记录在所述第一关联度模型下，所述第一应用程序和所述第二应用程序的所述第一关联度，以及响应于检测到第三应用程序切换至后台运行、前台运行的为所述第二应用程序，且所述第一关联度模型还未更新，将所述第一关联度作为所述第三应用程序和所述第二应用程序的关联度，所述第三应用程序与所述第一应用程序为同一类型的应用程序。

第三方面，本申请实施例提供一种电子设备，该电子设备可以包括：处理器、存储器。存储器用于存储计算机可执行程序代码，程序代码包括指令；当处理器执行指令时，指令使所述电子设备执行如第一方面中的方法。

第四方面，本申请实施例提供一种电子设备，该电子设备可以为第二方面的应用程序后台保活的装置或第一方面所述的终端设备。该电子设备可以包括用于执行以上第一方面所提供的方法的单元、模块或电路。

第五方面，本申请实施例提供一种包含指令的计算机程序产品，当其在计算机上运行时，使得计算机执行上述第一方面中的方法。

第六方面，本申请实施例提供一种计算机可读存储介质，所述计算机可读存储介质中存储有指令，当其在计算机上运行时，使得计算机执行上述第一方面中的方法。

上述第二方面至第六方面的各可能的实现方式，其有益效果可以参见上述第一方面所带来的有益效果，在此不加赘述。

本申请实施例提供一种应用程序后台保活的方法、装置和电子设备，该方法包括：响应于检测到第一应用程序切换至后台运行，基于第一关联度模型，获取第一应用程序与运行在前台的第二应用程序的第一关联度，第一关联度模型是基于终端设备所属的用户使用应用程序的第一数据得到的；根据第一关联度，获取第一应用程序的第一后台保活时长；根据第一后台保活时长，对第一应用程序进行后台保活处理。本申请实施例中，终端设备可以基于切换至后台运行的第一应用程序和运行在前台的第二应用程序的第一关联度，为第一应用程序设置后台保活时长，当第一关联度较小时，第一应用程序的后台保活时长较短，终端设备可以很快挂起第一应用程序，减少第一应用程序的进程对内存的占用，空出的内存可以分配给其他后台保活时长较长的应用程序使用。当第一关联度较大时，第一应用程序的后台保活时长较长，这样当第一应用程序重新切换至前台运行时，终端设备可以在内存中启动第一应用程序，启动效率高，能耗小。

附图说明

图1为本申请实施例适用的终端设备的一种软件结构框图；

图2为终端设备启动应用程序和管理应用程序进程的一种流程示意图；

图3为终端设备管理应用程序进程的一种示意图；

图4为本申请实施例提供的应用程序后台保活的方法的一种实施例的流程示意图；

图5为本申请实施例提供的应用程序运行的一种示意图；

图6为本申请实施例提供的训练得到第一关联度模型的流程示意图；

图7为本申请实施例提供的应用程序后台保活的方法的另一实施例的流程示意图；

图8为本申请实施例适用的终端设备的另一种软件结构框图；

图9为本申请实施例提供的应用程序后台保活的方法的另一实施例的流程示意图；

图10为本申请实施例适用的终端设备的一种界面示意图；

图11为本申请实施例适用的应用程序后台保活的方法的另一实施例的流程示意图。

具体实施方式

终端设备的软件***可以采用分层架构，事件驱动架构，微核架构，微服务架构，或云架构。本申请实施例以分层架构的软件***为Android***为例，示例性说明终端设备的软件结构。图1为本申请实施例适用的终端设备的一种软件结构框图。分层架构将终端设备的软件***分成若干个层，每一层都有清晰的角色和分工。层与层之间通过软件接口通信。在一些实施例中，可以将Android***分为四层，分别为应用程序层(applications)、应用程序框架层(application framework)、安卓运行时(Android runtime)和***库，以及内核层(kernel)。应理解，图1中示出了本申请实施例中涉及的应用程序层、应用程序框架层和内核层。

应用程序层可以包括一系列应用程序包。如，应用程序层内可以包括：相机，图库，日历，通话，地图，导航，蓝牙，音乐，视频，短信息等应用程序，图1中未示出。在一种实施例中，应用程序层可以包括：安卓***桌面启动器launcher，应理解，launcher可以理解为一个应用程序。Android***的用户界面(user interface，UI)可以统称为launcher，launcher中可以包括：应用程序的图标icon，用户点击终端设备的桌面上的应用程序的icon，可以触发launcher打开该应用程序，以使终端设备显示该应用程序的界面，具体可以参照下述的相关描述。

应用程序框架层为应用程序层的应用程序提供应用编程接口(applicationprogramming interface，API)和编程框架。应用程序框架层包括一些预先定义的函数。示例性的，应用程序框架层可以包括：活动管理服务(activity manager service，AMS)、输入管理服务(input manager service，IMS)(图1中未示出IMS)等。其中，AMS是Android***中的核心服务，主要负责***中四大组件的启动、切换、调度及应用进程的管理和调度等工作，其职责与操作***中的进程管理和调度模块相类似。

当然，应用程序框架层中还可以包括显示策略服务、电源管理服务(powermanager service，PMS)、显示管理服务(display manager service，DMS)、活动管理器、窗口管理器，内容提供器，视图***，电话管理器，资源管理器，通知管理器等，本申请实施例对此不作任何限制。

Android Runtime包括核心库和虚拟机。Android runtime负责安卓***的调度和管理。

核心库包含两部分：一部分是java语言需要调用的功能函数，另一部分是安卓的核心库。

应用程序层和应用程序框架层运行在虚拟机中。虚拟机将应用程序层和应用程序框架层的java文件执行为二进制文件。虚拟机用于执行对象生命周期的管理，堆栈管理，线程管理，安全和异常的管理，以及垃圾回收等功能。

***库可以包括多个功能模块。例如：状态监测服务，表面管理器(surfacemanager)，媒体库(Media Libraries)，三维图形处理库(例如：OpenGL ES)，2D图形引擎(例如：SGL)等。状态监测服务用于根据内核层上报的监测数据确定手机的具体朝向、柔性屏幕的物理状态等。表面管理器用于对显示子***进行管理，并且为多个应用程序提供了2D和3D图层的融合。媒体库支持多种常用的音频，视频格式回放和录制，以及静态图像文件等。媒体库可以支持多种音视频编码格式，例如:MPEG4，H.264，MP3，AAC，AMR，JPG，PNG等。三维图形处理库用于实现三维图形绘图，图像渲染，合成和图层处理等。2D图形引擎是2D绘图的绘图引擎。

内核层是终端设备中处于硬件和软件之间的层。内核层中至少包括硬件的驱动，用于驱动硬件工作。示例性的，内核层中包括显示驱动，传感器驱动，摄像头驱动，音频驱动等，本申请实施例对此不做任何限制。在一种实施例中，参照图1，内核层可以包括进程管理模块，该进程管理模块如可以为低内存管理(low memory killer，LMK)模块，用于管理运行在后台的进程。

本申请中的术语释义：

应用程序运行在前台：终端设备可以显示应用程序的界面。示例性的，应用程序为通话应用，通话应用运行在前台可以理解为：终端设备显示的界面为用户通话的界面。应用程序运行在前台也可以称为：应用程序在前台运行，或应用程序的运行状态为前台运行。

应用程序运行在后台：终端设备的界面显示其他应用程序的界面。在一种实施例中，该其他应用的界面上可以显示切换至应用程序的图标。

示例性的，应用程序为通话应用，通话应用运行在后台可以理解为：终端设备显示其他应用程序的界面，且该其他应用程序的界面上显示有可以切换至通话应用的图标，用户点击该图标，终端设备可以显示通话应用的界面，使得通话应用从后台运行切换至前台运行。应用程序运行在后台也可以称为：应用程序在后台运行，或应用程序的运行状态为后台运行。

应用程序挂起：终端设备挂起内存中缓存的应用程序的进程，即杀掉应用程序，或称为杀掉应用程序的进程，可以参照下述S205中的相关描述。

终端设备中可以安装多个应用程序，终端设备的桌面上可以显示多个应用程序的图标，用户操作一应用程序的图标，可以触发终端设备启动该应用程序，且显示该应用程序的界面。基于图1所示的软件结构，下面首先对终端设备启动一个应用程序，以及应用程序从前台运行切换至后台运行时对进程的管理进行介绍。

参照图2，终端设备启动应用程序的过程可以包括：

S201，launcher向AMS发送启动活动startActivity请求。

launcher为Android***的UI的统称。在一种实施例中，launcher响应于用户点击终端设备的桌面上的应用程序的icon，可以调用启动活动startActivity的方法，调用应用程序框架层中的相关函数，向AMS发送启动活动startActivity请求。startActivity请求用于指示AMS启动应用程序。

S202，AMS启动应用程序的进程，以启动应用程序。

AMS响应于startActivity请求，可以启动应用程序。其中，AMS启动一个应用程序，首先要启动这个应用程序的进程，因此，AMS在启动应用程序时会检查该应用程序的进程是否存在。若应用程序的进程存在，则AMS启动应用程序的进程，以启动应用程序。若应用程序的进程不存在，AMS可以向Zygote进程请求应用程序的进程。

应理解，Zygote进程是Android***中的一个重要的守护进程服务(daemService)。如果每个应用程序在启动时都需要单独运行和初始化一个虚拟机，会大大降低***性能，因此Android***首先创建一个Zygote进程，然后通过Zygote进程孵化出应用程序启动时所需要的虚拟机进程(可以理解为应用程序的进程)，这样大幅度提高应用程序的启动速度。

示例性的，如AMS可以向Zygote进程发送创建应用程序的进程的请求。Zygote进程响应于创建应用程序的进程的请求，可以创建应用程序的进程，并向AMS反馈该应用程序的进程。如此，AMS可以基于Zygote进程反馈的应用程序的进程，启动应用程序的进程，以达到启动应用程序的目的。本申请实施例对Zygote进程创建应用程序的进程的过程不做赘述，可以参照现有技术中的相关说明。

如上介绍了终端设备启动应用程序的过程，下述介绍终端设备对应用程序的进程的管理过程，可以包括：

S203，AMS将应用程序的进程记录在列表中。

AMS可以记录已经启动的应用程序的进程，如AMS可以将已经启动的应用程序的进程记录在ActivityManagerService.mLruProcesses列表中，由AMS进行统一管理。

在一种实施例中，ActivityManagerService.mLruProcesses列表中还可以记录有：应用程序的进程的属性。属性可以包括但不限于：应用程序的进程的启动时刻、应用程序的进程的类别等。应用程序的进程的类别可以包括但不限于：前台进程(foregroundprocess)，可见进程(visible process)，服务进程(service process)，后台进程(background process)，空进程(empty process)等。

S204，AMS设置应用程序的进程的adj值。

AMS可以为应用程序的进程设置对应的adj值，adj值表征应用程序的进程的重要程度。其中，adj值越小，表征应用程序的进程越重要，应用进程的优先级越高。

在一种实施例中，每一类别的进程具有预设的adj值的取值范围。示例性的，前台进程的adj值为0，可见进程的adj值为1，后台进程的adj值的取值范围为9-15。据此，AMS可以基于应用程序的进程预设的adj值的取值范围，为应用程序的进程设置adj值。示例性的，AMS可以设置运行在前台的应用程序的进程的adj值为0。其中，进程的类别和adj值的取值范围，具体可以参照目前低内存管理(low memory killer，LMK)机制中的相关描述。

S205，AMS向进程管理模块同步应用程序的进程的adj值。

AMS在为应用程序的进程设置adj值后，可以向进程管理模块同步应用程序的进程的adj值。进程管理模块响应于接收到来自AMS的应用程序的进程的adj值，可以将应用程序的进程的adj值存储在内核进程列表中。

在一种实施例中，应用程序的进程中包含有界面activity状态等信息，界面activity状态可以包括：可见状态(visible)和不可见状态(invisible)，运行在后台的应用程序的界面为不可见状态。当应用程序从前台运行切换至后台运行时，AMS可以基于应用程序的进程中的界面activity状态，确定应用程序从前台运行切换至后台运行，AMS可以对应调整应用程序的进程的adj值，且将调整后的应用程序的进程的adj值同步至进程管理模块。

示例性的，参照图3中的a，当应用程序A运行在前台时，AMS可以将应用程序A的进程的adj值设置为0，内核进程列表中应用程序A的进程排序在第一位，即具有最高优先级。参照图3中的b，当应用程序A从前台运行切换至后台运行，应用程序B运行在前台时，AMS可以将应用程序A的进程的adj值调整至9-15之间的任意一个值，且设置应用程序B的进程的adj值为0。AMS可以向进程管理模块同步应用程序A的进程的adj值，以及应用程序B的进程的adj值。进程管理模块相应地可以调整内核进程列表。

如图3中的b所示，进程管理模块可以调整内核进程列表，其中，应用程序A的进程的adj值示例性的可以为10，排列在内核进程列表的第二位，应用程序B的进程的adj值为0，排列在内核进程列表的第一位。

S206，进程管理模块基于应用程序的进程的adj值，对应用程序进行后台保活处理。

应理解，出于体验和性能的考虑，应用程序从前台运行切换至后台运行时，进程管理模块并不会立刻挂起或杀掉应用程序的进程，而是将应用程序的进程缓存在内存中，以便于下次启动应用程序时能够在内存中直接启动，而无需按照上述S202中方式启动，因此可以加快应用程序的启动速度。终端设备中打开的应用程序越多，内存中缓存的应用程序的进程也越多。在内存不足的情况下(如内存的剩余空间小于预设空间)，进程管理模块可以依据自身的一套进程回收机制来判断要挂起哪些进程，以释放内存来供给优先级高(即adj值较小)的应用程序的进程运行。

在一种实施例中，进程回收机制可以为LMK机制，LMK机制是基于Linux内核的内存溢出管理(Out-Of-Memory killer，OOM Killer)机制得到的。本申请实施例对低内存管理机制进行简要说明：

在一种实施例中，进程管理模块可以挂起adj值大于阈值的应用程序的进程。其中，AMS可以调用updateOomLevels方法，计算阈值，且将阈值同步至进程管理模块，如此，进程管理模块可以得到阈值。

在一种实施例中，AMS在设置应用程序的进程的adj值后，当应用程序从前台运行切换至后台运行，AMS在设置应用程序的进程的adj值后，AMS还可以基于应用程序运行在后台的时间，实时调整应用程序的进程的adj值，并同步至进程管理模块。其中，应用程序的进程的adj值可以随着应用程序的进程切换至后台的时长逐渐增大，也就是说，应用程序的进程的adj值与应用程序的进程切换至后台的时长为正相关。

示例性的，如上图3中的b所示，应用程序A从前台运行切换至后台运行后，AMS可以将应用程序A的进程的adj值调整为10，且随着应用程序A运行在后台的时间逐渐增大，AMS可以将应用程序A的进程的adj值在10的基础上，逐渐增大至11、12等，且向进程管理模块同步应用程序A的进程的adj值，使得进程管理模块更新内核进程列表中存储的应用程序A的进程的adj值。

如此，随着应用程序的进程运行在后台的时长越长，应用程序的进程的adj值逐渐增大，进程管理模块可以挂起adj值大于阈值的应用程序的进程。换句话说，进程管理模块可以挂起切换至后台的时长大于预设时长的应用程序的进程。对于应用程序来说，应用程序切换至后台运行的时长大于预设时长，进程管理模块可以挂起该应用程序的进程。应理解，预设时长可以理解为：应用程序在后台运行时的保活时长。其中，应用程序在后台运行时的保活时长也可以称为“应用程序的后台保活时长”。

目前，对于所有的应用程序来说，应用程序的后台保活时长是相同的，为一预设值。这样，对于用户常用的应用程序来说，应用程序切换至后台运行时若被挂起，则当用户需求重新使用该应用程序时，AMS需要重新启动该应用程序的进程，效率低且能耗大。若用户重复将常用的应用程序切换至后台运行，导致AMS需要重复多次启动该应用程序的进程，不仅导致该应用程序的启动速度慢、效率低，且还会导致AMS的工作量大。

示例性的，用户常用社交类应用程序，在用户使用社交类应用程序一段时间后，若将社交类应用程序切换至后台运行，在前台使用音频播放类应用程序。当社交类应用程序运行在后台的时长大于预设时长，则进程管理模块可以将该社交类应用程序的进程挂起。若用户重新使用社交类应用程序，AMS需要重新启动社交类应用程序的进程。若用户重复性地将社交类应用程序在前台运行和后台运行之间进行切换，AMS需要频繁重新启动社交类应用程序的进程。

应用程序之间具有关联性，如应用程序A和应用程序B之间具有较高的关联性，即用户在使用应用程序A时也会使用应用程序B，这样应用程序A和应用程序B可以在前台运行和后台运行之间进行切换。那么，当应用程序B切换至后台运行，且应用程序A运行在前台时，用户大概率很快会将应用程序B切换至前台运行。

基于用户的使用应用程序的习惯，以及应用程序之间的关联性，本申请实施例提供一种应用程序后台保活的方法，当应用程序运行至后台时，可以基于前台运行的应用程序和后台运行的应用程序之间的关联性，对后台运行的应用程序设置后台保护时长，如此可以实现对后台运行的不同应用程序设置不同的后台保护时长，如对用户常用的应用程序设置较长的后台保护时长，对用户不常用的应用程序设置较短的保活时长。

这样，一方面可以保证用户常用的应用程序在后台运行时不容易被挂起，当用户重新使用该应用程序时，终端设备在内存中可以快速启动应用程序，提高应用程序启动的效率，且降低终端设备的能耗。另一方面，对于用户不常用的应用程序，当其切换至后台运行时，因为后台保活时长较短，可以很快挂起，可以减少内存的占用，空出的内存可以分配给其他后台保活时长较长的应用程序使用。

应理解，本申请实施例中的终端设备可以称为用户设备(user equipment，UE)、终端(terminal)等，例如，终端设备可以为平板电脑(portable android device，PAD)、个人数字处理(personal digital assistant，PDA)、具有无线通信功能的手持设备、计算设备、车载设备或可穿戴设备，虚拟现实(virtual reality，VR)终端设备、增强现实(augmentedreality，AR)终端设备、工业控制(industrial control)中的无线终端、无人驾驶(selfdriving)中的无线终端、远程医疗(remote medical)中的无线终端、智能电网(smartgrid)中的无线终端、运输安全(transportation safety)中的无线终端、智慧城市(smartcity)中的无线终端、智慧家庭(smart home)中的无线终端等具有触控屏的移动终端或固定终端。本申请实施例中对终端设备的形态不做具体限定。

基于图1中的终端设备的软件结构，下面结合具体的实施例对本申请实施例提供的应用程序后台保活的方法进行说明。下面这几个实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例不再赘述。

图4为本申请实施例提供的应用程序后台保活的方法的一种实施例的流程示意图。参照图4，本申请实施例提供的应用程序后台保活的方法可以包括：

S401，AMS响应于第一应用程序从前台运行切换至后台运行，基于第一关联度模型，获取第一应用程序和运行在前台的第二应用程序的第一关联度。

AMS可以检测应用程序的运行状态，确定应用程序运行在前台还是后台，其中，应用程序的运行状态可以为：前台或后台。在一种实施例中，AMS可以查询应用程序的运行状态的记录，该运行状态记录中存储有应用程序的运行状态的标识，AMS可以基于应用程序的运行状态的标识，确定应用程序的运行状态。

示例性的，AMS可以查询应用程序的运行状态application state的记录，若application state记录的运行状态的标识为“UI Application State Active”，表征应用程序运行在前台，若application state记录的运行状态的标识为“UI Application StateBackground”，表征应用程序运行在后台。

其中，AMS响应于检测到application state记录的运行状态的标识从“UIApplication State Active”调整为“UI Application State Background”，可以确定第一应用程序从前台运行切换至后台运行，则确定第一应用程序的进程的类别从前台进程切换为后台进程。

在一种实施例中，第一应用程序的进程中包含有界面activity状态等信息，界面activity状态可以包括：可见状态(visible)和不可见状态(invisible)，运行在后台的第一应用程序的界面为不可见状态。当第一应用程序从前台运行切换至后台运行时，AMS可以基于应用程序的进程中的界面activity状态，确定应用程序从前台运行切换至后台运行，则确定第一应用程序的进程的类别从前台进程切换为后台进程。

第一关联度模型，用于获取“切换至后台的应用程序”与“运行在前台的应用程序”的关联度，本申请实施例中“切换至后台的应用程序”为第一应用程序，“运行在前台的应用程序”为第二应用程序，第一应用程序与第二应用程序之间的关联度称为第一关联度。应理解，第一关联度模型，可以是以大量用户对应用程序的使用数据为训练数据训练得到的，具体的训练过程可以参照下述图6中的相关描述。在一种实施例中，该第一关联度模型可以称为初始关联度模型。

第一关联度表征第一应用程序和第二应用程序之间的关联性，第一关联度越大，表征第一应用程序和第二应用程序之间的关联性越大，即用户在使用第一应用程序时会使用第二应用程序，用户习惯在第一应用程序和第二应用程序之间进行切换。

示例性的，如第一应用程序为社交类应用程序，第二应用程序为音频播放类应用程序，用户在使用社交类应用程序时，通常会打开音频播放类应用程序，在这两个应用程序之间进行切换。如用户使用社交类应用程序进行社交时，会打开音频播放类应用程序听歌，且可以将音频播放类应用程序切换至后台运行，在前台继续使用社交类应用程序进行社交。用户在前台继续使用社交类应用程序的过程中，可以将社交类应用程序切换至后台运行，且音频播放类应用程序切换至前台运行，如更换歌曲、观看歌曲的MV等。示例性的，在用户通过音频播放类应用程序更换歌曲后，可以将音频播放类应用程序切换至后台运行，将后台运行的社交类应用程序切换至前台运行。这样，用户反复将音频播放类应用程序和社交类应用程序在前台运行和后台运行之间进行切换。

如此，社交类应用程序和音频播放类应用程序的第一关联度较大，若用户切换社交类应用程序至后台运行，当前台运行的应用程序为音频播放类应用程序，则用户很快就会切换社交类应用程序至前台运行。

应理解，该示例中以用户使用两个应用程序为例，本申请实施例中，用户还可以使用三个或三个以上的应用程序。示例性的，当用户同时使用三个应用程序时，运行在后台的每个应用程序均可以称为第一应用程序，运行在前台的应用程序可以称为第二应用程序。

本申请实施例中，AMS响应于第一应用程序从前台运行切换至后台运行，可以基于第一关联度模型，获取第一应用程序和第二应用程序的第一关联度。示例性的，AMS可以将第一应用程序的标识和第二应用程序的标识输入至第一关联度模型中，第一关联度模型可以输出第一关联度。

S402，AMS基于第一关联度，获取第一应用程序的后台保活时长。

第一关联度越大，表征第一应用程序和第二应用程序的关联性越大，说明用户将第一应用程序切换至后台运行后，还会重新将第一应用程序切换至前台运行。因此，若第一应用程序的后台保活时长较小，则第一应用程序切换至后台运行后，进程管理模块很快就会挂起第一应用程序的进程，则AMS响应于第一应用程序从后台运行切换至前台运行，需要重新启动应用程序的进程，启动效率低。而若将第一应用程序设置较大的后台保活时长，则第一应用程序的进程一直存活在内存中未被挂起，则AMS响应于第一应用程序从后台运行切换至前台运行，可以在内存中启动第一应用程序的进程，启动速度快，效率高。

第一应用程序的后台保活时长和第一关联度相关，具体的，第一应用程序的后台保活时长和第一关联度正相关。也就是说，第一关联度越大，第一应用程序的后台保活时长越长，第一关联度越小，第一应用程序的后台保活时长越短。在一种实施例中，第一关联度与第一应用程序的后台保活时长具有第一映射关系，AMS可以基于第一关联度，以及该第一映射关系，获取第一应用程序的后台保活时长。

应理解，第一应用程序的后台保活时长可以理解为：第一应用程序的进程的后台保活时长。

S403，AMS向进程管理模块同步第一应用程序的后台保活时长。

在一种实施例中，AMS可以向进程管理模块同步第一应用程序的后台保活时长，同步方式可以参照AMS向进程管理模块同步应用程序的进程的adj值的方式，如AMS向进程管理模块发送第一应用程序的后台保活时长，具体的，AMS向进程管理模块发送第一应用程序的标识和后台保活时长。

在一种实施例中，第一应用程序的后台保活时长与第一应用程序的进程的adj值相关，具体的，第一应用程序的后台保活时长与第一应用程序的进程的adj值负相关。也就是说，第一应用程序的后台保活时长越长，第一应用程序的进程的adj值越小，第一应用程序的后台保活时长越短，第一应用程序的进程的adj值越大。

在一种实施例中，第一应用程序的后台保活时长与第一应用程序的进程的adj值具有第二映射关系。AMS可以基于第一应用程序的后台保活时长和第二映射关系，获取第一应用程序的进程的adj值，进而将第一应用程序的进程的adj值同步至进程管理模块。应理解，因为应用程序的进程的adj值与后台保活时长相关，因此AMS向进程管理模块同步第一应用程序的进程的adj值，可以理解为：AMS向进程管理模块同步第一应用程序的后台保活时长。

S404，进程管理模块基于第一应用程序的后台保活时长，对第一应用程序进行后台保活处理。

对第一应用程序进行后台保活处理可以理解为：第一应用程序在后台运行的时长达到后台保活时长时，挂起应用程序，或者第一应用程序在后台运行的时长未达到后台保活时长，切换至前台运行时，启动应用程序。

在一种实施例中，进程管理模块响应于来自AMS的第一应用程序的后台保活时长，启动定时器，该定时器的时长为第一应用程序的后台保活时长。进程管理模块可以在启动定时器后，检测第一应用程序的运行状态，进而基于第一应用程序的运行状态，对第一应用程序(或第一应用程序的进程)进行后台保活处理。

运行状态可以包括：前台运行和后台运行。基于上述S401中的相关描述，AMS可以获取第一应用程序的运行状态，在一种实施例中，AMS可以向进程管理模块同步第一应用程序的运行状态，进而进程管理模块可以得到第一应用程序的运行状态。

在一种实施例中，若在定时器倒计时未结束时，第一应用程序从后台运行切换至前台运行，进程管理模块可以关闭定时器，清除定时器中的计时。在该种场景下，AMS也可以检测到第一应用程序从后台运行切换至前台运行，进而在内存中启动第一应用程序的进程。

在一种实施例中，若在定时器倒计时的过程中，第一应用程序的运行状态一直为后台运行，则在定时器倒计时结束时，进程管理模块可以挂起第一应用程序(或第一应用程序的进程)。换句话说，当第一应用程序在后台运行的时长等于后台保活时长时，进程管理模块可以挂起第一应用程序。

示例性的，如关联度为“1-10”，参照图5中的a，终端设备在前台运行社交类应用程序，在后台运行音频播放类应用程序和票务类应用程序，社交类应用程序和音频播放类应用程序的第一关联度为8，社交类应用程序和票务类应用程序的第一关联度为3。相应的，AMS基于第一关联度8，获取音频播放类应用程序的后台保活时长为5分钟，AMS基于第一关联度3，获取票务类应用程序的后台保活时长为1分钟。

参照图5中的b，进程管理模块可以响应于检测到票务类应用程序在后台的运行时长达到1分钟时，挂起内存中的票务类应用程序的进程。参照图5中的b和c，进程管理模块可以响应于检测到音频播放类应用程序在后台运行2分钟时切换至前台运行，AMS可以在内存中启动音频播放类应用程序的进程。

本申请实施例中，针对切换至后台运行的第一应用程序，可以基于第一应用程序和运行在前台的第二应用程序的第一关联度，为第一应用程序设置后台保活时长。当第一关联度较小时，第一应用程序的后台保活时长较短，进程管理模块可以很快挂起第一应用程序，减少第一应用程序的进程对内存的占用，空出的内存可以分配给其他后台保活时长较长的应用程序使用。当第一关联度较大时，第一应用程序的后台保活时长较长，这样当第一应用程序重新切换至前台运行时，AMS可以在内存中启动第一应用程序，启动效率高，能耗小。

第一关联度模型可以为模型训练服务器(或其他服务器)训练得到，且预先设置在终端设备中的，在一种实施例中，第一关联度模型可以预先设置在终端设备中的应用程序框架层，以便于AMS使用。其中，模型训练服务器可以将用户对应用程序的使用数据作为训练数据，输入初始网络模型进行训练，得到第一关联度模型。

应理解，此处用于训练第一关联度模型的训练数据为：不同用户对应用程序的使用数据。其中，第一关联度模型可以称为初始关联度模型，基于初始关联度模型得到的关联度可以称为第二关联度，基于第二关联度获取的后台保活时长可以称为第二后台保活时长。

在一种实施例中，初始网络模型可以但不限于为：卷积神经网络模型(convolutional neural networks，CNN)、循环神经网络模型(recurrent neuralnetwork，RNN)、长短期记忆网络模型(long short-term memory，LSTM)等。下述以初始网络模型为LSTM为例进行说明，LSTM网络模型包括：输入层、至少一个隐含层和输出层。输入层用于接收训练数据，且将训练数据中的数据分发至隐含层的神经元。隐含层的神经元用于根据数据进行计算，且将计算结果输出至输出层。输出层用于输出运算结果。

参照图6，本申请实施例中训练第一关联度模型的方法可以包括：

S601，初始化LSTM网络模型中各隐含层的神经元的权重值。

示例性的，模型训练服务器可以将各隐含层的神经元的权重值初始化成服从高斯分布的随机权重值。

S602，将训练数据分成N个批次。

训练数据可以包括：用户使用应用程序的数据。用户使用应用程序的数据具体可以包括：运行在前台的应用程序的顺序，以及应用程序运行在后台的时长。

以用户使用的应用程序包括：应用程序A、应用程序B、应用程序C，以及应用程序D为例，训练数据可以包括：应用程序运行在前台的顺序，如应用程序A-应用程序C-应用程序A-应用程序C，应用程序A-应用程序B-应用程序C，以及应用程序A-应用程序D等。其中，以“应用程序A-应用程序C-应用程序A-应用程序C”这个顺序为例，应用程序运行在后台的时长可以包括：应用程序C切换至前台运行后，应用程序A在后台运行的时长为1分钟，应用程序A切换至前台运行后，应用程序C运行在后台的时间为5分钟，应用程序C重新切换至前台运行后，应用程序A在后台运行的时长为1分钟。

其中，以应用程序A和应用程序C之前的关联度为例，在应用程序运行在前台的顺序中，越靠近应用程序A的应用程序，与应用程序A之间的关联度越大。当应用程序A从前台运行切换至后台运行时，运行在前台的应用程序C的次数，与应用程序A和应用程序C之间的关联度相关。其中，运行在前台的应用程序C的次数越多，二者之间的关联度越大。

当应用程序A运行在后台，应用程序C运行在前台时，应用程序A运行在后台的时长，与应用程序A和应用程序C之间的关联度相关。其中，应用程序A运行在后台的时长越短，二者之间的关联度越大。

模型训练服务器可以将训练数据分成N个批次，以采用该N个批次的训练数据对LSTM网络模型进行迭代训练。示例性的，模型训练服务器可以按照训练数据的数据量，将训练数据平均分成N个批次。其中，N为大于1的整数。

S603，将第i个批次的训练数据输入LSTM网络模型，得到第i个批次的交叉熵损失。

示例性的，训练开始时，即当i为1时，模型训练服务器将第1个批次的训练数据输入至LSTM网络模型中，LSTM网络模型可以输出第1个批次的训练数据的交叉熵损失(crossentropy loss)。应理解，交叉熵损失用于表征模型训练服务器采用LSTM网络模型预测的应用程序之间的关联度与关联度标签的相似度。其中，关联度标签可以理解为：工作人员预先标定的应用程序之间的关联度。该交叉熵损失越小，表征LSTM网络模型中各隐含层的神经元的权重值越准确。其中，i为大于或等于1且小于或等于N的整数。

S604，根据第i个批次的交叉熵损失，更新LSTM网络模型中各隐含层的神经元的权重值。

示例性的，模型训练服务器可以根据第1个批次的交叉熵损失，更新各隐含层的神经元的初始权重值。模型训练服务器可以根据第1个批次的交叉熵损失，确定采用LSTM网络模型预测的应用程序之间的关联度与关联度标签的相似度与100％之间的误差，进而根据该误差更新各隐含层的神经元的权重值。示例性的，模型训练服务器可以采用梯度下降法(gradient decent)或随机梯度下降法(stochastic gradient decent)更新各隐含层的神经元的权重值。

S605，判断i是否小于N。若是，则将i加1，执行S603。若否，执行S606。

模型训练服务器可以判断i是否小于N，以确定N个批次的训练数据是否训练完成。其中，若i小于N，模型训练服务器可以将i加1，继续执行S603。如，当i为1，N为10时，模型训练服务器确定i小于N，进而将第2个批次的训练数据输入至更新权重值的LSTM网络模型中，得到第2个批次的交叉熵损失。

同理的，模型训练服务器可以根据该第2个批次的交叉熵损失，采用梯度下降法或随机梯度下降法，更新各隐含层的神经元的权重值。如此不断迭代，直至i等于N(如10)时，模型训练服务器将第N个批次的训练数据输入至LSTM网络模型中，且模型训练服务器根据该第N个批次的交叉熵损失更新各隐含层的神经元的权重值。其中，当i等于N时，模型训练服务器可以执行下述S606。

S606，根据目标交叉熵损失和第N个批次的交叉熵损失，确定训练是否收敛。若训练收敛，则执行S607，若训练未收敛，则返回执行S602。

用户可以预先设置目标交叉熵损失作为训练的收敛依据。模型训练服务器在得到第N个批次的交叉熵损失时，可以根据第N个批次的交叉熵损失和目标交叉熵损失，确定训练是否收敛。其中，若第N个批次的交叉熵损失小于或等于目标交叉熵损失，则表征依据采用LSTM网络模型预测的应用程序之间的关联度接近关联度标签，则模型训练服务器可以确定训练收敛。若LSTM网络模型输出的第N个批次的交叉熵损失大于目标交叉熵损失，则确定训练未收敛。当训练未收敛时，模型训练服务器返回执行S602，即继续将训练数据重新分成N个批次，采用N个批次的训练数据对LSTM网络模型继续训练，直至训练收敛。

S607，结束。

若模型训练服务器确定训练收敛，则结束训练，即可得到第一关联度模型。

如上，图6中以初始网络模型为LSTM网络模型为例，基于训练数据得到第一关联度模型。

在一种实施例中，对于不同的用户来说，用户使用应用程序的习惯不同，如用户a习惯同时使用应用程序A和应用程序B，用户b习惯使用应用程序A和应用程序C。若采用如上大数据(不同用户使用应用程序的数据)训练得到的第一关联度模型，预测应用程序之间的关联性，不能很好地适配于每个用户的习惯。据此，本申请实施例中，终端设备可以将用户自身使用应用程序的数据作为训练数据，优化第一关联度模型，进而基于优化后的关联度模型，获取应用程序之间的关联度，可以提高关联度的准确性，还能适配于用户的习惯，提高用户体验。

参照图7，在一种实施例中，本申请实施例提供的应用程序后台保活的方法还可以包括：

S701，模型训练模块基于用户使用应用程序的数据，更新第一关联度模型，得到第二关联度模型。

在一种实施例中，AMS可以记录用户使用应用程序的数据，用户使用应用程序的数据可以包括：运行在前台的应用程序的顺序，以及应用程序运行在后台的时长，可以参照上述的相关描述。其中，因为AMS可以获取应用程序的运行状态，因此AMS可以记录运行在前台的应用程序的顺序，以及应用程序运行在后台的时长。

在一种实施例中，安卓***中的使用状态服务UsageStatsService中可以存储终端设备中各应用程序的使用数据，应用程序的使用数据包括：应用程序的下载时间，应用程序运行在前台的时间、运行在后台的时间等。

如上图1可以替换为图8，在一种实施例中，应用程序框架层还可以包括：模型训练模块。其中，模型训练模块可以从AMS中获取AMS记录的用户使用应用程序的数据，进而将用户使用应用程序的数据作为训练数据，更新第一关联度模型，得到第二关联度模型。

或者，在一种实施例中，模型训练模块可以从使用状态服务中获取各应用程序的使用数据，进而基于各应用程序的使用数据，得到运行在前台的应用程序的顺序，以及应用程序运行在后台的时长，进而将“运行在前台的应用程序的顺序，以及应用程序运行在后台的时长”作为训练数据，优化更新第一关联度模型，得到第二关联度模型。

在一种实施例中，第一关联度模型可以称为初始关联度模型，第二关联度模型可以称为第一关联度模型，其中，用于更新初始关联度模型的数据可以称为第二数据。

在一种实施例中，模型训练模块在训练得到第二关联度模型后，可以将第二关联度模型发送给AMS，应理解，图7中以模型训练模块向AMS发送第二关联度模型为例进行说明。或者，在一种实施例中，模型训练模块在训练得到第二关联度模型后，可以将第二关联度模型替换存储在预设位置的第一关联度模型，AMS可以在该预设位置调用第二关联度模型。在该种实施例中，模型训练模块在预设位置存储第二关联度模型时，可以在该预设位置写入第二关联度模型的存储时间。

S702，AMS响应于第一应用程序从前台运行切换至后台运行，基于第二关联度模型，获取第一应用程序和运行在前台的第二应用程序的第二关联度。

应理解，S702-S705可以参照上述S401-S404的相关描述。

在一种实施例中，S702可以替换为：AMS响应于第一应用程序从前台运行切换至后台运行，若检测到训练第二关联度模型的训练数据中，未包括用户使用第一应用程序的数据，则可以基于第二关联度模型，获取与第一应用程序的类型相同的第三应用程序与第二应用程序的第二关联度，且将该第二关联度作为第一应用程序和第二应用程序的第二关联度。

示例性的，如第一应用程序为音频播放类应用程序1，第二应用程序为社交类应用程序，第三应用程序为音频播放类应用程序2。如，模型训练模块训练得到第二关联度模型时，终端设备还未下载音频播放类应用程序1，因此模型训练模块可以基于用户使用社交类应用程序和音频播放类应用程序2的数据，训练得到第二关联度模型。

其中，安卓***中的使用状态服务中可以存储各应用程序的安装时间，因此AMS可以获取音频播放类应用程序1安装的时间。

在一种实施例中，AMS可以将接收来自模型训练模块的第二关联度模型的时间，作为训练得到第二关联度模型的时间。在一种实施例中，AMS可以在预设位置读取训练得到第二关联度模型时，可以将模型训练模块写入的关联度模型的存储时间作为训练得到第二关联度模型的时间。

另外，AMS中可以存储有相同类型的应用程序的标识，AMS基于第一应用程序和标识和第三应用程序的标识，可以确定第一应用程序和第三应用程序为相同类型的应用程序。

据此，AMS可以基于模型训练模块训练得到第二关联度模型的时间，以及终端设备中安装音频播放类应用程序1的时间，确定训练第二关联度模型的训练数据中，未包括用户使用音频播放类应用程序1的数据。因此，AMS可以将音频播放类应用程序2的标识和社交类应用程序的标识，输入至第二关联度模型，得到音频播放类应用程序2的和社交类应用程序的第二关联度，且将该第二关联度作为音频播放类应用程序1和社交类应用程序的第二关联度。

在一种实施例中，AMS可以记录基于第二关联度模型获取的应用程序之间的第二关联度，得到关联度记录。示例性的，AMS可以记录基于第二关联度模型获取的“第三应用程序和第二应用程序之间的第二关联度”。

在该种实施例中，S702可以替换为：AMS响应于第一应用程序从前台运行切换至后台运行，在关联度记录中查询基于第二关联度模型获取的“与第一应用程序类型相同的应用程序与第二应用程序的第二关联度”，且将该第二关联度作为第一应用程序与第二应用程序的第二关联度。

示例性的，第一应用程序为音频播放类应用程序1，第二应用程序为社交类应用程序，第三应用程序为音频播放类应用程序2。关联度记录中存储有AMS基于第二关联度模型获取的“社交类应用程序与音频播放类应用程序2的第二关联度8”，则AMS响应于音频播放类应用程序1切换至后台，可以确定与音频播放类应用程序1的类型相同的音频播放类应用程序2，且查询关联度记录，可以得到基于第二关联度获取的“音频播放类应用程序2和社交类应用程序”的第二关联度8，AMS可以将该第二关联度8作为“社交类应用程序与音频播放类应用程序1的第二关联度”。

在该种实施例中，AMS可以基于关联度记录获取第二关联度，避免了AMS使用第二关联度模型计算关联度的过程，可以减少AMS的计算量。

S703，AMS基于第二关联度，获取第一应用程序的后台保活时长。

该实施例中，第一应用程序的后台保活时长可以称为第二后台保活时长。

S704，AMS向进程管理模块同步第一应用程序的后台保活时长。

S705，进程管理模块基于第一应用程序的后台保活时长，对第一应用程序进行保活处理。

可以想到的是，模型训练模块在得到第二关联度模型后，可以基于用户自己使用应用程序的数据，继续不断更新第二关联度模型，得到第三关联度模型，以使得得到的关联度模型预测的关联度更为准确，且更为匹配于用户的使用习惯。模型训练模块更新第二关联度模型的方式可以参照模型训练模块更新第二关联度模型的相关描述。

在该实施例中，第二关联度模型相对于第三关联度模型来说，可以称为初始关联度模型，第三关联度模型可以称为第一关联度模型，用于更新初始关联度模型得到第一关联度模型的用户使用应用程序的数据，可以称为第一数据，采用第一关联度模型得到的应用程序之间的关联度可以称为第一关联度，基于第一关联度得到的后台保活时长可以称为第一后台保活时长。

值得注意的是，本申请实施例中，对于更新一次关联度模型来说，可以将更新前的关联度模型称为初始关联度模型，将更新后的关联度模型称为第一关联度模型。

在一种实施例中，模型训练模块更新第一关联度模型(或第二关联度模型)的方式可以但不限于为：周期性更新，条件触发更新等。

其一，周期性更新。

示例性的，模型训练模块可以周期性地从AMS或使用状态服务中，获取用户使用应用程序的数据，并将用户使用应用程序的数据，输入至第一关联度模型中进行训练，更新第一关联度模型，得到第二关联度模型，训练的过程可以参照图6中的相关描述。

也就是说，模型训练模块可以每隔预设时长，从AMS或使用状态服务中，获取用户使用应用程序的数据，以更新第一关联度模型。换句话说，终端设备可以在采集用户使用应用程序的数据达到预设时长时，可以基于采集的用户使用应用程序的数据，更新第一关联度模型。

其二，条件触发更新。

示例性的，参照S702，AMS可以基于第二关联度模型获取应用程序之间的关联度，当预测的关联度大于或等于预设关联度时，可以触发模型训练模块更新第二关联度模型。

或者，AMS基于第二关联度获取后台保活时长，当后台保活时长大于或等于预设后台保活时长值时，可以触发模型训练模块更新第二关联度模型。

本申请实施例中，终端设备可以基于用户自己使用应用程序的数据，更新第一关联度模型，得到第二关联度模型(或者继续更新第二关联度模型)。终端设备可以基于优化后的关联度模型，获取应用程序之间的关联度，可以提高关联度的准确性，据此设置的应用程序的后台保活时长也更加适配于用户的习惯，可以提高用户体验。

在一种实施例中，用户白天使用应用程序的习惯与晚上使用应用程序的习惯不同，或者，用户在工作日和休息日使用应用程序的习惯不同。本申请实施例提供一种应用程序后台保活的方法，可以基于用户使用应用程序的时间，获取第一应用程序和第二应用程序的关联度，能够更加适配于用户的习惯，进一步提高用户体验。

在该种实施例中，模型训练服务器训练得到第一关联度模型时，训练数据中还可以包括：应用程序切换至后台运行的时间戳，以及应用程序切换至前台运行的时间戳。如此，第一关联度模型，可以用于预测不同时刻(或不同时间段)的应用程序的关联度模型。换句话说，第一关联度模型，用于预测不同时刻(或不同时间段)的应用程序之间的第一关联度。应理解，模型训练服器训练得到第一关联度模型的方式与图6中所示的方式相同，区别为训练数据不同。

在一种实施例中，时间戳可以为一天中的时刻，或者可以将一天分为多个时间段，时间戳可以为一天中的一时间段。示例性的，时间段可以为一天中的0:00-12:00，以及12:00至24:00。在一种实施例中，时间戳可以为：一周中的一天，或者一周中的一天中的时刻或时间段，本申请实施例对时间戳不做具体限制。

因为模型训练服务器在训练得到第一关联度模型时，增加了额外的条件“时间戳”，因此在AMS使用第一关联度模型获取第一关联度时，如上S401可以替换为：AMS响应于第一应用程序从前台运行切换至后台运行，获取当前时刻，且基于第一关联度模型，获取第一应用程序和运行在前台的第二应用程序的第一关联度。

应理解，AMS可以将当前时刻、第一应用程序的标识和第二应用程序的标识，输入至第一关联度模型，进而得到第一关联度模型输出的第一关联度。

相应的，S701中，AMS记录用户使用应用程序的数据时，还可以记录时间戳，如应用程序切换至后台运行的时间戳，以及应用程序切换至前台运行的时间戳。据此，模型训练模块从AMS或者使用状态服务获取的数据中，可以包括时间戳。如此，模型训练模块可以基于包含有时间戳的用户使用应用程序的数据，更新第一关联度模型，得到第二关联度模型。

S702可以相应替换为：AMS响应于第一应用程序从前台运行切换至后台运行，获取当前时刻，且基于第二关联度模型，获取第一应用程序和运行在前台的第二应用程序的第二关联度。

示例性的，若第一应用程序从前台运行切换至后台运行的当前时刻为6:00，AMS可以将当前时刻6:00，以及第一应用程序的标识和第二应用程序的标识，输入至第二关联度模型，得到第二关联度，第二关联度可以为8。若第一应用程序从前台运行切换至后台运行的当前时刻为0:00，AMS可以将当前时刻0:00，以及第一应用程序的标识和第二应用程序的标识，输入至第二关联度模型，得到第二关联度，第二关联度可以为3。也就是说，不同时间戳，相同的应用程序之间的关联度不同。

本申请实施例中，AMS可以基于当前时刻，使用第二关联度模型，获取第一应用程序和第二应用程序的第二关联度，第二关联度的准确性更高，由此AMS基于第二关联度得到的第一应用程序的后台保活时长也更加匹配用户的习惯，能够进一步提高用户体验。

在一种实施例中，除了如上AMS基于关联度模型(第一关联度模型、第二关联度模型或第三关联度模型)设置第一应用程序的保活时长外，本申请实施例中，用户可以自主修改应用程序的后台保活时长。

在该种实施例中，参照图9，本申请实施例提供的应用程序后台保活的方法可以包括：

S901，AMS响应于用户设置第一应用程序的后台保活时长为第一时长，存储第一时长。

在一种实施例中，用户可以在第一应用程序的后台启动管理的设置界面，设置第一应用程序的后台保活时长为第一时长。

示例性的，参照图10中的a，用户可以点击终端设备的设置界面101中的“电池”选项10，触发终端设备显示“电池详情”界面102。参照图10中的b，界面102上可以显示终端设备的耗电排行信息，耗电排行信息中包括硬件的耗电排行选项11和软件的耗电排行选项12。硬件的耗电排行选项11中可以包括：屏幕的耗电选项、信号待机的耗电选项，以及蓝牙的耗电选项等，界面102中未示出。软件的耗电排行选项12中可以包括：终端设备中的各应用程序的耗电排行选项，图10中的b中以终端设备中的应用程序包括应用程序A、应用程序B和应用程序C为例进行说明。当用户点击应用程序A的耗电排行选项121时，终端设备可以显示应用程序A的耗电详情界面103。参照图10中的c，界面103上可以包括应用程序A的设置框1211、耗电分析框1212，以及结束运行控件1213，本申请实施例中对设置框1211、耗电分析框1212，以及结束运行控件1213不做赘述。

设置框1211中可以包括：应用启动管理选项12112。当用户点击界面103上的应用启动管理选项12112，终端设备可以显示界面104。参照图10中的d，界面104上显示有应用程序A的启动方式，包括自动管理和手动管理。手动管理中包括：允许自启动、允许关联启动和允许后台活动。其中，允许自启动指的是：应用程序A在开机或运行在后台时可以自启动。允许关联启动指的是：应用程序A可以被其他应用程序启动。允许后台活动指的是：应用程序A可以运行在后台。

在一种实施例中，用户可以在允许后台活动的选择框1041中设置第一应用程序的后台保活时长。示例性的，允许后台活动的选择框1041中包括输入框1042，用户可以在输入框1042中输入第一时长，以设置第一应用程序的后台保活时长。

在一种实施例中，为了保证用户可以输入合适的第一时长，选择框1041中还可以显示有后台保活时长的说明1043，如说明1043可以为“后台保活时长可以设置为0-10分钟”。示例性的，用户可以在输入框1042中输入第一时长为3分钟。

应理解，用户在输入框1042输入第一时长的方式为一种示例，还可以采用其他方式输入第一时长，本申请实施例对此不作限制。

在一种实施例中，launcher响应于检测到用户在输入框1042输入第一时长，可以向AMS发送第一时长。如此，AMS可以确定用户设置的第一应用程序的后台保活时长为第一时长，进而存储第一时长。应理解，上述图10为用户手动设置第一应用程序的后台保活时长的一种示例，本申请实施例对用户手动设置第一应用程序的后台保活时长的方式不做限制。

S902，AMS响应于第一应用程序从前台运行切换至后台运行，向进程管理模块同步第一时长。

S902中AMS向进程管理模块同步第一时长的方式可以参照S403的相关描述。

S903，进程管理模块基于第一时长，对第一应用程序进行保活处理。

本申请实施例中，用户可以自主设置第一应用程序的后台保活时长为第一时长，进程管理模块可以基于第一时长，对在后台运行的第一应用程序进行后台保活处理。因为用户可以基于自身意愿设置应用程序的后台保活时长，可以匹配用户的使用习惯，提高用户体验。

终端设备中包括如上述如图1或图8所示的部件，在一种实施例中，针对终端设备来说，参照图11，本申请实施例提供的应用程序后台保活的方法可以包括：

S1101，响应于检测到第一应用程序切换至后台运行，基于第一关联度模型，获取第一应用程序与运行在前台的第二应用程序的第一关联度，第一关联度模型是基于终端设备所属的用户使用应用程序的第一数据得到的。

S1101可以参照S401中的相关描述，第一关联度模型是终端设备将第一数据作为训练数据训练得到的。应理解，终端设备可以采集第一数据，第一数据包括：运行在前台的应用程序的顺序，以及应用程序运行在后台的时长。

在一种实施例中，终端设备可以将第一数据输入至初始关联度模型，训练得到第一关联度模型，其中，初始关联度模型是基于用户使用应用程序的第二数据得到的，第二数据的采集时间早于第一数据的采集时间；或者，初始关联度模型是训练设备基于不同用户使用应用程序的数据得到的，且预置在终端设备中的。

S1102，根据第一关联度，获取第一应用程序的第一后台保活时长。

S1102可以参照S402中的相关描述。

S1103，根据第一后台保活时长，对第一应用程序进行后台保活处理。

S1103可以参照S403-S404中的相关描述。应理解，当第一应用程序切换至后台运行之后，终端设备可以将第一应用程序的进程缓存在内存中，且启动计时器，计时器的时长为第一后台保活时长。若计时器未完成计时之前检测到第一应用程序切换至前台运行，则终端设备可以在内存中启动第一应用程序的进程，以启动第一应用程序；若计时器完成计时第一应用程序仍处于后台运行，则终端设备可以挂起内存中的第一应用程序的进程，以关闭第一应用程序。

在一种实施例中，第一数据还包括应用程序切换至后台运行的时间戳，这样，终端设备可以基于第一数据，训练得到第一关联度模型。在该种实施例中，上述S1101可以替换为S1101A：响应于检测到第一应用程序切换至后台运行，基于第一关联度模型和当前时刻，获取第一应用程序与运行在前台的第二应用程序的第一关联度。

如此，在该种实施例中，终端设备可以基于用户自己使用应用程序的数据，训练得到第一关联度模型，进而基于该第一关联度模型，可以获取应用程序之间的关联度，据此设置的应用程序的后台保活时长能够适配于用户的习惯，可以提高用户体验。另外，终端设备训练的第一关联度模型还与时间戳相关，因此终端设备基于第一关联度模型得到的应用程序之间的关联度，可以与用户使用应用程序的时间相关，能够更加适配于用户的习惯。

在一种实施例中，本申请实施例还提供一种应用程序后台保活的装置，该装置可以包括：活动管理服务AMS、进程管理模块，以及模型训练模块，可以参照图8所示。

其中，活动管理服务AMS，用于：

响应于检测到第一应用程序切换至后台运行，基于第一关联度模型，获取第一应用程序与运行在前台的第二应用程序的第一关联度，第一关联度模型是基于终端设备所属的用户使用应用程序的第一数据得到的；根据第一关联度，获取第一应用程序的第一后台保活时长，且向进程管理模块同步第一后台保活时长。

进程管理模块，用于根据第一后台保活时长，对第一应用程序进行后台保活处理。

在一种可能的实现方式中，进程管理模块，还用于当第一应用程序切换至后台运行时，将第一应用程序的进程缓存在内存中。

进程管理模块，还用于：

启动计时器，计时器的时长为第一后台保活时长，若计时器未完成计时之前检测到第一应用程序切换至前台运行，则进程管理模块在内存中启动第一应用程序的进程，以启动第一应用程序，若计时器完成计时第一应用程序仍处于后台运行，则进程管理模块挂起内存中的第一应用程序的进程，以关闭第一应用程序。

在一种可能的实现方式中，第一数据包括：运行在前台的应用程序的顺序，以及应用程序运行在后台的时长。数据采集模块，用于采集第一数据。

模型训练模块，用于将第一数据作为训练数据，更新初始关联度模型，得到第一关联度模型。

其中，数据采集模块可以为模型训练模块或AMS。

在一种可能的实现方式中，初始关联度模型是基于用户使用应用程序的第二数据得到的，第二数据的采集时间早于第一数据的采集时间。或者，

初始关联度模型是基于不同用户使用应用程序的数据得到的。

在一种可能的实现方式中，AMS，还用于：

响应于检测到第一应用程序切换至后台运行，基于初始关联度模型，获取第一应用程序与运行在前台的第二应用程序的第二关联度。以及，

根据第二关联度，获取第一应用程序的第二后台保活时长。

相应的，进程管理模块，还用于根据第二后台保活时长，对第一应用程序进行后台保活处理。

在一种可能的实现方式中，模型训练模块，具体用于响应于第一数据的采集时长达到预设时长，将采集的第一数据作为训练数据。或者，

模型训练模块，具体用于响应于第二关联度大于或等于预设关联度，将采集的第一数据作为训练数据。或者，

模型训练模块，具体用于响应于第二后台保活时长大于或等于预设后台保活时长，将采集的第一数据作为训练数据。

在一种可能的实现方式中，第一数据还包括：应用程序切换至后台运行的时间戳。AMS，具体用于基于第一关联度模型和当前时刻，获取第一关联度。

在一种可能的实现方式中，AMS，还用于：

记录在第一关联度模型下，第一应用程序和第二应用程序的第一关联度，以及响应于检测到第三应用程序切换至后台运行、前台运行的为第二应用程序，且第一关联度模型还未更新，将第一关联度作为第三应用程序和第二应用程序的关联度，第三应用程序与第一应用程序为同一类型的应用程序。

在一种实施例中，本申请实施例还提供一种电子设备，该电子设备可以为上述实施例中所述的终端设备，该电子设备中可以包括：处理器(例如CPU)、存储器。存储器可能包含高速随机存取存储器(random-access memory，RAM)，也可能还包括非易失性存储器(non-volatile memory，NVM)，例如至少一个磁盘存储器，存储器中可以存储各种指令，以用于完成各种处理功能以及实现本申请的方法步骤。可选的，本申请涉及的电子设备还可以包括：电源、通信总线以及通信端口。上述通信端口用于实现电子设备与其他外设之间进行连接通信。在本申请实施例中，存储器用于存储计算机可执行程序代码，程序代码包括指令；当处理器执行指令时，指令使电子设备的处理器执行上述方法实施例中的动作，其实现原理和技术效果类似，在此不再赘述。

需要说明的是，上述实施例中所述的模块或部件可以是被配置成实施以上方法的一个或多个集成电路，例如：一个或多个专用集成电路(application specificintegrated circuit，ASIC)，或，一个或多个微处理器(digital signal processor，DSP)，或，一个或者多个现场可编程门阵列(field programmable gate array，FPGA)等。再如，当以上某个模块通过处理元件调度程序代码的形式实现时，该处理元件可以是通用处理器，例如中央处理器(central processing unit，CPU)或其它可以调用程序代码的处理器如控制器。再如，这些模块可以集成在一起，以片上***(system-on-a-chip，SOC)的形式实现。

在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行计算机程序指令时，全部或部分地产生按照本申请实施例的流程或功能。计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，DVD)、或者半导体介质(例如固态硬盘Solid State Disk(SSD))等。

本文中的术语“多个”是指两个或两个以上。本文中术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，本文中字符“/”，一般表示前后关联对象是一种“或”的关系；在公式中，字符“/”，表示前后关联对象是一种“相除”的关系。

另外，需要理解的是，在本申请的描述中，“第一”、“第二”等词汇，仅用于区分描述的目的，而不能理解为指示或暗示相对重要性，也不能理解为指示或暗示顺序。

可以理解的是，在本申请的实施例中涉及的各种数字编号仅为描述方便进行的区分，并不用来限制本申请的实施例的范围。在本申请的实施例中，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请的实施例的实施过程构成任何限定。

Claims (12)

1.一种应用程序后台保活的方法，其特征在于，应用于终端设备，包括：

响应于检测到第一应用程序切换至后台运行，基于第一关联度模型，获取所述第一应用程序与运行在前台的第二应用程序的第一关联度，所述第一关联度模型是基于所述终端设备所属的用户使用应用程序的第一数据得到的；

根据所述第一关联度，获取所述第一应用程序的第一后台保活时长；

根据所述第一后台保活时长，对所述第一应用程序进行后台保活处理。

2.根据权利要求1所述的方法，其特征在于，所述响应于检测到第一应用程序切换至后台运行之后，还包括：

将所述第一应用程序的进程缓存在内存中；

所述根据所述第一后台保活时长，对所述第一应用程序进行后台保活处理，包括：

启动计时器，所述计时器的时长为所述第一后台保活时长；

若所述计时器未完成计时之前检测到所述第一应用程序切换至前台运行，则在所述内存中启动所述第一应用程序的进程，以启动所述第一应用程序；

若所述计时器完成计时所述第一应用程序仍处于后台运行，则挂起所述内存中的所述的第一应用程序的进程，以关闭所述第一应用程序。

3.根据权利要求1或2所述的方法，其特征在于，所述第一数据包括：运行在前台的应用程序的顺序，以及应用程序运行在后台的时长；所述响应于检测到第一应用程序切换至后台运行之前，还包括：

采集所述第一数据；

将所述第一数据作为训练数据，更新初始关联度模型，得到所述第一关联度模型。

4.根据权利要求3所述的方法，其特征在于，所述初始关联度模型是基于所述用户使用应用程序的第二数据得到的，所述第二数据的采集时间早于所述第一数据的采集时间；或者，

所述初始关联度模型是基于不同用户使用应用程序的数据得到的。

5.根据权利要求4所述的方法，其特征在于，所述将所述第一数据作为训练数据之前，还包括：

响应于检测到所述第一应用程序切换至后台运行，基于所述初始关联度模型，获取所述第一应用程序与运行在前台的第二应用程序的第二关联度；

根据所述第二关联度，获取所述第一应用程序的第二后台保活时长；

根据所述第二后台保活时长，对所述第一应用程序进行后台保活处理。

6.根据权利要求5所述的方法，其特征在于，所述将所述第一数据作为训练数据，包括：

响应于所述第一数据的采集时长达到预设时长，将采集的所述第一数据作为所述训练数据；或者，

响应于所述第二关联度大于或等于预设关联度，将采集的所述第一数据作为所述训练数据；或者，

响应于所述第二后台保活时长大于或等于预设后台保活时长，将采集的所述第一数据作为所述训练数据。

7.根据权利要求3-6中任一项所述的方法，其特征在于，所述第一数据还包括：应用程序切换至后台运行的时间戳；所述基于第一关联度模型，获取所述第一应用程序与运行在前台的第二应用程序的第一关联度，包括：

基于所述第一关联度模型和当前时刻，获取所述第一关联度。

8.根据权利要求1-7中任一项所述的方法，其特征在于，所述获取所述第一应用程序与运行在前台的第二应用程序的第一关联度之后，还包括：

记录在所述第一关联度模型下，所述第一应用程序和所述第二应用程序的所述第一关联度；

响应于检测到第三应用程序切换至后台运行、前台运行的为所述第二应用程序，且所述第一关联度模型还未更新，将所述第一关联度作为所述第三应用程序和所述第二应用程序的关联度，所述第三应用程序与所述第一应用程序为同一类型的应用程序。

9.一种应用程序后台保活的装置，其特征在于，

活动管理服务AMS，用于：

响应于检测到第一应用程序切换至后台运行，基于第一关联度模型，获取所述第一应用程序与运行在前台的第二应用程序的第一关联度，所述第一关联度模型是基于终端设备所属的用户使用应用程序的第一数据得到的；

根据所述第一关联度，获取所述第一应用程序的第一后台保活时长，且向进程管理模块同步所述第一后台保活时长；

所述进程管理模块，用于根据所述第一后台保活时长，对所述第一应用程序进行后台保活处理。

10.一种电子设备，其特征在于，包括：处理器和存储器；

所述存储器存储计算机执行指令；

所述处理器执行所述存储器存储的计算机执行指令，使得所述处理器执行如权利要求1-8中任一项所述的方法。

11.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储有计算机程序或指令，当所述计算机程序或指令被运行时，实现如权利要求1-8中任一项所述的方法。

12.一种计算机程序产品，包括计算机程序或指令，其特征在于，所述计算机程序或指令被处理器执行时，实现权利要求1-8中任一项所述的方法。

Images