CN116166573B - 控制内存回收的方法、电子设备及存储介质 - Google Patents

Abstract

本申请提供了一种控制内存回收的方法、电子设备及存储介质，涉及内存管理技术领域。通过本申请方案，可以预先记录每次APP申请内存时的需回收内存量及申请时刻等相关数据，当前台应用申请内存时，可根据记录的相关数据计算最近一段时间内的内存申请压力值，并根据内存申请压力值来衡量系统内存当前实际压力状态，由此根据压力状态确定执行哪一种内存回收策略，例如在高压力情况下会触发后台应用查杀逻辑，快速释放内存。通过本申请方案，能够准确地衡量系统内存的实际压力状态，并采用当前压力状态对应的内存回收策略进行内存回收，可避免陷入持续采用常规内存回收GC的死循环，因此能够有效地为前台APP提供内存资源，避免出现卡顿现象。

Description

控制内存回收的方法、电子设备及存储介质

技术领域

本申请涉及内存管理技术领域，尤其涉及一种控制内存回收的方法、电子设备及存储介质。

背景技术

随着电子设备和存储器技术的飞速发展，电子设备不断更新换代，电子设备的系统内存容量也越来越大。例如，以前大部分手机的系统内存容量为8GB或者更小，现阶段大部分手机的系统内存容量为12GB或16GB甚至更大。

在用户使用电子设备的过程中，会启动很多个应用，每个应用都会占用一定的系统内存空间。电子设备会根据可用内存情况采用不同的内存回收机制。例如，当可用内存量大于查杀阈值（例如1.5G）时，表示可用内存充足，操作系统采用常规的内存回收机制即可；当可用内存量小于或等于该查杀阈值时，表示可用内存不足，操作系统采用查杀后台应用，快速释放后台应用占用的内存，供给前台运行的应用使用。

然而，随着系统内存容量的增大，上述内存回收判断逻辑不再适用，经常会出现系统运行卡顿的现象，原因在于：随着系统内存容量的增大，后台保活的APP增多，对应的文件页缓存也会相应地增多，导致系统的可用内存量（可用内存量等于剩余空闲内存加上文件页缓存）一直处于较充足的水平，这就导致可用内存量总是大于查杀阈值，导致电子设备一直采取常规内存回收机制进行内存供给。由于常规内存回收机制相对较慢，内存供给效率相对较低，因此会造成对前台应用的内存供给不足，从而引发卡顿现象。

发明内容

本申请提供一种控制内存回收的方法、电子设备及存储介质，能够准确地衡量系统内存的实际压力状态，并采用当前压力状态对应的内存回收策略进行内存回收，因此能够有效地为前台APP提供内存资源，避免出现卡顿现象。

为达到上述目的，本申请采用如下技术方案：

第一方面，本申请提供一种控制内存回收的方法，该方法包括：

响应于第一应用的申请内存请求，根据所述第一应用的申请内存量与系统内存中的剩余空闲内存量之间的差值，确定需回收内存量；

将所述需回收内存量及对应的申请时刻构成的第一数据对存储到缓存器中；其中，所述缓存器中还存储有除所述第一数据对之外的多个数据对，所述多个数据对包括在所述第一应用申请内存之前每当有应用申请内存时确定并存入的数据对；

从所述缓存器中获取预设窗长内的N个数据对，所述N个数据对包括所述第一数据对以及在所述第一应用申请内存之前存入的N-1个数据对，N为大于1的整数；

根据所述N个数据对，计算内存申请压力值；

根据所述内存申请压力值，确定内存回收策略；

按照所确定的内存回收策略进行内存回收。

通过本申请实施例提供的控制内存回收的方法，可以预先记录每次APP申请内存时的需回收内存量及申请时刻等相关数据，当前台应用申请内存时，可根据记录的相关数据计算最近一段时间内的内存申请压力值，并根据内存申请压力值来衡量系统内存当前实际压力状态，由此根据压力状态确定执行哪一种内存回收策略，例如在高压力情况下会触发后台应用查杀逻辑，快速释放内存。通过本申请方案，能够准确地衡量系统内存的实际压力状态，并采用当前压力状态对应的内存回收策略进行内存回收，能够避免陷入持续采用常规内存回收GC的死循环，因此能够有效地为前台APP提供内存资源，避免出现卡顿现象。

其中，上述预设窗长内的N个数据对指所述缓存器中最近缓存的预设数量的数据对。

在本申请实施例中，可以从缓存器队列中选择预设窗长（calc_window）内的历史值，即最近缓存的预设数量的数据对，然后根据缓存器队列中的全部数据来计算内存申请压力值。

其中，预设窗长内的N个数据可以是缓存器队列中的一部分数据，或者可以是缓存器队列中的全部数据对，具体可以根据实际使用需求设置，本申请实施例不作限定。

其中，根据所述内存申请压力值，确定内存回收策略，包括：将内存申请压力值与预设的压力阈值比较，根据比较结果确定内存回收策略。其中，预设的压力阈值可以是一个，也可以是两个，或者可以是三个或更多个。

示例性地，当预设了一个压力阈值1时，对应有两个区间，对应有两个压力等级或压力状态，例如无压力等级和有压力等级；每个压力等级对应设置一个内存回收策略，例如无压力等级对应常规内存回收策略，有压力等级对应查杀后台应用策略。示例性地，将内存申请压力值与压力阈值1比较，可以确定压力等级，进而根据压力等级确定内存回收策略；例如当内存申请压力值小于压力阈值1时，确定处于无压力等级，在此情况下可以采用常规内存回收策略；当内存申请压力值大于或等于压力阈值1时，确定处于有压力等级，在此情况下可以采用查杀后台应用策略。

示例性地，预设了两个压力阈值：压力阈值1和压力阈值2，压力阈值2大于压力阈值1，这种情况对应有三个区间，并对应有三个压力等级或压力状态，例如无压力等级、低压力等级、高压力等级；每个压力等级对应设置一个内存回收策略，例如无压力等级对应常规内存回收策略，低压力等级对应只回收文件页策略，高压力等级对应查杀后台应用策略。示例性地，将内存申请压力值与压力阈值1和压力阈值2进行比较，可以确定压力等级，进而根据压力等级确定内存回收策略。例如，当内存申请压力值小于压力阈值1时，确定处于无压力等级，在此情况下可以采用常规内存回收策略；当内存申请压力值大于或等于压力阈值1，且小于压力阈值2时，确定处于低压力等级，在此情况下可以采用只回收文件页策略。当内存申请压力值大于或等于压力阈值2时，确定处于有压力等级，在此情况下可以采用查杀后台应用策略。

在一种可能实现方式中，所述根据所述N个数据对，计算内存申请压力值，包括：将所述N个数据对中所有的所述需回收内存量求和，得到需回收内存总量；将所述N个数据对中的最后一个申请时刻与首个申请时刻求差，得到第一时长（时间差）；计算所述需回收内存总量与所述第一时长之间的比值，得到所述内存申请压力值。

在一种可能实现方式中，所述响应于第一应用的申请内存请求，根据所述第一应用的申请内存量与系统内存中的剩余空闲内存量之间的差值，确定需回收内存量，包括：响应于所述第一应用的申请内存请求，当满足预设条件时，根据所述第一应用的申请内存量与系统内存中的剩余空闲内存量之间的差值，确定需回收内存量。

在一种可能实现方式中，所述预设条件包括以下至少一项：电子设备支持的后台保活应用的最大数量大于或等于保活数量阈值；所述电子设备的系统内存量大于或等于内存量阈值。

在一种可能实现方式中，所述根据所述内存申请压力值，确定内存回收策略，包括：当所述内存申请压力值小于第一压力阈值时，执行第一内存回收策略；当所述内存申请压力值大于或等于所述第一压力阈值，且小于第二压力阈值时，执行第二内存回收策略；当所述内存申请压力值大于或等于所述第二压力阈值时，执行第三内存回收策略。

其中，所述第二压力阈值大于所述第一压力阈值；其中，所述第三内存回收策略的回收效率大于所述第二内存回收策略的回收效率，所述第二内存回收策略的回收效率大于所述第一内存回收策略的回收效率。

在一种可能实现方式中，所述第一内存回收策略为常规内存回收；所述第二内存回收策略为只回收文件页；所述第三内存回收策略为查杀后台应用。

在一种可能实现方式中，所述第一内存回收策略为常规内存回收；所述第二内存回收策略为回收文件页和匿名页、且对所述文件页的回收比例大于对所述匿名页的回收比例；所述第三内存回收策略为查杀后台应用。

