CN106528216A - 一种启动应用程序的方法及终端 - Google Patents

Abstract

本发明实施例公开了一种启动应用程序的方法及终端，所述方法包括若检测到启动应用程序的请求，从预存的数据库中获取启动应用程序的预估消耗内存；获取当前系统的剩余内存以及预存的临界内存；计算剩余内存与临界内存的差值；判断差值是否小于应用程序的预估消耗内存；若小于应用程序的预估消耗内存，根据预设规则结束当前后台部分进程来回收内存直至使剩余内存与临界内存的差值不小于预估消耗内存；若的差值不小于所述预估消耗内存，启动应用程序，进而实现了检测当前是否需要回收内存以满足当前被启动的应用程序的内存需求，既可以为被启动的应用程序提供内存，还可以防止内存空闲时部分后台应用功能散失。

Description

一种启动应用程序的方法及终端

技术领域

本发明涉及电子技术领域，尤其涉及一种启动应用程序的方法及终端。

背景技术

随着电子产品的不断发展，便携式电子设备已经变成用户生活中不可缺少的一部分，尤其是手机成为了人手必备的设备。由于现在的应用越来越丰富，因此对电子设备的内存需求也越来也高。例如手机的内存较低时，再启动一个大应用，就容易出现卡顿以及黑屏，甚至崩溃。现有技术为了解决内存不足的问题，常监控应用程序的使用情况，根据用户的使用信息，定时将不常用的应用或者占用较大的应用退出以增加系统的剩余内存，但是这样容易在内存空闲的时候仍然将一些后台应用退出，导致部分后台应用的功能比较容易散失。

发明内容

本发明实施例提供一种启动应用程序的方法及终端，可以通过在启动应用程序时先检测当前系统内存是否满足当前被启动的应用程序的启动需求来判断当前是否需要回收内存，并防止内存空闲时部分后台应用功能散失。

第一方面，本发明实施例提供了一种启动应用程序的方法，所述方法包括：

若检测到启动应用程序的请求，从预存的数据库中获取启动应用程序的预估消耗内存，数据库用于预存应用程序的预估消耗内存；获取当前系统的剩余内存以及预存的临界内存，临界内存为系统触发低内存回收机制时的内存阈值；计算剩余内存与临界内存的差值；判断差值是否小于应用程序的预估消耗内存；若小于应用程序的预估消耗内存，根据预设规则结束当前后台部分进程来回收内存直至使剩余内存与临界内存的差值不小于预估消耗内存；若所述剩余内存与所述临界内存的差值不小于所述预估消耗内存，启动应用程序。

另一方面，本发明实施例提供了一种终端，该终端包括：第一获取单元、第二获取单元、计算单元、判断单元、回收单元以及启动单元，其中，

第一获取单元，用于若检测到启动应用程序的请求，从预存的数据库中获取启动应用程序的预估消耗内存，数据库用于预存应用程序的预估消耗内存；第二获取单元，用于获取当前系统的剩余内存以及预存的临界内存，临界内存为系统触发低内存回收机制时的内存阈值；计算单元，用于计算剩余内存与临界内存的差值；判断单元，用于判断差值是否小于应用程序的预估消耗内存；回收单元，用于若判断单元判断出差值小于应用程序的预估消耗内存，根据预设规则结束当前后台部分进程来回收内存直至使剩余内存与临界内存的差值不小于预估消耗内存；启动单元，用于启动应用程序。

本发明实施例所公开的一种启动应用程序的方法和终端通过若检测到启动应用程序的请求，从预存的数据库中获取启动应用程序的预估消耗内存；获取当前系统的剩余内存以及预存的临界内存，临界内存为系统触发低内存回收机制时的内存阈值；计算剩余内存与临界内存的差值；判断差值是否小于应用程序的预估消耗内存；若小于应用程序的预估消耗内存，根据预设规则结束当前后台部分进程来回收内存直至使剩余内存与临界内存的差值不小于预估消耗内存；若所述剩余内存与所述临界内存的差值不小于所述预估消耗内存，启动应用程序，进而实现了启动应用程序时，先检测当前是否需要回收内存以满足当前被启动的应用程序的内存需求，因此可以为被启动的应用程序提供内存，还可以防止内存空闲时部分后台应用功能散失。

附图说明

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

图1是本发明实施例提供的一种启动应用程序的方法的示意性流程图；

图2是本发明实施例提供的一种启动应用程序的方法的部分示意流程图；

