回收内存的方法及装置与流程

本公开涉及终端技术领域，特别涉及一种回收内存的方法及装置。

背景技术：

随着终端技术的发展，终端可以运行各种各样的进程，进程可以为操作系统的系统进程以及应用的应用进程，其中每个进程在运行过程中会占用一定的内存，在内存中存储自身的数据。随着终端的运行，运行的进程越来越多，占用的内存会越来越多，空闲内存会越来越少，当终端面临空闲内存不满足内存需求的情况时，需要对进程占用的内存进行回收，以保证终端的空闲内存满足内存需求。

以低内存回收(lowmemorykiller，lmk)进程执行回收内存的过程为例，回收内存的过程具体为：lmk进程获取当前每个进程的oom_adj，并获取每个进程占用的内存，其中，oom_adj用于指示进程的优先级，om_adj值越高代表该进程优先级越低，然后根据每个进程的oom_adj和占用的内存，对每个进程打分，得到每个进程的分值。之后，根据每个进程的分值确定要杀死的进程，进程的分值越大，越优先杀死该进程，杀死进程后其关联的进程会关闭，该进程占用的内存会释放，从而回收了该进程占用的内存。其中，oom_adj的取值固定，例如当进程为后台进程时，oom_adj为2，当进程为原生进程时，oom_adj为-17，oom_adj值越大，进程的分值越高，另外，进程占用的内存越大，进程的分值也会越高。

在实现本公开的过程中，发明人发现相关技术至少存在以下问题：

上述方案回收内存时，仅考虑了进程的oom_adj以及进程占用的内存，容易误杀进程，影响进程的正常运行。

技术实现要素：

本公开实施例提供了一种回收内存的方法及装置，能够解决相关技术中容易误杀进程的问题。所述技术方案如下：

第一方面，提供了一种回收内存的方法，所述方法包括：

在检测到空闲内存不满足预设条件时，确定处于后台运行的多个应用进程；

确定所述多个应用进程中每个应用进程在当前时间点所属的时间段的用户偏好度，所述用户偏好度用于指示应用进程被调用的可能性大小；

根据所述多个应用进程中每个应用进程的用户偏好度，确定所述多个应用进程中待回收的应用进程；

回收所述待回收的应用进程占用的内存。

本实施例提供的方法，在回收内存时考虑到了用户的使用习惯，结合每个应用进程的用户偏好度确定待回收的应用进程，进而回收待回收的应用进程所占用的内存，优先回收用户偏好度较低的应用进程所占用的内存，避免回收用户偏好度较高的应用进程所占用的内存，保证回收各个应用进程的内存时顺序的准确性以及合理性，避免误杀进程以及误将应用进程的数据转移至预设存储空间的情况，从而避免影响应用进程的正常运行，保证回收内存的过程对终端的运行造成的整体影响尽量小。

在一种可能的设计中，所述确定所述多个应用进程中每个应用进程在当前时间点所属的时间段的用户偏好度，包括：

根据所述多个应用进程中每个应用进程在历史运行中所述时间段的活跃时长，确定所述多个应用进程中每个应用进程在当前时间点所属的时间段的用户偏好度。

基于本设计，保证回收内存的过程具有时效性：考虑到用户所偏好的应用进程可以随着时间的推移发生变化，例如某用户过去偏好使用微博应用的应用进程，现在偏好使用即时通信应用的应用进程等。本实施例中，并非预先获取了用户对每个应用进程的用户偏好度，而是由终端在回收应用进程占用的内存时，实时根据应用进程最近在历史运行的活跃时长来计算出每个应用进程的用户偏好度，也即是，动态地自学习应用进程的用户偏好度，每次计算出的用户偏好度可以随着时间进行动态变化，则每次回收应用进程占用的内存的顺序也会进行动态变化，例如终端上个月计算用户偏好度时即时通信应用的应用进程的用户偏好度最高，则回收即时通信应用的应用进程的内存的概率最小，这个月计算用户偏好度时音乐播放应用的应用进程的用户偏好度最高，则回收音乐播放应用的应用进程的内存的概率最小。

在一种可能的设计中，所述根据所述多个应用进程中每个应用进程在历史运行中所述时间段的活跃时长，确定所述多个应用进程中每个应用进程在当前时间点所属的时间段的用户偏好度，包括：

将所述活跃时长作为所述用户偏好度。

在这种设计中，终端可以简单有效地得到用户偏好度。

或，计算所述活跃时长与活跃时长总和之间的比值，作为所述用户偏好度，所述活跃时长总和是指所述多个应用进程在历史运行中所述时间段的活跃时长的和值。

在这种设计中，终端可以保证用户偏好度处于合理的数值范围内。

或，计算所述活跃时长与所述应用进程的冷启动时长之间的乘积，作为所述用户偏好度；

在这种设计中，在准确地回收应用进程占用的内存的基础上，兼顾了每个应用进程的冷启动时长，尽量减少对终端造成的整体影响。

或，计算所述活跃时长与活跃时长总和之间的比值，以及计算所述比值与所述应用进程的冷启动时长之间的乘积，作为所述用户偏好度。

在这种设计中，在提供了准确获取用户偏好度的方式的基础上，能够保证用户偏好度处于合理的数值范围内，同时兼顾了应用进程的冷启动时长，保证回收应用进程占用的内存时对终端的整体影响尽量小。

在一种可能的设计中，所述根据所述多个应用进程中每个应用进程的用户偏好度，确定所述多个应用进程中待回收的应用进程，包括：

基于所述多个应用进程中每个应用进程的用户偏好度，获取所述每个应用进程的回收优先级，所述每个应用进程的回收优先级与所述每个应用进程的用户偏好度负相关；

基于所述每个应用进程的回收优先级，确定所述多个应用进程中待回收的应用进程。

在一种可能的设计中，所述基于所述多个应用进程中每个应用进程的用户偏好度，获取所述每个应用进程的回收优先级，包括：

确定所述每个应用进程的最近活跃权重，所述每个应用进程的最近活跃权重用于指示所述每个应用进程最近活跃的程度；

根据所述每个应用进程的用户偏好度与所述每个应用进程的最近活跃权重，获取所述每个应用进程的回收优先级。

在一种可能的设计中，所述确定所述每个应用进程的最近活跃权重，包括：

获取所述每个应用进程的最近活跃时长，所述每个应用进程的最近活跃时长用于指示所述每个应用进程最近一次处于前台运行的活跃时长；

基于所述每个应用进程的最近活跃时长的结束时间点与所述当前时间点之间的时间差，对所述每个应用进程的最近活跃时长进行衰减以得到衰减后的最近活跃时长，将所述衰减后的最近活跃时长作为所述最近活跃权重。

本设计中，通过结合用户偏好度和应用进程的最近活跃权重确定回收优先级，可以进一步提高回收内存的准确性：对于用户偏好度接近的多个应用进程来说，若某个应用进程是最近活跃的应用进程，最近活跃权重会较大，则回收优先级会较低，能避免回收该应用进程的内存，从而尽量避免影响最近活跃的应用进程的正常运行。若某个应用进程是很久之前活跃的应用进程，则最近活跃权重较小，则回收优先级会较高，会优先回收该应用进程的内存，通过优先回收很久以前活跃的应用进程所占用的内存，在实现回收内存的基础上，保证对终端运行的整体影响尽量小。

在一种可能的设计中，所述基于所述多个应用进程中每个应用进程的用户偏好度，获取所述每个应用进程的回收优先级，包括：

确定与所述每个应用进程的功能对应的功能权重，所述每个应用进程的功能权重用于指示所述每个应用进程的功能的重要程度；

根据所述每个应用进程的用户偏好度与所述每个应用进程的功能权重，获取所述每个应用进程的回收优先级。

