WO2017167120A1

WO2017167120A1 - 一种管理应用程序的方法及装置

Info

Publication number: WO2017167120A1
Application number: PCT/CN2017/077914
Authority: WO
Inventors: 强波
Original assignee: 阿里巴巴集团控股有限公司; 强波
Priority date: 2016-03-31
Filing date: 2017-03-23
Publication date: 2017-10-05
Also published as: US20190095250A1; US11182213B2; CN107291549A; CN107291549B

Abstract

一种管理应用程序的方法及装置，用以结合用户使用习惯对应用程序实现合理化管理。该方法为：智能设备监控到应用程序被切换到后台（100），会根据记录的所述应用程序的历史使用过程信息，判断所述应用程序是否会被继续使用（110）；若确定所述应用程序不会被继续使用，回收所述应用程序占用的资源（120）。这样，可以结合用户使用习惯对应用程序实现合理化管理，不但提高了用户操作效率，提升了用户体验，同时能达到节省电能，延迟电池使用寿命的效果。

Description

一种管理应用程序的方法及装置

技术领域

本申请涉及通信领域，特别涉及一种管理应用程序的方法及装置。

背景技术

目前，在主流的智能操作系统中，均设置了能够自动回收运行中的应用程序功能。即：在系统资源不足的情况下，自动回收运行中的应用程序。而现有的智能操作系统在判断是否需要对应用程序进行的资源回收时，主要依赖如下一些因素：应用程序是否处于前台，应用程序的启动时长，应用程序占用内存资源的大小等等。并且，应用程序的资源回收需要一些事件的触发，例如：用户主动请求，或者，系统资源紧张。

然而，若智能操作系统长时间处于锁屏状态(例如，用户在睡觉时)，最近打开的一些应用程序即便长时间都不会被使用，但仍然不会被回收。并且可能存在有些应用程序刚刚在被回收之后，立刻又被用户打开，从而造成了系统资源浪费。

发明内容

本申请实施例提供一种管理应用程序的方法及装置，用以结合用户使用习惯对应用程序实现合理化管理。

本申请实施例提供的具体技术方案如下：

一种管理应用程序的方法，包括：

监控到应用程序被切换到后台；

根据记录的所述应用程序的历史使用过程信息，判断所述应用程序是否会被继续使用；

若确定所述应用程序不会被继续使用，回收所述应用程序占用的资源。

一种管理应用程序的装置，包括：

监控单元，用于监控到应用程序被切换到后台；

判断单元，用于根据记录的所述应用程序的历史使用过程信息，判断所述应用程序是否会被继续使用；

处理单元，用于确定所述应用程序不会被继续使用时，回收所述应用程序占用的资源。

本申请有益效果如下：

本申请实施例中，智能设备监控到应用程序被切换到后台，会根据记录的所述应用程序的历史使用过程信息，判断所述应用程序是否会被继续使用；若确定所述应用程序不会被继续使用，回收所述应用程序占用的资源。这样，可以结合用户使用习惯对应用程序实现合理化管理，不但提高了用户操作效率，提升了用户体验，同时能达到节省电能，延迟电池使用寿命的效果。

附图说明

图1本申请实施例中智能设备管理应用程序概述流程图；

图2为本申请实施例中智能设备管理应用程序示例流程图；

图3为本申请实施例中智能设备计算应用程序的综合状态值流程图；

图4为本申请实施例中基于内存空闲率管理应用程序流程图；

图5为本申请实施例中智能设备第一功能结构示意图；

图6为本申请实施例中智能设备第二功能结构示意图。

具体实施方式

为了能够结合用户使用习惯对智能设备上运行的应用程序实现合理化管理，本申请实施例中，结合用户所处的当前场景和用户的历史习惯，来改善系统中运行状态的应用程序的管理方式，以提升用户体验，同时能达到节省电能，延迟电池使用寿命的效果。

下面结合附图对本申请优选的实施方式进行详细说明。

本申请实施例中，智能设备上的应用程序在启动(例如，每一次启动)时，智能设备会记录，应用程序启动时智能设备的位置信息或时间信息，作为前台状态信息，经过一定时间的累积，可以获得前台状态信息集合。

通常情况下，应用程序启动时一般位于前台，而一般一次只能有一个应用程序位于前台，其余应用程序可能需要被切换至后台。