图3是本发明实施例提供的一种终端的第一实施例的示意性框图；

图4是图3中的一种回收单元的示意性框图；

图5是本发明实施例提供的一种终端的第二实施例的示意性框图。

具体实施方式

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

应当理解，当在本说明书和所附权利要求书中使用时，术语“包括”和“包含”指示所描述特征、整体、步骤、操作、元素和/或组件的存在，但并不排除一个或若干个其它特征、整体、步骤、操作、元素、组件和/或其集合的存在或添加。还应当理解，在此本发明说明书中所使用的术语仅仅是出于描述特定实施例的目的而并不意在限制本发明。如在本发明说明书和所附权利要求书中所使用的那样，除非上下文清楚地指明其它情况，否则单数形式的“一”、“一个”及“该”意在包括复数形式。

本发明实施例提供的一种启动应用程序的方法应用于终端，终端包括但是不限制于任何一种可与用户进行人机交互的电子产品，例如智能手机(如Android手机、ios手机、Windows Phone手机等)、平板电能、掌上电能、笔记本电脑、移动互联网设备等。以上电子设备仅是举例，而非穷举，本发明实施例提供的终端包括但是不限制于上述电子设备。

请看图1，是本发明实施例提供的一种启动应用程序的方法的示意性流程图，如图所示，所述方法包括如下S101～S115：

S101，若检测到启动应用程序的请求，从预存的数据库中获取启动应用程序的预估消耗内存，数据库用于预存应用程序的预估消耗内存。

具体的，数据库中预存有终端上应用程序的预估消耗内存，预估消耗内存用于表示预估启动应用程序的内存消耗。本发明实施例中第一次启动应用程序时，应用程序对应的预估消耗内存为一个预设值，该预设值是根据应用程序的大小设定；非第一次启动应用程序时，一个应用程序对应的预估消耗内存是根据记录的每次启动同一应用程序实际消耗的内存相关。因此应当理解，每一次启动应用程序时，将会记录启动该应用程序过程中实际消耗的内存，并根据记录的实际消耗内存更新数据库中的该应用程序的预估消耗内存。本实施例中优选，非第一次被启动的应用程序对应的预估消耗内存为记录的每次启动该应用程序过程实际消耗内存的平均值。因此还应当理解，每个应用程序对应的预估消耗内存是动态数值，且随着应用程序启动的次数增加，预估消耗内存的准预存准确性将不断提高。

S103，获取当前系统的剩余内存以及预存的临界内存，临界内存为系统触发低内存回收机制时的内存阈值。

具体的，当系统内存较少，启动应用程序时若无法一次性申请到足够的内存，应用程序的线程将被暂停，需要等待系统触发低内存回收机制来回收内存，低内存回收机制LMK(Low Memory Killer)为系统内存低于对应阈值时，将会触发自动结束后台进程来回收内存。需要说明的是，预存的临界内存的数值大小是预先设置的，具体可以是根据实验实践经验而设置，在一些可行的实施例中，系统的临界内存的数值大小是固定的。

还需要说明的是，由于系统启动低内存回收机制时，将会使linux内核(linuxkernel)的kswap进程的CPU使用率提升到一个较高的状态，导致linux内核任务增加变忙碌，进而影响应用内存的分配任务，导致内存分配效率降低，降低了启动应用程序的速率。因此为了提高启动应用程序速率，应当避免启动应用程序时启动低内存回收机制。还需要说明的是，本发明实施例中临界内存为触发低内存回收机制时的内存阈值。即系统剩余内存低于临界内存时，将触发低内存回收机制来回收内存。

S105，计算剩余内存和临界内存的差值。

S107，判断差值是否小于应用程序的预估消耗内存，若小于应用程序的预估消耗内存，执行S109；若不小于应用程序的预估消耗内存，执行S111。

具体的，由于临界内存为系统触发低内存回收机制时的内存阈值，为了防止启动应用程序时触发低内存回收机制，应当满足剩余内存和临界内存的差值不小于应用程序的预估消耗内存。

S109，根据预设规则结束当前后台部分进程来回收内存直至使剩余内存与临界内存的差值不小于预估消耗内存。

具体的，若剩余内存和临界内存的差值小于应用程序的预估消耗内存，则表示启动应用程序时将会触发低内存回收机制，进而降低启动应程序的启动效率。因此需要先回收内存而避免启动应用程序过程中通过低内存回收机制回收内存。