在一种可能实现方式中，所述根据所述内存申请压力值，确定内存回收策略，包括：当所述内存申请压力值小于第一压力阈值时，执行第一内存回收策略；当所述内存申请压力值大于或等于所述第一压力阈值时，执行第二内存回收策略。其中，所述第二内存回收策略的回收效率大于所述第一内存回收策略的回收效率。

在一种可能实现方式中，所述第一内存回收策略为常规内存回收，所述第二内存回收策略为查杀后台应用。

在一种可能实现方式中，所述方法还包括：响应于所述第一应用的申请内存请求，按照所述第一应用的申请内存量，从所述系统内存中的所述剩余空闲内存为所述第一应用分配内存。

第二方面，本申请提供一种控制内存回收的装置，该装置包括用于执行上述第一方面中的方法的单元。该装置可对应于执行上述第一方面中描述的方法，该装置中的单元的相关描述请参照上述第一方面的描述，为了简洁，在此不再赘述。

其中，上述第一方面描述的方法可以通过硬件实现，也可以通过硬件执行相应的软件实现。硬件或软件包括一个或多个与上述功能相对应的模块或单元。例如，处理模块或单元、显示模块或单元等。

第三方面，本申请提供一种电子设备，所述电子设备包括处理器、处理器以及存储器中存储的计算机程序或指令，处理器用于执行计算机程序或指令，使得第一方面中的方法被执行。

第四方面，本申请提供一种计算机可读存储介质，其上存储有用于实现第一方面中的方法的计算机程序（也可称为指令或代码）。例如，该计算机程序被计算机执行时，使得该计算机可以执行第一方面中的方法。

第五方面，本申请提供一种芯片，包括处理器。处理器用于读取并执行存储器中存储的计算机程序，以执行第一方面及其任意可能的实现方式中的方法。可选地，所述芯片还包括存储器，存储器与处理器通过电路或电线连接。

第六方面，本申请提供一种芯片系统，包括处理器。处理器用于读取并执行存储器中存储的计算机程序，以执行第一方面及其任意可能的实现方式中的方法。可选地，所述芯片系统还包括存储器，存储器与处理器通过电路或电线连接。

第七方面，本申请提供一种计算机程序产品，所述计算机程序产品包括计算机程序（也可称为指令或代码），所述计算机程序被电子设备执行时使得电子设备实现第一方面中的方法。

可以理解的是，上述第二方面至第七方面的有益效果可以参见上述第一方面中的相关描述，在此不再赘述。

附图说明

图1为本申请实施例中的页缓存的流程示意图；

图2为本申请实施例中的系统内存的示意图；

图3为本申请实施例中APP申请内存以及向APP分配内存的流程示意图；

图4为本申请实施例中两种系统内存容量场景下后台保活APP的对比示意图；

图5为相关技术根据内存可用量确定内存回收方式的流程示意图；

图6为本申请实施例提供的一种电子设备的结构示意图；

图7为本申请实施例提供的一种电子设备的软件架构示意图；

图8为本申请实施例提供的一种控制内存回收的方法中各模块交互的时序示意图；

图9为本申请实施例提供的控制内存回收的方法的流程示意图一；

图10为本申请实施例提供的控制内存回收的方法中存储器存储数据的示意图；

图11为本申请实施例提供的控制内存回收的方法的流程示意图二；

图12为本申请实施例提供的控制内存回收的方法中计算内存申请压力值的示意图；

图13为本申请实施例提供的控制内存回收的方法中多种内存回收策略的对比示意图；

图14为本申请实施例提供的控制内存回收的方法中的页缓存回收示意图；

图15为本申请实施例提供的控制内存回收的方法中的多种内存回收策略的区间示意图；

图16为本申请实施例提供的控制内存回收的方法的流程示意图三；

图17为本申请实施例提供的控制内存回收的方法的流程示意图四；

图18为本申请实施例提供的控制内存回收的方法的流程示意图五；

图19为本申请实施例提供的控制内存回收的装置的结构示意图。

具体实施方式

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

本文中术语“和/或”，是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。本文中符号“/”表示关联对象是或者的关系，例如A/B表示A或者B。

本文中的说明书和权利要求书中的术语“第一”和“第二”等是用于区别不同的对象，而不是用于描述对象的特定顺序。在本申请实施例的描述中，除非另有说明，“多个”的含义是指两个或者两个以上，例如，多个处理单元是指两个或者两个以上的处理单元等；多个元件是指两个或者两个以上的元件等。

在本申请实施例中，“示例性的”或者“例如”等词用于表示作例子、例证或说明。本申请实施例中被描述为“示例性的”或者“例如”的任何实施例或设计方案不应被解释为比其它实施例或设计方案更优选或更具优势。确切而言，使用“示例性的”或者“例如”等词旨在以具体方式呈现相关概念。

为便于理解本申请实施例，以下对本申请实施例的部分用语进行解释说明，以便于本领域技术人员理解。

（1）页缓存

文件通常存放在硬盘中，CPU并不能直接访问硬盘中的数据，而是需要先将硬盘中的数据读入到内存中，然后数据才能被CPU访问。Linux内核使用页缓存机制来对文件中的数据进行缓存。即，在内存中会为每个文件创建一个缓存，因为缓存的单位是页，所以称为页缓存。其中，页缓存包括文件页缓存（FileCache）和匿名页缓存。内核缓存的磁盘数据和内核缓存的文件数据都称为文件页。

如图1所示，当用户对文件进行读写时，实际上是对文件的页缓存进行读写，所以对文件进行读写操作时，会分以下两种情况进行处理：

情况一：当从文件中读取数据时，如果要读取的数据所在的页缓存已经存在，那么就直接把页缓存的数据拷贝给用户即可。如果要读取的数据所在的页缓存不存在，那么内核首先会申请一个空闲的内存页（页缓存），然后从文件中读取数据到页缓存，并且把页缓存的数据拷贝给用户。

情况二：当向文件中写入数据时，如果要写入的数据所在的页缓存已经存在，那么直接把新数据写入到页缓存即可。如果要写入的数据所在的页缓存不存在，那么内核首先会申请一个空闲的内存页（页缓存），然后从文件中读取数据到页缓存，并且把新数据写入到页缓存中。对于被修改的页缓存，内核会定时把这些页缓存刷新到文件中。

（2）内存回收（garbage collection，GC）

GC也称为垃圾回收，指通过GC线程对堆中的孤立对象进行回收，以释放内存空间的一种内存回收机制。其中，GC线程用于管理堆中的对象，可以对堆中的对象进行标记、整理以及删除孤立对象等，用于释放那些不再使用的对象所占用的内存。内存回收的目的在于清除不再使用的对象，通过回收被无用对象占用的内存空间，使该内存空间可被程序再次使用。

随着Linux系统不断分配内存，当系统内存压力越来越大时，就会口进行内存回收，内存回收主要是针对匿名页和文件页进行的。对于匿名页，内存回收过程中会筛选出一些不经常使用的匿名页，将它们写入到swap分区中，然后作为空闲页框释放。而对于文件页，内存回收过程中也会筛选出一些不经常使用的文件页，如果此文件页中保存的内容与磁盘中文件对应内容一致，说明此文件页是一个干净的文件页，就不需要进行回写，直接将此页作为空闲页框释放，相反，如果文件页保存的数据与磁盘中文件对应的数据不一致，则认定此文件页为脏页，需要先将此文件页回写到磁盘中对应数据所在位置上，然后再将此页作为空闲页框释放。这样当内存回收完成后，系统空闲的页框数量就会增加，能够缓解内存压力。

（3）系统内存

系统内存也称为运行内存，指电子设备（如手机）运行程序时使用的内存。系统内存只能临时存储数据，用于与CPU交换高速缓存数据。这种存储器在断电时将丢失其存储内容，故主要用于存储短时间使用的程序。例如，手机的系统内存为随机存取存储器（RAM）。

通常，系统内存的一部分内存会被应用进程占用，以及另一部分内存会被页缓存占用，并且还有一部分预留内存，即剩余空闲内存。在剩余空闲内存紧张时，有必要释放页缓存，或者杀掉应用进程，实现内存回收。在页缓存中，文件页可直接释放内存，匿名页不能直接释放内存。

