CN104598315A - 管理内存的方法、装置及终端 - Google Patents

Abstract

本申请公开了管理内存的方法、装置及终端。所述方法的一具体实施方式包括：获取用户对应用程序的使用习惯数据；基于所述使用习惯数据确定受限应用程序；以及根据所述受限应用程序管理内存。该实施方式实现了自动根据用户对应用程序的使用习惯管理内存，提高了内存的使用效率，保证了***运行的流畅性。

Description

管理内存的方法、装置及终端

技术领域

本申请涉及计算机技术领域，具体涉及终端技术领域，尤其涉及管理内存的方法、装置及终端。

背景技术

随着科学技术的不断发展，智能终端被广泛地应用于人们的日常生活中，成为人们生活和工作中不可或缺的重要工具。但是，目前大部分智能终端在使用一段时间后，***的运行速度会变得缓慢。这是由于终端中某些第三方应用程序可通过多种方式启用自己的后台服务并长期占用内存。这些在后台运行的服务不断尝试连接网络或处理数据，占用了大量CPU资源，使***长期处于低内存状态，从而导致***性能下降，运行速度变慢，影响了用户正常的使用。

目前，现有的很多***管理工具都采用了用户自定义黑名单的方式，让用户自主选择常用或不常用的应用服务，从而阻止不常用的应用服务的启动。

发明内容

然而，大部分普通用户对自己的使用习惯并没有太多留意，对于应用的类别属性也没有准确的认识。因此，他们在选择需要列入黑名单的应用服务的方面，不具有专业的判断力，这造成人工定义的黑名单并不会是最优的。另一方面，专业知识的缺乏使得普通用户希望尽量避免***方面的修改。

为了解决上述一个或多个问题，本申请提供了一种管理内存的方法、装置及终端。

第一方面，本申请提供了一种管理内存的方法，所述方法包括：获取用户对应用程序的使用习惯数据；基于所述使用习惯数据确定受限应用程序；以及根据所述受限应用程序管理内存。

在某些实施方式中，所述确定受限应用程序包括：根据所述使用习惯数据计算每个应用程序的活跃度；以及按照所述活跃度选取应用程序作为所述受限应用程序。

在某些优选实施方式中，所述选取应用程序包括以下至少一项：按照活跃度从低到高的顺序选取预定个数的应用程序；按照活跃度从低到高的顺序选取预定比例的应用程序；以及选取活跃度低于预定活跃值的应用程序。

在某些优选实施方式中，所述使用习惯数据包括预定时间段内的以下至少一项特征值：应用程序在前台的运行时间；用户进入应用程序的次数；以及应用程序的CPU占有率。

在某些优选实施方式中，所述应用程序的CPU占有率为：在所述预定时间段内所述应用程序的所有进程中的最高CPU占有率；或在所述预定时间段内所述应用程序的所有进程的平均CPU占有率。

在某些优选实施方式中，所述计算每个应用程序的活跃度包括：计算所述特征值的加权和以作为所述活跃度。

在某些优选实施方式中，所述计算每个应用程序的活跃度包括：计算本次预定时间段内所述特征值的加权和以作为本次的基础活跃度；以及将上次的活跃度与本次的基础活跃度以预定权重比例相加作为本次的活跃度。

在某些优选实施方式中，所述上次的活跃度的权重低于所述本次的基础活跃度的权重。

在某些实施方式中，所述确定受限应用程序响应于满足如下至少一项条件而执行：预定时间段期满；到达预定时刻；以及清理内存的触发条件。

在某些实施方式中，所述管理内存包括以下至少一项：响应于满足清理内存的触发条件，根据所述受限应用程序清理内存；以及根据所述受限应用程序限制所述受限应用程序对应服务的自启动。

在某些优选实施方式中，所述清理内存包括：强制停止所述受限应用程序对应的服务。

在某些优选实施方式中，所述清理内存还包括：强制停止所述受限应用程序的所有进程。

在某些优选实施方式中，所述限制包括以下至少一项：取消所述服务的自启动设置；以及响应于检测到所述受限应用程序对应服务的自启动，阻止所述服务自启动。

在某些优选实施方式中，所述阻止包括：判断所述服务对应的所述受限应用程序是否处于用户可感状态；若所述受限应用程序处于用户可感状态，则允许所述服务启动；以及若所述受限应用程序不处于用户可感状态，则阻止所述服务启动。

在某些实施方式中，所述方法还包括：提供操作界面以供用户确认和/或调整所述受限应用程序。

在某些优选实施方式中，在所述操作界面上显示应用程序的使用习惯数据。

在某些优选实施方式中，所述应用程序按照所述使用习惯数据中的一项或多项特征值而排序。