需要说明的是，在一些可行的实施例中，预设规则可以是根据当前后台进程的启动时间的先后顺序结束进程来回收内存；在另一些可行的实施例中，预设规则还可以是根据当前后台进程对应的应用程序的使用频率的高低顺序结束进程来回收内存；在另一些可行的实施例中，预设规则还可以是根据当前后台进程对应的应用程序所占据的内存大小顺序结束进程来回收内存。本发明实施例对此不进行具体的限定。

还需要说明的是，根据预设规则技术当前后台部分进程时，在一些可行的实施例中，被结束的后台进程的数量可以是通过修改后台最大进程数实现；在另一些可行的实施例中，所结束的后台进程的数量还可以是通过结束预设数量的进程实现。

S111，启动应用程序。

S113，记录当前启动应用程序的实际消耗内存。

S115，根据记录的实际消耗内存修改并更新预存的数据库中该应用程序的预估消耗内存。流程结束

具体的，由于本实施例中非第一次被启动的应用程序对应的预估消耗内存为记录的每次启动该应用程序过程实际消耗内存的平均值，因此修改后的预估消耗内存为记录的当前启动该应用程序的实际消耗内存和记录的此前每次启动该应用程序的实际消耗内存的平均值。

应当理解，启动同一应用程序时所消耗的实际内存可能不一样。例如用户修改了应用程序中的功能配置时或者第一次启动应用程序时初始化工作相较于非第一次启动同一应用程序时较多等都可能导致启动同一应用程序时所消耗的内存不同。

在一些可行的实施例中，为了提高预估消耗内存的预估准确性，S111后如图2所示的流程，需要说明的是如图2所示的流程与S115的顺序不受限定，优选于S115之后执行。若应用程序的预估消耗内存的数值更接近实际消耗内存的数值，则表示预估消耗内存的预估准确性更高。

S201，判断启动应用程序过程是否发生了卡顿，若发生了卡顿，执行S203；若没有发生卡顿，流程结束。

需要说明的是，在一些可行的实施例中，若图2中所示的部分流程先于S115，若没有发生卡顿，则再执行S115。

S203，记录卡顿时长。

S205，判断卡顿时长是否超过了预设时长，若超过了预设时长，执行S207；若没超过预设时长，流程结束。

需要说明的是，在一些可行的实施例中，若图2中所示的部分流程先于S115，若没有发生卡顿，则再执行S115。

S207，判断启动同一应用程序的过程卡顿时长超过预设时长的频率是否超过了预设频率，若超过了预设频率，执行S209；若未超过预设频率，流程结束。

具体的，若启动同一应用程序的过程卡顿时长超过预设时长的频率超过了预设频率，则表示应用程序的预估消耗内存与实际消耗内存差异较大，需要修改预估消耗内存的数值大小，使其更接近该应用程序的实际消耗内存，来提高预估消耗内存的预估准确性。

S209，根据记录的每次超过预设时长的卡顿时长修改并更新应用程序的预估消耗内存，修改后的预估消耗内存大于原预估消耗内存。

具体的，为了提高预估消耗内存的预估准确性，本发明实施例还包括预估消耗内存的修订系数K，修订系数K是大于1，修订系数K与记录的每次超过预设时长的卡顿时长相关，一些可行的实施例中，若记录的每次超过预设时长的平均时长越大，修订系数K越大。

还需要说明的是，在一些可行的实施例中，若图2中所示的部分流程先于S115，则S209之前需执行S115步骤。

从上述实施例可知，本发明实施例中通过当前系统的剩余内存是否满足当前被启动的应用程序的预估消耗内存和临界内存来判断是否要进行内存回收，一方面既能满足启动应用程序时的内存需求，又能防止内存空闲时部分后台应用功能散失；另一方面还能防止启动应用程序时触发低内存回收机制而导致启动应用程序的效率降低。此外，本发明实施例还对记录每次启动应用程序的实际消耗内存，用于修正同一应用程序的预估消耗内存的预估准确性；再者本发明实施例还监控启动应用程序时是否发生卡顿，用于进一步地修正同一应用程序的预估消耗内存的预估准确性。

为了更加有效地回收内存，又降低回收内存时对用户当前使用所述终端的影响，在一些可行的实施例中，S109中根据预设规则结束当前后台部分进程来回收内存直至使剩余内存与临界内存的差值不小于预估消耗内存，具体包括：