本设计中，通过结合用户偏好度和功能权重确定回收优先级，可以进一步提高回收内存的准确性：对于用户偏好度接近的多个应用进程来说，若某个应用进程的进程功能较为次要，可以认为该应用进程当前的运行活动对于终端的重要性低，回收该应用进程的内存时造成的影响较小，而结合功能权重确定回收优先级时，回收优先级会较高，终端会优先回收该应用进程的内存，从而尽量减少回收内存对终端造成的整体影响。

在一种可能的设计中，所述基于所述多个应用进程中每个应用进程的用户偏好度，获取所述每个应用进程的回收优先级，包括：

确定与所述每个应用进程的功耗对应的功耗权重，所述每个应用进程的功耗权重用于指示所述每个应用进程的功耗的大小；

根据所述每个应用进程的用户偏好度与所述每个应用进程的功耗权重，获取所述每个应用进程的回收优先级。

本设计中，通过结合用户偏好度和应用进程的功耗确定回收优先级，可以达到以下技术效果：对于用户偏好度接近的多个应用进程来说，若某个应用进程的功耗越大，则功耗权重越大，回收优先级会越高，则终端会优先回收该应用进程占用的内存。通过优先回收功耗大的应用进程占用的内存，在实现回收内存功能的基础上，能够节约终端的功耗。

在一种可能的设计中，所述基于所述多个应用进程中每个应用进程的用户偏好度，获取所述每个应用进程的回收优先级，包括：

确定与所述每个应用进程的内存占比对应的内存占比权重，所述每个应用进程的内存占比用于指示所述每个应用进程占用的内存与总内存开销之间的比值；

根据所述每个应用进程的用户偏好度与所述每个应用进程的内存占比权重，获取所述每个应用进程的回收优先级。

本设计中，通过结合用户偏好度和应用进程的内存占比确定回收优先级，可以进一步提高回收内存的准确性：对于用户偏好度接近的多个应用进程来说，假设某应用进程的内存占比较大，则内存占比权重较大，回收优先级会越高，因此会优先回收该应用进程的内存，能够保证回收的内存较多，保证空闲内存尽量快地满足内存需求。

在一种可能的设计中，所述基于所述多个应用进程中每个应用进程的用户偏好度，获取所述每个应用进程的回收优先级，包括：

确定所述每个应用进程的调用频率，所述每个应用进程的调用频率用于指示所述多个应用进程在历史运行中所述时间段内调用所述每个应用进程的总次数；

根据所述每个应用进程的用户偏好度与所述每个应用进程的调用频率，获取所述每个应用进程的回收优先级。

在一种可能的设计中，所述确定所述每个应用进程的调用频率，包括：

获取所述每个应用进程的调用记录，所述每个应用进程的调用记录用于记录所述每个应用进程调用所述多个应用进程中所述每个应用进程以外的应用进程的事件；

基于所述每个应用进程的调用记录，确定所述每个应用进程的调用频率。

本设计中，通过结合用户偏好度和应用进程的调用频率确定回收优先级，能够保证被频繁调用的应用进程的回收顺序靠后，回收优先级会越低，从而尽量避免回收被频繁调用的应用进程时导致的对其他应用进程的运行造成影响。

在一种可能的设计中，所述确定处于后台运行的多个应用进程之前，所述方法还包括：

统计所述多个应用进程中每个应用进程在历史运行中所述时间段的活跃时长。

基于本设计，保证回收内存的过程贴近用户的个人使用习惯：考虑到日常生活中不同用户所偏好使用的应用进程可能不同，例如用户a偏好使用即时通信应用的应用进程，用户b偏好使用音乐播放应用的应用进程，用户c偏好使用在线购物应用的应用进程等。本实施例中，并非统一地设置了所有用户对应用进程的用户偏好度，而是由终端以自学习的方式，实时统计每个应用进程的活跃时长来分析出每个应用进程的用户偏好度，每个应用进程的用户偏好度能够反映用户的个人使用习惯，因此结合用户偏好度回收内存时能够满足个性化需求，例如用户a的终端回收即时通信应用的应用进程的内存的概率最小，用户b的终端回收音乐播放应用的应用进程的内存的概率最小等等。

在一种可能的设计中，所述回收所述待回收的应用进程占用的内存，包括：

杀死所述待回收的应用进程；或，

将所述待回收的应用进程在内存中的数据转移至预设存储空间。

第二方面，提供了一种回收内存的装置，所述装置包括多个功能模块，以实现上述第一方面以及第一方面的任一种可能设计中的回收内存的方法。

第三方面，提供了一种回收内存的装置，所述回收内存的装置包括：

存储器，用于存储程序；

处理器，用于执行所述存储器存储的所述程序，当所述程序被执行时，所述处理器用于执行如上述第一方面以及第一方面的任一种可能设计中的回收内存的方法。

第四方面，提供了一种计算机可读存储介质，包括指令，当其在计算机上运行时，使得计算机执行如上述第一方面以及第一方面的任一种可能设计中的回收内存的方法。

附图说明

图1是本公开实施例提供的一种回收内存的装置的结构示意图；

图2是本公开实施例提供的一种回收内存的方法的流程图；

图3是本公开实施例提供的一种回收内存的方法的设计示意图；

图4是本公开实施例提供的一种回收内存的装置的结构示意图。

具体实施方式

为使本公开的目的、技术方案和优点更加清楚，下面将结合附图对本公开实施方式作进一步地详细描述。

为了方便理解，下面先对本公开实施例中涉及的名词进行解释：

冷启动：在启动应用时，若后台没有应用的主进程，则终端会创建一个进程并将进程分配给该应用，由该进程作为该应用的主进程，进而启动该应用，这种启动应用的方式称为冷启动。在终端开机后第一次启动应用的场景中，或在之前杀死了应用的主进程后再次启动应用的场景中，应用会以冷启动的方式启动。冷启动应用时，终端要从磁盘读取应用的数据，再将应用的数据写入到内存中，再从内存中加载数据，才能基于数据启动应用，由于将数据从磁盘交换到内存所耗费的时长通常较长，因此冷启动时长通常较长。

热启动：在启动应用时，若后台已有应用关联的主进程，则终端会直接采用该主进程启动应用，这种启动应用的方式称为热启动。在终端开机后已经启动了应用，之后将该应用进程切换为后台运行，再重新将该应用切换为前台运行的场景中，应用会以热启动的方式启动。热启动应用时，终端直接从内存中加载数据即可启动应用，而无需重新将应用的数据从磁盘交换到内存中，因此热启动时长通常较短。

低内存回收(lowmemorykiller，lmk)机制：是linux操作系统的一种内存保护机制，lmk进程会检测终端的空闲内存，当空闲内存小于内存阈值时，获取当前每个进程的oom_adj，并获取每个进程占用的内存，根据每个进程的oom_adj和占用的内存，对每个进程打分，得到每个进程的分值(oom_score_adj)，根据每个进程的分值依次杀死每个进程，已回收进程占用的空闲内存，直到空闲内存不小于内存阈值。

kswapd进程机制：为linux操作系统中的一种内存保护机制，kswapd进程又称页面交换守护进程，同样会检测终端的空闲内存，当空闲内存小于内存阈值时，kswapd进程会扫描内存中已存储数据的每个内存页，当内存页的访问次数较少或者存储时间较早时，会将内存页中的数据转移至zram分区(一种存储空间)中，从而将内存空闲出来，直至空闲内存不小于内存阈值。

内存直接回收(directreclaim)机制：为linux操作系统中的一种内存保护机制，当某进程向操作系统请求内存，而请求的内存超过当前的空闲内存时，该进程会扫描内存中已存储数据的每个内存页，当内存页的访问次数较少或者存储时间较早时，会将内存页中的数据转移至zram分区中，从而将内存空闲出来，直至空闲内存不小于请求的内存。