第二方面，本申请提供了一种管理内存的装置，所述装置包括：获取单元，用于获取用户对应用程序的使用习惯数据；确定单元，用于基于所述使用习惯数据确定受限应用程序；以及管理单元，用于根据所述受限应用程序管理内存。

在某些实施方式中，所述确定单元包括：计算子单元，用于根据所述使用习惯数据计算每个应用程序的活跃度；选取子单元，用于按照所述活跃度选取应用程序作为所述受限应用程序。

在某些优选实施方式中，所述选取子单元配置用于按照以下至少一项来选取应用程序：按照活跃度从低到高的顺序选取预定个数的应用程序；按照活跃度从低到高的顺序选取预定比例的应用程序；以及选取活跃度低于预定活跃值的应用程序。

在某些优选实施方式中，所述使用习惯数据包括预定时间段内的以下至少一项特征值：应用程序在前台的运行时间；用户进入应用程序的次数；以及应用程序的CPU占有率。

在某些优选实施方式中，所述应用程序的CPU占有率为：在所述预定时间段内所述应用程序的所有进程中的最高CPU占有率；或在所述预定时间段内所述应用程序的所有进程的平均CPU占有率。

在某些优选实施方式中，所述计算子单元配置用于按如下计算活跃度：计算所述特征值的加权和以作为所述活跃度。

在某些优选实施方式中，所述计算子单元配置用于按如下计算活跃度：计算本次预定时间段内所述特征值的加权和以作为本次的基础活跃度；以及将上次的活跃度与本次的基础活跃度以预定权重比例相加作为本次的活跃度。

在某些优选实施方式中，所述上次的活跃度的权重低于所述本次的基础活跃度的权重。

在某些实施方式中，所述确定单元配置用于响应于满足如下至少一项条件而执行所述确定：预定时间段期满；到达预定时刻；以及清理内存的触发条件。

在某些实施方式中，所述管理单元包括以下至少一个子单元：清理子单元，用于响应于满足清理内存的触发条件，根据所述受限应用程序清理内存；以及限制子单元，用于根据所述受限应用程序限制所述受限应用程序对应服务的自启动。

在某些优选实施方式中，所述清理子单元配置用于强制停止所述受限应用程序对应的服务。

在某些优选实施方式中，所述清理子单元还配置用于强制停止所述受限应用程序的所有进程。

在某些优选实施方式中，所述限制子单元包括以下至少一个模块：修改模块，用于取消所述服务的自启动设置；以及阻止模块，用于响应于检测到所述受限应用程序对应服务的自启动，阻止所述服务自启动。

在某些优选实施方式中，所述阻止模块配置用于通过如下来阻止服务自启动：判断所述服务对应的所述受限应用程序是否处于用户可感状态；以及响应于所述受限应用程序不处于用户可感状态，阻止所述服务启动。

在某些实施方式中，所述装置还包括：界面单元，用于提供操作界面以供用户确认和/或调整所述受限应用程序。

在某些优选实施方式中，在所述操作界面上显示应用程序的使用习惯数据。

在某些优选实施方式中，所述应用程序按照所述使用习惯数据中的一项或多项特征值而排序。

第三方面，本申请提供了一种终端，包括：第二方面或第二方面的任一种可能的实现方式所述的装置。

本申请提供的管理内存的方法、装置及终端通过学习用户对应用程序的使用习惯，确定受限应用程序，并基于受限应用程序对内存进行管理，从而提高了内存的使用效率，保证了***运行的流畅性。

附图说明

通过阅读参照以下附图所作的对非限制性实施例所作的详细描述，本申请的其它特征、目的和优点将会变得更明显：

图1是本申请提供的管理内存的方法的一个实施例的流程图；

图2是本申请实施例提供的终端屏幕上悬浮按钮的示意图；

图3是本申请提供的基于使用习惯数据确定受限应用程序的方法的一个实施例的流程图；

图4是本申请提供的阻止受限应用程序对应服务的自启动的方法的一个实施例的流程图；

图5是本申请实施例提供的确认和/或调整受限应用程序的操作界面的示意图；以及

图6是本申请提供的管理内存的装置的一个实施例的结构示意图。

具体实施方式

下面结合附图和实施例对本申请作进一步的详细说明。可以理解的是，此处所描述的具体实施例仅仅用于解释相关发明，而非对该发明的限定。另外还需要说明的是，为了便于描述，附图中仅示出了与有关发明相关的部分。

需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。下面将参考附图并结合实施例来详细说明本申请。

