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

本发明涉及信息技术领域，尤其涉及一种内存回收方法及装置。

背景技术：

随着终端(如智能手机、平板电脑等终端)的发展，终端已成为人们日常生活必不可缺的物品。实践中发现，用户在刚开始购买终端的时候，用户使用终端非常顺滑，应用运行起来非常快，而在终端被长期使用后，由于安装的应用越来越多，会有许多无用进程和服务在后台运行，并且用户浏览网页以及使用应用程序(application，app)会产生过多的缓存，这些将会使得系统的可用内存变少，进而导致终端出现卡顿现象。

通常采取的做法是在系统分配内存时检查系统是否有充足的可用内存，若发现当前系统的可用内存不能支撑当前的内存分配需求，则会启动系统内存清理操作，比如：回收系统缓存、关闭进程等。然而，这样会导致需要内存资源的应用阻塞，处于等待状态，延长了app的响应时间，进而增大了终端出现卡顿现象的概率。

技术实现要素：

本发明实施例提供了一种内存回收方法及装置，可以减少终端出现卡顿现象的概率。

本发明实施例第一方面公开了一种内存回收方法，包括：

在确定系统当前的可用内存小于内存阈值时，从后台进程列表中确定待回收内存的进程，其中，所述后台进程列表包括一个或多个应用的进程，所述待回收内存的进程为所述一个或多个应用的进程中满足进程所占用内存与内存压力值的差值的绝对值小于预设阈值的条件的进程，所述内存压力值为所述内存阈值与所述系统当前的可用内存的差值；向系统内核发送处理指令，以触发所述系统内核对所述待回收内存的进程进行处理以回收所述待回收内存的进程所占用的内存。

其中，可以由一个或多个内存管控线程、一个或多个内存管控进程、应用中的任一个来执行上述方法的步骤。

其中，后台进程列表是一个根据应用的重要程度以及进程优先级进行排序的动态二维表，包括一个或多个应用的进程，即后台进程列表可以包括一个或多个应用，同时，一个应用可以包括一个或多个进程。该后台进程列表在2种情况下创建，第一种：在确定系统当前的可用内存小于内存阈值时创建后台进程列表，这种情况一般是针对需要立即进行内存回收的场景，第二种：在确定系统当前的可用内存小于内存阈值并且系统处于空闲状态时创建后台进程列表，这种情况一般是用户和终端进行交互，为了不影响用户体验，需要在系统空闲的时候进行内存回收。

具体的，本发明实施例中，在确定系统当前的可用内存小于内存阈值时，可以制定内存回收策略，根据该内存回收策略，从后台进程列表中确定待回收内存的进程，进一步地，向系统内核发送处理指令，以触发系统内核对待回收内存的进程进行处理以回收待回收内存的进程对应的内存，直到缓解系统当前的内存压力。

此外，由于应用之间存在各种关联关系，在对后台进程所占用的内存进行回收时，为了防止被清理的进程被其关联的进程拉起来，所以，在回收内存时是以应用为单位，回收该应用包括的进程所占用的内存。其中，进程所占用的内存是指该进程独立占用的那部分内存，而不包括该进程与其他进程共享的那部分内存。

可见，这种方式中，在确定系统当前的可用内存小于内存阈值时，可以主动进行内存回收，当应用程序真正需要大量内存的时候，系统内核已经回收回来大量可用的内存，从而可以减少终端出现卡顿现象的概率。

在一个可能的实施方式中，在检测到第一关键事件时触发所述确定系统当前的可用内存小于内存阈值的操作，且所述内存阈值为与所述第一关键事件对应的第一内存阈值。其中，该内存阈值可以是静态预置的，也可以是动态配置的。不同的第一关键事件对应的场景是不同的，相应的第一内存阈值也不同。

在一个可能的实施方式中，所述第一关键事件包括如下事件中的任意一种：程序启动开始事件、清理事件以及内存不足oom事件。其中，当发生第一关键事件时需要立即进行内存回收。

在一个可能的实施方式中，在检测到第二关键事件且确定系统处于空闲状态时触发所述确定当前系统的可用内存小于内存阈值的操作，且所述内存阈值为与所述第二关键事件对应的第二内存阈值。其中，该内存阈值可以是静态预置的，也可以是动态配置的。不同的第二关键事件对应的场景是不同的，相应的第二内存阈值也不同。

其中，在该实施方式中，步骤的先后顺序是：在检测到第二关键事件时先判断系统是否处于空闲状态，在确定系统处于空闲状态时再去读取当前系统的可用内存，在确定当前系统的可用内存小于内存阈值时，从后台进程列表中确定待回收内存的进程，进一步地，向系统内核发送处理指令，以触发系统内核对待回收内存的进程进行处理以回收待回收内存的进程对应的内存。

在一个可能的实施方式中，在检测到第二关键事件时触发所述确定当前系统的可用内存小于内存阈值的操作，在确定系统处于空闲状态时触发所述从后台进程列表中选择待回收内存的进程的操作，且所述内存阈值为与所述第二关键事件对应的第二内存阈值。

其中，在该实施方式中，步骤的先后顺序是：在检测到第二关键事件时，先读取当前系统的可用内存，在确定当前系统的可用内存小于内存阈值的情况下，再判断系统是否处于空闲状态，在确定系统处于空闲状态时从后台进程列表中选择待回收内存的进程，进一步地，向系统内核发送处理指令，以触发系统内核对待回收内存的进程进行处理以回收待回收内存的进程对应的内存。

在一个可能的实施方式中，所述第二关键事件包括如下事件中的任意一种：程序启动完成事件、亮屏事件、灭屏事件、触屏事件、界面切换事件、任务切换完成事件以及广播事件。

在一个可能的实施方式中，所述确定系统处于空闲状态包括：

判断所述系统当前的负载是否小于负载阈值；在所述系统当前的负载小于所述负载阈值的情况下，确定系统处于空闲状态。

其中，系统处于空闲状态有2种场景，第一种是在用户未使用终端的情况下，比如终端处于待机状态可以看作是系统处于空闲状态，又比如：在应用启动完成出现显示画面，但以后并没有和终端进行交互，这个时候系统没有大量的io操作，可以看作是系统处于空闲状态，第二种是在用户使用终端但系统当前的负载不影响用户体验的情况下，可以看作是系统处于空闲状态，比如系统的负载小于负载阈值。

在一个可能的实施方式中，在确定出的所述待回收的进程为多个的情况下，所述向系统内核发送处理指令包括：

调用多个线程向系统内核发送多个处理指令，其中，每个所述线程用于发送一个或多个处理指令。

其中，确定出的待回收的进程可以为一个也可以为多个，在一个进程需要发送多个处理指令的情况下，该进程可以一个一个连续地发送处理指令，而不需要在发送完一个处理指令后去检测系统内核回收进程对应的内存的状态，然后再去发送另一个处理指令。