相应的，智能设备上的应用程序在被切换至后台后(例如，每一次切换)，智能设备会记录，应用程序切换至后台时智能设备的位置信息或时间信息，作为后台状态信息，经过一定时间的累积，可以获得后台状态集合。

上述前台状态信息集合和后台状态信息集合可以记录在同一列表中。

可选的，根据当前时间的不同，可以选择将前台状态信息集合和后台状态信息集合记录在不同的列表中，因为不同时间段，用户的使用习惯不一致。

例如，在工作日时，将前台状态信息集合和后台状态信息集合记录在工作日列表中，而在休息日，则将前台状态信息集合和后台状态信息集合记录在休息日列表中。

又例如，在第一季度，将前台状态信息集合和后台状态信息集合记录在第一季度列表中，第二季度时，将前台状态信息集合和后台状态信息集合记录在第二季度列表中……

显然，通过上述方式，可以分类记录应用程序在历史使用过程中产生的前台状态信息和后台状态信息，即用户在不同时间段启动应用程序及将应用程序切换至后台时，智能设备分别处于何种位置或处于何种时间，这样，可以分类地收集用户的历史数据，从而掌握用户的使用习惯。

进一步地，除了对应应用程序记录前台状态信息集合和后台状态信息集合之外，可选的，还可以记录以下内容：应用程序每一次的启动时间、以结合用户使用习惯对应用程序实现合理化管理。

可选的，还可以记录以下内容：每一次处于前台的时间范围(起始时间和结束时间)、应用程序每一次切换至后台的时间，应用程序每一次处于后台的时间范围(起始时间和结束时间)，应用程序每一次退出的时间(即应用程序被资源回收的时间)。

实际应用中，智能设备上通常存在多个应用程序，智能设备需要对应每一个应用程序分别记录相应的前台状态信息集合和后台状态信息集合，一个应用程序的前台状态信息集合和后台状态信息集合，也称为这个应用程序的历史使用过程信息。为了便于描述，后续实施例中，以智能设备针对一个应用程序进行管理为例进行说明，但应当能够合理推断出，智能设备针对每一个应用程序均采用的是相同或类似的管理方式，针对不同应用程序的管理可以并行，在此不再赘述。

基于上述应用场景，参阅图1所示，本申请实施例中，智能设备管理应用程序的概述流程如下：

步骤100：智能设备监控到应用程序被切换到后台。

具体的，智能设备会随时监控应用程序的使用状态，监控到应用程序启动时，以及监控到应用程序切换至后台时，均需要进行记录。

步骤110：智能设备根据记录的上述应用程序的历史使用过程信息，判断应用程序是否会被继续使用。

可选的，在执行步骤110时，可以采用但不限于以下两种方式：

第一种方式：

首先，应用程序的历史使用过程信息中选取前台状态信息集合；

其次，确定上述应用程序的当前状态信息。

应用程序的当前状态信息可以是承载应用程序的智能设备当前的位置信息，也可以是当前时间，具体视前台状态信息集合是按哪一种方式记录的。

再次，计算与应用程序的当前状态信息匹配的信息，在该应用程序的前台状态信息中占用的第一比例。

例如，假设应用程序的当前状态信息为位置1，则计算在应用程序的前台状态信息中，与位置1近似的所有位置信息占用的第一比例。

这样，智能设备可以很容易判断出，用户是否在一个经常使用上述应用程序的地点，将该应用程序放置在前台使用。

最后，智能设备判定第一比例是否达到第一设定门限，若是，则确定上述应用程序会被继续使用，否则，确定上述应用程序不会被继续使用。

例如，假设应用程序的当前状态信息为位置1，在应用程序的前台状态信息中，与位置1相似的所有位置信息占用的比例为80％，超过了第一设定门限40％，则说明智能设备当前所处的位置，是用户经常使用应用程序的位置范围，因此，不能回收应用程序占用的资源。

第二种方式：

首先，应用程序的历史使用过程信息中选取前台状态信息集合和后台状态信息集合。

其次，确定上述应用程序的当前状态信息。

再次，计算与上述应用程序的当前状态信息匹配的信息，在该应用程序的前台状态信息中占用的第二比例，以及计算与上述应用程序的当前状态信息匹配的信息，在该应用程序的后台状态信息中占用的第三比例。

