CN106547615A - 一种后台应用的管理方法及管理模块 - Google Patents

Abstract

本发明实施例公开了一种后台应用的管理方法及管理模块，涉及终端控制领域，用于减少利用率低的后台应用对系统资源的浪费，和现有技术相比，减少了后台应用的数目，延长待机时长，减缓甚至避免出现系统卡顿。本发明方法包括：检测第一应用转入后台运行；记录第一应用在后台运行的后台持续时长；判断后台持续时长是否超过预设时长；若是，则关闭第一应用。

Description

一种后台应用的管理方法及管理模块

技术领域

本发明涉及终端控制领域，具体涉及一种后台应用的管理方法及管理模块。

背景技术

随着电子技术的发展，智能终端，比如智能手机，安装的应用越来越多，应用的类别也不断增多，逐渐覆盖用户生活的方方面面。经常会出现这样一种情况，用户在较短的时长内，会交替使用多个应用，比如，用户在使用A应用的过程中，会临时打开B应用，短暂的使用B应用后，会希望继续A应用的进程。为了在用户再次打开A应用时，能够接续之前的界面，减少应用的打开时长，多任务处理技术帮助终端满足了用户的需求。

但是多任务处理技术有一个弊端，也就是在后台运行的应用仍然占用着大量的系统资源，比如耗费电能、占用内存、占用CPU等。用户在临时使用B应用之后，很可能在短期内不会再使用B应用，B应用长期驻留在后台，会浪费系统资源。随着终端上安装的应用增多，在终端后台同时运行的应用也逐渐增多，但是系统资源是有限的，过多的后台应用会影响终端的正常运行。

为了解决终端后台应用过多对终端正常运行的影响，现有技术在检测到终端的系统资源不足时，比如检测到电量过低，或可用内存过低，或CPU利用率过高等情况时，会关闭部分后台应用，以释放其占用的系统资源。

但是，现有技术只有在检测到系统资源不足时，才会对后台应用进行管理，关闭部分后台应用，此时系统资源不足已导致终端的待机时长过短，或者出现系统卡顿等情况，降低用户体验。

发明内容

本发明实施例提供了一种后台应用的管理方法及管理装置，用于延长待机时间。

为达到上述目的，本发明实施例的一方面提供了一种后台应用的管理方法，所述方法包括：

检测第一应用转入后台运行；

记录所述第一应用在后台运行的后台持续时长；

判断所述后台持续时长是否超过预设时长；

若是，则关闭所述第一应用。

结合第一方面，在第一方面的第一种可能的实现方式中，在所述检测第一应用转入后台运行之后，在判断所述后台持续时长是否超过预设时长之前，所述方法还包括：

获取所述第一应用的属性信息；

判断所述第一应用的属性信息是否为第一属性信息；

若是，则从预存的属性信息与所述预设时长的取值的第一对应关系集合中，确定所述第一属性信息对应的所述预设时长的取值为第一时长，并将所述预设时长的取值设置为所述第一时长。

结合第一方面的第一种可能的实现方式，在第一方面的第二种可能的实现方式中，在所述检测第一应用转入后台运行之前，所述方法还包括：

在统计时段记录第一集合中的应用在前台运行的第一前台持续时长，所述第一集合为第一属性信息对应的应用组成的集合；

根据所述第一前台持续时长计算所述第一集合对应的第一总时长；

根据所述第一总时长确定所述第一属性信息对应的所述预设时长的取值为所述第一时长，所述第一总持续时长与所述第一时长正相关；

将所述第一属性信息与所述第一时长关联存储于所述第一对应关系集合中。

结合第一方面的第一种可能的实现方式，在第一方面的第三种可能的实现方式中，若判定所述第一应用的属性信息不是第一属性信息，所述方法还包括：

判断所述第一应用的属性信息是否为第二属性信息；

若是，则从所述第一对应关系集合中确定所述第二属性信息对应的所述预设时长的取值为第二时长，并将所述预设时长的取值设置为所述第二时长，所述第二时长与所述第一时长不同。

结合第一方面，在第一方面的第四种可能的实现方式中，在所述检测第一应用转入后台运行之后，在判断所述后台持续时长是否超过预设时长之前，所述方法还包括：

获取前台运行的第三应用的第三属性信息；

从预存的属性信息与预设时长的第二对应关系集合中，确定所述第三属性信息对应的所述预设时长的取值为第三时长；

将所述预设时长的取值设置为所述第三时。

结合第一方面的第四种可能的实现方式，在第一方面的第五种可能的实现方式中，在所述检测第一应用转入后台运行之前，所述方法还包括：

在统计时段记录第三集合中的应用在前台运行的第三前台持续时长，所述第三集合为所述第三属性信息对应的应用组成的集合；

根据所述第三前台持续时长计算所述第三集合对应的第三总时长；