在该可选的实施方式中，在确定出的所述待回收的进程为多个的情况下，可以调用多个线程向系统内核发送多个处理指令。具体的，一个线程发送多个处理指令是指该线程一个一个连续地发送处理指令，而不需要在发送完一个处理指令后去检测系统内核回收进程对应的内存的状态，然后再去发送另一个处理指令。其中，每个处理指令携带一个待回收的进程的标识。

可见，这种方式可以提高线程向系统内核发送处理指令的效率，同时，也可以加速系统内核回收内存性能。

在一个可能的实施方式中，所述从后台进程列表中确定待回收内存的进程包括：

根据应用的重要程度从低到高的顺序，从所述后台进程列表包括的多个应用中确定至少一个应用；根据进程优先级从低到高的顺序，从所述至少一个应用包括的进程中确定待回收内存的进程。

在一个可能的实施方式中，所述方法还包括：

在确定所述系统当前的可用内存小于所述内存阈值时创建所述后台进程列表。其中，这种情况是针对需要立即进行内存回收的场景而言的。

在一个可能的实施方式中，所述方法还包括：

在确定所述系统当前的可用内存小于所述内存阈值并且所述系统处于空闲状态时创建所述后台进程列表。其中，这种情况是针对用户和终端进行交互，为了不影响用户体验，需要在系统空闲的时候进行内存回收的场景而言的。

在一个可能的实施方式中，所述创建所述后台进程列表包括：

确定当前在后台运行的每个应用的关键因素的分值，所述关键因素包括以下中的一个或多个：进程优先级、用户使用习惯、进程占用系统资源以及应用的关联关系；针对每个所述应用，将所有所述关键因素的分值进行加权计算，获得所述应用的重要程度；根据所有所述应用的重要程度，对所有所述应用进行排序；根据进程优先级，对排序后的每个所述应用包括的进程进行排序，以生成后台进程列表。

其中，系统资源可以包括但不限于计算资源，存储资源，cpu资源以及io资源。基于应用的关键因素(进程优先级、用户使用习惯、进程占用系统资源以及应用的关联关系)来创建后台进程列表，后续就可以根据内存的需求从该后台进程列表中确定需要处理的进程，这样就可以精确地选择可杀进程队列，减少错杀/多杀/少杀进程的概率。

本发明实施例第二方面公开了一种内存回收装置，包括用于执行本发明实施例第一方面任一方法的部分或全部步骤的功能单元。其中，该终端执行第一方面任一方法的部分或全部步骤时可以减少终端出现卡顿现象的概率。

本发明实施例第三方面公开了一种终端，包括处理器以及存储器，所述存储器被配置用于存储指令，所述处理器被配置用于运行所述指令，所述处理器运行所述指令以执行本发明实施例第一方面任一方法的部分或全部步骤。其中，该终端执行第一方面任一方法的部分或全部步骤时可以减少终端出现卡顿现象的概率。

本发明实施例第四方面公开了一种计算机存储介质，所述计算机存储介质存储有程序，所述程序具体包括用于执行本发明实施例第一方面任一方法的部分或全部步骤的指令。

附图说明

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

图1是本发明实施例公开的一种操作系统的结构示意图；

图2是本发明实施例公开的一种内存回收方法的流程示意图；

图2a是本发明实施例公开的一种app重要程度识别的示意图；

图2b是本发明实施例公开的一种应用的关联关系的示意图；

图2c是本发明实施例公开的一种相机启动时序图；

图2d是本发明实施例公开的另一种相机启动时序图；

图3是本发明实施例公开的另一种内存回收方法的流程示意图；

图4是本发明实施例公开的另一种内存回收方法的流程示意图；

图5是本发明实施例公开的一种内存回收装置的结构示意图；

图6是本发明实施例公开的一种终端的结构示意图。

具体实施方式

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

本发明的说明书和权利要求书及上述附图中的术语“包括”和“具有”以及它们任何变形，意图在于覆盖不排他的包含。例如包含了一系列步骤或单元的过程、方法、系统、产品或设备没有限定于已列出的步骤或单元，而是可选地还包括没有列出的步骤或单元，或可选地还包括对于这些过程、方法、产品或设备固有的其它步骤或单元。

本发明实施例公开了一种内存回收方法及装置，可以减少终端出现卡顿现象的概率。以下分别进行详细说明。

本发明实施例提供的内存回收方法主要应用于终端，该终端也可称之为用户设备(userequipment，简称为“ue”)、移动台(mobilestation，简称为“ms”)、移动终端(mobileterminal)等，可选的，该终端可以具备经无线接入网(radioaccessnetwork，ran)与一个或多个核心网进行通信的能力，例如，终端可以是移动电话(或称为“蜂窝”电话)、或具有移动性质的计算机等，例如，终端还可以是便携式、袖珍式、手持式、计算机内置的或者车载的移动装置。该终端的操作系统可包括但不限于android(安卓)操作系统、ios操作系统、symbian(塞班)操作系统、blackberry(黑莓)操作系统、windowsphone8操作系统等等。

本发明实施例提供的内存回收方法主要应用于具有android操作系统的终端。

为了更好的理解本发明实施例，下面先对本发明实施例公开的一种操作系统的结构示意图进行描述。

请参阅图1，图1是本发明实施例公开的一种操作系统的结构示意图。具体的，该操作系统可以是android操作系统。android操作系统是google开发的基于linux平台的开源操作系统，android操作系统是一个分层的环境，构建在linux内核的基础上，它包括丰富的功能。

如图1所示，该操作系统100包括应用层110、框架层120、核心库层130以及内核层140。

其中，应用层110包括终端工作时所需的所有应用程序，比如电子邮件客户端、短信、日历、地图、浏览器等应用程序，这些应用程序可以由java、c/c++等语言编写。

框架层120即为android应用程序框架，android应用程序均是基于该框架进行开发的。该框架通过提供一组基础类库，可以使开发者开发出丰富且新颖的应用程序，基于该类库，开发者可以自由地利用设备硬件优势，实现访问位置信息，运行后台服务，设置闹钟，向状态栏添加通知等功能。需要说明的是，图1所示的框架层120保留了原有android操作系统框架层的功能模块，此外，在系统服务121上做了一些修改，如图1所示，本发明中，该系统服务121包括资源管理系统(resourcemanagementsystem，rms)模块1211、应用管控模块1212以及系统资源状态采集模块1213，其中，rms模块1211主要用于对系统资源状态采集模块1213采集的信息进行管理，应用管控模块1212主要用于对进程快速处理，系统资源状态采集模块1213主要用于采集并识别系统的资源负载状态。此外，如图1所示，在该框架层120中新增了感知进程122，感知进程122包括rms模块1221、省电精灵模块1222以及内存管控模块1223，其中，rms模块1221主要用于处理执行时间较长的内存管控措施以及亮灭屏识别，省电精灵模块1222主要用于识别应用的运行状态，并判断应用所消耗的电量是否超过电量阈值，以进行管控处理(如关闭进程、限制应用启动，延迟分发消息等)，内存管控模块1223主要用于外部模块接口管理及处理、系统空闲状态/负载状态识别，空闲内存阈值配置管理、内存压力状态识别、精细化内存回收策略制定、智能内存分配以及维测管理。