例如，假设应用程序的当前状态信息为时间1，则计算在上述应用程序的前台状态信息中，与时间1近似的所有时间信息占用的第二比例，以及计算在上述应用程序的后台状态信息中，与时间1近似的所有时间信息占用的第三比例。

这样，智能设备可以很容易判断出，用户在当前时间下，是会经常在前台使用上述应用程序，还是会经常将上述应用程序切换至后台。

最后，基于第二比例和第三比例，计算所述应用程序的综合状态值，判定所述综合状态值是否达到第二设定门限，若是，则确定上述应用程序会被继续使用，否则，确定上述应用程序不会被继续使用。

例如，假设应用程序的当前信息为时间1，在应用程序的前台状态信息中，与时间1相似的所有时间信息占用的比例为60％，在应用程序的后台状态信息中，与时间1相似的所有时间信息占用的比例为40％，则假设综合状态值＝60％a+40％b＝50％，其中，a、b为预设权值，那么，综合状态值达到了第二设定门限50％，则说明在当前时间下，用户会更多地在前台使用上述应用程序，因此，不能回收应用程序占用的资源。

当然，在上述第一种方式下，智能设备所计算的第一比例也可以视为一种特殊情况下的综合状态值，即仅参考前台状态信息集合所计算出的综合状态值，在此不再赘述。

步骤120：智能设备确定上述应用程序不会被继续使用时，回收应用程序占用的资源。

具体的，智能设备确定上述应用程序不会被继续使用时，才会回收应用程序占用资源。相应的，如果智能设备确定上述应用程序会被继续使用，则即使智能设备确定上述应用程序满足回收资源的条件、也不回收应用程序占用的资源。

具体的，所谓确定应用程序满足回收资源的条件，即是指确定应用程序的运行状态和/或系统状态满足设定条件，具体的，可以包含但不限于以下任意一种情况：

情况1：智能设备对应用程序被切换到后台的时间进行计时，并且确定计时达到第一设定阈值。

具体而言，即使应用程序被切换至后台很长时间了，智能设备一旦判定用户有可能继续使用该应用程序，也不会回收应用程序占用的资源。

情况2：智能设备确定应用程序的资源占用时长达到第二设定阈值。

具体而言，即使应用程序占用资源的时间过长，智能设备一旦判定用户有可能继续使用该应用程序，也不会回收应用程序占用的资源。

情况3：智能设备确定系统的内存空闲率低于第三设定阈值。

具体而言，即使系统的内存空闲率过低，智能设备一旦判定用户有可能继续使用该应用程序，也不会回收应用程序占用的资源。

基于上述实施例，实际应用中，为了保证智能设备的性能，智能设备在确定系统当前的内存空闲率小于第三设定门限时，会按照步骤110中介绍的第二种方式，分别计算本地位于后台的每一个应用程序的综合状态值，并按照综合状态值依次对相应的应用程序进行资源回收，直到系统当前的内存空闲率不小于所述第三设定门限为止。当然，回收的顺序，可以是按照综合状态值从大到小的顺序回收，也可以按照综合状态值从小到大的顺序回收，具体操作视运用环境而定在，在此不再赘述。

下面以一个具体的应用场景对上述实施例作出进一步详细说明。

仍以一个应用程序为例，且假设应用程序的前台状态信息和后台状态信息中均记录的是智能设备在相应状态下的位置信息，那么，参阅图2所示，本申请实施例中，智能设备管理应用程序的具体流程如下：

步骤200：在应用程序启动后，智能设备对应该应用程序记录该应用程序启动时智能设备的第一位置信息，并将第一位置信息作为应用程序的前台状态信息保存至前台状态信息集合。

本申请实施例中，可选的，为了节省智能设备的资源，在获得第一位置信息时，智能设备无需进行精确定位，如，可以将第一位置信息精确到智能设备周围100米(仅为举例)范围即可。

例如，用户在家开启“视频播放”这一应用程序后，智能设备对应“视频播放”记录其位置信息，可以是物理位置信息(如，具体物理坐标)，也可以是虚拟位置信息(如，家)。

步骤210：在上述应用程序被切换至后台后，智能设备对应该应用程序记录该应用程序切换时智能设备的第二位置信息，并将第二位置信息作为应用程序的后台状态信息保存至后台状态信息集合。

本申请实施例中，可选的，为了节省智能设备的资源，在获得第二位置信息时，智能设备亦无需进行精确定位，如，可以将第二位置信息精确到智能设备周围100米(仅为举例)范围即可。