减小后台最大进程数；以及根据减小后的最大进程数结束当前后台部分进程，使当前后台进程数小于或等于最大进程数。

具体的，后台最大进程数用于限制当前后台进程数量，若当前后台进程数量超过了减小后的最大进程数，则需要结束部分后台进程用以满足后台进程数量不超过减小后的后台最大进程数。

需要说明的是，在一些可行的实施例中减小后台最大进程数的方式为阶梯式减小后台最大进程数，例如若原始后台最大进程数为8，每次减小2，第一次减小后台最大进程数为6，再根据减小后的后台最大进程数结束后台进程来回收内存，若仍未使剩余内存与临界内存的差值不小于预估消耗内存；则再次减小后台最大进程数为4，再根据减小后的后台最大进程数结束后台进程来回收内存，以此方式直至使剩余内存与临界内存的差值不小于预估消耗内存。

在另一些可行的实施例中，减小的后台最大进程数为一个预设数值，该预设数值不限定为固定数值或动态数值，例如若减小后的后台最大进程为动态数值，可以是根据剩余内存与临界内存的差值以及预估消耗内存来设定，例如若差值与预估消耗内存相差越大，减小后的最大进程数越小。例如将减小的后台最大进程数设置为2。

还需要说明的是，在一些可行的实施例中，根据减小的后台最大进程数结束进程后使后台的进程数量为最大进程数。在另一些可行的实施例中，根据减小的后台最大进程数结束进程后使后台的进程数量小于最大进程数，数量不定。

在一些可行的实施例中，若预设规则是根据当前后台进程的启动时间的先后顺序来回收内存，则根据减小后的最大进程数结束当前后台部分进程具体为按照当前后台进程的启动时间的先后顺序结束进程。

在另一些可行的实施例中，若预设规则是根据当前后台进程对应的应用程序的使用频率的高低顺序结束进程来回收内存，则根据减小后的最大进程数结束当前后台部分进程具体为按照当前后台进程的对应的应用程序的使用频率的高低顺序结束进程。

在另一些可行的实施例中，若预设规则是根据当前后台进程对应的应用程序所占据的内存大小顺序结束进程来回收内存，根据减小后的最大进程数结束当前后台部分进程具体为按照当前后台进程的对应的应用程序所占据的内存大小顺序结束进程。

还需要说明的是，在其他实施例中，为了回收内存，S109中根据预设规则结束当前后台部分进程来回收内存直至使剩余内存与临界内存的差值不小于预估消耗内存具体为根据预设规则结束当前后台预设数量的进程来回收内存直至使剩余内存与临界内存的差值不小于预估消耗内存。

具体的，预设数量可以是一个固定值，还可以是动态值，若预设数量是动态值，优选预设数量是根据剩余内存与临界内存的差值以及预估消耗内存来设定。此时被结束的进程还可以是根据当前后台进程的启动时间的先后顺序来实现；在其他可行的实施例中，被结束的进程还可以是根据根据当前后台进程对应的应用程序的使用频率的高低顺序结束进程来实现；在其他可行的实施例中，被结束的进程还可以是根据当前后台进程对应的应用程序所占据的内存大小顺序结束进程来实现。

从上述可知，若根据当前后台进程的启动时间的先后顺序来回收进程所占内存，基于用户越早启动的应用程序，用户再使用的几率越低，结束使用几率低的应用程序的进程可以对用户使用终端时的影响；若根据当前后台进程对应的应用程序的使用频率的高低顺序来回收进程所占内存，基于用户使用频率越低的应用程序，用户再次使用的几率越低，结束结束使用几率低的应用程序的进程可以对用户使用终端时的影响；若根据当前后台进程对应的应用程序所占据的内存大小顺序结束进程来回收结束进程，这是基于结束所占内存越大的进程可以为系统腾出更多的内存以保证当前被启动的应用程序的启动速率。

请看图3，是本发明实施例提供的一种终端的第一实施例的示意性框图。如图所示，所述终端300包括第一获取单元301、第二获取单元302、计算单元303、判断单元304、回收单元305、启动单元306、记录单元307以及更新单元308。

其中，第一获取单元301，用于若检测到启动应用程序的请求，从预存的数据库中获取启动应用程序的预估消耗内存，数据库用于预存应用程序的预估消耗内存。