这里结合图2示例性地说明电子设备的系统内存的分配及回收场景。如图2中的（a）和（b）所示，系统内存包括已占用内存和未占用内存这两部分，未占用内存可称为剩余空闲内存（FreeRam）。其中，已占用内存包括应用进程占用的内存，该应用进程占用的内存包括文件页和匿名页这两类页缓存。电子设备根据实际使用需求对系统内存进行分配。

需要说明的是，为了保证电子设备有足够的预留内存空间以保持正常运行，通常要求剩余空闲内存不能低于某一阈值（例如100MB）。参考图2中的（b），当剩余空闲内存低于某一阈值时，电子设备内核就会启动常规内存回收功能，常规内存回收包括回收文件页和回收匿名页。

需要说明的是，除了采用常规内存回收之外，在必要时还可以执行查杀后台应用来回收内存。相关技术中，根据可用内存量和查杀阈值（也称为查杀线）的比较结果，确定是否查杀后台应用来回收内存。

示例性地，如图3所示，当电子设备的某一应用（application，APP）启动时，该APP向电子设备系统申请内存。电子设备可以根据可用内存量和查杀阈值（也称为查杀线）的比较结果来选择是采用常规内存回收策略，还是采用查杀后台应用方式。

这里需要说明的是，无论是采用哪种内存回收策略，APP真正申请到的内存都是需要从剩余空闲内存（FreeRam）获取的。

需要注意，在相关技术中，可用内存量的取值为剩余空闲内存与文件页缓存的求和值。也就是说，可用内存量是在当前剩余空闲内存（FreeRam）的基础上，加上从文件页缓存（FileCache）回收得到的内存量。

相关技术根据这个求和值和查杀阈值的比较结果进行评估，以确定是否需要查杀后台应用。下面以查杀阈值为1.5 GB为例示例性说明在打开应用过程中的内存供给情况。

情况一，当可用内存量大于查杀阈值1.5GB时，可用内存充足，此时默认采用常规内存回收，即回收文件页和回收匿名页。在此情况下，电子设备内核从剩余空闲内存（FreeRam）获取内存资源，供前台APP使用。

情况二，当可用内存量小于或等于查杀阈值1.5GB时，可用内存紧张，此时可以通过查杀后台应用方式，快速释放后台APP占用的内存。在此情况下，电子设备内核从剩余空闲内存（FreeRam）获取内存资源，供前台APP使用。

相比而言，常规内存回收效率相对较慢，查杀后台应用的回收效率相对较快。

以上说明了目前在应用申请内存时的内存回收及供给策略，下面说明本申请实施例在应用申请内存时的内存回收及供给策略方面所要解决的技术问题。

随着电子设备和存储器技术的飞速发展，电子设备不断更新换代，电子设备的系统内存容量也越来越大。例如，以前大部分手机的系统内存容量为8GB或者更小，现阶段大部分手机的系统内存容量为12GB或16GB甚至更大。

这里需要说明的是，Linux系统所采用的系统内存使用原则为物尽其用，即在保证基本预留内存（如100MB）的情况下，尽量让内存能够被更多的业务使用。图4示出了系统内存容量为8GB的手机和系统内存容量为12GB的手机各自的内存占用状态的示意图。如图4所示，在8GB手机上，可以保活9个APP；在12GB手机上，会尽量多的保活应用，例如可以保活12个APP或者可以保活更多个APP。同时可以看到，在8GB手机和12GB手机上，当系统达到平衡后，剩余空闲内存都约为100MB。

然而，随着系统内存容量的增大，会出现系统运行卡顿的现象，原因在于：现有的内存供给策略是依赖于可用内存量来决定的。以系统内存容量为12GB的手机为例，由于12GB手机后台保活的APP较多，因此文件页缓存（FileCache）也会相应地较多，导致系统的可用内存量（可用内存量等于剩余空闲内存加上文件页缓存）一直处于较充足的水平，这就导致在12GB手机上，系统会一直会采取常规内存回收方式进行内存供给。由于这种回收方式相对较慢，内存供给效率相对较低，因此会造成对前台应用的内存供给不足，从而引发卡顿现象。

图5示出了相关技术提供的内存供给方法的流程示意图。如图5所示，该方法包括S101-S106。

S101，APP申请内存。

例如，当某一APP启动时，该APP会向系统申请相应的运行内存，以实现该APP的正常运行。

S102，电子设备判断可用内存量（记为M）是否大于查杀阈值（如1.5GB）。

其中，可用内存量=剩余空闲内存（FreeRam）+文件页缓存（FileCache）。

其中，剩余空闲内存（FreeRam）通常约为100MB。

需要注意的是，文件页缓存（FileCache）的大小取决于电子设备正在运行的应用的数量，即正在运行的应用越多，文件页缓存（FileCache）也越多。

在相关技术中，电子设备根据可用内存大小来确定内存回收方式。具体地，当电子设备判断可用内存量大于查杀阈值时，电子设备继续执行S103-S104，即执行常规内存回收机制。当电子设备判断可用内存量小于或等于查杀阈值时，电子设备继续执行S105-S106，即通过查杀后台应用进行内存回收。

S103，电子设备执行常规内存回收机制。

其中，常规内存回收机制包括回收文件页和回收匿名页，这种方式回收效率相对较低。

S104，电子设备从剩余空闲内存（FreeRam）为APP分配内存。

S105，电子设备通过查杀后台应用，释放后台APP占用的内存。

其中，一旦查杀后台应用被触发，则电子设备执行对后台应用的查杀，能够快速释放内存资源，因此这种回收方式响应速度较高，即回收快。

在电子设备查杀后台应用之后，电子设备从剩余空闲内存（FreeRam）为APP分配内存。

这里需要说明的是，上述方法仅适用于较小系统内存（如8GB）的应用场景，但是随着系统内存容量的增大，后台保活的APP增多，相应的文件页缓存也增多，导致上述方法不再适用于较大系统内存（如12GB及以上）的应用场景。

这是因为，可用内存量等于剩余空闲内存（FreeRam）与文件页缓存（FileCache）的总和，在当前较大系统内存（如12GB及以上）的应用场景中，在剩余空闲内存（FreeRam）一定的情况下，随着文件页缓存（FileCache）增多，可用内存量（可用内存量等于剩余空闲内存加上文件页缓存）也会增多，这样可用内存量会始终大于查杀阈值，导致电子设备持续采取常规内存回收机制，陷入持续采用常规内存回收GC的死循环，而没有机会执行查杀后台应用的方式，由于常规内存回收机制响应速度较低，因此必然会引起卡顿。

针对上述问题，本申请实施例提供一种控制内存回收的方法及电子设备，通过在手机系统底层进行改进，以改善电子设备的内存回收策略，提升用户使用体验。

通过本申请方案，可以预先记录每次APP申请内存时的需回收内存量及申请时刻等相关数据，当前台应用申请内存时，可根据记录的相关数据计算最近一段时间内的内存申请压力值，并根据内存申请压力值来衡量系统内存当前实际压力状态，由此根据压力状态确定执行哪一种内存回收策略，例如在高压力情况下会触发后台应用查杀逻辑，快速释放内存。通过本申请方案，能够准确地衡量系统内存的实际压力状态，并采用当前压力状态对应的内存回收策略进行内存回收，因此能够有效地为前台APP提供内存资源，避免出现卡顿现象。

本申请实施例提供的控制内存回收的方法，应用于电子设备。本申请实施例中的电子设备可以为移动终端，也可以为非移动终端。示例性的，移动终端可以为手机、平板电脑、笔记本电脑、掌上电脑、车载终端、可穿戴设备、超级移动个人计算机（ultra-mobilepersonal computer，UMPC）、上网本或者个人数字助理（personal digital assistant，PDA）等，非移动终端可以为个人计算机（personal computer，PC）、电视机（television，TV）、柜员机或者自助机等，本申请实施例不作具体限定。

参见图6，为本申请实施例提供的一种电子设备的结构示意图。电子设备100可以包括处理器110，内部存储器120，外部存储器接口121，通用串行总线（universal serialbus，USB）接口130，充电管理模块140，电源管理模块141，电池142，天线1，天线2，移动通信模块150，无线通信模块160，音频模块170，扬声器170A，受话器170B，麦克风170C，耳机接口170D，传感器模块180，按键190，马达191，指示器192，摄像头193，显示屏194，以及用户标识模块（subscriber identification module，SIM）卡接口195等。其中传感器模块180可以包括压力传感器180A，陀螺仪传感器180B，磁传感器180D，加速度传感器180E，距离传感器180F，接近光传感器180G，指纹传感器180H，触摸传感器180K，环境光传感器180L等。