又例如，用户由家外出至公园后，关闭“视频播放”这一应用程序后，智能设备对应“视频播放”记录其位置信息，可以是物理位置信息(如，具体物理坐标)，也可以是虚拟位置信息(如，公园)。

步骤220：智能设备确定上述应用程序被切换至后台，且确定到达监控时间点时，获取当前位置信息。

可选的，每当应用程序被切换到后台之后，智能设备为该应用程序启动一个循环定时器，如，定时器的超时间是5分钟。当应用程序切换回前台后，定时器会被关闭。因此，当一个应用程序长时间处于后台，只要该应用程序没有退出，定时器每隔设定的时长(如，5分钟)便会触发一次，而定时器每触发一次，便是到达了监控时间点。

而每一次到达监控时间点时，智能设备均获取当前的位置信息，本实施例中，仅以其中的一次为例进行介绍。

步骤230：智能设备计算与上述应用程序的当前位置信息匹配的信息，在该应用程序的前台状态信息中占用的比例A，以及计算与上述应用程序的当前位置信息匹配的信息，在该应用程序的后台状态信息中占用的比例B。

例如，可以采用以下公式计算：

R＝A x a+B x b+C x c+D x d

公式一

A为与上述应用程序的当前位置信息匹配的信息，在该应用程序的前台状态信息中占用的比例；

B为与上述应用程序的当前位置信息匹配的信息，在该应用程序的后台状态信息中占用的比例；

C为与上述应用程序的当前位置信息不匹配的信息，在该应用程序的前台状态信息中占用的比例；

D为与上述应用程序的当前位置信息不匹配的信息，在该应用程序的后台状态信息中占用的比例；

a为预设的第一权值，b为预设的第二权值，c为预设的第三权值，d为预设的第四权值。

R为最终的综合状态值。

当然，如果只利用步骤110中介绍的第一种方式计算综合状态值，则也可以将上述公式转换为：

R＝A x a+C x c

公式二

本实施例中，仅以公式一为例进行介绍，在此不再赘述。

步骤240：智能设备判断基于比例A和比例B计算综合状态值，并判断综合状态值是否达到门限M，若是，则执行步骤250；否则，执行步骤 260。

步骤250：确定上述应用程序会被继续使用，不回收该应用程序占用的资源。

步骤260：确定上述应用程序不会被继续使用，回收该应用程序占用的资源。

采用公式一对应用程序进行评估，可以结合用户使用习惯获得应用程序的综合状态值，即用户如果在某一场景(以下称场景A)下经常使用某一应用程序(以下称应用程序X)，并且在另一场景(以下称场景B)下经常将应用程序X切换至后台。

那么，每次用户在场景A附近时(即当前位置信息为场景A)，智能设备检测到的与场景A相匹配的信息，在应用程序X的前台状态信息中出现的比例很高，在应用程序X的后台状态信息中出现的比例很低，则采用公式一计算的综合状态值R的取值便会很高，很容易达到门限M；因此，在场景A附近时，智能设备通常不会回收应用程序X占用的资源。

相应的，每次用户在场景B附近时(即当前位置信息为场景B)，智能设备检测到的与场景B相匹配的信息，在应用程序X的前台状态信息中出现的比例很低，在应用程序X的后台状态信息中出现的比例很高，则采用公式一计算的综合状态值R的取值便会很低，很容易低于门限M；因此，在场景B附近时，智能设备通常会很快回收应用程序X占用的资源。

当然，在上述过程中，智能设备在选定包含有应用程序X的前台状态信息和后台状态信息的历史使用过程信息时，可选的，需要根据当前时间所归属的时间范围，获取对应该时间范围预设的历史数据。如，若当前时间为休息日，则选定对应休息日记录的历史使用过程信息，若当前时间为工作日，则选定对应工作日记录的历史使用过程信息。

进一步在，智能设备在判断是否回收应用程序X时，还可以进一步加入其他元素，如，进一步参考定时器的触发次数，也可以理解为参考应用程序X切换至后台的时长，又如，进一步参考应用程序X占用资源的时长，又如，进一步参考系统的内存空闲率等等。

仍以上述应用程序X为例，假设采用公式一，智能设备计算得到应用程序X对应的R的取值达到门限M，这说明应用程序X此时很有可能被用户再次使用，那么，即使满足以下情况中的任意一种或任意组合，智能设备也不会回收应用程序X占用的资源：