具体的，数据库中预存有终端上应用程序的预估消耗内存，预估消耗内存用于表示预估启动应用程序的内存消耗。本发明实施例中第一次启动应用程序时，应用程序对应的预估消耗内存为一个预设值，该预设值是根据应用程序的大小设定；非第一次启动应用程序时，一个应用程序对应的预估消耗内存是根据记录的每次启动同一应用程序实际消耗的内存相关。本实施例中优选，非第一次被启动的应用程序对应的预估消耗内存为记录的每次启动该应用程序过程实际消耗内存的平均值。

第二获取单元302，用于获取当前系统的剩余内存以及预存的临界内存，临界内存为系统触发低内存回收机制时的内存阈值。

具体的，当系统内存较少，启动应用程序时若无法一次性申请到足够的内存，应用程序的线程将被暂停，需要等待系统触发低内存回收机制来回收内存，低内存回收机制LMK(Low Memory Killer)为系统内存低于对应阈值时，将会触发自动结束后台进程来回收内存。需要说明的是，预存的临界内存的数值大小是预先设置的，其可以是根据实验实践经验而设置，在一些可行的实施例中，系统的临界内存的数值大小是固定的。

还需要说明的是，由于系统启动低内存回收机制时，将会使linux内核(linuxkernel)的kswap进程的CPU使用率提升到一个较高的状态，导致linux内核任务增加变忙碌，进而影响应用内存的分配任务，导致内存分配效率降低，降低了启动应用程序的速率。因此为了提高启动应用程序速率，应当避免启动应用程序时启动低内存回收机制。还需要说明的是，本发明实施例中临界内存为触发低内存回收机制时的内存阈值。即系统剩余内存低于临界内存时，将触发低内存回收机制来回收内存。

计算单元303，用于计算剩余内存和临界内存的差值。

判断单元304，用于判断差值是否小于应用程序的预估消耗内存。

回收单元305，用于若判断单元304判断出差值是小于应用程序的预估消耗内存，根据预设规则结束当前后台部分进程来回收内存直至使剩余内存与临界内存的差值不小于预估消耗内存。

具体的，由于临界内存为系统触发低内存回收机制时的内存阈值，为了防止启动应用程序时触发低内存回收机制，应当满足剩余内存和临界内存的差值不小于应用程序的预估消耗内存。

若剩余内存和临界内存的差值小于应用程序的预估消耗内存，则表示启动应用程序时将会触发低内存回收机制，进而降低启动应程序的启动效率。因此需要先回收内存而避免启动应用程序过程中通过低内存回收机制回收内存。

需要说明的是，在一些可行的实施例中，预设规则可以是根据当前后台进程的启动时间的先后顺序结束进程来回收内存；在另一些可行的实施例中，预设规则还可以是根据当前后台进程对应的应用程序的使用频率的高低顺序结束进程来回收内存；在另一些可行的实施例中，预设规则还可以是根据当前后台进程对应的应用程序所占据的内存大小顺序结束进程来回收内存。本发明实施例对此不进行具体的限定。

还需要说明的是，根据预设规则技术当前后台部分进程时，在一些可行的实施例中，被结束的后台进程的数量可以是通过修改后台最大进程数实现；在另一些可行的实施例中，所结束的后台进程的数量还可以是通过结束预设数量的进程实现。

启动单元306，用于启动应用程序。

记录单元307，用于记录当前启动应用程序的实际消耗内存。

更新单元308，用于根据记录的实际消耗内存修改并更新预存的数据库中该应用程序的预估消耗内存。

具体的，由于本实施例中非第一次被启动的应用程序对应的预估消耗内存为记录的每次启动该应用程序过程实际消耗内存的平均值，因此修改后的预估消耗内存为记录的当前启动该应用程序的实际消耗内存和记录的此前每次启动该应用程序的实际消耗内存的平均值。

在一些可行的实施例中，为了提高预估消耗内存的预估准确性，所述终端还包括第一检测单元309、第二检测单元310以及第三检测单元311。

第一检测单元309，用于判断启动应用程序过程是否发生了卡顿。

记录单元307，还用于若第一检测单元309检测出启动应用程序过程是发生了卡顿，记录卡顿时长。

第二检测单元310，用于判断卡顿时长是否超过了预设时长。

第三检测单元311，用于若第二检测单元310判断出卡顿时长超过了预设时长，判断启动同一应用程序的过程卡顿时长超过预设时长的频率是否超过了预设频率。