核心库层130主要为框架层120的各个组件提供其基本实现的一组c/c++库(应用框架的底层库)，其中，核心库层130包括感知守护进程131，感知守护进程131主要用于采集系统资源状态信息。

内核层140位于android操作系统的最底层，可以看做为硬件层与系统中其他软件组直接的抽象，主要为android操作系统提供核心的系统服务，包括安全机制、内存管理、进程管理、文件管理、网络通讯管理以及驱动管理，此外，本发明实施例中，内核层140还可以用于单个进程级的缓存回收。

请参见图2，图2是本发明实施例公开的一种内存回收方法的流程示意图。其中，该方法可以应用于图1所示的内存管控模块1223，具体的，内存管控模块1223可以是一个或多个线程，或者，内存管控模块1223可以是一个或多个进程。如图2所示，该方法可以包括以下步骤。

201、在检测到第一关键事件时，确定系统当前的可用内存小于内存阈值。

本发明实施例中，内存管控模块1223可以检测应用程序的关键事件，具体的，可以在活动管理器服务(activitymanagerservice，ams)启动每个应用的活动(activity)的时候，通过钩子(hook)函数获取应用程序的关键信息(如进程名称、用户身份标识(useridentifier，uid)以及进程身份标识(processidentifier，pid)，进一步地，ams可以将获取到的应用程序的关键信息发送给内存管控模块1223，这样，内存管控模块1223就可以检测到应用程序的关键事件。

其中，该应用程序的关键事件可以包括但不限于程序启动开始事件、清理事件、内存不足(outofmenory，oom)事件，程序启动完成事件、亮屏事件、灭屏事件、触屏事件、界面切换事件、任务切换完成事件、广播事件、网络连接/扫描/状态变化事件(如wifi、2/3/4g、蓝牙、红外、全球定位系统(globalpositioningsystem，gps)、电台广播、近场通信(nearfieldcommunication，nfc))、外设连接变化事件(如插拔充电器等)、通知闹铃类事件、电话类事件(来电、信号变化等)、媒体类事件(音视频变化、录音播放)、闪光灯相关类事件、程序安装卸载类事件、电池电量类事件等。

本发明实施例中，可以预先将需要立即进行内存回收的事件定义为第一关键事件，该第一关键事件可以包括但不限于程序启动开始事件、清理事件以及oom事件。其中，程序启动开始事件主要指由用户触发的需要立即启动的应用程序事件(如用户点击微信应用)，清理事件可以包括但不限于终端管家清理事件、一键清理事件、应用卸载事件以及应用缓存清空事件。oom事件可以包括但不限于大内存应用启动需求内存超过内存阈值事件、系统oom事件以及应用强制停止事件。

本发明实施例中，系统的内存可以包括：被占用内存以及可用内存，其中，被占用内存主要指当前正在运行的进程和服务所占用的内存以及内核运行所占用的内存，可用内存指系统的空闲内存和缓存。

在检测到第一关键事件时可以获取系统当前的可用内存，并判断系统当前的可用内存是否小于内存阈值，当确定系统当前的可用内存小于内存阈值时，表明当前系统存在内存压力，需要进行内存回收。其中，该内存阈值为与第一关键事件对应的第一内存阈值。

可选的，该内存阈值可以是静态预置的。具体的，有如下几种情况：

(1)根据产品规格配置内存阈值

针对2g/3g/4g/6g随机存取存储器(randomaccessmemory，ram)的产品，系统的可用内存不同，相应的，内存阈值也不同。比如：针对3gram的产品，可以配置内存阈值为600mb，针对4gram的产品，可以配置内存阈值为700mb。

(2)根据应用场景配置尽可能小的内存阈值

不同的应用及其不同的场景，对于内存的耗费是不同的。因此要想配置合理的内存阈值，采用方式(1)存在一些弊端，可能会因为没有考虑某个第三方应用而出现该应用启动时卡顿的现象。针对此类问题，可以通过离线分析应用市场中排名靠前的第三方应用，获取各类应用在各个场景中最大的内存占用信息。

请参见表1，表1为第三方应用在典型场景下最大的内存占用信息。需要说明的是，表1只是示例性地列举了几个应用。

表1

具体的，可以在终端开机完成，接收到启动完成(boot_completed)事件时，查询所有在终端上已安装的应用的标识(如应用名称)，进一步地，根据应用的标识从表1中获取需要的信息(如进程名称、运行场景、最大内存占用信息)，以生成本地程序内存占用表，可以使用可扩展标记语言(extensiblemarkuplanguage，xml)文件或者txt文件来保存本地程序内存占用表。终端可以针对不同的应用，分别从本地程序内存占用表中查询该应用的最大内存占用信息，并设置内存阈值为该应用的最大占用内存。

(3)根据系统运行进程历史占用内存进行配置

由于每个用户都有自己的特点，终端被长时间使用后，终端上安装和运行的应用并不一致，可以根据系统运行进程历史占用内存来配置内存阈值。具体的，可以在用户不使用终端的时候(比如半夜)查询每个进程运行时内存占用的历史状态信息(procstats)，获取其中最大的内存占用信息(如应用程序名称、最大占用内存)，进一步地，将最大占用内存和当前系统的内存阈值比较，若最大占用内存大于当前系统的内存阈值，则选取该最大占用内存作为系统新的内存阈值。

(4)通过云端下发配置内存阈值

云端服务器可以根据终端的标识收集在终端上运行的所有应用在各个场景占用的内存信息，将占用内存大于预设值(如300mb)的应用名及该应用当时的运行场景等信息形成一张表单，定期(如每月)将该表单推送给终端；终端接收到表单后，将此表单中的应用信息和本地应用列表进行遍历，并确定终端上安装的应用的最大内存占用信息，进一步地，将最大占用内存和当前系统的内存阈值进行比较，若最大占用内存大于当前系统的内存阈值，则选取该最大占用内存作为系统新的内存阈值。

可选的，该内存阈值可以是动态配置的。

具体的，可以通过用户行为分析算法，根据用户使用习惯、应用使用历史、使用频率、使用时长等信息，根据预测算法，预测出接下来最有可能运行的应用，并形成应用列表；获取应用列表中的应用需要使用的最大内存，并将最大内存和当前系统的内存阈值相比，若最大内存大于当前系统的内存阈值，则选取该最大内存作为系统新的内存阈值。

202、在确定系统当前的可用内存小于内存阈值时创建后台进程列表。

其中，在确定系统当前存在内存压力时需要立即创建后台进程列表，该后台进程列表为一个根据应用的重要程度以及进程优先级进行排序的动态二维表，包括一个或多个应用的进程，即后台进程列表可以包括一个或多个应用，同时，一个应用可以包括一个或多个进程。该后台进程列表为根据应用的重要程度以及进程优先级排序后的列表。

具体的，创建后台进程列表的方式具体包括以下步骤：

11)确定当前在后台运行的每个应用的关键因素的分值，所述关键因素包括以下中的一个或多个：进程优先级、用户使用习惯、进程占用系统资源以及应用的关联关系；