情况1，应用程序切换至后台的时长达到阈值1，换言之，定时器的触发次数达到阈值1’；

情况2、应用程序的资源占用时长达到阈值2；

情况3、系统的内存空闲率低于阈值3。

参阅图3所示，仍以应用程序X为例，本申请实施例中，智能设备计算应用程序X的综合状态值的流程如下：

步骤300：智能设备根据应用程序X的状态变化，判断应用程序X当前位于前台还是后台，若位于前台，则执行步骤310；若位于后台，则执行步骤320。

步骤310：智能设备对应应用程序X移除定时器。

步骤320：智能设备对应应用程序X设置定时器。

步骤330：智能设备维护定时器，并在确定定时器超时，重新启动定时器，以及执行步骤340。

步骤340：智能设备计算应用程序X的综合状态值，并判断综合状态值是否大于预设的门限值(如，0.5)，若是，则返回步骤330，等待定时器下一次超时；否则，执行步骤350。

步骤350：智能设备将应用程序X退出，进行资源回收。

基于上述实施例，另一方面，系统在内存空闲率小于等于第三设定门限(如，20％)的时候，即使没有应用程序的综合状态值低于上述第二设定门限，也会强行进行资源回收，以保证系统性能，具体的，智能设备手机此时会遍历所有处于后台的应用程序，按照其综合状态值从低到高或从高到低的顺序依次进行退出，直到系统的内存空闲率超过第三设定门限(如，20％)为止，具体过程如图4所示：

步骤400：智能设备确定内存状态的变化，判定当前的内容空闲率是否小于等于20％，若是，则执行步骤410，否则，当前不执行操作，等待下一次判定。

步骤410：智能设备为各个应用程序计算综合状态值。

步骤420：智能设备按照综合状态值从小到大的将各个应用程序依次排序。

步骤430：智能设备从综合状态值最小的应用程序开始，依次退出应用程序，直到内存空闲率大于20％，返回步骤400。

下面通过具体的应用场景对上述实施例作出坦步详细说明。

第一场景：

用户经常在家中在手机上使用应用程序“网游”，同时，在离开家时，将“网游”切换至后台，那么，每次用户在家打开“网游”时，手机记录“网游”的前台状态信息为“家”，而用户外出后，将“网游”切换至后台，用户记录“网游”的后台状态信息为“离家”。

那么，假设用户的历史使用过程信息中，用户曾经9次在家时打开“网游”，并且离家时将“网游”切换至后台，以及用户曾经1次离家时打开“网游”，并且在家时将“网游”切换至后台；假设手机检测到用户当前将“网游”切换至后台，且当前的位置信息为“在家”，那么，手机计算与“在家”相匹配的信息在用户的前台状态信息集合中出现的比例A为90％，与“在家”相匹配的信息在用户的后台状态信息集合中出现的比例 B为10％，手机采用公式一“R＝A x 2+B x 1.8+C x 1.6+D x 1.5”计算后，假设获得的综合状态值R＝5，远远高于门限M＝2，则手机判定无需回收“网游”占用的资源。

显然，在第一场景中，“网游”非常符合用户的使用习惯，因此，在“网游”切换至后台之后，智能设备会保留分配给“网游”的资源，以便用户随时再次调用“网游”，从而保证了用户体验。

进一步地，经过一两个小时后，用户仍没有在手机上关闭“网游”，而定时器已多次超时，手机也多次计算“网游”的综合状态值，该综合状态值将随着时间的推移越来越低，在低于0.5后，手机关闭应用程序“网游”。

显然，在第一场景中，用户长时间不使用“网游”，智能设备也会回收“网游”所占用的资源，以保证系统的系统可用率。

第二场景：

用户经常在12:00至13:30在手机上使用应用程序“订餐”，而在其他时间段将“订餐”切换至后台，那么，每次用户在12:00至13:30之间打开“订餐”时，手机记录“订餐”的前台状态信息为“12:00至13:30”，而用户将“订餐”切换至后台时，用户记录“订餐”的后台状态信息为“其余时间”。

那么，假设用户的历史使用过程信息中，用户曾经8次在12:00至13:30打开“订餐”，以及在“其余时间”将“订餐”切换至后台，2次在“其余时间”打开“订餐”，以及在“其余时间”将“订餐”切换至后台；