可以理解的是，本申请实施例示意的结构并不构成对电子设备100的具体限定。在本申请另一些实施例中，电子设备100可以包括比图示更多或更少的部件，或者组合某些部件，或者拆分某些部件，或者不同的部件布置。图示的部件可以以硬件，软件或软件和硬件的组合实现。

处理器110可以包括一个或多个处理单元，例如：处理器110可以包括应用处理器（application processor，AP），调制解调处理器，图形处理器（graphics processingunit，GPU），图像信号处理器（image signal processor，ISP），控制器，存储器，视频编解码器，数字信号处理器（digital signal processor，DSP），基带处理器，和/或神经网络处理器（neural-network processing unit，NPU）等。其中，不同的处理单元可以是独立的器件，也可以集成在一个或多个处理器中。例如，处理器110用于执行本申请实施例中的控制内存回收的方法。

其中，控制器可以是电子设备100的神经中枢和指挥中心。控制器可以根据指令操作码和时序信号，产生操作控制信号，完成取指令和执行指令的控制。

处理器110中还可以设置存储器，用于存储指令和数据。在一些实施例中，处理器110中的存储器为高速缓冲存储器。该存储器可以保存处理器110刚用过或循环使用的指令或数据。如果处理器110需要再次使用该指令或数据，可从存储器中直接调用。避免了重复存取，减少了处理器110的等待时间，因而提高了系统的效率。

内部存储器120，也可以称为“内存”或“系统内存”，可以用于存储计算机可执行程序代码，可执行程序代码包括指令。处理器通过运行存储在存储器的指令，从而执行网络设备的各种功能应用以及数据处理。内部存储器120可以包括存储程序区和存储数据区。其中，存储程序区可存储操作系统、至少一个功能所需的应用程序（比如声音播放功能、图像播放功能等）等；存储数据区可存储根据手机的使用所创建的数据（比如音频数据、电话本等）等。此外，内部存储器120可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。

外部存储器121一般指外存储器，在本申请实施例中，外部存储器是指除电子设备的内存及处理器的高速缓存以外的储存器，该储存器一般为非易失性存储器。

显示屏194用于显示图像，视频等。显示屏194包括显示面板。显示面板可以采用有机发光二极管（organic light-emitting diode，OLED）。在一些实施例中，电子设备100可以包括1个或更多个显示屏194。

电子设备100通过GPU，显示屏194，以及应用处理器等实现显示功能。GPU为图像处理的微处理器，连接显示屏194和应用处理器。GPU用于执行数学和几何计算，用于图形渲染。处理器110可包括一个或多个GPU，其执行程序指令以生成或改变显示信息。

以上是以电子设备100为例对本申请实施例作出的具体说明。应该理解的是，本申请实施例示意的结构并不构成对电子设备100的具体限定。电子设备100可以具有比图中所示的更多的或者更少的部件，可以组合两个或多个的部件，或者可以具有不同的部件配置。图中所示出的各种部件可以在包括一个或多个信号处理和/或专用集成电路在内的硬件、软件、或硬件和软件的组合中实现。

另外，在电子设备的上述部件之上，运行有操作系统，例如苹果公司所开发的iOS操作系统，谷歌公司所开发的Android开源操作系统，或者微软公司所开发的Windows操作系统等，在操作系统上可以安装运行应用程序。

电子设备100的操作系统可以采用分层架构，事件驱动架构，微核架构，微服务架构，或云架构。本申请实施例以分层架构的Android系统为例，示例性说明电子设备100的软件结构。

图7是本申请实施例的电子设备100的软件结构框图。

分层架构将软件分成若干个层，每一层都有清晰的角色和分工。层与层之间通过软件接口通信。在本申请实施例中，分层架构包括应用程序层（applications），应用程序框架层（application framework），以及内核层（kernel）。

其中，应用程序层可以包括安卓操作系统中的各个应用程序（包括系统应用程序和第三方应用程序）。为了便于说明，在本申请实施例中将电子设备正在运行的所有应用划分为在前台运行的应用（前台APP）以及在后台运行的应用（称为后台APP）。

例如，如图7所示，在本申请实施例中，应用程序层包括一个前台APP，以及多个后台APP，例如后台APP1，后台APP2以及后台APP3。

应用程序框架层为应用程序层的应用程序提供应用编程接口（applicationprogramming interface，API）和编程框架。应用程序框架层包括一些预先定义的函数。应用程序框架层是应用程序的框架，开发人员可以在遵守应用程序的框架的开发原则的情况下，基于应用程序框架层开发一些应用程序。

例如，在本申请实施例中，应用程序框架层可以包括内存管理模块和应用查杀模块等。

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

内核层是安卓操作系统的操作系统层，属于安卓操作系统软件层次的最底层。内核层属于硬件和软件之间的层。内核层基于Linux内核为安卓操作系统提供核心系统服务和与硬件相关的驱动程序。内核层至少包含显示驱动，摄像头驱动，音频驱动，传感器驱动。

例如，在本申请实施例中，内核层包括内存回收算法模块、内存申请监控模块，后台应用查杀逻辑模块、常规内存回收逻辑模块以及文件页回收逻辑模块。其中，内存申请监控模块具有监控APP申请内存事件的功能。在内存申请监控模块监控到发生APP申请内存事件时，内存申请监控模块向内存回收算法模块通知APP申请内存事件。内存回收算法模块可以本申请实施例提供的内存申请压力算法来计算内存申请压力值。其中，该内存申请压力算法的具体算法逻辑将在下文详细描述。

为了更好地理解本申请实施例，这里结合图7所示的软件架构对本申请实施例进行简要说明：

在本申请实施例中，当某一应用启动时，该应用申请内存。该应用为应用程序层的前台APP，此时电子设备在后台还运行有多个APP，如后台APP1，后台APP2以及后台APP3。

应用程序层向应用框架层发下申请内存请求，为前台APP申请内存。应用框架层的内存管理模块接收到前台APP发送的申请内存请求。内核层的内存申请监控模块监控到APP申请内存事件，并通知内核层的内存回收算法模块。内存回收算法模块根据本申请实施例提供的内存申请压力算法来计算内存申请压力值。然后根据内存申请压力值确定合适的内存回收策略，然后为前台APP分配内存。

在本申请实施例中，当内存申请压力值在预设压力阈值范围内时，内存回收算法模块确定与预设压力阈值范围对应的内存回收策略。

回收策略1：当内存申请压力值小于第一压力阈值（如50MB/ms）时，内存回收算法模块确定通过常规内存回收策略进行内存回收。常规内存回收策略包括回收文件页和回收匿名页。

回收策略2：当内存申请压力值大于或等于第一压力阈值且小于第二压力阈值（如150MB/ms）时，内存回收算法模块确定通过只回收文件页进行内存回收。

回收策略3：当内存申请压力值大于或等于第二压力阈值时，内存回收算法模块确定通过查杀后台应用方式实现内存回收。

通过上述三种策略中的至少一种策略进行内存回收，然后从剩余空闲内存（FreeRam）为前台APP分配内存。

示例性地，这里以查杀后台应用策略进行举例说明。内核层向应用程序框架层上报查杀后台应用的消息。应用程序框架层通过后台应用查杀模块进行后台应用查杀。

在一些实施例中，按照后台应用占用的内存量从大到小的顺序来查杀后台应用，即占用的内存量越大的后台应用，其进程优先被终止。示例性地，后台APP1，后台APP2以及后台APP3分别占用不同的内存量，假设后台APP3占用的内存量最大，因此后台APP3的进程优先被终止，释放内存资源。按此方式查杀后台应用，直到释放足够的内存为止。

在另一些实施例中，按照后台应用各自的最近使用频率从低到高的顺序来查杀后台应用，即最近使用频率越小的后台应用，其进程优先被终止。示例性地，假设后台APP3最近使用频率最小，如空闲时间最长，因此后台APP3的进程优先被终止，释放内存资源。按此方式查杀后台应用，直到释放足够的内存为止。

内存回收算法模块从剩余空闲内存（FreeRam）调取内存分配给前台APP，并向应用程序框架层上报分配内存消息。应用程序框架层的内存管理模块接收到该分配内存消息，并将从剩余空闲内存（FreeRam）调取的内存分配给前台APP。