本申请的管理内存的方法可以应用于各种终端，这些终端能够运行第三方服务，并且具有用于显示信息的屏幕以便与用户进行交互。终端可以包括但不限于智能手机、平板电脑、个人数字助理、智能穿戴设备、膝上型便携计算机及台式电脑等等。出于示例描述目的以及为了简洁起见，在接下来的讨论中，结合智能手机来描述本申请的示例性实施例。

请参考图1，其示出了根据本申请的管理内存的方法的一个实施例的流程100。

如图1所示，在步骤101中，获取用户对应用程序的使用习惯数据。

一般而言，应用程序为安装在终端上的一种第三方应用软件。应用程序运行在用户模式下，可以与用户交互，通常具有可视的用户界面。每个应用程序可以启用多个进程，这些进程中可能包括该应用程序的多个服务(服务进程)。当应用程序关闭以后，其对应的某些服务可能仍然在后台保持运行状态。例如，某个视频播放应用程序具有UI(User Interface，用户界面)进程和其它多个服务进程。当用户关闭该视频播放应用程序后，UI进程停止运行，但其它的一些服务进程可能仍然在后台运行，例如从服务器获取某些数据推送给用户。因此，在用户关闭此视频播放应用程序后，该程序仍然能向用户推送一些关于热点视频的消息。应用程序通过这种方式常驻于内存中，消耗了***大量资源。

在本实施例中，使用习惯数据反映了用户对应用程序的使用习惯。可以通过统计用户在某个时间段内对应用程序的使用情况来反映用户对应用程序的使用习惯。可以理解，统计的时间段越长，越能够真实地反映用户的使用习惯。使用习惯数据例如可以包含反映用户在预定时间段内使用各个应用程序的频率的相关数据；也可以包含反映用户在预定时间段内使用各个应用程序的时间长度的相关数据；还可以包含反映在预定时间段内，各个应用程序对CPU的占用情况的相关数据。除了前台运行的应用程序占用较高的CPU以外，当某应用程序对应的服务跨程序运行时，该应用程序也占用了较高的CPU。因为，虽然前台运行的是其它应用程序，但该应用程序对应的服务也同时在运行和执行任务。例如，用户在阅读电子书时，可以同时使用翻译的应用程序进行屏幕取词，此时，在前台运行的是电子书阅读应用程序，但翻译的应用程序对应的服务也在运行。所以翻译的应用程序也占用了较高的CPU。因此，应用程序对CPU的占用情况也能反映用户的使用习惯。可以理解，使用习惯数据可以包含任意能够反映上述情况的数据，本申请对此方面不限定。

可选地，在一些实施例中，使用习惯数据具体可以包括预定时间段内的以下至少一项特征值：应用程序在前台的运行时间，用户进入应用程序的次数以及应用程序的CPU占有率。

在本实施例中，可以通过不同的方式获取应用程序在前台的运行时间。例如，在一种实现方式中，可以在每次应用程序进入前台运行的时刻，启动计时器开始计时，并在应用程序退出前台运行的时刻，停止计时器的计时，从计时器获取每次应用程序在前台的运行时间。然后，可以通过将预定时间段内每次应用程序在前台的运行时间相加，获得预定时间段内应用程序在前台的运行的总时间。

在另一种实现方式中，也可以分别记录每次应用程序进入前台运行的时刻和退出前台运行的时刻，将上述两个时刻之间的时间差作为每次应用程序在前台的运行时间。并可以通过将预定时间段内每次应用程序在前台的运行时间相加，获得预定时间段内应用程序在前台的运行的总时间。可以理解，还有其他获取应用程序在前台的运行时间的方式，本申请对此方面不限定。

在本实施例中，也可以通过不同的方式获取用户进入应用程序的次数。例如，可以在每次应用程序进入前台运行后，当该应用程序退出前台运行时，其对应的次数计数增加1。可以理解，还有其他获取用户进入应用程序的次数的方式，本申请对此方面不限定。

应用程序的CPU占有率反映了应用程序对CPU的占用情况。应用程序的CPU占有率可以为在预定时间段内该应用程序的所有进程中的最高CPU占有率，也可以为在预定时间段内该应用程序的所有进程的平均CPU占有率。可以理解，任何能够反映应用程序对CPU的占用情况的数据均可以作为应用程序的CPU占有率，本申请对此方面不限定。

例如，在获取应用程序的CPU占有率时，可以先获取每个应用程序所包含的所有进程的集合，然后计算应用程序对应的每个进程的CPU占有率，取其中最高的CPU占有率作为该应用程序的CPU占有率，或者取应用程序对应的每个进程的CPU占有率的平均值作为该应用程序的CPU占有率。