假设手机检测到用户当前将“订餐”切换至后台，且当前的时间信息为“16：00”，属于“其余时间”，那么，手机计算与“16：00”相匹配的信息在用户的前台状态信息集合中出现的比例A为20％，与“16：00”相匹配的信息在用户的后台状态信息集合中出现的比例B为80％，手机采用公式一“R＝A x 2+B x 1.8+C x 1.6+D x 1.5”计算后，假设获得的综合状态值R＝1.5，低于门限M＝2，则手机判定立即回收“订餐”占用的资源。

基于上述实施例，参阅图5所示，本申请实施例中，智能设备至少包括监控单元50、判断单元51和处理单52，其中，

监控单元50，用于监控到应用程序被切换到后台；

判断单元51，用于根据记录的所述应用程序的历史使用过程信息，判断所述应用程序是否会被继续使用；

处理单元52，用于确定所述应用程序不会被继续使用时，回收所述应用程序占用的资源。

可选的，回收所述应用程序占用的资源之前，处理单元52还用于：

确定所述应用程序满足回收资源的条件。

可选的，确定所述应用程序满足回收资源的条件时，处理单元52用于：

当确定所述应用程序的运行状态和/或系统状态满足设定条件时，确定所述应用程序满足回收资源的条件。

可选的，确定所述应用程序的运行状态和/或系统状态满足设定条件时，处理单元52用于：

对所述应用程序被切换到后台的时间进行计时，并且确定所述计时达到第一设定阈值；或者，

确定所述应用程序的资源占用时长达到第二设定阈值；或者，

确定系统的内存空闲率低于第三设定阈值。

可选的，处理单元52进一步用于：

在确定所述应用程序满足回收资源的条件、且确定所述应用程序会被继续使用时，不回收所述应用程序占用的资源。

可选的，所述历史使用过程信息，包括：

所述应用程序的前台状态信息集合；

根据所述历史使用过程信息，判断所述应用程序是否会被继续使用时，判断单元51用于：

确定所述应用程序的当前状态信息；

计算与所述应用程序的当前状态信息匹配的信息，在所述应用程序的前台状态信息中占用的第一比例；

判定所述第一比例是否达到第一设定门限，若是，则确定所述应用程序会被继续使用，否则，确定所述应用程序不会被继续使用。

可选的，所述历史使用过程信息，还包括：

所述应用程序的后台状态信息集合；

确定所述应用程序的当前状态信息；

计算与所述应用程序的当前状态信息匹配的信息，在所述应用程序的前台状态信息中占用的第二比例；

计算与所述应用程序的当前状态信息匹配的信息，在所述应用程序的后台状态信息中占用的第三比例；

基于所述第二比例和第三比例，计算所述应用程序的综合状态值；

判定所述综合状态值是否达到第二设定门限，若是，则确定所述应用程序会被继续使用，否则，确定所述应用程序不会被继续使用。

可选的，所述应用程序的当前状态信息包括：

承载所述应用程序的智能设备的当前位置信息；或者，

当前的时间信息。

可选的，处理单元52进一步用于：

确定系统当前的内存空闲率小于第三设定门限时，分别计算本地位于后台的每一个应用程序的综合状态值，并按照综合状态值依次对相应的应用程序进行资源回收，直到系统当前的内存空闲率不小于所述第三设定门限为止。

基于上述实施例，参阅图6所示，本申请实施例中，智能设备至少包括处理器60和收发机61，其中，

处理器60，用于读取存储器中的程序，通过执行下列过程：

监控到应用程序被切换到后台；

确定所述应用程序不会被继续使用时，回收所述应用程序占用的资源；

收发机61，用于在处理器60的控制下接收和发送数据。

可选的，回收所述应用程序占用的资源之前，处理器60还用于：

确定所述应用程序满足回收资源的条件。

可选的，确定所述应用程序满足回收资源的条件时，处理器60用于：

可选的，确定所述应用程序的运行状态和/或系统状态满足设定条件时，处理器60用于：

确定系统的内存空闲率低于第三设定阈值。

可选的，处理器60进一步用于：

可选的，所述历史使用过程信息，包括：

所述应用程序的前台状态信息集合；

根据所述历史使用过程信息，判断所述应用程序是否会被继续使用时，处理器60用于：