根据所述第三总时长确定所述第三属性信息对应的所述预设时长的取值为所述第三时长，所述第三总持续时长与所述第三时长负相关；

将所述第三属性信息与所述第三时长关联存储于所述第二对应关系集合中。

本发明实施例的第二方面提供了一种后台应用的管理模块，所述管理模块包括：

检测单元，用于检测第一应用转入后台运行；

第一记录单元，用于记录所述第一应用在后台运行的后台持续时长；

第一判断单元，用于判断所述后台持续时长是否超过预设时长；

关闭单元，用于当所述判断单元判定所述后台持续时长超过所述预设时长时，关闭所述第一应用。

结合第二方面，在第二方面的第一种可能的实现方式中，所述管理模块还包括：

第一获取单元，用于获取所述第一应用的属性信息；

第二判断单元，用于判断所述第一应用的属性信息是否为第一属性信息；

第一确定单元，用于当所述第二判断单元判定所述第一应用的属性信息为第一属性信息时，从预存的属性信息与所述预设时长的取值的第一对应关系集合中，确定所述第一属性信息对应的所述预设时长的取值为第一时长；

第一设置单元，用于在所述第一确定单元确定所述预设时长的取值为第一时长之后，将所述预设时长的取值设置为所述第一时长。

结合第二方面的第一种可能的实现方式，在第二方面的第二种可能的实现方式中，所述管理模块还包括：

第二记录单元，用于在统计时段记录第一集合中的应用在前台运行的第一前台持续时长，所述第一集合为第一属性信息对应的应用组成的集合；

第一计算单元，用于根据所述第一前台持续时长计算所述第一集合对应的第一总时长；

第二确定单元，用于根据所述第一总时长确定所述第一属性信息对应的所述预设时长的取值为所述第一时长，所述第一总持续时长与所述第一时长正相关；

第一存储单元，用于将所述第一属性信息与所述第一时长关联存储于所述第一对应关系集合中。

结合第二方面的第一种可能的实现方式，在第二方面的第三种可能的实现方式中，所述管理模块还包括：

第三判断单元，用于判断所述第一应用的属性信息是否为第二属性信息；

第三确定单元，用于当所述第三判断单元判定所述第一应用的属性信息为第二属性信息时，从所述第一对应关系集合中确定所述第二属性信息对应的所述预设时长的取值为第二时长；

第二设置单元，用于当所述第三确定单元确定所述预设时长的取值为第二时长时，将所述预设时长的取值设置为所述第二时长，所述第二时长与所述第一时长不同。

结合第二方面，在第二方面的第四种可能的实现方式中，所述管理模块还包括：

第二获取单元，用于获取前台运行的第三应用的第三属性信息；

第四确定单元，用于从预存的属性信息与预设时长的第二对应关系集合中，确定所述第三属性信息对应的所述预设时长的取值为第三时长；

第三设置单元，用于将所述预设时长的取值设置为所述第三时长。

结合第二方面的第四种可能的实现方式，在第二方面的第五种可能的实现方式中，所述管理模块还包括：

第三记录单元，用于在统计时段记录第三集合中的应用在前台运行的第三前台持续时长，所述第三集合为所述第三属性信息对应的应用组成的集合；

第二计算单元，用于根据所述第三前台持续时长计算所述第三集合对应的第三总时长；

第五确定单元，用于根据所述第三总时长确定所述第三属性信息对应的所述预设时长的取值为所述第三时长，所述第三总持续时长与所述第三时长负相关；

第二存储单元，用于将所述第三属性信息与所述第三时长关联存储于所述第二对应关系集合中。

从以上技术方案可以看出，本发明实施例具有以下优点：

由于一般情况下，应用在后台运行的持续时长越长，其利用率越低。本发明记录应用在后台运行的持续时长，当持续时长超过预设时长时，便会关闭该应用，可以减少利用率低的应用对系统资源的浪费，和现有技术相比，减少了后台应用的数目，减少系统资源浪费，延长待机时长，减缓甚至避免出现系统卡顿。

附图说明

图1是本发明后台应用的管理方法一个实施例示意图；

图2是本发明后台应用的管理方法另一个实施例示意图；

图3是本发明建立第一对应关系集合的方法一个实施例示意图；

图4是本发明后台应用的管理方法另一个实施例示意图；

图5是本发明建立第二对应关系集合的方法一个实施例示意图；

图6是本发明后台应用的管理模块一个实施例示意图；

图7是本发明后台应用的管理模块另一个实施例示意图；

图8是本发明后台应用的管理模块另一个实施例示意图。

具体实施方式

本发明实施例提供了本发明实施例提供了一种后台应用的管理方法及管理模块，用于减少系统资源浪费。

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

本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”、“第四”等(如果存在)是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的实施例能够以除了在这里图示或描述的内容以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