12)针对每个所述应用，将所有所述关键因素的分值进行加权计算，获得所述应用的重要程度；

13)根据所有所述应用的重要程度，对所有所述应用进行排序；

14)根据进程优先级，对排序后的每个所述应用包括的进程进行排序，以生成后台进程列表。

在该实施例中，在终端后台运行的每个应用可以包括一个或多个进程，每个应用的关键因素包括以下种的一个或多个：进程优先级、用户使用习惯、进程占用系统资源以及应用的关联关系。每个关键因素都有相应的分值。基于应用的关键因素(进程优先级、用户使用习惯、进程占用系统资源以及应用的关联关系)来创建后台进程列表，后续就可以根据内存的需求从该后台进程列表中确定需要处理的进程，这样就可以精确地选择可杀进程队列，减少错杀/多杀/少杀进程的概率。

其中，系统会对每个进程的重要性进行评估，进程的重要性也代表了进程优先级。通常，将重要性以oom_adj(outofmemoryadjust)这个数值表示出来，赋予各个进程，系统会根据oom_adj来判断需要结束哪些进程。一般，oom_adj的分值由系统提供，系统可以根据应用当前的运行状态来分配，oom_adj的分值范围如下：-17<oom_adj<16。oom_adj的分值越大，该进程被系统选中终止的可能就越高，进程优先级就越低。

其中，用户使用习惯可以包括但不限于应用的使用时间记录、应用的累计使用次数、每次被使用的时长以及累计使用时长。根据用户使用习惯可以确定哪些进程为用户经常使用的应用的进程，或者确定哪些进程为用户使用时间较长的应用的进程，或者确定哪些进程为用户最近使用的应用的进程等等相关进程的信息。其中，可以通过rms模块1221来进行app使用习惯的学习，此外，可以综合考虑三类算法来识别app的重要程度。

请一并参见图2a，图2a是本发明实施例公开的一种app重要程度识别的示意图。如图2a所示，虚线框1代表的是基于机器学习的app重要程度识别模型；虚线框2代表的是基于统计规则的app重要程度识别模型，第三类算法是基于最近使用的应用(latestrecentused，lru)来识别。针对应用a来说，假设基于机器学习的app重要程度为ph(a)，基于统计规则的app重要程度识别为pl(a)，基于最近使用的应用识别为pu(a)，对应的权重分别为wh、wl、wu，则最后应用a的重要程度计算公式为

p(a)＝wh*ph(a)+wl*pl(a)+wu*pu(a)

其中，各权重值需要在训练中不断学习得到，与用户无关，预置到app重要程度识别插件中，通过版本迭代更新。

可以根据应用的重要程度来分配用户使用习惯(habit)的分值，habit的分值范围如下：0<habit<16。habit的分值越低，表明用户使用应用越频繁。

其中，进程占用系统资源可以包括但不限于计算资源，存储资源，中央处理器(centralprocessingunit，cpu)资源以及输入输出(inputoutput，io)资源。可以根据资源占用大小来设定进程占用系统资源(resource)的分值，resource的分值范围如下：0<resource<16，比如，进程占用cpu>3％，则resource＝16。通常，进程占用的系统资源越多，该进程就越容易被选中回收该进程对应的内存。

应用的关联关系是指应用之间存在的关联关系，具体的，两个应用之间可以通过进程关联起来。本发明实施例中可以是后台应用与前台应用的关联关系，该关联关系是一个瞬态，可以根据当前进程状态实时更新。其中，关联关系包括但不限于getcontentprovider、startactivity、bindservice、unbindservice、startservice、stopservice以及widget。

请一并参见图2b，图2b是本发明实施例公开的一种应用的关联关系的示意图。其中，pid1、pid2、pid3、pid4……代表进程的身份标识，图2b中最左边的进程表示被最右边的进程所依赖，两个进程存在关联关系，例如：pid1进程的service1被pid2进程通过bindservice关联，pid2进程的service1被pid3进程通过startservice关联。

一般在进行后台进程清理的时候，被清理的进程可能会被其关联的进程拉起来，或者由于清理了某个进程会导致功能异常。举例来说，前台输入法需要使用后台的provider独立进程，如果把该后台的provider独立进程冻结或清理，会导致前台输入法异常；如果后台应用在播放音乐，而音乐又依赖后台的service独立进程，如果把该service独立进程冻结或清理，会导致音乐播放应用异常。其中，用户可以设定应用的关联关系(application-relation)的分值，以进行后续的加权操作。application-relation的分值的范围如下：0<application-relation<16，如果应用之间是直接关联，application-relation的分值可以为0，如果应用之间是间接关联，application-relation的分值可以为16。application-relation的分值越高，表明该应用与其他应用的关联性就越弱。

进一步地，针对每个应用，可以将所有关键因素的分值进行加权计算，获得应用的重要程度。具体的，算法如下：

score＝oom_adj*poom_adj+habit*phabit+resource*presource+application-relation*papplication-relation，其中，poom_adj+phabit+presource+papplication-relation＝1。

score得分可以用来衡量应用的重要程度，score得分越小，应用的重要程度越高。比如：应用1的score得分高于应用2的score得分，则可以确定应用2的重要程度高于应用1。

更进一步地，根据score得分的高低可以对应用进行排序，针对每个应用，在应用包括至少两个进程的情况下，可以根据进程优先级，对该应用包括的进程进行排序，这样就可以生成后台进程列表，该后台进程列表实质上是一个包括应用以及应用的进程的二维表，该二维表中应用按照重要程度从高到底或者从低到高进行排序，应用的进程按照进程优先级从高到底或者从低到高进行排序。

请参见表2，表2是本发明实施例公开的一种应用-进程列表。

表2

其中，系统内运行的应用可以分为18大类；主要包括：关键系统服务、关键常驻应用、前台应用、systemserver、前台所依赖的后台、普通系统服务、普通常驻应用、home在后台、用户可感知到的后台应用、visible应用、手机管家保护的后台、上一次在前台的应用、和前台弱关联的后台、用户对应用使用习惯、应用预置重要程度、应用oom_adj大于2、系统识别为有害应用、人为识别有害应用(黑名单)。

作为一种可选的实施方式，上述后台进程列表可以为一张表(如上表2)，或者，上述后台进程列表可以包括3张子表(比如将上述表2分割成3部分，形成3张子表)，分别为不可回收列表、重要进程列表以及可杀列表。其中，不可回收列表主要是系统进程和服务，如果缺少这些进程，将会影响整个应用的运行，比如关键系统服务、关键常驻应用、前台应用、systemserver、前台所依赖的后台等相关类应用，重要进程列表主要是设备阈值应用、用户感知类应用以及用户常用的重要应用，比如普通系统服务、普通常驻应用、home在后台、用户可感知到的后台应用、visible应用、手机管家保护的后台、上一次在前台的应用、和前台弱关联的后台等相关类应用，可杀列表主要包括用户对应用使用习惯、应用预置重要程度、应用oom_adj大于2、系统识别为有害应用、人为识别有害应用等相关类应用。