在一些实施例中，可以持续地获取用户对应用程序的使用习惯数据。例如，当用户首次使用终端时即开始监控用户的使用习惯。可以理解，由于存储容量的限制，只能存储有限的使用习惯数据。在一些实施例中，可以始终保存最近一段时间内的使用习惯数据，例如一天内、一周内或者更长或更短的时间内。在另一些实施例中，可以始终保存一定数量的使用习惯数据。取决于终端上所安装的/需监控的应用程序的数量，所保存的使用习惯数据所涉及的时间段长度也可能不尽相同。例如，当应用程序数量较多时，可能只能保存最近较短一段时间内的使用习惯数据；而当应用程序数量较少时，可以保存最近较长一段时间内的使用习惯数据。

接着，在步骤102中，基于上述使用习惯数据确定受限应用程序。

在本实施例中，可以将用户平时使用较少的应用程序确定为受限应用程序。由于使用习惯数据反映了用户在某个时间段内对应用程序的使用习惯，因此，根据使用习惯数据确定受限应用程序，可以智能地确定用户不常用的应用程序，而无需用户人工定义不常用的应用程序，诸如人工定义黑名单。

最后，在步骤103中，根据上述受限应用程序管理内存。

在本实施例的一种实现中，可以将确定的受限应用程序列入受限列表(如黑名单)中，依据受限列表来管理内存。在另一种实现中，也可以对确定的受限应用程序进行标识，根据受限应用程序的标识来管理内存。可以理解，还可以有其他记录或标记受限应用程序的方式，本申请对此方面不限定。

在本实施例中，管理内存可以包括以下至少一项：响应于满足清理内存的触发条件，根据受限应用程序清理内存；以及限制受限应用程序对应服务的自启动。

清理内存的触发条件可以包括但不限于：可用内存低于预设内存值(例如，100MB)；运行的服务进程数量超过预设数量值(例如，55个)；以及用户的预定操作。前两个条件取决于终端的状态，后一个条件取决于用户的意愿，也即用户在任意时刻如果想清理内存，就可以执行清理内存的预定操作。在一些实施例中，用户清理内存的预定操作可以为按压预设按钮。图2示出了本申请实施例提供的预设按钮的一种示例性实现，也即终端屏幕上的悬浮按钮。如图2所示，点击屏幕上的悬浮按钮，可以触发清理内存的操作。在另一些实施例中，用户清理内存的预定操作也可以是关闭屏幕的操作，也即关闭屏幕后进行内存的清理。在又一些实施例中，用户清理内存的预定操作还可以是用户从操作界面的菜单中选取清理内存的菜单选项。可以理解，用户清理内存的预定操作还可以为其它形式的操作，可以通过用户接口对预定操作的具体形式进行设置，本申请对此方面不限定。

本申请的上述实施例提供的管理内存的方法，通过学习用户对应用程序的使用习惯，确定受限应用程序，并基于受限应用程序对内存进行管理，从而提高了内存的使用效率，保证了***运行的流畅性。

进一步参考图3，其示出了本申请提供的基于使用习惯数据确定受限应用程序的方法的一个实施例的流程图，也即图1中的步骤102的一个实施例的流程200。

如图3所示，在步骤301中，根据使用习惯数据计算每个应用程序的活跃度。

在本实施例中，应用程序的活跃度体现了该应用程序的使用率。例如，在预定时间段内，用户进入某应用程序的次数越多，或者使用该应用程序的时间越长，或者该应用程序占用的CPU越多(说明该应用程序在前台运行或者该应用程序对应的服务跨程序运行)，则该应用程序在预定时间段内的使用率越高，活跃度越大。

优选地，使用习惯数据包括预定时间段内的以下特征值：应用程序在前台的运行时间；用户进入应用程序的次数；以及应用程序的CPU占有率。为了便于描述，不防假设在预定时间段T内：某应用程序在前台的运行时间为t，用户进入该应用程序的次数为c，该应用程序的CPU占有率为u。

在一种实现中，计算每个应用程序的活跃度包括：计算使用习惯数据中的各个特征值的加权和以作为该应用程序的活跃度。以使用习惯数据包括上述特征值为例，在此实现中，某应用程序的活跃度可以表示为：

$S={\mathrm{\ω}}_1*\frac{t}{T}+{\mathrm{\ω}}_2*\frac{c}{C}+{\mathrm{\ω}}_3*u---\left(1\right)$

其中，S为该应用程序的活跃度，ω₁为该应用程序的前台运行时间在计算中所占的权重，T为预定时间段的时间长度，ω₂为用户进入该应用程序的次数在计算中所占的权重，C为预定时间段内用户进入所有应用程序的总次数，ω₃为该应用程序的CPU占有率在计算中所占的权重。