更新单元308，还用于若第三检测单元311判断出启动同一应用程序的过程卡顿时长超过预设时长的频率是超过了预设频率，根据记录的每次超过预设时长的卡顿时长修改并更新应用程序的预估消耗内存，修改后的预估消耗内存大于原预估消耗内存。

具体的，为了提高预估消耗内存的预估准确性，本发明实施例还包括预估消耗内存的修订系数K，修订系数K是大于1，修订系数K与记录的每次超过预设时长的卡顿时长相关，一些可行的实施例中，若记录的每次超过预设时长的平均时长越大，修订系数K越大。

相较于上述方案，进一步地，为了更加有效地回收内存，又降低回收内存时对用户当前使用所述终端的影响，在一些可行的实施例中，请看图4，回收单元305包括减小单元401和处理单元402。

减小单元401，用于减小后台最大进程数。

处理单元402，用于根据减小后的最大进程数结束当前后台部分进程，使当前后台进程数小于或等于最大进程数。

具体的，后台最大进程数用于限制当前后台进程数量，若当前后台进程数量超过了减小后的最大进程数，则需要结束部分后台进程用以满足后台进程数量不超过减小后的后台最大进程数。需要说明的是，在一些可行的实施例中减小后台最大进程数的方式为阶梯式减小后台最大进程数，例如若原始后台最大进程数为8，每次减小2，第一次减小后台最大进程数为6，再根据减小后的后台最大进程数结束后台进程来回收内存，若仍未使剩余内存与临界内存的差值不小于预估消耗内存；则再次减小后台最大进程数为4，再根据减小后的后台最大进程数结束后台进程来回收内存，以此方式直至使剩余内存与临界内存的差值不小于预估消耗内存。在另一些可行的实施例中，减小的后台最大进程数为一个预设数值，该预设数值不限定为固定数值或动态数值，例如若减小后的后台最大进程为动态数值，可以是根据剩余内存与临界内存的差值以及预估消耗内存来设定，例如若差值与预估消耗内存相差越大，减小后的最大进程数越小。例如将减小的后台最大进程数设置为2。

需要说明的是，在一些可行的实施例中，若预设规则是根据当前后台进程的启动时间的先后顺序来回收内存，则处理单元402根据减小后的最大进程数结束当前后台部分进程具体为按照当前后台进程的启动时间的先后顺序结束进程。

在另一些可行的实施例中，若预设规则是根据当前后台进程对应的应用程序的使用频率的高低顺序结束进程来回收内存，则处理单元402根据减小后的最大进程数结束当前后台部分进程具体为按照当前后台进程的对应的应用程序的使用频率的高低顺序结束进程。

在另一些可行的实施例中，若预设规则是根据当前后台进程对应的应用程序所占据的内存大小顺序结束进程来回收内存，则处理单元402根据减小后的最大进程数结束当前后台部分进程具体为按照当前后台进程的对应的应用程序所占据的内存大小顺序结束进程。

还需要说明的是，在其他实施例中，为了回收内存，回收单元305根据预设规则结束当前后台部分进程来回收内存直至使剩余内存与临界内存的差值不小于预估消耗内存具体为根据预设规则结束当前后台预设数量的进程来回收内存直至使剩余内存与临界内存的差值不小于预估消耗内存。

具体的，预设数量可以是一个固定值，还可以是动态值，若预设数量是动态值，优选预设数量是根据剩余内存与临界内存的差值以及预估消耗内存来设定。此时被结束的进程还可以是根据当前后台进程的启动时间的先后顺序来实现；在其他可行的实施例中，被结束的进程还可以是根据根据当前后台进程对应的应用程序的使用频率的高低顺序结束进程来实现；在其他可行的实施例中，被结束的进程还可以是根据当前后台进程对应的应用程序所占据的内存大小顺序结束进程来实现。

参见图5，是本发明实施方式提供的一种终端的第二实施例的示意性框图。如图所示的本实施例中的终端500可以包括一个或者若干个处理器501、一个或者若干个输入装置502、一个或者若干个输出装置503以及存储器504。上述处理器501、输入装置502、输出装置503以及存储器504通过总线连接。

输入装置502用于响应用户操作输入的信息。具体实现中，本发明实施例的输入装置502可包括键盘、鼠标、光电输入装置、声音输入装置、触摸式输入装置、扫描仪等。

输出装置503用于对外输出信息给用户。具体实现中，本发明实施例的输出装置503可包括显示器、扬声器、打印机等。