随着电子技术的发展，智能终端，比如智能手机，安装的应用越来越多，应用的类别也不断增多，逐渐覆盖用户生活的方方面面。经常会出现这样一种情况，用户在较短的时长内，会交替使用多个应用，比如，用户在使用优酷观看电影的过程中，收到微信的聊天通知，此时用户会临时打开微信，短暂的使用微信进行回复后，会希望快速打开优酷，并继续观影。多任务处理技术帮助终端满足用户快速接续的使用多个应用的需要。但是多任务处理技术有一个弊端，也就是在后台运行的应用仍然占用着大量的系统资源，比如耗费电能、占用内存、占用CPU等。用户在临时使用微信之后，很可能在短期内不会再使用微信，微信长期驻留在后台，会浪费系统资源。随着终端上安装的应用增多，在终端后台同时运行的应用也逐渐增多，但是系统资源是有限的，过多的后台应用会影响终端的正常运行。

为了解决终端后台应用过多对终端正常运行的影响，现有技术在检测到终端的系统资源不足时，比如检测到电量过低，或可用内存过低，或CPU利用率过高等情况时，会关闭部分后台应用，以释放其占用的系统资源。但是，现有技术只有在检测到系统资源不足时，才会对后台应用进行管理，关闭部分后台应用，此时系统资源不足已导致终端的待机时长过短，或者出现系统卡顿等情况，降低用户体验。

为了解决上述问题，本发明提供后台应用的管理方法及管理模块，通过限定应用在后台运行的时长来减少后台运行的应用的数目，和现有技术比，能够减少后台应用对系统资源的浪费，延长待机时长，减缓甚至避免出现系统卡顿。

为了便于本领域技术人员的理解，本发明通过以下实施例对本发明提供的技术方案的具体实现过程进行说明。

为便于理解，下面对本发明方法实施例中的具体流程进行描述，请参阅图1，本发明后台应用的管理方法一个实施例包括：

101、检测第一应用转入后台运行；

终端可以检测应用的运行情况，比如当前台运行的第一应用转入后台运行时，终端可以检测到第一应用转入后台。

102、记录第一应用在后台运行的后台持续时长；

在检测到第一应用转入后台运行之后，终端可以开启计时器，记录第一应用在后台运行的后台持续时长。

103、判断后台持续时长是否超过预设时长，若是，则执行步骤104，若否，则执行步骤105；

终端在记录第一应用在后台运行的后台持续时长的过程中，可以将记录的后台持续时长与预设时长进行比较，判断后台持续时长是否超过预设时长，若是，则执行步骤104，若否，则执行步骤105。

104、关闭第一应用；

若判定后台持续时长超过预设时长，则关闭第一应用，释放第一应用在运行过程中所占用的系统资源。

105、执行其他操作。

若判定后台持续时长未超过预设时长，则可以执行其他操作。

通过本发明实施例提供的方法，终端可以根据应用在后台运行的后台持续时长来关闭第一应用，和现有技术只在检测到终端的系统资源不足时才会关闭部分后台应用相比，可以减少终端在正常运行过程中后台应用的数目，减少后台应用对系统资源的浪费，延长待机时长，减缓甚至避免系统卡顿。

随着各种终端，如电视、手机、平板电脑、个人电脑的智能化，用户可以下载各种应用程序，以下简称应用，来扩展终端的功能，满足用户的个性化需求。随着应用种类及数目的增多，为了方便用户从统一的接口查询并获取所需应用，现有很多第三方的应用提供平台，比如安卓时长、应用汇等，应用提供平台提供各应用的属性信息，并将应用按照属性信息进行分类，供用户查询并获取所需应用。提供平台的数据库中存储的应用的属性信息通常包括：应用的名称、唯一标识、下载地址、分类、版本、详细描述、缩略图、包名、大小、开发者等信息。用户查询应用所需的关键信息通常为应用的分类信息，因此，以下所说的属性信息特指分类信息。这样，比如当用户需要获取视频应用时，可以查看属性信息为视频的应用，并从中寻找自己需要的具体应用。

终端获取应用后，可以对应用进行安装，安装后，应用可以在终端运行，但是，不同属性信息的应用的运行特征一般不同，而相同属性信息的应用通常具有相似的运行特征。这里的运行特征可以指应用在运行过程中所需要的系统资源，比如属性信息为导航的应用，需要使用终端的定位功能，而属性信息为视频的应用通常不需要定位功能，而是会需要更多的上网流量。应用的运行特征还可以指应用被用户使用的频率，这是因为，虽然终端中安装有多种属性信息的应用，但是不同用户对终端的使用习惯通常不同，比如有些用户倾向于使用终端观看视频，那么这类用户使用属性信息为视频的应用的频率更高，有些用户倾向于使用终端网购，那么这类用户使用属性信息为购物的应用的频率更高。