203、从后台进程列表中确定待回收内存的进程。

在后台进程列表包括3张子表的情况下，内存回收列表处理顺序为：在进行内存回收时，优先回收可杀列表，回收方式从可杀列表末尾从下往上进行回收；当可杀列表为空，同时系统内存还存在压力，则开始回收重要进程列表，回收方式还是从重要进程列表末尾从下往上进行回收。基于上述原则，可以优先从可杀列表中确定待回收内存的进程，其次是从重要进程列表中确定待回收内存的进程。

可选的，上述列表的分类也可以是变化，比如：对于重要进程列表中重要性不够高的应用，可以将该应用降低列入到可杀列表中。

其中，后台进程列表包括多个应用的进程，待回收内存的进程为多个应用的进程中满足进程所占用内存与内存压力值的差值的绝对值小于预设阈值的条件的进程，内存压力值为内存阈值与系统当前的可用内存的差值。也就是说，待回收内存的进程所占用内存可以大于内存压力值，也可以小于内存压力值，待回收内存的进程所占用内存与内存压力值的差值的绝对值在一定范围之内，即绝对值小于预设阈值，该预设阈值可以是用户设定的，也可以是系统默认的，本发明实施例不做限定。

其中，预先设定了内存压力等级：高级、中级以及低级，高级表征内存压力较大，中级表征内存压力适中，低级表征内存压力较小。以及预先设定了内存压力值所属的范围：第一范围、第二范围以及第三范围，其中，第一范围小于第二范围，第二范围小于第三范围。可以根据内存压力值所属的范围来确定系统当前的内存压力等级。比如：当内存压力值属于第一范围时，可以确定系统当前的内存压力等级为低级，当内存压力值属于第二范围时，可以确定系统当前的内存压力等级为中级，当内存压力值属于第三范围时，可以确定系统当前的内存压力等级为高级。

在确定系统当前的内存压力等级为高级的情况下，需要采取对待回收内存的进程进行清理的策略。这种策略是将终端中已存在的进程所占用的资源进行销毁回收，使得系统的可用内存增加。

在确定系统当前的内存压力等级为中级的情况下，需要采取对待回收内存的进程进行系统级或应用级的内存回收的策略，系统级的内存回收的策略可以将系统的缓存根据其重要程度进行回收，达到增大空闲内存的目的。其中，一个应用可能有一个或多个进程，因此，可以采取针对应用级的内存回收的策略，比如：kill、compress、dropcache等策略。

在确定系统当前的内存压力等级为低级的情况下，需要根据应用的重要程度采取对待回收内存的进程进行单个进程级压缩或者单个进程级缓存回收的策略。如果应用的重要程度较高，可以采取对待回收内存的进程进行单个进程级压缩，如果应用的重要程度较低，可以采取对待回收内存的进程进行单个进程级缓存回收。其中，对待回收内存的进程进行单个进程级压缩是将终端中运行进程占用的内存资源通过交换分区进行压缩处理，从而达到减小占用系统物理内存的目的。对待回收内存的进程进行单个进程级缓存回收是提前将终端中缓存占用的内存空间释放，减少缓存所占用的内存，从而增加空闲内存，这样就可以提高内存分配的效率。

本发明实施例中，根据系统当前的内存压力，可以从后台进程列表中确定待回收内存的进程，这样就不会错杀重要进程，不会多杀或少杀进程。

204、向系统内核发送处理指令，以触发系统内核对待回收内存的进程进行处理以回收待回收内存的进程所占用的内存。

本发明实施例中，不同的内存压力等级可以采取不同的内存回收策略，每种内存回收策略对应一个接口。可以通过与内存回收策略对应的接口向系统内核发送处理指令，系统内核接收到处理指令之后，就可以采取相应的内存回收策略对待回收内存的进程进行处理以回收所述待回收内存的进程对应的内存。

其中，可以以kill_sig信号的方式向系统内核发送处理指令，通常，一个处理指令可以携带一个待回收内存的进程的标识。

其中，确定出的待回收的进程可以为一个也可以为多个，在一个进程需要发送多个处理指令的情况下，该进程可以一个一个连续地发送处理指令，而不需要在发送完一个处理指令后去检测系统内核回收进程对应的内存的状态，然后再去发送另一个处理指令。

作为一种可选的实施方式，在确定出的待回收的进程为多个的情况下，向系统内核发送处理指令包括：

调用多个线程向系统内核发送多个处理指令，其中，每个所述线程用于发送一个或多个处理指令。

在该可选的实施例中，在确定出的待回收的进程为多个的情况下，可以调用多个线程向系统内核发送多个处理指令，具体的，一个线程发送多个处理指令的实现方式为：该线程一个一个连续地发送处理指令，而不需要在发送完一个处理指令后去检测系统内核回收进程对应的内存的状态，然后再去发送另一个处理指令。系统对该待回收内存的进程所占用的内存进行回收后，可以缓解系统当前的内存压力。

可见，这种方式中，不需要等待系统内核真正完成进程对应的内存的回收操作，直接采取异步回收待回收内存的进程对应的内存的机制，加速后台进程的回收性能，从而提高内存回收的效率。

请一并参见图2c以及图2d，图2c是本发明实施例公开的一种相机启动时序图，图2d是本发明实施例公开的另一种相机启动时序图。其中，图2c中，相机应用程序在系统可用内存只有619mb时，在启动开始时不进行内存回收，等到系统的内存低于系统水线后，通过(lowmemorykiller，lmk)机制回收内存，从图2c可以看出，整个相机在内存只有619mb的时候启动，到出现相机的拍照按钮截止，总计花费了3.255s。其中，图2d中，相机应用程序在系统可用内存只有604mb时，采用本发明实施例中的方案，在启动时采取相应的策略进行内存回收，从图2d可以看出，整个相机在内存只有604mb的时候启动，到出现相机的拍照按钮截止，总计花费了1.85s。可见，从图2c以及图2d的对比可以看出，在同样的测试环境，可用内存相差不大的条件下，本发明方案相较于传统的lmk方案，相机启动性能得到明显改善。

可见，在图2所描述的方法流程中，在检测到第一关键事件并确定系统当前的可用内存小于内存阈值时，可以主动进行内存回收，当应用程序真正需要大量内存的时候，系统内核已经回收回来大量可用的内存，从而可以减少终端出现卡顿现象的概率。

请参见图3，图3是本发明实施例公开的另一种内存回收方法的流程示意图。其中，该方法可以应用于图1所示的内存管控模块1223，具体的，内存管控模块1223可以是一个或多个线程，或者，内存管控模块1223可以是一个或多个进程。如图3所示，该方法可以包括以下步骤。