存储器504用于存储带有各种功能的程序数据以及存储数据库中各类数据，具体实现中，本发明实施例的存储器504可以是系统存储器，比如，挥发性的(诸如RAM)，非易失性的(诸如ROM，闪存等)，或者两者的结合。具体实现中，本发明实施例的存储器504还可以是系统之外的外部存储器，比如，磁盘、光盘、磁带等。

处理器501用于调用存储器504中存储的程序数据即执行存储器504存储的指令，并执行如下操作：

若检测到启动应用程序的请求，从预存的数据库中获取启动应用程序的预估消耗内存，数据库用于预存应用程序的预估消耗内存，获取当前系统的剩余内存以及预存的临界内存，临界内存为系统触发低内存回收机制时的内存阈值，计算剩余内存和临界内存的差值，判断差值是否小于应用程序的预估消耗内存，若小于应用程序的预估消耗内存，根据预设规则结束当前后台部分进程来回收内存直至使剩余内存与临界内存的差值不小于预估消耗内存，再启动应用程序，或者若不小于应用程序的预估消耗内存，也启动应用程序；启动应用程序过程记录当前启动应用程序的实际消耗内存，并根据记录的实际消耗内存修改并更新预存的数据库中该应用程序的预估消耗内存。

另一方面，进一步地处理器501用于调用存储器504中存储的程序数据即执行存储器504存储的指令，并在执行根据记录的实际消耗内存修改并更新预存的数据库中该应用程序的预估消耗内存之后，还执行如下操作：

判断启动应用程序过程是否发生了卡顿，若发生了卡顿，记录卡顿时长并判断卡顿时长是否超过了预设时长，若超过了预设时长，判断启动同一应用程序的过程卡顿时长超过预设时长的频率是否超过了预设频率，若超过了预设频率，根据记录的每次超过预设时长的卡顿时长修改并更新应用程序的预估消耗内存，修改后的预估消耗内存大于原预估消耗内存。

进一步地，处理器501用于调用存储器504中存储的程序数据即执行存储器504存储的指令，并执行根据预设规则结束当前后台部分进程来回收内存直至使剩余内存与临界内存的差值不小于预估消耗内存，具体执行如下操作：

减小后台最大进程数；以及根据减小后的最大进程数结束当前后台部分进程，使当前后台进程数小于或等于最大进程数。

进一步地，其他可实现的方式中，处理器501用于调用存储器504中存储的程序数据即执行存储器504存储的指令，并执行根据预设规则结束当前后台部分进程来回收内存直至使剩余内存与临界内存的差值不小于预估消耗内存，具体执行如下操作：根据预设规则结束当前后台预设数量的进程来回收内存直至使剩余内存与临界内存的差值不小于预估消耗内存。