在本实施例中，ω₁、ω₂、ω₃为经验值，可以通过多次实验获得的实验数据拟合并调整。在一种实现中，可以取ω₁＝80，ω₂＝110，ω₃＝1。可以理解，ω₁、ω₂、ω₃还可以取其它的值，本申请对ω₁、ω₂、ω₃的取值方面不限定。

在另一种实现中，计算应用程序的活跃度除了要考虑本次预定时间段内上述特征值的加权和(可以称为本次的基础活跃度)外，还要考虑上次的活跃度，即，将上次的活跃度与本次的基础活跃度以预定权重比例相加作为本次活跃度。在一种实施例中，应用程序的本次活跃度可以为：

S＝(1-ν)*S₁+ν*S₂   (2)

其中，S为本次活跃度，S₁为本次的基础活跃度，(1-ν)为本次的基础活跃度在计算中所占的权重，S₂为上次的活跃度，ν为上次活跃度在计算中所占的权重(S₁可根据公式(1)计算得到)。可以理解，本次活跃度S可以用于下次活跃度计算中。

在本实施例中，ν为经验值，可以通过多次实验获得的实验数据拟合并调整，优选地，上次活跃度的权重低于本次的基础活跃度的权重(即上次活跃度的权重ν＜0.5)。可以理解，ν的值可以有多种，本申请对ν的取值方面不限定。

考虑到每次计算活跃度所涉及的使用习惯数据的时间段的长短可能不一致，在一些实施例中，可以对活跃度进行归一化，例如统一以一个固定时长(例如，24小时)为标准来计算活跃度，从而便于直接利用历史活跃度来更新当前活跃度。在另一些实施例中，可以在需要利用历史活跃度来更新当前活跃度时，根据历史活跃度的计算中所涉及的时间段长度，将历史活跃度按比例换算为符合当前活跃度计算所涉及的时间段长度的值，然后再使用换算后的值来更新当前活跃度。

在上述各实施例中，通过考虑上次的活跃度，避免了单次活跃度不能准确反映用户的使用习惯。用户使用时间越长，通过学习用户习惯而确定的应用程序的活跃度越准确，在管理内存(例如，终止应用程序的进程等)方面的选择也更加准确，能有效提升用户体验。

最后，在步骤302中，按照活跃度选取应用程序作为受限应用程序。

在本实施例中，基于选择活跃度较小的应用程序作为受限应用程序的原则选取应用程序，也即需要限制用户不常使用的应用程序。在一种实现中，可以选取活跃度最小的若干个(预定个数)应用程序作为受限应用程序。具体来说，先根据活跃度对应用程序进行排序，然后按照活跃度从低到高的顺序选取预定个数的应用程序作为受限应用程序。其中，选取的受限应用程序的个数可以是***默认的，也可以是用户预先设定的，例如通过提供的用户接口来设定，本申请对受限应用程序的个数以及设置该个数的方式不限定。

在另一种实现中，可以选取活跃度最小的某个比例(预定比例，如20％)的应用程序作为受限应用程序。具体来说，也是先根据活跃度对应用程序进行排序，然后按照预定的比例计算需要选取的应用程序的个数n，再按照活跃度从低到高的顺序选取n个应用程序作为受限应用程序。其中，选取的受限应用程序所占比例可以是***默认的，也可以是用户预先设定的，例如通过提供的用户接口来设定，本申请对选取比例以及设置该选取比例的方式不限定。

在又一种实现中，还可以选取活跃度低于预定活跃值的应用程序作为受限应用程序。在该实现方式中，不需要对应用程序进行排序，而预定活跃值可以是***默认的，也可以是用户预先设定的，本申请同样对选取预定活跃值以及设置该预定活跃值的方式不限定。

在一些可选实施方式中，确定受限应用程序可以响应于满足如下至少一项条件而执行：预定时间段期满；到达预定时刻；以及清理内存的触发条件。

具体来说，在本实施例的一种实现中，可以预先设定一个周期T0，每个周期期满时，就执行确定受限应用程序的步骤，以保证不断根据用户新的使用习惯更新受限应用程序。周期越长，所表现出的用户习惯将更加准确且稳定。在一个示例中，周期可以是24小时。可以提供用户接口以供用户设定上述周期。

在另一种实现中，可以预先设定一个或多个时刻，这些预定的时刻可以是用户使用终端比较多的时刻，例如中午1点或者晚上9点等等。每到预定时刻时，就执行确定受限应用程序的步骤。可以提供用户接口以供用户设定上述时刻。

在又一种实现中，当满足清理内存的触发条件时，执行确定受限应用程序的步骤，然后根据确定的受限应用程序清理内存。其中，清理内存的触发条件如前面所提到的可以包括但不限于：可用内存低于预设内存值；运行的服务进程数量超过预设数量值；以及用户的预定操作。***内存贫乏时更新受限应用程序，可使得***尽快清理用户不常使用的应用程序，腾出更多的内存，使***尽快摆脱低内存状态，提高***性能。可以提供用户接口以供用户设定上述触发条件。