需要说明的是，确定内存回收策略的步骤以及向前台APP分配内存的步骤，这两个步骤的执行顺序可以根据实际情况进行确定。

例如，在一些实施例中，在应用申请内存之后，确定及执行内存回收策略，同时从剩余空闲内存（FreeRam）调取内存分配给前台APP，这两个步骤可以并行处理。

再例如，在另一些实施例中，在应用申请内存之后，当剩余空闲内存（FreeRam）不足时，可以先确定内存回收策略，在执行所确定的内存回收策略之后，剩余空闲内存（FreeRam）增大，再从剩余空闲内存（FreeRam）调取内存分配给前台APP，这两个步骤需要串行处理。

需要说明的是，本申请实施例虽然以Android系统为例进行说明，但是其基本原理同样适用于基于iOS或Windows等操作系统的电子设备。

本申请实施例提供的控制内存回收的方法的执行主体可以为上述的电子设备，也可以为该电子设备中能够实现该控制内存回收的方法的功能模块和/或功能实体，并且本申请方案能够通过硬件和/或软件的方式实现，具体的可以根据实际使用需求确定，本申请实施例不作限定。下面以电子设备为例，结合附图对本申请实施例提供的控制内存回收的方法进行示例性的说明。

首先结合图8从整体角度说明本申请实施例提供的控制内存回收的方法。需要说明的是，为了便于理解和说明，图8中主要示出了前台APP、内核层模块以及后台应用查杀模块，在实际实现时还会涉及其他模块，其中内核层模块可能涉及不同功能的多个子模块，具体可以根据实际情况确定。参照图8，该方法包括下述的步骤S201-S207。

S201，内核层模块监听到前台APP有内存申请需求。

S202，内核层模块根据内存申请量和剩余空闲内存量，计算需回收内存量。

其中，可以通过计算内存申请量和剩余空闲内存量的差值，得到需回收内存量。详细计算过程将在下文描述。

S203，内核层模块将需回收量和申请时刻构成的数据对存储到缓存器中。

S204，获取缓存器中已存储的多个数据对，计算内存申请压力值。

其中，可以根据多个数据对，计算最近一段时间需回收内存量的平均值，根据该平均值衡量内存申请压力。内存申请压力值等于该平均值。详细计算过程将在下文描述。

S205，将内存申请压力值与压力阈值进行比较，判断压力等级。

在一种实施例中，可以预设一个压力阈值，在此情况下存在两个压力值区间，相应地有两个压力等级，例如定义为无压力等级和有压力等级。

在另一种实施例中，可以预设两个压力阈值，在此情况下存在三个压力值区间，相应地有三个压力等级，例如定义为无压力等级、低压力等级和高压力等级。

在再一种实施例中，可以预设三个或更多个压力阈值，在此情况下存在四个或更多个压力值区间，相应地有四个或更多个压力等级，具体可以根据实际使用需求确定，本申请实施例不作限定。

S206，在高压力情况下，内核层模块向后台应用查杀模块发送查杀后台应用的消息。

S207，后台应用查杀模块接收到查杀后台应用的消息，触发后台应用查杀逻辑。

不同于相关技术中采用可用内存量来确定具体执行哪一种内存回收策略，本申请实施例可以根据内存申请压力值，衡量当前系统内存的实际可用程度。这种方式能够准确地衡量可用内存的实际情况，并在高压力情况下会触发后台应用查杀逻辑，快速释放内存。通过本申请方案，能够基于实际需求有效地为前台APP提供内存，避免出现卡顿现象。

下面结合具体的实施例分阶段介绍本申请实施例提供的控制内存回收的方法。

第一阶段：预先记录APP申请内存时的相关数据（，T）

图9是本申请实施例一提供的控制内存回收的方法的流程示意图。参照图9，该方法包括下述的步骤S301-S303。

S301，电子设备判断是否监听到APP申请内存事件。

其中，APP申请内存事件指某一APP向系统申请内存的事件。例如，在APP开始启动时，APP需要启动相应的进程，此时APP会向系统申请内存。再例如，在APP启动后，当APP运行某个功能时，例如APP加载新的页面时会启动相应的进程，此时APP也会向系统申请内存。

需要说明的是，电子设备的内核层会实时监听应用层是否有APP申请内存事件。例如，当应用层的某一APP（称为第一APP）申请内存时，电子设备的内核层可以监听到发生APP申请内存事件。

当监听到发生APP申请内存事件时，继续执行下述的步骤S302和S303。

S302，根据APP申请内存量和剩余空闲内存量，计算本次的需回收内存量。

本申请实施例中主要涉及的关键变量包括：内存申请量（ReqMem，记为Mr）、剩余空闲内存量（CurMem，记为Mc）、需回收内存量（MemGap，记为）、申请时刻（CurTime，记为T）。其中，剩余空闲内存量Mc也称为当前空闲内存量。

在本申请实施例中，参见下述的等式1，可以通过计算申请内存量Mr和剩余空闲内存量Mc之间的差值，得到本次的需回收内存量。

（等式1）

S303，将数据对（需回收内存量，申请时刻T）存储到缓存器中。

在计算得到需回收内存量之后，将需回收内存量/>和本次的申请时刻T存储到缓存器中。其中，需回收内存量/>和申请时刻T构成一个数据对（/>，T）。

其中，缓存器为固定容量的先入先出类型的存储器。在本申请实施例中，可以依次存储数据对（1，T1）、（/>2，T2）…（/>n，Tn），形成缓存器队列。在超过缓存器的固定存储存量的情况下，先存入的数据将被丢掉，这样可以不断存入新的数据对。

示例性地，缓存器可以为环形缓冲区（ring buffer），缓冲区中数据满足先进先出原则。

如图10中的（a）所示，存储器中存储有数据对（50，1）、（100，3）、（20，5）、（20，6）、（30，7）和（40，8），其中（40，8）为最新存储的数据对，（50，1）为最早存储的数据对。

存储器中会不断存入新的数据对，先存入的数据将被丢掉。如图10中的（b）所示，存储器中存储有数据对（100，3）、（20，5）、（20，6）、（30，7）、（40，8）和（50，15），其中（50，15）为存储器中当前最新存储的数据对。最早存入的数据对（50，1）被丢掉，这样可以不断存入新的数据对。

在S302之后，循环执行S301-S303。相应地，可以记录多个数据对（，T）。

在一些实施例中，可以采用数组形式记录（，T），得到多个数组（/>1，T1）、（2，T2）…（/>n，Tn）。

在另一些实施例中，可以采用表格形式记录（，T），如下述表2所示。

表2

每当有APP申请内存时，计算一次需回收内存量，并记录数据对（需回收内存量/>，申请时刻T），并将该数据对存储到存储器中。随着各个APP分别申请内存，存储器中依次存储多个数据对（/>，T）。

第二阶段：根据相关数据（，T）计算内存申请压力值

结合图9，如图11所示，在S303之后，控制内存回收的方法还包括S304和S305。

S304，从缓存器中获取最近缓存的预设数量的数据对（，T）。

其中，预设数量可以根据实际使用需求进行设置，本申请实施例对此不作限定。

在一些实施例中，可以从缓存器队列中选择一部分数据对，即从缓存器队列中选择预设窗长（calc_window）的历史值，作为最近缓存的预设数量的数据对。

在另一些实施例中，可以选择缓存器队列中的全部数据，作为最近缓存的预设数量的数据对。

下面以从缓存器队列中选择一部分数据对，作为最近缓存的预设数量的数据对为例进行示例性地说明。

示例性地，图12示出了在不同时刻从缓存器中获取最近缓存的预设数量的数据对的示意图。其中，假设缓存器队列中总共可以缓存六个数据对，预设数量设置为3个。

如图12中的（a）所示，缓存器队列中总共缓存了六个数据对，分别为（50，1）、（100，3）、（20，5）、（20，6）、（30，7）和（40，8）。在时刻1时，可以获取最近缓存的预设数量的数据对为（20，6）、（30，7）和（40，8）。

如图12中的（b）所示，缓存器队列中总共缓存了另外六个数据对，分别为（30，7）、（40，8）、（50，15）、（100，17）、（60，19）、（100，21）。在时刻2时，可以获取最近缓存的预设数量的数据对为（100，17）、（60，19）、（100，21）。

需要说明的是，时刻2晚于时刻1。这里为了便于说明，各个数据对中的申请时刻采用递增的数字表示。在实际实现时，申请时刻采用规范的时分秒的计时方式进行表示。