用户偏好度：用于指示应用进程被调用的可能性大小。应用进程可以由用户或者其他应用进程调用，用户偏好度越高，指示应用被调用的可能性越大，用户偏好度越低，指示应用被调用的可能性越小，用户偏好度能够表征用户对应用进程的偏好程度。对于任一应用进程来说，该应用进程在当前时间点所属的时间段的用户偏好度根据应用进程在历史运行中该时间段的活跃时长确定，例如，假设当前时间点为9:10,所属的时间段为9:00-10:00，则应用进程的用户偏好度根据历史运行中9:00-10:00的活跃时长确定，例如根据应用进程在昨天的9:00-10:00的活跃时长确定，根据应用进程在上个月9:00-10:00的活跃时长确定等。

回收优先级：与用户偏好度负相关，用于表征回收内存时的优先程度，应用进程的回收优先级高，则回收应用进程占用的内存的顺序越靠前，应用进程的回收优先级低，则回收应用进程占用的内存的顺序越靠后。

图1是本公开实施例提供的一种回收内存的装置的结构示意图，参见图1，该回收内存的装置包括：接收器101、发射器102、存储器103和处理器104，该接收器101、该发射器102和该存储器103分别与该处理器104连接，该存储器103存储程序，该处理器104用于执行存储器103存储的程序，当该程序被执行时，处理器104用于执行下述回收内存的方法。

在示例性实施例中，还提供了一种计算机可读存储介质，该计算机可读存储介质包括指令，例如包括指令的存储器，当指令在计算机上运行时，使得计算机可以执行如下述实施例中的回收内存的方法。例如，该计算机可读存储介质可以是只读存储器(read-onlymemory，rom)、随机存取存储器(randomaccessmemory，ram)、cd-rom、磁带、软盘和光数据存储设备等。

本公开实施例引入了一种针对用户的个人使用习惯，以动态自学习的方式获取应用进程的用户偏好度，进而结合用户偏好度来回收内存的策略，可以嵌入现有的linux操作系统以及android(安卓)操作系统中，作为各种操作系统中的一种全新的内存保护机制。本公开实施例可以应用于各种回收内存的场景中，能够对应用进程占用的内存进行回收与管控，保证终端运行的流畅度和响应度。以下以三种示例性场景为例进行阐述：

场景一、lmk机制。当lmk进程检测到空闲内存小于内存阈值时，终端可以采用本公开实施例提供的方法，确定每个处于后台运行的应用进程的用户偏好度，进而确定出待回收的应用进程，将待回收的应用进程提供给lmk进程，lmk进程可以杀掉待回收的应用进程，从而回收待回收的应用进程占用的内存。

在该场景中，lmk进程会优先杀用户偏好度较低的应用进程，在空闲内存不小于内存阈值时即停止杀进程，降低了杀掉用户频繁使用的应用进程的概率，从而避免了误杀应用进程，也就避免影响到用户频繁使用的应用进程的运行，保证终端运行的流畅度。

场景二、kswapd进程机制。当kswapd进程检测到空闲内存小于内存阈值时，终端可以采用本公开实施例提供的方法，确定每个处于后台运行的应用进程的用户偏好度，进而确定出待回收的应用进程，将待回收的应用进程提供给kswapd进程，kswapd进程会将待回收的应用进程在内存中的数据转移至预设存储空间中，以回收应用进程占用的内存。

在该场景中，kswapd进程会优先将用户偏好度较低的应用进程在内存中的数据转移至预设存储空间，在空闲内存不小于内存阈值时即停止转移数据的过程，因此降低了kswapd进程将用户频繁使用的应用进程在内存中的数据转移至预设存储空间的概率，也就避免影响到用户频繁使用的应用进程的运行，保证终端运行的流畅度。

场景三、内存直接回收机制。当任一进程向终端请求内存，而请求的内存超过空闲内存时，终端可以采用本公开实施例提供的方法，确定每个处于后台运行的应用进程的用户偏好度，进而确定出待回收的应用进程，将待回收的应用进程提供给该请求内存的进程，该请求内存的进程会将待回收的应用进程在内存中的数据转移至预设存储空间中，以回收应用进程占用的内存。

在该场景中，请求内存的进程会优先将用户偏好度较低的应用进程在内存中的数据转移至预设存储空间，在空闲内存超过请求的内存时即停止转移数据的过程，因此降低了将用户频繁使用的应用进程在内存中的数据转移至预设存储空间的概率，也就避免影响到用户频繁使用的应用进程的运行，保证终端运行的流畅度。

图2是本公开实施例提供的一种回收内存的方法的流程图，如图2所示，该方法的执行主体为终端，该终端可以为手机、平板电脑等，该方法包括以下步骤：

201、终端统计多个应用进程中每个应用进程在历史运行中每个时间段的活跃时长。

活跃时长：活跃时长是指应用进程处于前台运行的时长。每当某一应用进程某次处于前台运行时，终端可以记录活跃时长：当应用进程开始处于前台运行时，终端可以记录当前时间点，作为活跃时长的开始时间点，当应用进程结束处于前台运行时，终端可以记录当前时间点，作为活跃时长的结束时间点，计算该结束时间点和开始时间点之间的时间差，得到该应用进程本次处于前台运行的活跃时长。例如当应用进程9:00开始在前台运行，9:10时结束在前台运行时，记录活跃时长为10min。

时间段：时间段可以预先对一天划分得到，例如时间段可以包括早上对应的时间段、中午对应的时间段或晚上对应的时间段，每个时间段的时长可以为8小时。

可选地，时间段可以根据用户的生理作息确定，可以将发生某一生理作息行为的时间段作为时间段，例如，可以将午饭时间段作为一个时间段，将晚饭时间段作为一个时间段，将临睡时间段作为一个时间段等等，通过这种确定时间段的方式，可以提高用户偏好度的时效性，其技术效果的详细阐述参见以下步骤204。

统计活跃时长的具体方式：终端可以每当开始进入任一时间段，即当前时间点为时间段的起始点时，从零开始累计每个应用进程的活跃时长，当离开时间段，即当前时间点为时间段的结束点时，结束累计每个应用进程在该时间段的活跃时长，存储该时间段内每个应用进程累计的活跃时长，并开始下一次的统计过程，再次从零开始累计，依次类推。其中，针对每个时间段内累计活跃时长的过程，在每个时间段内每个应用进程可以活跃一次或多次，当应用进程在每个时间段内第一次活跃时，可以从零开始记录该应用进程的活跃时长，直至应用进程暂停活跃，而当应用进程第二次活跃至第n次活跃时，可以在已记录的该时间段内该应用进程的活跃时长的基础上增加本次活跃的活跃时长。

示例性地，假设当前时间点进入时间段8:00-10:00时，若应用进程a第一次活跃，活跃了5分钟，则此时应用进程a的活跃时长为5分钟，若应用进程a第二次活跃，活跃了10分钟，则此时应用进程a的活跃时长为5+10＝15分钟，若应用进程a第三次活跃,活跃了8分钟，则此时应用进程a的活跃时长为15+8＝23分钟，而在当前时间点达到10:00,进入下一时间段10:00-13:00时，应用进程a的活跃时长会重新从0开始统计。

可选地，每当终端获取某应用进程某次处于前台运行的活跃时长时，可以获取当前时间点所属的时间段，获取当前日期以作为记录日期，并获取应用进程的应用进程标识，记录活跃时长、时间段、记录日期、应用进程标识之间的对应关系，以便后续可以根据该对应关系获取到活跃时长。示例性地，终端可以记录“00:00-08:00(时间段)，12月7日(记录日期)、app1(应用进程标识)，50分钟(活跃时长)”。

需要说明的是，本步骤201可以由终端的活动管理服务(activitymanagerservice，ams)执行。ams是android操作系统的核心服务，在实施中，可以对ams的程序代码进行改进，向ams的程序代码中添加统计每个处于前台运行的应用进程的活跃时长的程序代码，以便ams在加载并运行程序代码时，可以实现统计活跃时长的功能。

202、在终端检测到空闲内存不满足预设条件时，确定处于后台运行的多个应用进程。