如前面所提到的，根据受限应用程序管理内存可以包括以下至少一项：响应于满足清理内存的触发条件，根据受限应用程序清理内存；以及限制受限应用程序对应服务的自启动。

有的应用程序在关闭以后，其对应的某些服务可能仍然在后台保持运行状态。应用程序通过这种方式常驻于内存中，消耗了***大量资源。因此，在一些可选实施方式中，清理内存可以包括强制停止受限应用程序对应的服务。这样，可以将不常用但是常驻内存的服务强制停止，从而释放***资源，保证***运行的流畅性。在进一步地实施方式中，清理内存还可以包括强制停止受限应用程序的所有进程。

有些情况下，有些服务进程即使在***例如由于低内存而清理内存时被暂时杀掉，但是在内存足够时又可能被重新启动，重新占用内存，使***再次进入低内存状态。这样，***忙于杀掉服务、启动服务的操作，来不及对用户的操作进行反应，***运行不流畅，严重影响了用户体验。

针对这种情况，本申请实施例的管理内存还可以包括限制受限应用程序对应服务的自启动。在一些可选实施方式中，限制受限应用程序对应服务的自启动可以包括以下至少一项：取消受限应用程序对应服务的自启动设置；以及响应于检测到受限应用程序对应服务的自启动，阻止该服务自启动。

具体来说，应用程序对应的服务可能预先设置了自启动，使服务能够在一定条件下自动启动，在本实施例中，通过取消受限应用程序对应服务的自启动设置，从而限制了受限应用程序对应服务的自启动。取决于具体设置，取消受限应用程序对应服务的自启动设置可以包括修改应用程序的设置以禁用服务自启动功能，也可以包括修改***的设置以禁用对应服务的自启动功能。

进一步参考图4，其示出了本申请提供的阻止受限应用程序对应服务的自启动的方法的一个实施例的流程400，该流程响应于检测到受限应用程序对应服务的自启动而执行。

如图4所示，在步骤401中，判断服务对应的受限应用程序是否处于用户可感状态。

在本实施例中，如果服务对应的受限应用程序处于用户可感状态说明该应用程序正在被用户使用。用户可感状态包括前台状态以及应用程序的用户界面退出但是后台服务正在处理用户可感受的任务，如播放音乐等。为了防止正在被用户使用的应用程序和其对应的服务被强制关闭，而给用户带来不必要的麻烦，需要首先判断服务对应的受限应用程序是否处于用户可感状态。

接着，在步骤402a中，若受限应用程序处于用户可感状态，则允许其对应的服务启动。

或者，在步骤402b中，若受限应用程序不处于用户可感状态，则阻止其对应的服务启动。

需要说明的是，为了防止一些重要的应用程序的服务在后台运行时，不被强制关闭，可以预先设置一个可放行列表(即白名单)，当确定受限应用程序时，可以不考虑可放行列表中的应用程序。可放行列表可以是***默认的，也可以提供用户接口以供用户设定可放行列表中的应用程序。例如，可以将一些***类应用程序、预加载类应用程序、翻译类应用程序、输入法类应用程序等设置为可放行列表中的应用程序。

在一些可选实施方式中，还可以提供操作界面以供用户确认和/或调整受限应用程序。

进一步地，在该操作界面上显示所有应用程序的使用习惯数据。每一项应用程序都表明了该应用的前台时间、进入次数以及CPU使用率，用户可以通过这些特征值了解应用程序的使用情况。可选地，应用程序可以按照使用习惯数据中的一项或多项特征值而递减或递增排序。

图5示出了确认和/或调整受限应用程序的操作界面示意图。如图5所示，用户可以通过在操作界面上的操作确认和/或调整受限应用程序(黑名单中的应用程序)。图5示出了黑名单(也即受限应用程序)、白名单(也即可放行应用程序)和所有应用三个选项卡。例如，用户可以选择“所有应用”选项卡，界面上会将所有应用程序及其对应的使用习惯数据显示出来。在“排序”一行的选项中，可以选择以何种特征值进行排序，如，按照前台时间、进入次数或CPU占有率进行排序。如果选择全部特征值，则按照基于这些特征值计算的活跃度排序。用户可以勾选出想要放入黑名单或白名单的应用程序，然后选择移动到黑名单或白名单即可。