确定所述应用程序的当前状态信息；

可选的，所述历史使用过程信息，还包括：

所述应用程序的后台状态信息集合；

确定所述应用程序的当前状态信息；

可选的，所述应用程序的当前状态信息包括：

承载所述应用程序的智能设备的当前位置信息；或者，

当前的时间信息。

可选的，处理器60进一步用于：

在图6中，总线架构中，总线可以包括任意数量的互联的总线和桥，总线将包括由通用处理器60代表的一个或多个处理器和存储器代表的存储器的各种电路链接在一起。总线还可以将诸如外围设备、稳压器和功率管理电路等之类的各种其他电路链接在一起，这些都是本领域所公知的，因此，本文不再对其进行进一步描述。收发机61可以是一个元件，也可以是多个元件，比如多个接收器和发送器，提供用于在传输介质上与各种其他装置通信的单元。例如：收发机61从其他设备接收外部数据。收发机61用于将处理器60处理后的数据发送给其他设备。取决于计算系统的性质，还可以提供用户接口，例如小键盘、显示器、扬声器、麦克风、操纵杆。

处理器60负责管理总线和通常的处理，如前述所述运行通用操作系统。而存储器可以被用于存储处理器60在执行操作时所使用的数据。

可选的，处理器60可以是CPU、ASIC、FPGA或CPLD。

综上所述，本申请实施例中，智能设备监控到应用程序被切换到后台，会根据记录的所述应用程序的历史使用过程信息，判断所述应用程序是否会被继续使用；若确定所述应用程序不会被继续使用，回收所述应用程序占用的资源。这样，可以结合用户使用习惯对应用程序实现合理化管理，不但提高了用户操作效率，提升了用户体验，同时能达到节省电能，延迟电池使用寿命的效果。

进一步地，智能设备在对应用程序进行评估时，还会参考当前的内存空闲率，在内存空闲率不高时，各个应用程序会按照综合状态值依次进行资源回收，从而有效保证了系统的内存空闲率，维持了系统的稳定性和系统性能。

显然，使用本申请实施例提供的技术方案，智能设备对于应用程序的资源回收更加智能，被退出的应用程序几乎是一段时间内用户不会在使用的，并且智能设备总是能够在合适的时候将应用程序退出以回收资源，尤其是在用户长时间使用之后，整个系统会越来越流畅，退出应用程序的方式会越来越符合用户的使用习惯，而电池寿命得到一定延长。

本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

尽管已描述了本申请的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例作出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本申请范围的所有变更和修改。

显然，本领域的技术人员可以对本申请实施例进行各种改动和变型而不脱离本申请实施例的精神和范围。这样，倘若本申请实施例的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。

Claims

一种管理应用程序的方法，其特征在于，包括：

监控到应用程序被切换到后台；

根据记录的所述应用程序的历史使用过程信息，判断所述应用程序是否会被继续使用；

若确定所述应用程序不会被继续使用，回收所述应用程序占用的资源。
如权利要求1所述的方法，其特征在于，回收所述应用程序占用的资源之前，还包括：

确定所述应用程序满足回收资源的条件。
如权利要求2所述的方法，其特征在于，确定所述应用程序满足回收资源的条件，包括：

当确定所述应用程序的运行状态和/或系统状态满足设定条件时，确定所述应用程序满足回收资源的条件。
如权利要求3所述的方法，其特征在于，确定所述应用程序的运行状态和/或系统状态满足设定条件，包括：

对所述应用程序被切换到后台的时间进行计时，并且确定所述计时达到第一设定阈值；或者，

确定所述应用程序的资源占用时长达到第二设定阈值；或者，

确定系统的内存空闲率低于第三设定阈值。
如权利要求2所述的方法，其特征在于，在确定所述应用程序满足回收资源的条件、且确定所述应用程序会被继续使用时，不回收所述应用程序占用的资源。
如权利要求1至5任一项所述的方法，其特征在于，所述历史使用过程信息，包括：

所述应用程序的前台状态信息集合；

根据所述历史使用过程信息，判断所述应用程序是否会被继续使用，包括：

确定所述应用程序的当前状态信息；

计算与所述应用程序的当前状态信息匹配的信息，在所述应用程序的前台状态信息中占用的第一比例；

判定所述第一比例是否达到第一设定门限，若是，则确定所述应用程序会被继续使用，否则，确定所述应用程序不会被继续使用。
如权利要求6所述的方法，其特征在于，所述历史使用过程信息，还包括：