S305，将获取的数据对中的所有求和，得到需回收内存总量（记为S）；并将获取的数据对中的最后时刻和首个时刻求差值，得到时间差（记为/>）；计算S和/>的比值，得到内存申请压力值（记为P）。

在本申请实施例中，采用下述的等式2、等式3和等式4，计算内存申请压力值P。

（等式2）

（等式3）

（等式4）

其中，Tn表示获取的数据对中的最后时刻，T1表示获取的数据对中的首个时刻。其中，P为正整数。

需要说明的是，在计算内存申请压力值P时，取缓存器队列中预设窗长中的历史值，计算预设窗长内的需回收内存总量及时间间隔，两者相除数值越大，代表较短时间内内存申请较多，即申请压力较大。

示例性地，参考图12中的（a）所示，在时刻1，最近缓存的预设数量的数据对取（20，6）、（30，7）和（40，8），其中，首个时刻为6，最后时刻为8。相应地，根据上述等式2、等式3和等式4可以计算得到内存申请压力值：

在时刻1，内存申请压力值为45MB/ms。

示例性地，参考图12中的（b）所示，在时刻2，最近缓存的预设数量的数据对取（100，17）、（60，19）、（100，21），其中，首个时刻为17，最后时刻为21。相应地，根据上述等式2、等式3和等式4可以计算得到内存申请压力值：

在时刻1，内存申请压力值为65MB/ms。

相比而言，时刻2的内存申请压力值大于时刻1的内存申请压力值。

在计算得到内存申请压力值之后，可以根据内存申请压力值选择内存回收策略，下面将结合附图进行详细说明。

第三阶段：根据内存申请压力值P选择内存回收策略

本申请实施例提供了一套内存申请压力评估机制，即基于内存申请压力值进行评估，确定合适的内存回收策略。

首先需要说明的是，根据上文描述内容可知，在系统容量变大后，后台保活APP增多，对应的文件页缓存也增多，这样相关算法统计的可用内存量是较大的，因此可用内存量一直会大于查杀阈值，导致一直采用常规内存回收策略进行内存回收，而没有机会查杀后台应用，由于常规内存回收效率较低，很容易引起卡顿现象。鉴于此，要想优化此类卡顿现象，本申请提出从两方面着手：

第一方面，提高内存回收效率，保障前台APP内存供给，以避免卡顿现象。

举例来说，在Linux内核的内存回收机制中，主要回收文件页、匿名页和内核数据结构（SLAB）这三种内存。对于回收效率来说，文件页回收效率最高，匿名页回收效率最低，SLAB介于两者之间。鉴于此，本申请实施例提出，为了提高内存回收效率，可以在一次回收过程中，多回收文件页，少回收匿名页，即以不同回收比例来回收文件页和匿名页，文件页的回收比例大于匿名页的回收比例。或者，为了提高内存回收效率，在内存申请压力较大的场景下，只回收文件页，提升内存回收效率。

第二方面，及时上报内存回收压力，根据内存申请压力确定合适的内存回收策略，例如上层逻辑在内存申请压力较大时会触发查杀后台应用，快速释放内存，能够避免卡顿现象。

本申请实施例结合上述两个方面，提供了根据内存申请压力值确定内存回收策略的实现方式，下面结合附图对本申请实施例提供的控制内存回收的方法进行详细说明。

本申请实施例中，可以根据实际使用需求设置多种内存回收策略，分别具有不同的内存回收效率。在实际实现时，可以基于内存申请压力大小，选择对应内存回收效率的内存回收策略。例如，若内存申请压力值较大，则选择较高内存回收效率的内存回收策略；若内存申请压力值较小，则选择较小内存回收效率的内存回收策略。具体内存回收策略的划分，可以根据实际使用需求设置，本申请实施例不作限定。

例如，在一些实施例中，如图13中的（a）所示，可以设置如下三种内存回收策略：常规内存回收、只回收文件页、查杀后台应用。其中，常规内存回收这种方式包括回收文件页和回收匿名页，受匿名页回收效率低的影响，常规内存回收效率低，相应地内存供给效率也低。相对而言，由于只回收文件页这种方式不受匿名页回收效率低的影响，因此只回收文件页的回收效率高于常规内存回收的回收效率。图14中的（a）示出了只回收文件页的示意图。

如图13中的（a）所示，常规内存回收、只回收文件页、查杀后台应用这三种内存回收策略，内存回收效率依次增高，相应地，内存供给效率也依次增高。其中，当采用查杀后台应用进行内存回收时，回收内存效率最高，相应地系统为前台APP提供内存的效率（简称内存供给效率）也最快。

再例如，在另一些实施例中，如图13中的（b）所示，可以设置如下三种内存回收策略：常规内存回收、高比例回收文件页及低比例回收匿名页、查杀后台应用。其中，高比例回收文件页且低比例回收匿名页这种方式，受匿名页回收效率低的影响有所抑制，因此这种方式回收内存效率高于常规内存回收策略。图14中的（b）示出了高比例回收文件页及低比例回收匿名页的示意图。

如图13中的（b）所示，常规内存回收、高比例回收文件页且低比例回收匿名页、查杀后台应用这三种内存回收策略，内存回收效率依次增高，相应地，内存供给效率也依次增高。

为了便于说明，本申请实施例以常规内存回收、只回收文件页、查杀后台应用这三种内存回收策略为例进行示例性说明。

在设置多种内存回收策略的情况下，本申请实施例会针对每种内存回收策略，设置一个压力值区间，每个压力值区间定义一个压力等级。在计算得到内存申请压力值之后，判断内存申请压力值位于哪一个压力值区间，即可确定选择哪一种内存回收策略。

示例性地，在本申请实施例中，可以预设压力等级、预设的压力值区间、预设的内存回收策略之间的一一对应关系。表1示例性地示出了多个对应关系。

表1