为了保证终端的正常运行，终端可以在运行过程中检测空闲内存是否满足预设条件，当检测到空闲内存不满足预设条件时，即确定处于后台运行的多个应用进程，以便从这些应用进程中确定出待回收的应用进程，进而进行内存回收。其中，预设条件以及检测空闲内存是否满足预设条件的过程具体可以包括以下两种设计：

设计一、预设条件可以为空闲内存小于内存阈值，终端可以实时或周期性地检测当前的空闲内存是否小于内存阈值，该内存阈值用于指示终端正常运行所需内存的最小值，当空闲内存小于内存阈值时，终端会确定空闲内存不满足预设条件。可选地，终端可以启动lmk进程或kswapd进程，由lmk进程或kswapd进程执行检测空闲内存是否小于内存阈值的过程。

其中，lmk进程检测到空闲内存小于内存阈值时，可以获取当前运行的所有进程的oom_adj，根据每个进程的oom_adj生成待杀进程列表，该待杀进程列表包括lmk进程确定可以杀掉的处于后台运行的进程，终端可以确定待杀进程列表中每个进程所关联的应用进程，作为后续要获取用户偏好度并可回收内存的应用进程。

设计二、预设条件可以为请求的内存超过空闲内存，当任一应用进程向终端请求内存时，可以向终端发送内存请求，该内存请求携带应用进程所请求的内存，终端可以根据该内存请求获取应用进程请求的内存，判断请求的内存是否超过空闲内存，当请求的内存超过空闲内存时，终端可以确定空闲内存不满足预设条件。

203、终端确定多个应用进程中每个应用进程在当前时间点所属的时间段的用户偏好度。

当终端确定了当前处于后台运行的多个应用进程后，会确定多个应用进程中每个应用进程的用户偏好度，以便基于每个应用进程的用户偏好度，从多个应用进程中确定出待回收的应用进程。可选地，确定用户偏好度的具体过程可以包括以下步骤一至步骤二：

步骤一、获取每个应用进程在历史运行中当前时间点所属的时间段的活跃时长。

对于多个应用进程中的每个应用进程，终端可以获取应用进程在历史运行中当前时间点所属的时间段的活跃时长，该活跃时长反映了应用进程在历史运行中该时间段的活跃程度，由于时间段是根据当前时间点确定的，可以认为活跃时长与应用进程在当前运行过程中当前时间点前后的活跃程度较为匹配，从而保证后续基于活跃时长确定出的用户偏好度具有高时效性，准确性高。

获取应用进程在历史运行中时间段的活跃时长的过程具体可以包括以下步骤(1)-(3)：

(1)获取时间段。

终端可以获取当前时间点，确定当前时间段所属的时间段。

(2)获取历史周期。

终端可以根据当前日期以及预设统计周期确定历史周期，该历史周期以当前日期为时间结束点且时长为预设统计周期。以当前日期为2017年12月7日为例，假设预设统计周期为1天，则历史周期为2017年12月6日至2017年12月7日，假设预设统计周期为一个月，则历史周期为2017年11月7日至2017年12月7日。其中，预设统计周期可以根据实际需求确定，本实施例对预设统计周期的具体数值不做限定。

(3)根据历史周期以及时间段，获取应用进程在历史运行中该时间段的活跃时长。

终端可以根据历史周期、时间段以及应用进程的应用进程标识，查询活跃时长、时间段、记录日期、应用进程标识之间的对应关系，得到与时间段、历史周期以及应用进程标识均对应的活跃时长，即对应该时间段、对应的记录日期为历史周期、且对应于应用进程标识的活跃时长，作为应用进程在历史运行中该时间段的活跃时长。例如假设历史周期为2017年11月7日至2017年12月7日，时间段为17:00-19:00,应用进程标识为service1，终端可以获取service1的位于2017年11月7日至2017年12月7日的17:00-19:00的活跃时长。

步骤二、根据多个应用进程中每个应用进程在历史运行中该时间段的活跃时长，确定多个应用进程中每个应用进程的用户偏好度。

当获取到每个应用进程在历史运行中该时间段(即当前时间点所属的时间段)的活跃时长后，终端可以基于活跃时长获取每个应用进程的用户偏好度，以便后续基于用户偏好度确定待回收的应用进程。获取用户偏好度的具体过程可以包括以下几种设计：

设计一、将活跃时长作为用户偏好度。

也即是，终端可以直接将应用进程在历史运行中该时间段的活跃时长作为应用进程的用户偏好度，从而简单有效地得到了用户偏好度。

设计二、计算活跃时长与活跃时长总和之间的比值，作为用户偏好度。

活跃时长总和是指当前在后台运行的多个应用进程在历史运行中该时间段的活跃时长的和值，针对获取活跃时长总和的过程，终端可以遍历多个应用进程中的每个应用进程，通过上述步骤203提供的方式确定每个应用进程的活跃时长，得到多个应用进程的活跃时长，计算多个活跃时长的和值，得到活跃时长总和。

本设计中，当要确定某个应用进程的用户偏好度时，计算该应用进程的活跃时长与该活跃时长总和之间的比值，将该比值作为用户偏好度，该用户偏好度也可以称为活跃时间占比，即应用进程的活跃时长在多个应用进程的活跃时长中的比例。通过这种结合应用进程的活跃时长与多个应用进程的活跃时长总和来获取用户偏好度，可以达到以下技术效果：

保证用户偏好度处于合理的数值范围内：考虑到实际应用进程中，用户在不同日期对终端的整体使用情况可以不同，则在不同日期统计用户偏好度时获取的活跃时长也会不同。例如，节假日可以为用户使用终端的高峰期，在节假日期间每个应用进程在各个时间段的活跃时长通常会较长，若此时统计用户偏好度，获取到的每个应用进程的活跃时长偏长，而通过计算应用进程的活跃时长与活跃时长总和之间的比值，能够保证用户偏好度不会过高。又如，考试周以及工作日可能为用户使用终端的低潮期，在考试周以及工作日期间每个应用进程在各个时间段的活跃时长都会偏短，若此时统计用户偏好度，获取到的每个应用进程获取到的活跃时长偏短，而通过计算活跃时长与活跃时长总和之间的比值，能够保证用户偏好度不会过低。也即是，保证计算得到的应用进程的用户偏好度相对稳定，而不会由于当前日期的影响产生过高或过低的情况，那么后续基于用户偏好度确定待回收的应用进程时，能够保证回收应用进程占用的内存过程的准确性。

设计三、计算活跃时长与应用进程的冷启动时长之间的乘积，作为用户偏好度。

应用进程的冷启动时长是指应用进程以冷启动的方式启动对应的应用时耗费的时长。针对获取冷启动时长的方式，可以预先在任一应用以冷启动的方式启动时，记录冷启动时长和启动该应用的应用进程之间的对应关系，当要获取冷启动时长时，可以获取该应用进程已记录的所有冷启动时长中最新记录的冷启动时长，以便基于该冷启动时长计算用户偏好度。另外，还可以获取应用进程已记录的所有冷启动时长中最近n次记录的冷启动时长，计算n个冷启动时长的平均值，作为获取到的冷启动时长。

本设计中，在计算用户偏好度时，会获取应用进程的冷启动时长，采用该冷启动时长对活跃时长进行加权，即计算冷启动时长与活跃时长之间的乘积作为用户偏好度，通过结合冷启动时长与活跃时长来获取用户偏好度，可以达到以下技术效果：

对于活跃时长相等的应用进程a和应用进程b来说，假设应用进程a的冷启动时长较长，应用进程b的冷启动时长较短，应用进程a冷启动时速度较慢，如果回收了应用进程a占用的内存，之后再次启动应用进程a时会由于速度较慢，对终端的运行造成较大的影响，同时容易带来终端卡顿的用户体验。而本设计中，通过采用冷启动时长对活跃时长进行加权，能适当增大应用进程a的用户偏好度，后续确定待回收的应用进程时，会避免将应用进程a确定为待回收的应用进程，进而避免再次启动应用进程a时，由于冷启动时长较长对终端的运行造成的较大的影响。