应当理解，在本发明实施例中，所称处理器501可以是中央第一处理单元402(Central Processing Unit，CPU)，该处理器501还可以是其他通用处理器、数字信号处理器(Digital Signal Processor，DSP)、专用集成电路(Application Specific IntegratedCircuit，ASIC)、现成可编程门阵列(Field-Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。

需要说明的是，本发明实施例方法中的步骤可以根据实际需要进行顺序调整、合并和删减。

本发明实施例终端中的单元可以根据实际需要进行合并、划分和删减。

所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，上述描述的终端和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。在本申请所提供的几个实施例中，应该理解到，所揭露的终端和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如若干个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另外，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口、装置或单元的间接耦合或通信连接，也可以是电的，机械的或其它的形式连接。

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

以上所述，为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到各种等效的修改或替换，这些修改或替换都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应以权利要求的保护范围为准。

Claims (10)

1.一种启动应用程序的方法，其特征在于，包括：

若检测到启动应用程序的请求，从预存的数据库中获取启动所述应用程序的预估消耗内存，所述数据库用于预存所述应用程序的预估消耗内存；

获取当前系统的剩余内存以及预存的临界内存，所述临界内存为系统触发低内存回收机制时的内存阈值；

计算所述剩余内存与所述临界内存的差值；

判断所述差值是否小于所述应用程序的预估消耗内存；

若小于所述应用程序的预估消耗内存，根据预设规则结束当前后台部分进程来回收内存直至使所述剩余内存与所述临界内存的差值不小于所述预估消耗内存；

若所述剩余内存与所述临界内存的差值不小于所述预估消耗内存，启动所述应用程序。

2.根据权利要求1所述方法，其特征在于，非第一次被启动的应用程序对应的所述预估消耗内存是记录的每次启动所述应用程序过程实际消耗内存的平均值，所述启动所述应用程序之后，所述方法还包括：

记录当前启动所述应用程序的实际消耗内存；

根据记录的所述实际消耗内存修改并更新预存的数据库中所述应用程序的预估消耗内存，修改后的所述预估消耗内存为记录的当前启动所述应用程序的实际消耗内存和记录的此前每次启动所述应用程序的实际消耗内存的平均值。

3.根据权利要求1所述的方法，其特征在于，所述启动所述应用程序之后，所述方法还包括：

判断启动所述应用程序过程是否发生了卡顿；

若发生卡顿，记录卡顿时长；

若卡顿时长超过预设时长，判断启动同一所述应用程序时卡顿时长超过预设时长的频率是否超过了预设频率；

若超过了预设频率，根据记录的每次超过预设时长的卡顿时长修改并更新所述应用程序的预估消耗内存，修改后的所述预估消耗内存大于原预估消耗内存。

4.根据权利要求1所述的方法，其特征在于，所述根据预设规则结束当前后台部分进程来回收内存直至使所述剩余内存与所述临界内存的差值不小于所述预估消耗内存，具体包括：

减小后台最大进程数；

根据减小后的所述最大进程数结束当前后台部分进程，使当前后台进程数小于或等于所述最大进程数。

5.根据权利要求4所述的方法，其特征在于，若所述预设规则为根据当前后台进程的启动时间的先后顺序来回收内存，所述根据减小后的所述最大进程数结束当前后台部分进程，具体包括：

按照当前后台进程的启动时间的先后顺序结束进程。

6.一种终端，其特征在于，所述终端包括：

第一获取单元，用于若检测到启动应用程序的请求，从预存的数据库中获取启动所述应用程序的预估消耗内存，所述数据库用于预存所述应用程序的预估消耗内存；

第二获取单元，用于获取当前系统的剩余内存以及预存的临界内存，所述临界内存为系统触发低内存回收机制时的内存阈值；

计算单元，用于计算所述剩余内存与所述临界内存的差值；

判断单元，用于判断所述差值是否小于所述应用程序的预估消耗内存；

回收单元，用于若所述判断单元判断出所述差值小于所述应用程序的预估消耗内存，根据预设规则结束当前后台部分进程来回收内存直至使所述剩余内存与所述临界内存的差值不小于所述预估消耗内存；

启动单元，用于若所述剩余内存与所述临界内存的差值不小于所述预估消耗内存，启动所述应用程序。

7.根据权利要求6所述的终端，其特征在于，非第一次被启动的应用程序对应的所述预估消耗内存是记录的每次启动所述应用程序过程实际消耗内存的平均值，所述终端还包括：

记录单元，用于记录当前启动所述应用程序的实际消耗内存；

更新单元，用于根据记录的所述实际消耗内存修改并更新预存的数据库中所述应用程序的预估消耗内存，修改后的所述预估消耗内存为记录的当前启动所述应用程序的实际消耗内存和记录的此前每次启动所述应用程序的实际消耗内存的平均值。

8.根据权利要求6所述的终端，其特征在于，所述终端还包括第一检测单元以及第三检测单元：

所述第一检测单元，用于判断启动所述应用程序过程是否发生了卡顿；

所述记录单元，用于若所述第一检测单元判断出启动所述应用程序过程发生了卡顿，记录卡顿时长；

所述第三检测单元，用于若卡顿时长超过预设时长，判断启动同一所述应用程序时卡顿时长超过预设时长的频率是否超过了预设频率；

所述更新单元，还有用于若所述第三检测单元判断出启动同一所述应用程序时卡顿时长超过预设时长的频率超过了预设频率，根据记录的每次超过预设时长的卡顿时长修改并更新所述应用程序的预估消耗内存，修改后的所述预估消耗内存大于原预估消耗内存。

9.根据权利要求6所述的终端，其特征在于，所述回收单元包括：

减小单元，用于减小后台最大进程数；

处理单元，用于根据减小后的所述最大进程数结束当前后台部分进程，使当前后台进程数小于或等于所述最大进程数。

10.根据权利要求9所述的终端，其特征在于，若所述预设规则为根据当前后台进程的启动时间的先后顺序来回收内存，所述处理单元用于按照当前后台进程的启动时间的先后顺序，结束进程。