在一些实施例中，响应于确定受限应用程序，可以向用户提供或推送一个通知或者消息，以提示用户已自动确定受限应用程序。继而，用户可以通过预定的操作(如点击确认按钮或点击通知消息)进入确认和/或调整受限应用程序的操作界面，以对受限应用程序进行人工调整。通过这种人工调整，可以避免或减少错误的确定。

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

进一步参考图6，其示出了根据本申请的管理内存的装置的一个实施例的结构示意图。

如图6所示，本实施例的管理内存的装置600包括：获取单元601，确定单元602和管理单元603。其中，获取单元601用于获取用户对应用程序的使用习惯数据。确定单元602用于基于上述使用习惯数据确定受限应用程序。管理单元603用于根据上述受限应用程序管理内存。

在一些可选实施方式中，确定单元602包括计算子单元以及选取子单元(未示出)。其中，计算子单元用于根据使用习惯数据计算每个应用程序的活跃度。选取子单元用于按照上述活跃度选取应用程序作为受限应用程序。

在一些可选实施方式中，选取子单元配置用于按照以下至少一项来选取应用程序：按照活跃度从低到高的顺序选取预定个数的应用程序；按照活跃度从低到高的顺序选取预定比例的应用程序；以及选取活跃度低于预定活跃值的应用程序。

在一些可选实施方式中，使用习惯数据包括预定时间段内的以下至少一项特征值：应用程序在前台的运行时间；用户进入应用程序的次数；以及应用程序的CPU占有率。

在一些可选实施方式中，应用程序的CPU占有率为：在上述预定时间段内应用程序的所有进程中的最高CPU占有率；或在上述预定时间段内应用程序的所有进程的平均CPU占有率。

在一些可选实施方式中，计算子单元配置用于按如下计算活跃度：计算上述特征值的加权和以作为活跃度。

在一些可选实施方式中，计算子单元配置用于按如下计算活跃度：计算本次预定时间段内上述特征值的加权和以作为本次的基础活跃度。以及将上次的活跃度与本次的基础活跃度以预定权重比例相加作为本次的活跃度。

在一些可选实施方式中，上次的活跃度的权重低于本次的基础活跃度的权重。

在一些可选实施方式中，确定单元602配置用于响应于满足如下至少一项条件而执行上述确定：预定时间段期满；到达预定时刻；以及清理内存的触发条件。

在一些可选实施方式中，管理单元603包括以下至少一个子单元：清理子单元和限制子单元(未示出)，其中，清理子单元用于响应于满足清理内存的触发条件，根据受限应用程序清理内存。限制子单元用于根据受限应用程序限制该受限应用程序对应服务的自启动。

在一些可选实施方式中，清理子单元配置用于强制停止上述受限应用程序对应的服务。

在一些可选实施方式中，清理子单元还配置强制停止上述受限应用程序的所有进程。

在一些可选实施方式中，限制子单元包括以下至少一个模块：修改模块和阻止模块(未示出)，修改模块用于取消上述服务的自启动设置。阻止模块用于响应于检测到受限应用程序对应服务的自启动，阻止所述服务自启动。

在一些可选实施方式中，阻止模块配置用于通过如下来阻止服务自启动：判断上述服务对应的受限应用程序是否处于用户可感状态；以及响应于该受限应用程序不处于用户可感状态，阻止对应服务启动。

在一些可选实施方式中，装置600还包括界面单元(未示出)，界面单元用于提供操作界面以供用户确认和/或调整受限应用程序。

在一些可选实施方式中，在操作界面上显示应用程序的使用习惯数据。

在一些可选实施方式中，应用程序按照使用习惯数据中的一项或多项特征值而排序。

应当理解，装置600中记载的诸单元或模块与参考图1-5描述的方法中的各个步骤相对应。由此，上文针对方法描述的操作和特征同样适用于装置600及其中包含的单元，在此不再赘述。装置600可以预先设置在终端中，也可以通过下载等方式而加载到终端中。装置600中的相应单元可以与终端中的单元相互配合以实现管理内存的方案。

本申请还提供了一种终端，该终端包括上述的管理内存的装置。在本实施例中，该终端包括但不限于智能手机、平板电脑、个人数字助理、智能穿戴设备、膝上型便携计算机及台式电脑等等。

描述于本申请实施例中所涉及到的单元模块可以通过软件的方式实现，也可以通过硬件的方式来实现。所描述的单元模块也可以设置在处理器中，例如，可以描述为：一种处理器包括获取单元，确定单元，管理单元。其中，这些单元模块的名称在某种情况下并不构成对该单元模块本身的限定，例如，获取单元还可以被描述为“用于获取用户对应用程序的使用习惯数据的单元”。