同理地，应用进程b冷启动时速度较快，即使回收了应用进程b占用的内存，之后再次启动应用进程b时由于速度较快，对终端运行造成的影响较小，同时不容易造成终端卡顿的用户体验。而本设计中，通过采用冷启动时长对活跃时长进行加权，能适当衰减应用进程b的用户偏好度，则后续会优先将应用进程b作为待回收的应用进程，优先回收应用进程b占用的内存，也即是，在准确地回收应用进程占用的内存的基础上，兼顾了每个应用进程的冷启动时长，尽量减少对终端造成的整体影响。

需要说明的是，在实施中，应用在运行过程中可以开启多个应用进程，由该多个应用进程中的主进程以冷启动的方式或热启动的方式启动应用，而主进程以外的每个子进程分别用于提供启动应用以外的功能。在本步骤中，当应用进程为主进程时，可以直接获取已记录的主进程启动对应的应用的冷启动时长，以计算该主进程的用户偏好度。而当应用进程为子进程时，可以确定子进程对应的主进程的冷启动时长，作为子进程的冷启动时长，以计算子进程的用户偏好度。

设计四、计算活跃时长与活跃时长和值之间的比值，以及计算比值与应用进程的冷启动时长之间的乘积，作为用户偏好度。

本设计为设计二与设计三相结合的方式，活跃时长和值的获取方式详见设计二，冷启动时长的获取方式详见设计三，在此不做赘述。本设计中，在提供了准确获取用户偏好度的方式的基础上，能够保证用户偏好度处于合理的数值范围内，同时兼顾了应用进程的冷启动时长，保证回收应用进程占用的内存时对终端的整体影响尽量小。

需要说明的是，当上述步骤201中时间段根据用户的生理作息行为确定，本步骤中还可以达到用户偏好度与用户的生理作息习惯相匹配的效果：例如考虑到用户通常在午饭时间段和晚饭时间段偏好使用外卖订餐应用的应用进程，预先将午饭时间段和晚饭时间段设置为时间段来实时统计活跃时长，如果在当前时间点为午饭时间段和晚饭时间段时要回收内存，计算出的外卖订餐应用的应用进程的用户偏好度会较高，则可以避免回收外卖订餐应用的应用进程占用的内存，又如考虑到用户通常在临睡时间段偏好使用音乐播放应用的应用进程，预先将临睡时间段设置为时间段来实时统计活跃时长，如果在当前时间点为临睡时间段时要回收内存，计算出的音乐播放应用的应用进程的用户偏好度会较高，则可以避免回收音乐播放应用的应用进程占用的内存。

204、终端基于每个应用进程的用户偏好度，获取每个应用进程的回收优先级。

终端可以获取每个应用进程的回收优先级，以便基于每个应用进程的回收优先级确定待回收的应用进程。其中，每个应用进程的回收优先级与每个应用进程的用户偏好度负相关，若应用进程的用户偏好度越高，则应用进程的回收优先级越低，应用进程的用户偏好度越低，则应用进程的回收优先级越高。

进一步地，在提供了基于用户偏好度确定回收优先级的基础上，本实施例还提供了结合用户偏好度与应用进程的内存占比、应用进程的功能、应用进程最近一次的活跃时长、应用进程的功耗等因素，共同确定回收优先级的方式，详见以下设计一至设计四。需要说明的是，以下各种设计中回收优先级的数值与回收优先级的高低成反比，即回收优先级的数值越小，回收优先级越高，回收优先级的数值越大，回收优先级越低。

设计一、结合用户偏好度与应用进程的内存占比确定回收优先级。

本设计具体可以包括以下步骤一至步骤三：

步骤一、终端确定与每个应用进程的内存占比对应的内存占比权重，每个应用进程的内存占比用于指示每个应用进程占用的内存与总内存开销之间的比值。

内存占比：对于多个应用进程中的每个应用进程，终端可以获取该每个应用进程占用的内存以及当前的总内存开销，计算该每个应用进程占用的内存与总内存开销之间的比值，将该比值作为内存占比。其中总内存开销是指终端当前总计占用的内存大小，为终端运行的各种应用进程所占用的内存的总和。示例性地，假设应用进程占用的内存为100m，当前的总内存开销为1000m，则得到应用进程的内存占比为100m/1000m＝10％。

内存占比权重：终端可以基于应用进程的内存占比与内存占比权重之间的对应关系，获取应用进程的内存占比对应的内存占比权重。其中，内存占比与内存占比权重之间的对应关系包括多个内存占比以及对应的多个内存占比权重，内存占比越大，对应的内存占比权重越大。内存占比与内存占比权重之间的对应关系可以由开发人员预先设置。当终端得到内存占比后，可以采用内存占比为索引，查询内存占比与内存占比权重之间的对应关系，从对应关系中获取内存占比对应的内存占比权重。

可选地，终端可以对内存占比进行量化，例如可以设置多个内存占比区间，并设置内存占比区间与内存占比权重之间的对应关系，当得到应用进程的内存占比时，可以从多个内存占比区间中获取该内存占比所属的内存占比区间，基于内存占比区间与内存占比权重之间的对应关系，获取应用进程的内存占比区间对应的内存占比权重。其中，内存占比区间可以由开发人员根据实际需求设置，例如设置1％-10％为一个内存占比区间。

通过对内存占比进行量化，可以将一定数值范围内的所有内存占比统一与某个内存占比权重对应，则内存占比与内存占比权重之间的对应关系中无需包括该数值范围内的所有内存占比，只需包括内存占比区间，从而实现了对应关系的简化，减少了要存储的数据量。

步骤二、终端根据每个应用进程的用户偏好度与每个应用进程的内存占比权重，获取每个应用进程的回收优先级。

应用进程的回收优先级与内存占比权重正相关，且与用户偏好度负相关。可选地，可以计算用户偏好度与内存占比权重之间的比值，得到回收优先级。示例性地，可以采用以下公式计算回收优先级：yi＝bi/ai，其中，yi表征回收优先级，bi表征用户偏好度，ai表征内存占比权重。

本设计中，应用进程的内存占比权重越大，则回收优先级越高，因此后续被确定为待回收的应用进程的概率越大，应用进程的内存占比权重越小，则回收优先级越低，因此后续被确定为待回收的应用进程的概率越小。

通过结合用户偏好度和应用进程的内存占比确定回收优先级，可以进一步提高回收内存的准确性：对于用户偏好度接近的多个应用进程来说，假设某应用进程的内存占比较大，则内存占比权重较大，因此该应用进程的回收优先级会较高，会优先回收该应用进程的内存，能够保证回收的内存较多，保证空闲内存尽量快地满足内存需求。

设计二、结合用户偏好度和应用进程的功能，确定应用进程的回收优先级。

本设计具体可以包括以下步骤一至步骤二：

步骤一、终端确定与每个应用进程的功能对应的功能权重。

应用进程的功能：可以包括推送功能、网络连接功能等，应用可以同时开启一个或多个应用进程，每个应用进程可以根据其当前执行的活动具有对应的进程功能，例如即时通信应用可以开启主进程、推送子进程、连网子进程等，由推送子进程进行推送消息，由连网子进程进行网络连接。对于任一应用进程来说，终端可以与该应用进程之间进行交互，获知应用进程的进程功能。

确定应用进程的功能对应的功能权重的过程：对于多个应用进程中每个应用进程，当终端确定每个应用进程的进程功能后，采用进程功能为索引，查询进程功能与功能权重之间的对应关系，从对应关系中获取进程功能对应的功能权重。其中，进程功能与功能权重之间的对应关系包括多个功能以及对应的多个功能权重，可以根据经验确定，例如认为进程功能越重要，则设置的功能权重越大，认为进程功能越次要，则设置的功能权重越小。示例性地，考虑到推送功能的应用进程在运行过程中通常会打扰用户，同时影响终端接收网络数据的速度，可以为推送功能设置较小的功能权重，以保证推送功能的应用进程的回收优先级较高，进而优先回收该应用进程的内存。