可见，应用的属性信息不仅可以在应用提供平台上用来帮助用户查找需要的应用，还可以在用户终端上用来对已安装的应用进行分类，以方便终端确定各应用的运行特征，对安装的应用进行管理。

图1对应的实施例中，预设时长的设置用于评判后台运行的应用在接下来的一段时间内被用户再次使用的可能性，若某后台运行的应用的后台持续时长超过预设时长，则判定该应用在接下来的一段时长内被用户再次使用的概率较低。但是应用的属性信息不同，其被用户使用的频率一般不同，因此属性信息不同的应用，在后台运行的过程中，使用同一预设时长的取值来作为评判其被用户再次使用的可能性的标准是不够准确的。因此，本发明进一步提供根据应用的属性信息对后台运行的应用进行管理的方案。具体的，是在图1对应的实施例的基础上，在步骤101之后，在步骤103之前，根据前台运行的应用或者第一应用的属性信息来确定预设时长的取值。

一、根据第一应用的属性信息来确定预设时长的取值

请参阅图2，本发明后台应用的管理方法另一个实施例包括：

201、检测第一应用转入后台运行；

终端可以检测应用的运行情况，比如当前台运行的第一应用转入后台运行时，终端可以检测到第一应用转入后台。

202、记录第一应用在后台运行的后台持续时长；

在检测到第一应用转入后台运行之后，终端可以开启计时器，记录第一应用在后台运行的后台持续时长。

203、获取第一应用的属性信息；

在检测到第一应用转入后台运行之后，可以获取第一应用的属性信息。作为举例，获取第一应用的属性信息的具体方式可以为：首先终端可以从应用商店服务器或云端后台获取热门应用的属性信息，并将获取到的属性信息进行存储。获取的属性信息可以包括应用的分类、标签、体积、用户评星、下载次数、包名等信息，也可以只包括应用的分类信息。当用户安装应用时，可以从本地存储的热门应用的属性信息中确定该应用的分类信息，如未存储安装的应用对应的分类信息，则可以联网从应用商店的服务器存储的应用属性信息中进行查询。确定安装的应用的属性信息之后，可以对该应用标识其属性信息，在检测到第一应用转入后台运行之后，通过第一应用的属性信息标识，可以获取第一应用的属性信息。

204、判断第一应用的属性信息是否为第一属性信息，若是，则执行步骤205，若否，则执行步骤206；

在获取第一应用的属性信息之后，可以判断第一应用的属性信息是否是第一属性信息，若是，则执行步骤205，若否，则执行步骤206。

205、确定第一属性信息对应的预设时长的取值为第一时长；

终端预存有后台运行的应用的属性信息与预设时长的取值的第一对应关系集合，若判定第一应用的属性信息是第一属性信息，则从预存的属性信息与预设时长的取值的第一对应关系集合中，确定第一属性信息对应的预设时长的取值为第一时长，并将预设时长的取值设置为第一时长。

206、判断第一应用的属性信息是否为第二属性信息，若是，则执行步骤207，若否，则执行步骤208；

若判定第一应用的属性信息不是第一属性信息，则可以继续判断第一应用的属性信息是否是第二属性信息，若是，则执行步骤207，若否，则执行步骤208。

207、从第一对应关系集合中确定第二属性信息对应的预设时长的取值为第二时长；

若判定第一应用的属性信息是第二属性信息，则从第一对应关系集合中确定第二属性信息对应的预设时长的取值为第二时长，并将预设时长的取值设置为第二时长，第二时长与第一时长不同。假设第一属性信息为视频，其对应的第一时长为4小时；第二属性信息为购物，其对应的第二时长为1小时。

208、执行其他操作；

若判定第一应用的属性信息不是第二属性信息，则可以执行其他操作，比如继续判断第一应用的属性信息是否为第一对应关系集合中预存的其他属性信息，或者，将预设时长的取值设置为默认时长，比如2小时。

第一对应关系集合中也可以只存储第一属性信息与第一时长的对应关系，在判定第一应用的属性信息不是第一属性信息时，不执行步骤206至步骤207，而直接将预设时长的取值设置为默认时长，比如2小时。

209、判断后台持续时长是否超过预设时长，若是，则执行步骤210，若否，则执行步骤211；

在根据第一应用的属性信息确定预设时长的取值之后，可以判断记录的后台持续时长是否超过预设时长，若是，则执行步骤210，若否，则执行步骤211。

210、关闭第一应用；

若判定后台持续时长超过预设时长，则关闭第一应用。