301、在检测到第二关键事件且确定系统处于空闲状态时，确定当前系统的可用内存小于内存阈值。

本发明实施例中，内存管控模块1223可以检测应用程序的关键事件，具体的，可以在活动管理器服务(activitymanagerservice，ams)启动每个应用的活动(activity)的时候，通过钩子(hook)函数获取应用程序的关键信息(如进程名称、用户身份标识(useridentifier，uid)以及进程身份标识(processidentifier，pid)，进一步地，ams可以将获取到的应用程序的关键信息发送给内存管控模块1223，这样，内存管控模块1223就可以检测应用程序的关键事件。

其中，该应用程序的关键事件可以包括但不限于程序启动开始事件、清理事件、内存不足(outofmenory，oom)事件，程序启动完成事件、亮屏事件、灭屏事件、触屏事件、界面切换事件、任务切换完成事件、广播事件、网络连接/扫描/状态变化事件(如wifi、2/3/4g、蓝牙、红外、gps、电台广播、近场通信(nearfieldcommunication，nfc))、外设连接变化事件(如插拔充电器等)、通知闹铃类事件、电话类事件(来电、信号变化等)、媒体类事件(音视频变化、录音播放)、闪光灯相关类事件、程序安装卸载类事件、电池电量类事件等。

本发明实施例中，如果当前系统存在人机交互操作，系统直接进行内存回收，有可能会导致用户的响应操作由于cpu得不到及时响应而影响用户体验，这种情况下就不能立即进行内存回收。

可以预先将不需要立即进行内存回收的事件定义为第二关键事件，该第二关键事件可以包括但不限于以下程序启动完成事件、亮屏事件、灭屏事件、触屏事件、界面切换事件、任务切换完成事件以及广播事件。

在检测到第二关键事件时，可以先判断系统是否处于空闲状态，在确定系统处于空闲状态时，再读取当前系统的可用内存，以及判断当前系统的可用内存是否小于内存阈值，在确定当前系统的可用内存小于内存阈值时，表明当前系统存在内存压力，需要进行内存回收。其中，该内存阈值为与第二关键事件对应的第一内存阈值。其中，系统的空闲状态可以包括终端的空闲状态和应用的空闲状态。

可选的，该内存阈值可以静态预置的，或者，该内存阈值可以动态配置的，具体可以参照图2中所描述的，在此不再赘述。

可选的，可以通过读取终端的运行状态来确定系统是否处于空闲状态，或者，可以通过判断系统当前的负载情况来确定系统是否处于空闲状态。

系统处于空闲状态有2种场景，第一种是在用户未使用终端的情况下，比如终端处于待机状态可以看作是系统处于空闲状态，又比如：在应用启动完成出现显示画面，但以后并没有和终端进行交互，这个时候系统没有大量的io操作，可以看作是系统处于空闲状态，第二种是在用户使用终端但系统当前的负载不影响用户体验的情况下，可以看作是系统处于空闲状态，比如系统的负载小于负载阈值。

具体的，确定系统处于空闲状态的方式具体可以包括以下步骤：

11)判断所述系统当前的负载是否小于负载阈值；

12)在所述系统当前的负载小于所述负载阈值的情况下，确定系统处于空闲状态。

在该实施例中，可以预先设置一个负载阈值，该负载阈值可以是影响用户体验的系统的负载的临界值。如果判断系统当前的负载小于负载阈值，表明系统当前的负载不影响用户体验，则可以确定系统处于空闲状态。

302、在系统处于空闲状态时创建后台进程列表。

本发明实施例中，需要在系统处于空闲状态时进程内存回收，而后台进程列表是一个动态列表，故同样需要在系统处于空闲状态时创建后台进程列表，这样可以确保后台进程列表的有效性。

303、从后台进程列表中确定待回收内存的进程。

304、向系统内核发送处理指令，以触发系统内核对待回收内存的进程进行处理以回收待回收内存的进程对应的内存。

可见，在图3所描述的方法流程中，在检测到第二关键事件且系统处于空闲状态时确定当前系统的可用内存小于内存阈值，可以主动进行内存回收，当应用程序真正需要大量内存的时候，系统内核已经回收回来大量可用的内存，从而可以减少终端出现卡顿现象的概率。

请参见图4，图4是本发明实施例公开的另一种内存回收方法的流程示意图。其中，该方法可以应用于图1所示的内存管控模块1223，具体的，内存管控模块1223可以是一个或多个线程，或者，内存管控模块1223可以是一个或多个进程。如图4所示，该方法可以包括以下步骤。

401、在检测到第二关键事件时，确定当前系统的可用内存小于内存阈值。

其中，第二关键事件具体可以参照图3中所描述的，在此不再赘述，内存阈值具体可以参照图2所描述的，在此不再赘述。

本发明实施例中，图3所示的实施例是在检测到第二关键事件时先判断系统是否处于空闲状态，在确定系统处于空闲状态时再去读取当前系统的可用内存，而图4所示的实施例是在检测到第二关键事件时，先读取当前系统的可用内存，在确定当前系统的可用内存小于内存阈值的情况下，再判断系统是否处于空闲状态，在确定系统处于空闲状态时，执行步骤402。

402、在确定系统处于空闲状态时创建后台进程列表。

403、从后台进程列表中确定待回收内存的进程。

404、向系统内核发送处理指令，以触发系统内核对待回收内存的进程进行处理以回收待回收内存的进程对应的内存。

可见，在图4所描述的方法流程中，在检测到第二关键事件并确定系统当前的可用内存小于内存阈值时，可以在系统处于空闲状态时主动进行内存回收，当应用程序真正需要大量内存的时候，系统内核已经回收回来大量可用的内存，从而可以减少终端出现卡顿现象的概率。

请参见图5，图5是本发明实施例公开的一种内存回收装置的结构示意图。其中，该内存回收装置可以用于执行图2～图4中所描述的内存回收方法的部分或全部步骤，具体请参见图2～图4中的相关描述，在此不再赘述。如图5所示，该内存回收装置500可以包括：

确定单元501，用于在确定系统当前的可用内存小于内存阈值时，从后台进程列表中确定待回收内存的进程，其中，所述后台进程列表包括一个或多个应用的进程，所述待回收内存的进程为所述一个或多个应用的进程中满足进程所占用内存与内存压力值的差值的绝对值小于预设阈值的条件的进程，所述内存压力值为所述内存阈值与所述系统当前的可用内存的差值；

发送单元502，用于向系统内核发送处理指令，以触发所述系统内核对所述待回收内存的进程进行处理以回收所述待回收内存的进程所占用的内存。

其中，可选的，在检测到第一关键事件时触发所述确定系统当前的可用内存小于内存阈值的操作，且所述内存阈值为与所述第一关键事件对应的第一内存阈值。所述第一关键事件包括如下事件中的任意一种：程序启动开始事件、清理事件以及内存不足oom事件。