所述应用程序的后台状态信息集合；

根据所述历史使用过程信息，判断所述应用程序是否会被继续使用，包括：

确定所述应用程序的当前状态信息；

计算与所述应用程序的当前状态信息匹配的信息，在所述应用程序的前台状态信息中占用的第二比例；

计算与所述应用程序的当前状态信息匹配的信息，在所述应用程序的后台状态信息中占用的第三比例；

基于所述第二比例和第三比例，计算所述应用程序的综合状态值；

判定所述综合状态值是否达到第二设定门限，若是，则确定所述应用程序会被继续使用，否则，确定所述应用程序不会被继续使用。
如权利要求6或7所述的方法，其特征在于，所述应用程序的当前状态信息包括：

承载所述应用程序的智能设备的当前位置信息；或者，

当前的时间信息。
如权利要求7所述的方法，其特征在于，进一步包括：

确定系统当前的内存空闲率小于第三设定门限时，分别计算本地位于后台的每一个应用程序的综合状态值，并按照综合状态值依次对相应的应用程序进行资源回收，直到系统当前的内存空闲率不小于所述第三设定门限为止。
一种管理应用程序的装置，其特征在于，包括：

监控单元，用于监控到应用程序被切换到后台；

判断单元，用于根据记录的所述应用程序的历史使用过程信息，判断所述应用程序是否会被继续使用；

处理单元，用于确定所述应用程序不会被继续使用时，回收所述应用程序占用的资源。
如权利要求10所述的装置，其特征在于，回收所述应用程序占用的资源之前，所述处理单元还用于：

确定所述应用程序满足回收资源的条件。
如权利要求11所述的装置，其特征在于，确定所述应用程序满足回收资源的条件时，所述处理单元用于：

当确定所述应用程序的运行状态和/或系统状态满足设定条件时，确定所述应用程序满足回收资源的条件。
如权利要求12所述的装置，其特征在于，确定所述应用程序的运行状态和/或系统状态满足设定条件时，所述处理单元用于：

对所述应用程序被切换到后台的时间进行计时，并且确定所述计时达到第一设定阈值；或者，

确定所述应用程序的资源占用时长达到第二设定阈值；或者，

确定系统的内存空闲率低于第三设定阈值。
如权利要求11所述的装置，其特征在于，所述处理单元进一步用于：

在确定所述应用程序满足回收资源的条件、且确定所述应用程序会被继续使用时，不回收所述应用程序占用的资源。
如权利要求10至14任一项所述的装置，其特征在于，所述历史使用过程信息，包括：

所述应用程序的前台状态信息集合；

根据所述历史使用过程信息，判断所述应用程序是否会被继续使用时，所述判断单元用于：

确定所述应用程序的当前状态信息；

计算与所述应用程序的当前状态信息匹配的信息，在所述应用程序的前台状态信息中占用的第一比例；

判定所述第一比例是否达到第一设定门限，若是，则确定所述应用程序会被继续使用，否则，确定所述应用程序不会被继续使用。
如权利要求15所述的装置，其特征在于，所述历史使用过程信息，还包括：

所述应用程序的后台状态信息集合；

根据所述历史使用过程信息，判断所述应用程序是否会被继续使用时，所述判断单元用于：

确定所述应用程序的当前状态信息；

计算与所述应用程序的当前状态信息匹配的信息，在所述应用程序的前台状态信息中占用的第二比例；

计算与所述应用程序的当前状态信息匹配的信息，在所述应用程序的后台状态信息中占用的第三比例；

基于所述第二比例和第三比例，计算所述应用程序的综合状态值；

判定所述综合状态值是否达到第二设定门限，若是，则确定所述应用程序会被继续使用，否则，确定所述应用程序不会被继续使用。
如权利要求15或16所述的装置，其特征在于，所述应用程序的当前状态信息包括：

承载所述应用程序的智能设备的当前位置信息；或者，

当前的时间信息。
如权利要求16所述的装置，其特征在于，所述处理单元进一步用于：

确定系统当前的内存空闲率小于第三设定门限时，分别计算本地位于后台的每一个应用程序的综合状态值，并按照综合状态值依次对相应的应用程序进行资源回收，直到系统当前的内存空闲率不小于所述第三设定门限为止。