在实际使用中，一些应用虽然在后台运行，但并不是处于等待用户使用的状态，而是在后台为用户提供服务。比如音乐播放类的应用在后台运行的过程，可能正在播放音乐，这样用户在利用前台应用浏览网页或者网购的过程中，可以同时听歌。或者，一些应用在后台运行的过程中可能在下载文件，比如下载视频文件、文档文件等。为了保证这类后台应用继续在后台为用户提供服务，本实施例可以在关闭第一应用之前，判断第一应用是否在进行有效业务，有效业务包括数据更新或者音频播放，若否，则执行关闭第一应用的步骤，若是，则可以在有效业务结束后关系第一应用，或者在有效业务结束后重新计时，并在时长超过某预定时长时，关闭第一应用。作为举例，判断应用是否进行数据更新，可以判断该应用上传或下载的数据流量是否超过某预设流量，若是，则判定该应用在进行数据更新，即进行有效业务。

211、执行步骤209。

若判定后台持续时长未超过预设时长，则获取后台持续时长的当前取值，判断后台持续时长是否超过预设时长，若是，则执行步骤210，若否，则执行步骤211。

若某属性信息对应的应用被用户使用的频率很高，那么可以延长该属性信息对应的预设时长的取值，方便用户再次使用该属性信息对应的应用。若某属性信息对应的应用被用户使用的频率很低，该类应用转入后台后，其被用户再次使用的概率很低，那么可以缩短该属性信息对应的预设时长的取值，减少系统资源的浪费。由于不同用户使用应用的习惯不同，因此难以在出厂时统一预设后台运行的应用的属性信息与预设时长的取值的第一对应关系集合。为了更加合理的设置属性信息对应的预设时长的取值，作为举例，本发明提供一种建立后台运行的应用的属性信息与预设时长的取值的第一对应关系集合的方法，方法包括：

301、在统计时段记录第一集合中的应用在前台运行的第一前台持续时长；

统计时段可以为一天，或者一周等预设的一段时长，在本实施例中，以统计时段为一周为例。在一周内，记录第一集合中的应用在前台运行的第一前台持续时长，第一集合为第一属性信息对应的应用组成的集合。在本实施例中，假设第一属性信息为视频，第一集合包括优酷影音、腾讯视频、乐视视频等。那么，在统计时段内，记录优酷影音、腾讯视频、乐视视频等在前台运行的第一前台持续时长。

302、根据第一前台持续时长计算第一集合对应的第一总时长；

记录一周内第一集合中的应用在前台运行的第一前台持续时长之后，可以根据第一前台持续时长计算第一集合对应的第一总时长。假设记录的优酷影音的第一前台持续时长为10小时，腾讯视频的第一前台持续时长为4小时，乐视视频的第一前台持续时长为6消失，那么第一集合对应的第一总时长为20小时。

303、根据第一总时长确定第一属性信息对应的预设时长的取值为第一时长；

在计算得到第一总时长之后，可以根据第一总时长确定第一属性信息对应的预设时长的取值为第一时长，第一总持续时长与第一时长正相关。作为举例，可以预设作为参考的前台持续总时长，比如10小时，并预设作为参考的预设时长的取值，比如2小时，那么第一属性信息对应的预设时长的取值可以为：(第一总时长/10小时)*2小时，由于第一总时长为20小时，那么第一时长为4小时。

304、将第一属性信息与第一时长关联存储于第一对应关系集合中。

确定第一时长之后，可以将第一属性信息与第一时长关联存储于第一对应关系集合中。

参照步骤301至步骤304，可以在统计时段记录第二集合中的应用在前台运行的第二前台持续时长，第二集合为第二属性信息对应的应用组成的集合，根据第二前台持续时长计算第二集合对应的第二总时长，根据第二总时长确定第二属性信息对应的预设时长的取值为第二时长，第二总持续时长与第二时长正相关，并将第二属性信息与第二时长关联存储于第一对应关系集合中。假设第二集合包括天猫、京东、唯品会，在统计时段内第二集合对应的第二总时长为5小时，那么第二属性信息对应的预设时长的取值可以为：(第二总时长/10小时)*2小时＝1小时。

可见，在统计时段内某属性信息对应的应用在前台运行的持续时长越大，该属性信息的应用被用户使用的频率越高，该属性信息对应的预设时长的取值越大。

在建立第一对应关系集合和第二对应关系集合之后，第一对应关系集合和第二对应关系集合可以用于图2对应的实施例中根据后台运行的应用的属性信息确定其对应的预设时长的取值。

由于用户使用应用的习惯可能会发生变化，为了更加准确的判断各属性信息对应的应用的使用频率，可以周期性的进行步骤301至步骤304，对属性信息与预设时长的取值的第一对应关系集合进行更新，那么图2对应的实施例中所参照的第一对应关系集合为更新后的第一对应关系集合。

二、根据前台应用的属性信息来确定预设时长的取值

请参阅图4，本发明后台应用的管理方法另一个实施例包括：

401、检测第一应用转入后台运行；

402、记录第一应用在后台运行的后台持续时长；

步骤401至步骤402与图2对应的实施例中的步骤201至步骤202相同，此处不再赘述。

403、获取前台运行的第三应用的第三属性信息；