其中，可选的，在检测到第二关键事件且确定系统处于空闲状态时触发所述确定当前系统的可用内存小于内存阈值的操作，且所述内存阈值为与所述第二关键事件对应的第二内存阈值。

其中，可选的，在检测到第二关键事件时触发所述确定当前系统的可用内存小于内存阈值的操作，在确定系统处于空闲状态时触发所述从后台进程列表中选择待回收内存的进程的操作，且所述内存阈值为与所述第二关键事件对应的第二内存阈值。所述第二关键事件包括如下事件中的任意一种：程序启动完成事件、亮屏事件、灭屏事件、触屏事件、界面切换事件、任务切换完成事件以及广播事件。

可选的，所述确定单元501具体用于：

判断所述系统当前的负载是否小于负载阈值；

在所述系统当前的负载小于所述负载阈值的情况下，确定系统处于空闲状态。

可选的，在确定出的所述待回收的进程为多个的情况下，所述发送单元502具体用于：

调用多个线程向系统内核发送多个处理指令，其中，每个所述线程用于发送一个或多个处理指令。

可选的，所述确定单元501具体用于：

根据应用的重要程度从低到高的顺序，从所述后台进程列表包括的多个应用中确定至少一个应用；

根据进程优先级从低到高的顺序，从所述至少一个应用包括的进程中确定待回收内存的进程。

可选的，所述内存回收装置还包括：

创建单元503，用于在所述确定单元501确定所述系统当前的可用内存小于所述内存阈值时创建所述后台进程列表，或，用于在所述确定单元501确定所述系统当前的可用内存小于所述内存阈值并且所述系统处于空闲状态时创建所述后台进程列表。

可选的，创建单元503具体用于：

确定当前在后台运行的每个应用的关键因素的分值，所述关键因素包括以下中的一个或多个：进程优先级、用户使用习惯、进程占用系统资源以及应用的关联关系；

针对每个所述应用，将所有所述关键因素的分值进行加权计算，获得所述应用的重要程度；

根据所有所述应用的重要程度，对所有所述应用进行排序；

根据进程优先级，对排序后的每个所述应用包括的进程进行排序，以生成后台进程列表。

在图5所描述的内存回收装置中，在确定系统当前的可用内存小于内存阈值时，可以主动进行内存回收，当应用程序真正需要大量内存的时候，系统内核已经回收回来大量可用的内存，从而可以减少终端出现卡顿现象的概率。

请参见图6，图6是本发明实施例公开的一种终端的结构示意图。其中，该终端可以用于执行图2～图4中所描述的内存回收方法的部分或全部步骤，具体请参见图2～图4中的相关描述，在此不再赘述。如图6所示，终端600包括：射频(radiofrequency，rf)电路601、存储器602、输入单元603、显示单元604、传感器605、音频电路606、无线保真(wirelessfidelity，wifi)模块607、处理器608、以及电源609等部件。本领域技术人员可以理解，图6中示出的终端结构并不构成对手机的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。

rf电路601可用于收发信息或通话过程中，信号的接收和发送，特别地，将基站的下行信息接收后，给处理器608处理；另外，将设计上行的数据发送给基站。通常，rf电路601包括但不限于天线、至少一个放大器、收发信机、耦合器、低噪声放大器(lownoiseamplifier，lna)、双工器等。此外，rf电路601还可以通过无线通信与网络和其他设备通信。上述无线通信可以使用任一通信标准或协议，包括但不限于全球移动通讯系统(globalsystemofmobilecommunication，gsm)、通用分组无线服务(generalpacketradioservice，gprs)、码分多址(codedivisionmultipleaccess，cdma)、宽带码分多址(widebandcodedivisionmultipleaccess，wcdma)、长期演进(longtermevolution，lte)、电子邮件、短消息服务(shortmessagingservice，sms)等。

存储器602存储计算机程序，该计算机程序包括应用程序6021和操作系统程序6022，处理器608用于读取存储器602中的计算机程序，然后执行计算机程序定义的方法，例如处理器608读取操作系统程序6022从而在该终端600上运行操作系统以及实现操作系统的各种功能，或读取一种或多种应用程序6021，从而在该终端600上运行应用。操作系统6022中包含了可实现本发明实施例提供的内存回收方法的计算机程序，从而使得处理器608读取到该操作系统程序6022并运行该操作系统后，该操作系统可具备本发明实施例提供的内存回收功能。另外，存储器602还存储有除计算机程序之外的其他数据6023，其他数据6023可包括操作系统6022或应用程序6021被运行后产生的数据，该数据包括系统数据(例如操作系统的配置参数)和用户数据。此外，存储器602一般包括内存和外存。内存可以为随机存储器(ram)，只读存储器(rom)，以及高速缓存(cache)等。外存可以为硬盘、光盘、usb盘、软盘或磁带机等。计算机程序通常被存储在外存上，处理器在执行处理前会将计算机程序从外存加载到内存。

输入单元603可用于接收输入的数字或字符信息，以及产生与终端600的用户设置以及功能控制有关的键信号输入。具体地，输入单元603可包括触控面板6031以及其他输入设备6032。触控面板6031，也称为触摸屏，可收集用户在其上或附近的触摸操作(比如用户使用手指、触笔等任何适合的物体或附件在触控面板6031上或在触控面板6031附近的操作)，并根据预先设定的程式驱动相应的连接装置。可选的，触控面板6031可包括触摸检测装置和触摸控制器两个部分。其中，触摸检测装置检测用户的触摸方位，并检测触摸操作带来的信号，将信号传送给触摸控制器；触摸控制器从触摸检测装置上接收触摸信息，并将它转换成触点坐标，再送给处理器608，并能接收处理器608发来的命令并加以执行。此外，可以采用电阻式、电容式、红外线以及表面声波等多种类型实现触控面板6031。除了触控面板6031，输入单元603还可以包括其他输入设备6032。具体地，其他输入设备6032可以包括但不限于物理键盘、功能键(比如音量控制按键、开关按键等)、轨迹球、鼠标、操作杆等中的一种或多种。

显示单元604可用于显示由用户输入的信息或提供给用户的信息以及手机的各种菜单。显示单元604可包括显示面板6041，可选的，可以采用液晶显示器(liquidcrystaldisplay，lcd)、有机发光二极管(organiclight-emittingdiode,oled)等形式来配置显示面板6041。进一步的，触控面板6031可覆盖显示面板6041，当触控面板6031检测到在其上或附近的触摸操作后，传送给处理器608以确定触摸事件的类型，随后处理器608根据触摸事件的类型在显示面板6041上提供相应的视觉输出。虽然在图6中，触控面板6031与显示面板6041是作为两个独立的部件来实现手机的输入和输入功能，但是在某些实施例中，可以将触控面板6031与显示面板6041集成而实现手机的输入和输出功能。