如表1所示，三个压力等级分别为无压力等级、低压力等级和高压力等级，随着压力等级增大，压力程度依次增大。其中，无压力高压力等级对应的压力值区间为第一区间[0, L0），以及对应的内存回收策略为常规内存回收。低压力等级对应的压力值区间为第二区间[L0, L1），以及对应的内存回收策略为只回收文件页。高压力等级对应的压力值区间为第三区间[L1, ∞），以及对应的内存回收策略为查杀后台应用。

其中，L0小于L1。L0和L1分别表示各个压力等级的门限值。示例性地，L0为50MB/ms，L1为150MB/ms。需要说明的是，在实际实现时，门限值可以根据实际使用需求进行设置，本申请实施例对此不作限定。下面以L0为50MB/ms，L1为150MB/ms为例进行示例性说明。

需要说明的是，表1所示为示例性的举例说明，在实际实现时，压力等级数量、预设的压力值区间、预设的内存回收策略分别可以根据实际使用需求进行设置，本申请实施例对此不作限定。例如，可以预设更多个压力等级。再例如，每个等级对应的内存回收策略可以包括一个或更多个内存回收方式。示例性地，可以同时回收文件页和回收匿名页，其中回收文件页的比例大于回收匿名页的比例。

举例来说，参考图15，在计算得到内存申请压力值（记为P）之后，判断内存申请压力值P落在哪个压力值区间内，如果判断内存申请压力值P＜L0，落在第一区间[0, L0）内，由于第一区间[0, L0）对应常规内存回收策略，那么执行常规内存回收策略。或者，如果判断内存申请压力值P落在第二区间[L0, L1）内，由于第二区间[L0, L1）对应只回收文件页策略，那么可以执行只回收文件页策略。或者，如果判断内存申请压力值P≥L1，落在第三区间[L1, ∞）内，由于第三区间[L1, ∞）对应查杀后台应用策略，那么可以执行查杀后台应用策略。

示例性地，结合上述图12计算得到的两个内存申请压力值P进行说明。在时刻1计算得到的内存申请压力值P为45，P＜50，属于第一区间，执行常规内存回收策略。在时刻2计算得到的内存申请压力值P为65，50＜P＜150，执行只回收文件页策略。

下面再结合流程图对本申请实施例提供的控制内存回收的方法进行说明。

结合图11，如图16所示，在S305之后，本申请实施例提供的控制内存回收的方法还包括S306-S312。其中，假设第一区间[0, 50），第二区间[50, 150），第三区间[150, ∞）。

S306，电子设备判断内存申请压力值P是否小于第一压力阈值（50MB/ms）。

在S306的一种可能情况下，当内存申请压力值P小于第一压力阈值时，表示内存无压力，继续执行下述的S307，即执行常规内存回收策略。

S307，电子设备执行常规内存回收策略。

在S306的另一种可能情况下，当内存申请压力值P大于或等于第一压力阈值时，继续执行下述的S308，需要根据内存申请压力值P再作进一步判断。

S308，电子设备判断内存申请压力值P是否大于或等于第一压力阈值，且小于第二压力阈值（150MB/ms）。

S309，当内存申请压力值P大于或等于50MB/ms且小于150MB/ms时，电子设备执行只回收文件页策略，释放文件页缓存。

相比于常规内存回收策略，只回收文件页策略的回收效率较高。

S310，电子设备判断内存申请压力值P是否大于或等于150MB/ms。

S311，当内存申请压力值P大于或等于150MB/ms时，电子设备执行查杀后台应用策略，释放后台APP占用的内存。

在S307执行常规内存回收策略的情况下还会执行下述的S312，或者在S309执行只回收文件页策略的情况下还会执行下述的S312，或者在S311执行查杀后台应用策略的情况下还会执行下述的S312。

S312，电子设备从剩余空闲内存（FreeRam）为APP分配内存。

在本实施例中，针对三种内存回收策略对应设置三个压力值区间，相应地有三个压力等级。可以根据内存申请压力值进行压力评估，然后根据评估结果选择对应的内存回收策略。

若内存申请压力值低于压力阈值50MB/ms，表示内存无压力，则执行常规内存回收策略。常规内存回收策略包括回收文件页和回收匿名页，这种内存回收策略效率相对较低。

若内存申请压力值高于或等于压力阈值50MB/ms但低于压力阈值150MB/ms，表示内存有轻微压力，则执行只回收文件页策略。只回收文件页策略包括只回收文件页，而不回收匿名页，因此提高了回收效率，这种只回收文件页的效率高于常规内存回收的效率。

若内存申请压力值高于或等于压力阈值150MB/ms，表示内存有较大压力，则需要通过查杀后台应用来快速释放内存。一旦查杀后台应用被触发，则电子设备执行对后台应用的查杀，能够快速释放内存资源，这种回收策略的回收效率最高。

在通常情况下，系统默认执行常规内存回收策略，系统会唤醒kswapd内核线程来回收内存。kswapd是一个内核线程，在内存不足时负责在后台进行内存回收，这个过程发生在后台，因此是异步发生，不会阻塞进程。

如果后台异步回收跟不上进程申请内存的速度，那么直接回收文件页，此时回收内存的过程是同步的，会阻塞应用进程的执行。在执行只回收文件页策略时，可以使用最近最少使用（least recently used，LRU）算法，直接回收最近使用最少的内存页面。即，在缓存写满的时候，会根据所有内存的访问记录，释放被访问率最低的内存，也就是说，优先回收被访问率最低的内存。

如果只回收文件页无法满足内存需求，那么执行查杀后台应用策略，系统会通过OOM（out of memory，内存溢出）机制，直接终止后台占用大量内存的进程。在实际实现时，可以根据算法选择并终止占用物理内存较高的进程，以便释放内存资源，如果物理内存依然不足，会继续查杀占用物理内存较高的进程，直到释放足够的内存。

以上说明了预设内存回收策略包括常规内存回收、只回收文件页、查杀后台应用的情况，下面简单说明预设内存回收策略包括常规内存回收、高比例回收文件页及低比例回收匿名页、查杀后台应用的情况。

示例性地，表2示出了本申请实施例提供的预设压力等级、预设的压力值区间、预设的内存回收策略之间的一一对应关系。

表2

相应地，图17示出了与表2对应的控制内存回收的方法的流程图。与图16不同之处在于，在图17中，在S308判断内存申请压力值在第二区间[50, 150）内的情况下，执行S309A，即以高比例回收文件页，低比例回收匿名页。

本申请实施例中，可以预先记录每次申请内存时的相关数据，根据记录的相关数据计算内存申请压力值，并根据内存申请压力值来确定执行哪一种内存回收策略。不同于相关技术中采用可用内存量来确定具体执行哪一种内存回收策略，本申请实施例可以根据内存申请压力值，衡量当前系统内存的实际可用程度。这种方式能够准确地衡量可用内存的实际情况。通过本申请方案，能够基于实际需求有效地为前台APP提供内存，避免出现卡顿现象。

以上实施例中以预设三种内存回收策略为例进行示例性说明，在实际实现时，还可以预设两种内存回收策略，也可以预设三种以上内存回收策略，具体可以根据实际使用需求进行设置，本申请实施例不作限定。

下面简单说明预设两种内存回收策略的情况。其中，第一阶段和第二阶段可参见上述说明，不同之处在于第三阶段。

示例性地，在本申请实施例中，可以预设压力等级、预设的压力值区间、预设的内存回收策略之间的一一对应关系。表3示例性地示出了多个对应关系。

表3

如表3所示，设置有无压力等级和有压力等级，随着压力等级增大，压力程度增大。其中，无压力等级对应的压力值区间为第一区间[0, L3），以及对应的内存回收策略为常规内存回收。有压力等级对应的压力值区间为第二区间[L3, ∞），以及对应的内存回收策略为查杀后台应用。

其中，L3表示压力等级的门限值。示例性地，L3取100MB/ms。需要说明的是，在实际实现时，门限值可以根据实际使用需求进行设置，本申请实施例对此不作限定。下面以L3为100MB/ms为例进行示例性说明。

举例来说，在计算得到内存申请压力值（记为P）之后，判断内存申请压力值P落在哪个压力值区间内，如果判断内存申请压力值P落在第一区间[0, L3）内，由于第一区间[0,L3）对应常规内存回收策略，那么执行常规内存回收策略。或者，如果判断内存申请压力值P≥L3，落在第二区间[L3, ∞）内，由于第二区间[L1, ∞）对应查杀后台应用策略，那么可以执行查杀后台应用策略。

下面再结合流程图对本申请实施例提供的控制内存回收的方法进行说明。

示例性地，结合图11，如图18所示，在S305之后，本申请实施例提供的控制内存回收的方法还可以包括S313-S316。其中，假设第一区间[0, 100），第二区间 [100, ∞）。

S313，电子设备判断内存申请压力值P是否小于100MB/ms。

在S313的一种可能情况下，当内存申请压力值P小于第一压力阈值时，表示内存无压力，继续执行下述的S314，即执行常规内存回收策略。

S314，电子设备执行常规内存回收策略。

在S313的另一种可能情况下，当内存申请压力值P大于或等于100MB/ms时，继续执行下述的S315。

S315，电子设备执行查杀后台应用策略，释放后台APP占用的内存。

在S314执行常规内存回收策略的情况下还会执行下述的S316，或者在S315执行查杀后台应用策略的情况下还会执行下述的S316。

S316，电子设备从剩余空闲内存（FreeRam）为APP分配内存。

在本实施例中，针对两种内存回收策略对应设置两个压力值区间，相应地有两个压力等级。可以根据内存申请压力值进行压力评估，然后根据评估结果选择对应的内存回收策略。若内存申请压力值低于压力阈值100MB/ms，表示内存无压力，则执行常规内存回收策略。若内存申请压力值高于或等于压力阈值100MB/ms，表示内存有压力，则需要通过查杀后台应用来快速释放内存。一旦查杀后台应用被触发，则电子设备执行对后台应用的查杀，能够快速释放内存资源，因此这种回收策略的回收效率最高。

综上所述，目前市场上，8GB手机已经逐渐被12GB甚至16GB手机取代，以前针对内存压力场景下的供给策略不再适用于大内存（12GB已上）设备，在一些场景中可能会引发卡顿现象，因此本申请提出了基于大内存设备的内存回收及供给策略。通过本申请方案，可以预先记录每次APP申请内存时的需回收内存量及申请时刻等相关数据，当前台应用申请内存时，可根据记录的相关数据计算最近一段时间内的内存申请压力值，并根据内存申请压力值来衡量系统内存当前实际压力状态，由此根据压力状态确定执行哪一种内存回收策略，例如在高压力情况下会触发后台应用查杀逻辑，快速释放内存。通过本申请方案，能够准确地衡量系统内存的实际压力状态，并采用当前压力状态对应的内存回收策略进行内存回收，因此能够有效地为前台APP提供内存资源，避免出现卡顿现象。

本申请实施例提供的方案可以应用于诸如游戏场景、相机拍照场景，或者其他内存重载场景。

需要说明的是，在本申请实施例中，“大于”可以替换为“大于或等于”，“小于或等于”可以替换为“小于”，或者，“大于或等于”可以替换为“大于”，“小于”可以替换为“小于或等于”。

本文中描述的各个实施例可以为独立的方案，也可以根据内在逻辑进行组合，这些方案都落入本申请的保护范围中。

上文主要从方法步骤的角度对本申请实施例提供的方案进行了描述。可以理解的是，为了实现上述功能，实施该方法的电子设备包含了执行各个功能相应的硬件结构和/或软件模块。本领域技术人员应该可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，本申请能够以硬件或硬件和计算机软件的结合形式来实现。某个功能究竟以硬件还是计算机软件驱动硬件的方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的保护范围。

本申请实施例可以根据上述方法示例，对电子设备进行功能模块的划分，例如，可以对应各个功能划分各个功能模块，也可以将两个或两个以上的功能集成在一个处理模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。需要说明的是，本申请实施例中对模块的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可以有其它可行的划分方式。下面以采用对应各个功能划分各个功能模块为例进行说明。

图19为本申请实施例提供的控制内存回收的装置400的示意性框图。该装置400可以用于执行上文方法实施例中电子设备所执行的动作。该装置400包括处理单元410、存储单元420以及内存回收控制单元430。

处理单元410，用于响应于第一应用的申请内存请求，根据所述第一应用的申请内存量与系统内存中的剩余空闲内存量之间的差值，确定需回收内存量；

存储单元420，用于将所述需回收内存量及对应的申请时刻构成的第一数据对存储到缓存器中；其中，所述缓存器中还存储有除所述第一数据对之外的多个数据对，所述多个数据对包括在所述第一应用申请内存之前每当有应用申请内存时确定并存入的数据对；

处理单元410，还用于从所述缓存器中获取预设窗长内的N个数据对，所述N个数据对包括所述第一数据对以及在所述第一应用申请内存之前存入的M-1个数据对，M为大于1的整数；

处理单元410，还用于根据所述N个数据对，计算内存申请压力值；

处理单元410，还用于根据所述内存申请压力值，确定内存回收策略；

内存回收控制单元430，用于按照处理单元410所确定的内存回收策略进行内存回收。

通过本申请实施例提供的装置，可以预先记录每次APP申请内存时的需回收内存量及申请时刻等相关数据，当前台应用申请内存时，可根据记录的相关数据计算最近一段时间内的内存申请压力值，并根据内存申请压力值来衡量系统内存当前实际压力状态，由此根据压力状态确定执行哪一种内存回收策略，例如在高压力情况下会触发后台应用查杀逻辑，快速释放内存。通过本申请方案，能够准确地衡量系统内存的实际压力状态，并采用当前压力状态对应的内存回收策略进行内存回收，因此能够有效地为前台APP提供内存资源，避免出现卡顿现象。

根据本申请实施例的装置400可对应于执行本申请实施例中描述的方法，并且装置800中的单元的上述和其它操作和/或功能分别为了实现方法的相应流程，为了简洁，在此不再赘述。

本申请还提供一种芯片，该芯片与存储器耦合，该芯片用于读取并执行存储器中存储的计算机程序或指令，以执行上述各实施例中的方法。

本申请还提供一种电子设备，该电子设备包括芯片，该芯片用于读取并执行存储器存储的计算机程序或指令，使得各实施例中的方法被执行。

本实施例还提供一种计算机可读存储介质，该计算机可读存储介质中存储有计算机指令，当该计算机指令在电子设备上运行时，使得电子设备执行上述相关方法步骤实现上述实施例中的控制内存回收的方法。

本实施例还提供了一种计算机程序产品，该计算机可读存储介质存储有程序代码，当该计算机程序产品在计算机上运行时，使得计算机执行上述相关步骤，以实现上述实施例中的控制内存回收的方法。

另外，本申请的实施例还提供一种装置，这个装置具体可以是芯片，组件或模块，该装置可包括相连的处理器和存储器；其中，存储器用于存储计算机执行指令，当装置运行时，处理器可执行存储器存储的计算机执行指令，以使芯片执行上述各方法实施例中的控制内存回收的方法。

其中，本实施例提供的电子设备、计算机可读存储介质、计算机程序产品或芯片均用于执行上文所提供的对应的方法，因此，其所能达到的有益效果可参考上文所提供的对应的方法中的有益效果，此处不再赘述。

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

以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。

Claims (11)

1.一种控制内存回收的方法，其特征在于，包括：

响应于第一应用的申请内存请求，根据所述第一应用的申请内存量与系统内存中的剩余空闲内存量之间的差值，确定需回收内存量；

将所述需回收内存量及对应的申请时刻构成的第一数据对存储到缓存器中；其中，所述缓存器中还存储有除所述第一数据对之外的多个数据对，所述多个数据对包括在所述第一应用申请内存之前每当有应用申请内存时确定并存入的数据对；

从所述缓存器中获取预设窗长内的N个数据对，所述N个数据对包括所述第一数据对以及在所述第一应用申请内存之前存入的N-1个数据对，N为大于1的整数；

根据所述N个数据对，计算内存申请压力值；

根据所述内存申请压力值，确定内存回收策略；

按照所确定的内存回收策略进行内存回收；

其中，所述根据所述N个数据对，计算内存申请压力值，包括：

将所述N个数据对中所有的所述需回收内存量求和，得到需回收内存总量；

将所述N个数据对中的最后一个申请时刻与首个申请时刻求差，得到第一时长；

计算所述需回收内存总量与所述第一时长之间的比值，得到所述内存申请压力值。

2.根据权利要求1所述的方法，其特征在于，所述响应于第一应用的申请内存请求，根据所述第一应用的申请内存量与系统内存中的剩余空闲内存量之间的差值，确定需回收内存量，包括：

响应于所述第一应用的申请内存请求，当满足预设条件时，根据所述第一应用的申请内存量与系统内存中的剩余空闲内存量之间的差值，确定需回收内存量。

3.根据权利要求2所述的方法，其特征在于，所述预设条件包括以下至少一项：

电子设备支持的后台保活应用的最大数量大于或等于保活数量阈值；

所述电子设备的系统内存量大于或等于内存量阈值。

4.根据权利要求1至3中任一项所述的方法，其特征在于，所述根据所述内存申请压力值，确定内存回收策略，包括：

当所述内存申请压力值小于第一压力阈值时，执行第一内存回收策略；

当所述内存申请压力值大于或等于所述第一压力阈值，且小于第二压力阈值时，执行第二内存回收策略；

当所述内存申请压力值大于或等于所述第二压力阈值时，执行第三内存回收策略；

其中，所述第二压力阈值大于所述第一压力阈值；

其中，所述第三内存回收策略的回收效率大于所述第二内存回收策略的回收效率，所述第二内存回收策略的回收效率大于所述第一内存回收策略的回收效率。

5.根据权利要求4所述的方法，其特征在于，

所述第一内存回收策略为常规内存回收；

所述第二内存回收策略为只回收文件页；

所述第三内存回收策略为查杀后台应用。

6.根据权利要求4所述的方法，其特征在于，

所述第一内存回收策略为常规内存回收；

所述第二内存回收策略为回收文件页和匿名页、且对所述文件页的回收比例大于对所述匿名页的回收比例；

所述第三内存回收策略为查杀后台应用。

7.根据权利要求1至3中任一项所述的方法，其特征在于，所述根据所述内存申请压力值，确定内存回收策略，包括：

当所述内存申请压力值小于第一压力阈值时，执行第一内存回收策略；

当所述内存申请压力值大于或等于所述第一压力阈值时，执行第二内存回收策略；

其中，所述第二内存回收策略的回收效率大于所述第一内存回收策略的回收效率。

8.根据权利要求7所述的方法，其特征在于，

所述第一内存回收策略为常规内存回收；

所述第二内存回收策略为查杀后台应用。

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

响应于所述第一应用的申请内存请求，按照所述第一应用的申请内存量，从所述系统内存中的所述剩余空闲内存为所述第一应用分配内存。

10.一种电子设备，其特征在于，包括处理器、存储器以及存储在所述存储器上的计算机程序，所述处理器用于执行所述计算机程序，以使得所述电子设备实现如权利要求1至9中任一项所述的方法。

11.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有计算机程序，当所述计算机程序在电子设备上运行时，使得所述电子设备执行如权利要求1至9中任一项所述的方法。