检测第三应用转入后台运行之后，可以获取前台运行的第三应用的第三属性信息。作为举例，获取第三应用的属性信息的具体方式可以为：首先终端可以从应用商店服务器或云端后台获取热门应用的属性信息，并将获取到的属性信息进行存储。获取的属性信息可以包括应用的分类、标签、体积、用户评星、下载次数、包名等信息，也可以只包括应用的分类信息。当用户安装应用时，可以从本地存储的热门应用的属性信息中确定该应用的分类信息，如未存储安装的应用对应的分类信息，则可以联网从应用商店的服务器存储的应用属性信息中进行查询。确定安装的应用的属性信息之后，可以对该应用标识其属性信息，在检测到第三应用转入后台运行之后，通过第三应用的属性信息标识，可以获取第三应用的属性信息。

404、从预存的属性信息与预设时长的第二对应关系集合中，确定第三属性信息对应的预设时长的取值为第三时长；

终端预存有前台运行的应用的属性信息与预设时长的取值的第二对应关系集合，在确定前台运行的第三应用的属性信息之后，可以从预存的属性信息与预设时长的第二对应关系集合中，确定第三属性信息对应的预设时长的取值为第三时长。

405、将预设时长的取值设置为第三时长；

在确定第三属性信息对应的预设时长的取值为第三时长之后，可以将预设时长的取值设置为第三时长。

406、判断后台持续时长是否超过第三时长，若是，则执行步骤407，若否，则执行步骤408；

判断记录的第一应用的后台持续时长是否超过第三时长，若是，则执行步骤407，若否，则执行步骤408。

407、关闭第一应用；

若判定记录的第一应用的后台持续时长超过第三时长，则关闭第一应用。

408、执行其他操作。

若判定记录的第一应用的后台持续时长未超过第三时长，则执行其他操作，比如检测前台运行的应用是否改变，若前台运行的应用未改变，则重新判断第一应用的后台持续时长的当前取值是否超过第三时长；若前台运行的应用发生改变，则重新执行步骤403。

若某属性信息对应的应用被用户使用的频率很高，那么用户在使用该属性信息对应的应用的过程中，该应用在前台持续运行的时长一般较长，那么该应用在前台运行的过程中，后台运行的应用在接下来的一段时长内被用户再次使用的概率较低，因此当该属性信息对应的应用在前台运行时，可以减小预设时长的取值，减少后台运行的应用对系统资源的浪费。若某属性信息对应的应用被用户使用的频率很低，那么该应用在前台持续运行的时长一般较短，那么该应用在前台运行的过程中，后台运行的应用在接下来的一段时长内被用户再次使用的概率较高，此时可以增大预设时长的取值，方便用户再次使用后台运行的应用。由于不同用户使用应用的习惯不同，因此难以在出厂时统一预设前台运行的应用的属性信息与预设时长的取值的第二对应关系集合。为了更加合理的设置属性信息对应的预设时长的取值，作为举例，本发明提供一种建立前台运行的应用的属性信息与预设时长的取值的第二对应关系集合的方法，方法包括：

501、在统计时段记录第三集合中的应用在前台运行的第三前台持续时长；

统计时段可以为一天，或者一周等预设的一段时长，在本实施例中，以统计时段为一周为例。在一周内，记录第三集合中的应用在前台运行的第三前台持续时长，第三集合为第三属性信息对应的应用组成的集合。在本实施例中，假设第三属性信息为阅读，第三集合包括起点读书、当当读书、安卓读书等。那么，在统计时段内，记录起点读书、当当读书、安卓读书等在前台运行的第三前台持续时长。

502、根据第三前台持续时长计算第三集合对应的第三总时长；

记录一周内第三集合中的应用在前台运行的第三前台持续时长之后，可以根据第三前台持续时长计算第三集合对应的第三总时长。假设记录的起点读书的第一前台持续时长为10小时，当当读书的第三前台持续时长为4小时，安卓读书的第三前台持续时长为6小时，那么第三集合对应的第三总时长为20小时。

503、根据第三总时长确定第三属性信息对应的预设时长的取值为第三时长；

在计算得到第三总时长之后，可以根据第三总时长确定第三属性信息对应的预设时长的取值为第三时长，第三总持续时长与第三时长正相关。作为举例，可以预设作为参考的前台持续总时长，比如10小时，并预设作为参考的预设时长的取值，比如2小时，那么第三属性信息对应的预设时长的取值可以为：(10小时/第三总时长)*2小时，由于第三总时长为20小时，那么第三时长为1小时。第三总时长越大，第三属性信息对应的预设时长的取值越小。

504、将第三属性信息与第三时长关联存储于第二对应关系集合中。

确定第三时长之后，可以将第三属性信息与第三时长关联存储于第三对应关系集合中。

在建立第三对应关系集合之后，第三对应关系集合可以用于图4对应的实施例中根据前台运行的应用的属性信息确定预设时长的取值。