传感器605可以为光传感器、运动传感器以及其他传感器。具体地，光传感器可包括环境光传感器及接近传感器，其中，环境光传感器可根据环境光线的明暗来调节显示面板6041的亮度，接近传感器可在手机移动到耳边时，关闭显示面板6041和/或背光。作为运动传感器的一种，加速计传感器可检测各个方向上(一般为三轴)加速度的大小，静止时可检测出重力的大小及方向，可用于识别手机姿态的应用(比如横竖屏切换、相关游戏、磁力计姿态校准)、振动识别相关功能(比如计步器、敲击)等；至于手机还可配置的陀螺仪、气压计、湿度计、温度计、红外线传感器等其他传感器，在此不再赘述。

音频电路606、扬声器6061，传声器6062可提供用户与手机之间的音频接口。音频电路606可将接收到的音频数据转换后的电信号，传输到扬声器6061，由扬声器6061转换为声音信号输出；另一方面，传声器6062将收集的声音信号转换为电信号，由音频电路606接收后转换为音频数据，再将音频数据输出处理器608处理后，经rf电路601以发送给比如另一手机，或者将音频数据输出至存储器602以便进一步处理。

wifi属于短距离无线传输技术，终端通过wifi模块607可以帮助用户收发电子邮件、浏览网页和访问流式媒体等，它为用户提供了无线的宽带互联网访问。虽然图6示出了wifi模块607，但是可以理解的是，其并不属于终端的必须构成，完全可以根据需要在不改变发明的本质的范围内而省略。

处理器608是终端的控制中心，利用各种接口和线路连接整个终端的各个部分，通过运行或执行存储在存储器602内的软件程序和/或模块，以及调用存储在存储器602内的数据，执行终端的各种功能和处理数据，从而对终端进行整体监控。可选的，处理器608可以包括一个或多个处理器，例如，处理器608可以包括一个或多个中央处理器，或者包括一个中央处理器和一个图形处理器。当处理器608包括多个处理器时，这多个处理器可以集成在同一块芯片上，也可以各自为独立的芯片。一个处理器可以包括一个或多个处理核。

终端600还包括给各个部件供电的电源609(比如电池)，优选的，电源可以通过电源管理系统与处理器608逻辑相连，从而通过电源管理系统实现管理充电、放电、以及功耗管理等功能。

尽管未示出，终端还可以包括摄像头、蓝牙模块等，在此不再赘述。

前述实施例中，各步骤方法流程可以基于该终端的结构实现。其中应用层和操作系统内核均可视为处理器608的抽象化结构的组成部分。

在本发明实施例中，处理器608通过调用存储于存储器602中的程序代码，用于执行以下操作：

在确定系统当前的可用内存小于内存阈值时，从后台进程列表中确定待回收内存的进程，其中，所述后台进程列表包括一个或多个应用的进程，所述待回收内存的进程为所述一个或多个应用的进程中满足进程所占用内存与内存压力值的差值的绝对值小于预设阈值的条件的进程，所述内存压力值为所述内存阈值与所述系统当前的可用内存的差值；

向系统内核发送处理指令，以触发所述系统内核对所述待回收内存的进程进行处理以回收所述待回收内存的进程所占用的内存。

其中，在检测到第一关键事件时触发所述确定系统当前的可用内存小于内存阈值的操作，且所述内存阈值为与所述第一关键事件对应的第一内存阈值。

其中，所述第一关键事件包括如下事件中的任意一种：程序启动开始事件、清理事件以及内存不足oom事件。

其中，在检测到第二关键事件且确定系统处于空闲状态时触发所述确定当前系统的可用内存小于内存阈值的操作，且所述内存阈值为与所述第二关键事件对应的第二内存阈值。

其中，在检测到第二关键事件时触发所述确定当前系统的可用内存小于内存阈值的操作，在确定系统处于空闲状态时触发所述从后台进程列表中选择待回收内存的进程的操作，且所述内存阈值为与所述第二关键事件对应的第二内存阈值。

其中，所述第二关键事件包括如下事件中的任意一种：程序启动完成事件、亮屏事件、灭屏事件、触屏事件、界面切换事件、任务切换完成事件以及广播事件。

作为另一种可选的实施方式，所述处理器608确定系统处于空闲状态包括：

判断所述系统当前的负载是否小于负载阈值；

在所述系统当前的负载小于所述负载阈值的情况下，确定系统处于空闲状态。

作为另一种可选的实施方式，在确定出的所述待回收的进程为多个的情况下，所述处理器608向系统内核发送处理指令包括：

调用多个线程向系统内核发送多个处理指令，其中，每个所述线程用于发送一个或多个处理指令。

作为另一种可选的实施方式，所述处理器608从后台进程列表中确定待回收内存的进程包括：

根据应用的重要程度从低到高的顺序，从所述后台进程列表包括的多个应用中确定至少一个应用；

根据进程优先级从低到高的顺序，从所述至少一个应用包括的进程中确定待回收内存的进程。

作为另一种可选的实施方式，所述处理器608通过调用存储于存储器602中的程序代码，还用于执行以下操作：

在确定所述系统当前的可用内存小于所述内存阈值时创建所述后台进程列表。

作为另一种可选的实施方式，所述处理器608通过调用存储于存储器602中的程序代码，还用于执行以下操作：

在确定所述系统当前的可用内存小于所述内存阈值并且所述系统处于空闲状态时创建所述后台进程列表。

作为另一种可选的实施方式，所述处理器608创建所述后台进程列表包括：

确定当前在后台运行的每个应用的关键因素的分值，所述关键因素包括以下中的一个或多个：进程优先级、用户使用习惯、进程占用系统资源以及应用的关联关系；

针对每个所述应用，将所有所述关键因素的分值进行加权计算，获得所述应用的重要程度；

根据所有所述应用的重要程度，对所有所述应用进行排序；

根据进程优先级，对排序后的每个所述应用包括的进程进行排序，以生成后台进程列表。

在图6所描述的终端600中，可以在确定系统当前的可用内存小于内存阈值时，可以主动进行内存回收，当应用程序真正需要大量内存的时候，系统内核已经回收回来大量可用的内存，从而可以减少终端出现卡顿现象的概率。

需要说明的是，对于前述的各方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本发明并不受所描述的动作顺序的限制，因为依据本发明，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定是本发明所必须的。

在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。

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

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

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

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储器中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储器中，包括若干指令用以使得一台计算机设备(可为个人计算机、服务器或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储器包括：u盘、只读存储器(rom，read-onlymemory)、随机存取存储器(ram，randomaccessmemory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。

本领域普通技术人员可以理解上述实施例的各种方法中的全部或部分步骤是可以通过程序来指令相关的硬件来完成，该程序可以存储于一计算机可读存储器中，存储器可以包括：闪存盘、只读存储器(英文：read-onlymemory，简称：rom)、随机存取器(英文：randomaccessmemory，简称：ram)、磁盘或光盘等。

以上对本发明实施例进行了详细介绍，本文中应用了具体个例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心思想；同时，对于本领域的一般技术人员，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本发明的限制。