步骤二、根据每个应用进程的用户偏好度与每个应用进程的功能权重，获取每个应用进程的回收优先级。

其中，回收优先级与功能权重负相关，且与用户偏好度负相关。进一步地，可以计算用户偏好度与功能权重之间的乘积，得到回收优先级。示例性地，可以采用以下公式计算回收优先级：yi＝bi×di，其中，yi表征回收优先级，bi表征用户偏好度，di表征功能权重。

本设计中，应用进程的功能权重越小，则回收优先级越高，因此后续被确定为待回收的应用进程的概率越大，应用进程的功能权重越大，则回收优先级越低，因此后续被确定为待回收的应用进程的概率越大。

通过结合用户偏好度和功能权重确定回收优先级，可以进一步提高回收内存的准确性：对于用户偏好度接近的多个应用进程来说，若某个应用进程的进程功能较为次要，可以认为该应用进程当前的运行活动对于终端的重要性低，回收该应用进程的内存时造成的影响较小，而结合功能权重确定回收优先级时，该应用进程的回收优先级会较高，终端会优先回收该应用进程的内存，从而尽量减少回收内存对终端造成的整体影响。

设计三、结合用户偏好度和应用进程的最近一次的活跃时长，确定应用进程的回收优先级。

本设计具体可以包括以下步骤一至步骤三：

步骤一、确定每个应用进程的最近活跃权重，每个应用进程的最近活跃权重用于指示该每个应用进程最近活跃的程度。

确定最近活跃权重的具体过程可以包括以下(1)-(2)。

(1)获取每个应用进程的最近活跃时长，每个应用进程的最近活跃时长用于指示应用进程最近一次在前台运行的活跃时长。

对于多个应用进程中每个应用进程，终端可以获取应用进程已记录的多个活跃时长中距离当前时间点最近的活跃时长，得到最近活跃时长。

(2)基于最近活跃时长的结束时间点与当前时间点之间的时间差，对每个应用进程的最近活跃时长进行衰减，将衰减后的最近活跃时长作为最近活跃权重。

终端可以获取最近活跃时长的结束时间点，并获取当前时间点，计算该结束时间点与当前时间点之前的时间差，基于该时间差对最近活跃时长进行衰减，将衰减后的最近活跃时长作为最近活跃权重。

针对基于时间差对最近活跃时长进行衰减的具体过程，可以采用衰减函数对时间差和最近活跃时长进行计算，将计算结果作为最近活跃权重。其中，衰减函数可以为ti＝w×y^(-t)，ti表征最近活跃权重，w表征归一化的最近活跃时长，y为一个常数，t表征时间差。

基于上述计算方式，由于时间差能够反映应用进程最近一次的运行过程与当前时间点之间距离的远近，当某应用进程的时间差较小时，表明该应用进程是最近活跃的应用进程，可以认为该应用进程对用户当前的重要性较强，则基于时间差对最近活跃时长进行衰减时，衰减程度较少，以保证该应用进程的最近活跃权重较大。而当应用进程的时间差较大时，表明该应用进程是很久以前活跃的应用进程，可以认为该应用进程对用户当前的重要性较弱，则基于时间差对最近活跃时长进行衰减时，衰减程度较大，以保证应用进程的最近活跃权重较小。

步骤二、根据每个应用进程的用户偏好度与最近活跃权重，获取每个应用进程的回收优先级。

应用进程的回收优先级与最近活跃权重负相关，且与用户偏好度负相关。可选地，可以计算用户偏好度与最近活跃权重之间的乘积，得到回收优先级。示例性地，可以采用以下公式计算回收优先级：yi＝bi×ti，其中，yi表征回收优先级，bi表征用户偏好度，ti表征最近活跃权重。

本设计中，应用进程的最近活跃权重越小，则回收优先级越高，因此后续被确定为待回收的应用进程的概率越大。应用进程的最近活跃权重越大，则回收优先级越低，因此后续被确定为待回收的应用进程的概率越小。

通过结合用户偏好度和应用进程的最近活跃权重确定回收优先级，可以进一步提高回收内存的准确性：对于用户偏好度接近的多个应用进程来说，若某个应用进程是最近活跃的应用进程，最近活跃权重会较大，因此该应用进程的回收优先级会较低，则会避免回收该应用进程的内存，从而尽量避免影响最近活跃的应用进程的正常运行。若某个应用进程是很久之前活跃的应用进程，则最近活跃权重较小，因此该应用进程的回收优先级会较高，会优先回收该应用进程的内存，通过优先回收很久以前活跃的应用进程所占用的内存，在实现回收内存的基础上，保证对终端运行的整体影响尽量小。

设计四、结合用户偏好度和应用进程的功耗确定回收优先级。

本设计具体可以包括以下步骤一至步骤二：

步骤一、确定与每个应用进程的功耗对应的功耗权重。

功耗：功耗是指应用进程运行的耗电量，针对获取功耗的过程，终端可以预先在应用进程运行时，实时记录应用进程的功耗。则本步骤中，对于多个应用进程中每个应用进程，终端可以获取已记录的应用进程在历史运行中的功耗，例如可以获取应用进程最近一次运行的功耗，又如可以获取应用进程最近预设次数运行的功耗，计算预设次数的功耗的平均值。

确定功耗权重的过程：终端可以采用功耗为索引，查询功耗与功耗权重之间的对应关系，从对应关系中获取功耗对应的功耗权重。其中，功耗与功耗权重之间的对应关系包括多个功耗以及对应的多个功耗权重，功耗越大，对应的功耗权重越大，功耗与功耗权重的对应关系可以由开发人员预先设置，可以预先存储在终端中。

步骤二、根据每个应用进程的用户偏好度与每个应用进程的功耗权重，获取每个应用进程的回收优先级。

其中，回收优先级与功耗权重正相关，且与用户偏好度负相关。进一步地，可以计算用户偏好度与功耗权重之间的比值，得到回收优先级。示例性地，可以采用以下公式计算回收优先级：yi＝bi/hi，其中，yi表征回收优先级，bi表征用户偏好度，hi表征功耗权重。

本设计中，应用进程的功耗权重越大，则回收优先级越高，后续被确定为待回收的应用进程的概率越大。应用进程的功耗权重越小，则回收优先级越低，后续被确定为待回收的应用进程的概率越小。

通过结合用户偏好度和应用进程的功耗确定待回收的应用进程，可以达到以下技术效果：对于用户偏好度接近的多个应用进程来说，若某个应用进程的功耗越大，则功耗权重越大，则由于回收优先级较高，后续终端会优先回收该应用进程占用的内存。通过优先回收功耗大的应用进程占用的内存，在实现回收内存功能的基础上，能够节约终端的功耗。

设计五、结合用户偏好度和应用进程的调用频率确定待回收的应用进程，调用频率是指多个应用进程在历史运行中该时间段内调用应用进程的总次数。

本设计具体可以包括以下步骤一至步骤三：

步骤一、确定每个应用进程的调用频率，每个应用进程的调用频率用于指示多个应用进程在历史运行中时间段内调用每个应用进程的总次数。

确定调用频率的具体过程可以包括以下(1)-(2)：

(1)终端获取每个应用进程的调用记录。

调用记录也称调用链表，每个应用进程的调用记录用于记录每个应用进程调用多个应用进程中每个应用进程以外的应用进程的事件，当每个应用进程运行时，终端可以实时在每个应用进程的调用记录中记录应用进程调用其他应用进程的事件。例如，对于应用进程1-应用进程n来说，会在应用进程1的调用记录中，记录应用进程1调用应用进程2-应用进程n中的事件。

(2)终端基于每个应用进程的调用记录，确定每个应用进程的调用频率。