由于用户使用应用的习惯可能会发生变化，为了更加准确的判断各属性信息对应的应用的使用频率，可以周期性的进行步骤501至步骤504，对属性信息与预设时长的取值的第二对应关系集合进行更新，那么图4对应的实施例中所参照的第二对应关系集合为更新后的第二对应关系集合。

上面对本发明实施例中的后台应用的管理方法进行了描述，下面对本发明实施例中的后台应用的管理模块进行描述。

请参阅图6，本发明中后台应用的管理模块一个实施例包括：

检测单元601，用于检测第一应用转入后台运行；

第一记录单元602，用于记录第一应用在后台运行的后台持续时长；

第一判断单元603，用于判断后台持续时长是否超过预设时长；

关闭单元604，用于当判断单元判定后台持续时长超过预设时长时，关闭第一应用。

预设时长的取值可以根据第一应用的属性信息或者前台运行的应用的属性信息来设置，若根据第一应用的属性信息来设置，参阅图7，后台应用的管理模块包括：

检测单元701，用于检测第一应用转入后台运行；

第一记录单元702，用于记录第一应用在后台运行的后台持续时长；

第一判断单元703，用于判断后台持续时长是否超过预设时长；

关闭单元704，用于当判断单元判定后台持续时长超过预设时长时，关闭第一应用；

第一获取单元705，用于获取所述第一应用的属性信息；

第二判断单元706，用于判断所述第一应用的属性信息是否为第一属性信息；

第一确定单元707，用于当所述第二判断单元判定所述第一应用的属性信息为第一属性信息时，从预存的属性信息与所述预设时长的取值的第一对应关系集合中，确定所述第一属性信息对应的所述预设时长的取值为第一时长；

第一设置单元708，用于在所述第一确定单元确定所述预设时长的取值为第一时长之后，将所述预设时长的取值设置为所述第一时长；

第二记录单元709，用于在统计时段记录第一集合中的应用在前台运行的第一前台持续时长，所述第一集合为第一属性信息对应的应用组成的集合；

第一计算单元710，用于根据所述第一前台持续时长计算所述第一集合对应的第一总时长；

第二确定单元711，用于根据所述第一总时长确定所述第一属性信息对应的所述预设时长的取值为所述第一时长，所述第一总持续时长与所述第一时长正相关；

第一存储单元712，用于将所述第一属性信息与所述第一时长关联存储于所述第一对应关系集合中。

若根据前台运行的应用的属性信息来设置，参阅图8，后台应用的管理模块包括：

检测单元801，用于检测第一应用转入后台运行；

第一记录单元802，用于记录第一应用在后台运行的后台持续时长；

第一判断单元803，用于判断后台持续时长是否超过预设时长；

关闭单元804，用于当判断单元判定后台持续时长超过预设时长时，关闭第一应用；

第二获取单元805，用于获取前台运行的第三应用的第三属性信息；

第四确定单元806，用于从预存的属性信息与预设时长的第二对应关系集合中，确定第三属性信息对应的预设时长的取值为第三时长；

第三设置单元807，用于将预设时长的取值设置为第三时长；

第三记录单元808，用于在统计时段记录第三集合中的应用在前台运行的第三前台持续时长，第三集合为第三属性信息对应的应用组成的集合；

第二计算单元809，用于根据第三前台持续时长计算第三集合对应的第三总时长；

第五确定单元810，用于根据第三总时长确定第三属性信息对应的预设时长的取值为第三时长，第三总持续时长与第三时长负相关；

第二存储单元811，用于将第三属性信息与第三时长关联存储于第二对应关系集合中。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统，装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

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

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

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

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

以上所述，以上实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。

Claims (12)

1.一种后台应用的管理方法，其特征在于，包括：

检测第一应用转入后台运行；

记录所述第一应用在后台运行的后台持续时长；

判断所述后台持续时长是否超过预设时长；

若是，则关闭所述第一应用。

2.根据权利要求1所述的后台应用的管理方法，其特征在于，在所述检测第一应用转入后台运行之后，在判断所述后台持续时长是否超过预设时长之前，所述方法还包括：

获取所述第一应用的属性信息；

判断所述第一应用的属性信息是否为第一属性信息；

若是，则从预存的属性信息与所述预设时长的取值的第一对应关系集合中，确定所述第一属性信息对应的所述预设时长的取值为第一时长，并将所述预设时长的取值设置为所述第一时长。

3.根据权利要求2所述的后台应用的管理方法，其特征在于，在所述检测第一应用转入后台运行之前，所述方法还包括：

在统计时段记录第一集合中的应用在前台运行的第一前台持续时长，所述第一集合为第一属性信息对应的应用组成的集合；

根据所述第一前台持续时长计算所述第一集合对应的第一总时长；

根据所述第一总时长确定所述第一属性信息对应的所述预设时长的取值为所述第一时长，所述第一总持续时长与所述第一时长正相关；