作为另一方面，本申请还提供了一种计算机可读存储介质，该计算机可读存储介质可以是上述实施例中所述装置中所包含的计算机可读存储介质；也可以是单独存在，未装配入终端中的计算机可读存储介质。所述计算机可读存储介质存储有一个或者一个以上程序，所述程序被一个或者一个以上的处理器用来执行描述于本申请的管理内存的方法。

以上描述仅为本申请的较佳实施例以及对所运用技术原理的说明。本领域技术人员应当理解，本申请中所涉及的发明范围，并不限于上述技术特征的特定组合而成的技术方案，同时也应涵盖在不脱离所述发明构思的情况下，由上述技术特征或其等同特征进行任意组合而形成的其它技术方案。例如上述特征与本申请中公开的(但不限于)具有类似功能的技术特征进行互相替换而形成的技术方案。

Claims (20)

1.一种管理内存的方法，其特征在于，所述方法包括：

获取用户对应用程序的使用习惯数据；

基于所述使用习惯数据确定受限应用程序；以及

根据所述受限应用程序管理内存。

2.根据权利要求1所述的方法，其特征在于，所述确定受限应用程序包括：

根据所述使用习惯数据计算每个应用程序的活跃度；以及

按照所述活跃度选取应用程序作为所述受限应用程序。

3.根据权利要求2所述的方法，其特征在于，所述选取应用程序包括以下至少一项：

按照活跃度从低到高的顺序选取预定个数的应用程序；

按照活跃度从低到高的顺序选取预定比例的应用程序；以及

选取活跃度低于预定活跃值的应用程序。

4.根据权利要求2所述的方法，其特征在于，所述使用习惯数据包括预定时间段内的以下至少一项特征值：

应用程序在前台的运行时间；

用户进入应用程序的次数；以及

应用程序的CPU占有率。

5.根据权利要求4所述的方法，其特征在于，所述应用程序的CPU占有率为：

在所述预定时间段内所述应用程序的所有进程中的最高CPU占有率；或

在所述预定时间段内所述应用程序的所有进程的平均CPU占有率。

6.根据权利要求4所述的方法，其特征在于，所述计算每个应用程序的活跃度包括：计算所述特征值的加权和以作为所述活跃度。

7.根据权利要求4所述的方法，其特征在于，所述计算每个应用程序的活跃度包括：

计算本次预定时间段内所述特征值的加权和以作为本次的基础活跃度；以及

将上次的活跃度与本次的基础活跃度以预定权重比例相加作为本次的活跃度。

8.根据权利要求7所述的方法，其特征在于，所述上次的活跃度的权重低于所述本次的基础活跃度的权重。

9.根据权利要求1所述的方法，其特征在于，所述确定受限应用程序响应于满足如下至少一项条件而执行：

预定时间段期满；

到达预定时刻；以及

清理内存的触发条件。

10.根据权利要求1所述的方法，其特征在于，所述管理内存包括以下至少一项：

响应于满足清理内存的触发条件，根据所述受限应用程序清理内存；以及

根据所述受限应用程序限制所述受限应用程序对应服务的自启动。

11.根据权利要求10所述的方法，其特征在于，所述清理内存包括：

强制停止所述受限应用程序对应的服务。

12.根据权利要求11所述的方法，其特征在于，所述清理内存还包括：

强制停止所述受限应用程序的所有进程。

13.根据权利要求10所述的方法，其特征在于，所述限制包括以下至少一项：

取消所述服务的自启动设置；以及

响应于检测到所述受限应用程序对应服务的自启动，阻止所述服务自启动。

14.根据权利要求13所述的方法，其特征在于，所述阻止包括：

判断所述服务对应的所述受限应用程序是否处于用户可感状态；

若所述受限应用程序处于用户可感状态，则允许所述服务启动；以及

若所述受限应用程序不处于用户可感状态，则阻止所述服务启动。

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

提供操作界面以供用户确认和/或调整所述受限应用程序。

16.根据权利要求15所述的方法，其特征在于，在所述操作界面上显示应用程序的使用习惯数据。

17.根据权利要求16所述的方法，其特征在于，所述应用程序按照所述使用习惯数据中的一项或多项特征值而排序。

18.一种管理内存的装置，其特征在于，所述装置包括：

获取单元，用于获取用户对应用程序的使用习惯数据；

确定单元，用于基于所述使用习惯数据确定受限应用程序；以及

管理单元，用于根据所述受限应用程序管理内存。

19.根据权利要求18所述的装置，其特征在于，所述管理单元包括以下至少一个子单元：

清理子单元，用于响应于满足清理内存的触发条件，根据所述受限应用程序清理内存；以及

限制子单元，用于根据所述受限应用程序限制所述受限应用程序对应服务的自启动。

20.一种终端，其特征在于，包括根据权利要求18-19任一所述的装置。