对于多个应用进程中的每个应用进程，终端可以计算多个调用记录中调用该每个应用进程的调用次数的和值，作为该每个应用进程的调用频率。例如，对于应用进程1来说，可以根据应用进程2-应用进程n的调用记录，获取应用进程2-应用进程n调用应用进程1的调用次数的和值，作为应用进程1的调用频率。

步骤二、基于每个应用进程的调用频率，获取每个应用进程的回收优先级

回收优先级与调用频率负相关，且与用户偏好度负相关。可选地，终端可以基于调用频率，对回收优先级进行调节。终端可以设置第一频率阈值和第二频率阈值，当终端确定了每个应用进程的调用频率后，可以判断调用频率是否高于第一调用频率阈值，当调用频率高于第一调用频率阈值时，认为应用进程是被频繁调用的应用进程，回收该应用进程占用的内存后会对其他应用进程的运行造成较大的影响，则会将应用进程的回收优先级调低，以尽量避免回收应用进程占用的内存。同理地，终端可以判断应用进程的调用频率是否低于第二频率阈值，当调用频率低于第二调用频率阈值时，认为应用进程是很少被调用的应用进程，回收该应用进程占用的内存后对其他应用进程的运行造成的影响较小，则将应用进程的回收优先级调高。另外，当调用频率不高于第一频率阈值且不低于第二频率阈值时，终端可以无需调节应用进程的回收优先级。其中，第一调用频率阈值用于指示频繁调用的应用进程的调用频率的最低值，可以根据实际需求设置。第二调用频率阈值用于指示很少被调用的应用进程的调用频率的最高值，可以根据实际需求设置。

关于调低回收优先级的过程，终端可以设置预设调节数值，预设调节数值可以为正数，终端可以计算应用进程回收优先级的数值与预设调节数值的和值，将和值作为调低后的回收优先级。或者，预设调节数值可以为大于1的正数，终端可以计算应用进程回收优先级的数值与预设调节数值的乘积，将乘积作为调低后的回收优先级。

关于调高回收优先级的过程，终端可以设置预设调节数值，预设调节数值可以为正数，终端可以计算应用进程回收优先级的数值与预设调节数值的差值，将差值作为调高后的回收优先级。或者，预设调节数值可以为大于1的正数，终端可以计算应用进程回收优先级的数值与预设调节数值的比值，将比值作为调高后的回收优先级。

本设计中，应用进程的调用频率越小，则回收优先级越高，后续被确定为待回收的应用进程的概率越大。应用进程的调用频率越大，则回收优先级越低，后续被确定为待回收的应用进程的概率越小。通过结合用户偏好度和应用进程的调用频率确定回收优先级，能够保证被频繁调用的应用进程的回收优先级较低，从而尽量避免回收被频繁调用的应用进程时导致的对其他应用进程的运行造成影响。

需要说明的是，上述设计一至设计五可以采用任意结合的方式形成确定回收优先级的方式。例如，设计一与设计三结合时，终端可以获取内存占比权重和最近活跃权重，根据算用户偏好度、内存占比权重、最近活跃权重，确定回收优先级。又如，设计一、设计二、设计三和设计四结合时，终端可以获取内存占比权重、功能权重、最近活跃权重和应用进程的功耗，根据用户偏好度、内存占比权重、功能权重、最近活跃权重和应用进程的功耗，确定回收优先级。例如，终端可以采用以下公式计算回收优先级：yi＝(bi×di×ti)/(ai×hi)，其中，yi表征回收优先级，bi表征用户偏好度，di表征功能权重，ti表征最近活跃权重，ai表征内存占比权重，hi表征功耗权重。

205、终端基于每个应用进程的回收优先级，确定多个应用进程中待回收的应用进程。

终端可以对多个应用进程按照回收优先级进行排序，先将回收优先级最高的应用进程作为待回收的应用进程，以便回收该应用进程占用的内存。之后，若空闲内存仍不满足预设条件，会继续将回收优先级第二高的应用进程作为待回收的应用进程。那么，应用进程的回收优先级越高，越早回收应用进程所占用的内存，应用进程的回收优先级越低，越晚回收应用进程所占用的内存。

需要说明的是，上述步骤204-步骤205仅是以先基于用户偏好度确定回收优先级，再基于回收优先级确定待回收的应用进程为例进行说明，在实施中也可以直接基于用户偏好度确定待回收的应用进程，其中，若应用进程的用户偏好度越高，则会避免将应用进程作为待回收的应用进程，若应用进程的用户偏好度越低，则优先将应用进程作为待回收的应用进程。

通过基于用户偏好度确定待回收的应用进程的方式，可以达到以下技术效果：

第一，提高回收内存的准确性：对于高频应用进程(即平时频繁运行的应用进程)来说，应用进程的活跃时长会较长，则活跃时长对应的用户偏好度会较高，那么会避免将高频应用进程作为待回收的应用进程，保证高频应用进程的数据驻留在内存中，尽量避免影响高频应用进程的正常运行，同时降低高频应用进程的冷启动概率。

第二，提高回收内存的及时性：对于平时不经常运行的应用进程来说，该应用进程的活跃时长会较短，则活跃时长对应的用户偏好度会较小，那么会优先将低频应用进程作为待回收的应用进程，低频应用进程所占用的内存被回收的概率较大，能够及时回收低频应用进程所占用的内存。

第三，保证回收内存的过程贴近用户的个人使用习惯：考虑到日常生活中不同用户所偏好使用的应用进程可能不同，例如用户a偏好使用即时通信应用的应用进程，用户b偏好使用音乐播放应用的应用进程，用户c偏好使用在线购物应用的应用进程等。本实施例中，并非统一地设置了所有用户对应用进程的用户偏好度，而是由终端以自学习的方式，实时统计每个应用进程的活跃时长来分析出每个应用进程的用户偏好度，每个应用进程的用户偏好度能够反映用户的个人使用习惯，因此结合用户偏好度回收内存时能够满足个性化需求，例如用户a的终端回收即时通信应用的应用进程的内存的概率最小，用户b的终端回收音乐播放应用的应用进程的内存的概率最小等等。

第四，保证回收内存的过程具有时效性：考虑到用户所偏好的应用进程可以随着时间的推移发生变化，例如某用户过去偏好使用微博应用的应用进程，现在偏好使用即时通信应用的应用进程等。本实施例中，并非预先获取了用户对每个应用进程的用户偏好度，而是由终端在回收应用进程占用的内存时，实时根据应用进程最近在历史运行的活跃时长来计算出每个应用进程的用户偏好度，也即是，动态地自学习应用进程的用户偏好度，每次计算出的用户偏好度可以随着时间进行动态变化，则每次回收应用进程占用的内存的顺序也会进行动态变化，例如终端上个月计算用户偏好度时即时通信应用的应用进程的用户偏好度最高，则回收即时通信应用的应用进程的内存的概率最小，这个月计算用户偏好度时音乐播放应用的应用进程的用户偏好度最高，则回收音乐播放应用的应用进程的内存的概率最小。

206、终端回收待回收的应用进程占用的内存。

当终端确定待回收的应用进程后，会回收该应用进程占用的内存。其中，当回收该应用进程占用的内存后，可以再次检测空闲内存是否满足预设条件，当空闲内存已经满足预设条件时，则无需再次确定待回收的应用进程，结束本次回收内存的过程。当空闲内存仍不满足预设条件时，则再次采用本实施例提供的方法，继续确定待回收的应用进程，直至空闲内存满足预设条件为止。

示例性地，假设当检测到空闲内存不满足预设条件时，确定共有5个处于后台运行的应用进程，当回收了两个应用进程占用的内存后，确定空闲内存已经满足预设条件，则可以结束回收内存的过程，无需继续回收剩余的3个应用进程占用的内存。

可选地，结合根据回收优先级确定待回收的应用进程的设计，终端将回收优先级最高的应用进程作为待回收的应用进程，回收了该应用进程占用的内存后，可以再次检测空闲内存是否满足预设条件，当空闲内存已经满足预设条件时，则无需确定待回收的应用进程，结束本次回收内存的过程。当空闲内存仍不满足预设条件时，则将回收优先级第二高的应用进程作为待回收的应用进程，以便回收回收优先级第二高的应用进程的内存，以此类推。