将所述第一属性信息与所述第一时长关联存储于所述第一对应关系集合中。

4.根据权利要求2所述的后台应用的管理方法，其特征在于，若判定所述第一应用的属性信息不是第一属性信息，所述方法还包括：

判断所述第一应用的属性信息是否为第二属性信息；

若是，则从所述第一对应关系集合中确定所述第二属性信息对应的所述预设时长的取值为第二时长，并将所述预设时长的取值设置为所述第二时长，所述第二时长与所述第一时长不同。

5.根据权利要求1所述的后台应用的管理方法，其特征在于，在所述检测第一应用转入后台运行之后，在判断所述后台持续时长是否超过预设时长之前，所述方法还包括：

获取前台运行的第三应用的第三属性信息；

从预存的属性信息与预设时长的第二对应关系集合中，确定所述第三属性信息对应的所述预设时长的取值为第三时长；

将所述预设时长的取值设置为所述第三时长。

6.根据权利要求5所述的后台应用的管理方法，其特征在于，在所述检测第一应用转入后台运行之前，所述方法还包括：

在统计时段记录第三集合中的应用在前台运行的第三前台持续时长，所述第三集合为所述第三属性信息对应的应用组成的集合；

根据所述第三前台持续时长计算所述第三集合对应的第三总时长；

根据所述第三总时长确定所述第三属性信息对应的所述预设时长的取值为所述第三时长，所述第三总持续时长与所述第三时长负相关；

将所述第三属性信息与所述第三时长关联存储于所述第二对应关系集合中。

7.一种后台应用的管理模块，其特征在于，包括：

检测单元，用于检测第一应用转入后台运行；

第一记录单元，用于记录所述第一应用在后台运行的后台持续时长；

第一判断单元，用于判断所述后台持续时长是否超过预设时长；

关闭单元，用于当所述判断单元判定所述后台持续时长超过所述预设时长时，关闭所述第一应用。

8.根据权利要求7所述的后台应用的管理模块，其特征在于，所述管理模块还包括：

第一获取单元，用于获取所述第一应用的属性信息；

第二判断单元，用于判断所述第一应用的属性信息是否为第一属性信息；

第一确定单元，用于当所述第二判断单元判定所述第一应用的属性信息为第一属性信息时，从预存的属性信息与所述预设时长的取值的第一对应关系集合中，确定所述第一属性信息对应的所述预设时长的取值为第一时长；

第一设置单元，用于在所述第一确定单元确定所述预设时长的取值为第一时长之后，将所述预设时长的取值设置为所述第一时长。

9.根据权利要求8所述的后台应用的管理模块，其特征在于，所述管理模块还包括：

第二记录单元，用于在统计时段记录第一集合中的应用在前台运行的第一前台持续时长，所述第一集合为第一属性信息对应的应用组成的集合；

第一计算单元，用于根据所述第一前台持续时长计算所述第一集合对应的第一总时长；

第二确定单元，用于根据所述第一总时长确定所述第一属性信息对应的所述预设时长的取值为所述第一时长，所述第一总持续时长与所述第一时长正相关；

第一存储单元，用于将所述第一属性信息与所述第一时长关联存储于所述第一对应关系集合中。

10.根据权利要求8所述的后台应用的管理模块，其特征在于，所述管理模块还包括：

第三判断单元，用于判断所述第一应用的属性信息是否为第二属性信息；

第三确定单元，用于当所述第三判断单元判定所述第一应用的属性信息为第二属性信息时，从所述第一对应关系集合中确定所述第二属性信息对应的所述预设时长的取值为第二时长；

第二设置单元，用于当所述第三确定单元确定所述预设时长的取值为第二时长时，将所述预设时长的取值设置为所述第二时长，所述第二时长与所述第一时长不同。

11.根据权利要求7所述的后台应用的管理模块，其特征在于，所述管理模块还包括：

第二获取单元，用于获取前台运行的第三应用的第三属性信息；

第四确定单元，用于从预存的属性信息与预设时长的第二对应关系集合中，确定所述第三属性信息对应的所述预设时长的取值为第三时长；

第三设置单元，用于将所述预设时长的取值设置为所述第三时长。

12.根据权利要求11所述的后台应用的管理模块，其特征在于，所述管理模块还包括：

第三记录单元，用于在统计时段记录第三集合中的应用在前台运行的第三前台持续时长，所述第三集合为所述第三属性信息对应的应用组成的集合；

第二计算单元，用于根据所述第三前台持续时长计算所述第三集合对应的第三总时长；

第五确定单元，用于根据所述第三总时长确定所述第三属性信息对应的所述预设时长的取值为所述第三时长，所述第三总持续时长与所述第三时长负相关；

第二存储单元，用于将所述第三属性信息与所述第三时长关联存储于所述第二对应关系集合中。