针对回收应用进程的内存的具体过程，本实施例提供了以下两种设计：

设计一、杀死待回收的应用进程。

杀死待回收的应用进程后，应用进程所占用的内存会释放，达到回收应用进程所占用的内存的效果。可选地，终端可以运行lmk进程，由lmk进程杀死待回收的应用进程。

需要说明的是，本实施例以应用进程为统计用户偏好度以及回收内存的单位，当应用开启多个应用进程时，可以仅杀死多个应用进程中的某个应用进程而不杀死其他应用进程，则而应用可以仍保持运行状态。例如某阅读应用可以开启主进程、图片展示子进程、文字展示子进程等多个应用进程，其中计算用户偏好度时，图片展示子进程由于用户偏好度较低被优先杀死，此时该阅读应用可通过主进程继续运行，文字可通过文字展示子进程继续展示，仅是图片暂时无法显示。

设计二、将待回收的应用进程在内存中的数据转移至预设存储空间中。

终端可以按照回收优先级从高到低的顺序，依次将每个应用进程在内存中的数据转移至预设存储空间中，从而将应用进程在内存占用的内存空闲出来，达到回收应用进程所占用的内存的效果。可选地，可以先将数据进行压缩，压缩后数据的数据量会减小，之后再将压缩后的数据转移至预设存储空间中，例如，假设某应用进程在内存存储了50m的数据，可以将50m的数据压缩成20m，再将20m数据存储至预设存储空间中，则内存会空闲出50m的空间。其中，该预设存储空间可以为zram分区，zram分区也称为compcache(压缩缓存)，是指linux内核的一个模块，zram可以用内存替代硬盘为操作系统提供存储数据的功能，可以用于存储压缩后的应用进程的数据。

可选地，终端可以运行kswapd进程或之前请求内存的进程，由kswapd进程或之前请求内存的进程依次将每个应用进程在内存中的数据转移至预设存储空间中。

需要说明的是，参见图3，其示出了本公开实施例提供的一种回收内存的方法的设计示意图，开发人员可以参照图3的架构，分模块地设计回收内存过程的程序代码。其中，各种计算因子可以按照属性划分为4个模块，需求模块包括内存需求和空闲内存，用户偏好度模块包括活跃时长、时间段、最近活跃权重和调用频率，应用进程属性模块包括应用进程的内存占比、冷启动时长和进程功能，扩展模块包括应用进程的功耗。另外，每个模块的计算因子可以按照重要性划分为5个等级，开发人员可以按照计算因子的等级设置计算因子的数值范围，例如计算因子的等级越高，即重要性越强时，可以设置计算因子的数值范围较高，计算因子的等级越低，即重要性越弱时，可以设置计算因子的数值范围较低。

本实施例提供的方法，在回收内存时考虑到了用户的使用习惯，结合每个应用进程的用户偏好度确定待回收的应用进程，进而回收应用进程所占用的内存。优先回收用户偏好度较低的应用进程所占用的内存，避免回收用户偏好度较高的应用进程所占用的内存，保证回收各个应用进程的内存时顺序的准确性以及合理性，避免误杀进程以及误将应用进程的数据转移至预设存储空间的情况，从而避免影响应用进程的正常运行，保证回收内存的过程对终端的运行造成的整体影响尽量小。

图4是本公开实施例提供的一种回收内存的装置的结构示意图，如图4所示，该装置包括：确定模块401和回收模块402。

确定模块401，用于在检测到空闲内存不满足预设条件时，确定处于后台运行的多个应用进程；

该确定模块401，还用于确定该多个应用进程中每个应用进程在当前时间点所属的时间段的用户偏好度，该用户偏好度用于指示应用进程被调用的可能性大小；

该确定模块401，还用于根据该多个应用进程中每个应用进程的用户偏好度，确定该多个应用进程中待回收的应用进程；

回收模块402，用于回收该待回收的应用进程占用的内存。

在一种可能的设计中，该确定模块401，还用于：根据该多个应用进程中每个应用进程在历史运行中该时间段的活跃时长，确定该多个应用进程中每个应用进程在当前时间点所属的时间段的用户偏好度。

在一种可能的设计中，该确定模块401，还用于：

将该活跃时长作为该用户偏好度；或，

计算该活跃时长与活跃时长总和之间的比值，作为该用户偏好度，该活跃时长总和是指该多个应用进程在历史运行中该时间段的活跃时长的和值；或，

计算该活跃时长与该应用进程的冷启动时长之间的乘积，作为该用户偏好度；或，

计算该活跃时长与活跃时长总和之间的比值，以及计算该比值与该应用进程的冷启动时长之间的乘积，作为该用户偏好度。

在一种可能的设计中，该确定模块401，还包括：

获取子模块，用于基于该多个应用进程中每个应用进程的用户偏好度，获取该每个应用进程的回收优先级，该每个应用进程的回收优先级与该每个应用进程的用户偏好度负相关；

确定子模块，用于基于该每个应用进程的回收优先级，确定该多个应用进程中待回收的应用进程。

在一种可能的设计中，述获取子模块，还用于确定该每个应用进程的最近活跃权重，该每个应用进程的最近活跃权重用于指示该每个应用进程最近活跃的程度；根据该每个应用进程的用户偏好度与该每个应用进程的最近活跃权重，获取该每个应用进程的回收优先级。

在一种可能的设计中，该获取子模块，还用于获取该每个应用进程的最近活跃时长，该每个应用进程的最近活跃时长用于指示该每个应用进程最近一次处于前台运行的活跃时长；基于该每个应用进程的最近活跃时长的结束时间点与该当前时间点之间的时间差，对该每个应用进程的最近活跃时长进行衰减以得到衰减后的最近活跃时长，将该衰减后的最近活跃时长作为该最近活跃权重。

在一种可能的设计中，该获取子模块，还用于：确定与该每个应用进程的功能对应的功能权重，该每个应用进程的功能权重用于指示该每个应用进程的功能的重要程度；根据该每个应用进程的用户偏好度与该每个应用进程的功能权重，获取该每个应用进程的回收优先级。

在一种可能的设计中，该获取子模块，还用于：确定与该每个应用进程的功耗对应的功耗权重，该每个应用进程的功耗权重用于指示该每个应用进程的功耗的大小；根据该每个应用进程的用户偏好度与该每个应用进程的功耗权重，获取该每个应用进程的回收优先级。

在一种可能的设计中，该获取子模块，还用于：确定与该每个应用进程的内存占比对应的内存占比权重，该每个应用进程的内存占比用于指示该每个应用进程占用的内存与总内存开销之间的比值；根据该每个应用进程的用户偏好度与该每个应用进程的内存占比权重，获取该每个应用进程的回收优先级。

在一种可能的设计中，该获取子模块，还用于：确定该每个应用进程的调用频率，该每个应用进程的调用频率用于指示该多个应用进程在历史运行中该时间段内调用该每个应用进程的总次数；根据该每个应用进程的用户偏好度与该每个应用进程的调用频率，获取该每个应用进程的回收优先级。

在一种可能的设计中，该获取子模块，还用于：获取该每个应用进程的调用记录，该每个应用进程的调用记录用于记录该每个应用进程调用该多个应用进程中该每个应用进程以外的应用进程的事件；基于该每个应用进程的调用记录，确定该每个应用进程的调用频率。

在一种可能的设计中，该装置还包括：统计模块，用于统计该多个应用进程中每个应用进程在历史运行中该时间段的活跃时长。

在一种可能的设计中，该回收模块402，用于杀死该待回收的应用进程；或，将该待回收的应用进程在内存中的数据转移至预设存储空间。

本申请实施例描述的各示例的单元及方法过程，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能。

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

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，既可以位于一个地方，也可以分布到多个网络单元上。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。

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