CN105808447A - 一种终端设备的内存回收方法和装置 - Google Patents

Abstract

本发明实施例提供了一种终端设备的内存回收方法和装置，所述终端设备设置有一个或多个应用程序集合，所述应用程序集合中的应用程序具有对应的界面栈，所述界面栈处于运行状态时配置有相应的内存；所述的方法包括：当应用程序集合由前台界面切换到后台界面时，记录所述应用程序集合中处于运行状态的界面栈；在所述界面栈中确定待回收的界面栈；回收所述待回收的界面栈所配置的内存。本发明实施例能够按照应用程序集合的切换来释放多余的内存，增加***中剩余内存，减少***回收内存引起的卡顿现象。

Description

一种终端设备的内存回收方法和装置

技术领域

本发明涉及终端技术领域，特别是涉及一种终端设备的内存回收方法和一种终端设备的内存回收装置。

背景技术

目前，嵌入式智能操作***大量应用于消费电子产品中，例如手机、电脑、电视等等，用户可以在产品中下载并安装很多应用程序，以满足多样化的使用需求。

嵌入式智能操作***中有一个Launcher(应用启动器界面)，应用程序在Launcher上显示用于启动的应用图标，如果用户启动一个应用程序后要打开另一个应用程序，需要回到Launcher找到另一个应用图标点击启动，或者，通过***界面的运行程序列表找到另一个运行过的应用程序来点击切换。

上述方式是以应用程序为单位的产品使用方式，用户所感知到的是一个个单独的应用程序，使用产品时在每个独立的应用程序之间切换。然而，此类使用方式比较适用于电脑或者类似电脑的智能手机等近距离操作的产品，而不太适用于电视、机顶盒等远距离操作的产品。

目前存在一种能够按照功能聚合到同一应用程序集合中的产品，这种产品能够更加方便用户使用，而不再需要在每个独立的应用程序之间切换，并且能够通过一键切换将应用程序结合中的应用程序瞬间保存状态和恢复运行状态。但是，这种应用程序集合在使用过程存在的问题是：在应用程序集合中存在有多个应用程序集合，若同时保持该应用程序集合中的全部应用程序的运行状态，需要耗费大量的内存，使得应用程序界面的卡顿和响应缓慢，目前一种针对这种情况的回收策略是，当应用程序集合切换到后台界面时，立即回收该应用程序集合中的全部内存，但这种做法的缺点是若用户想要重新打开该应用程序集合中的应用程序，则需要重新加载，不仅速度慢而且之前运行时的状态和数据会丢失。另外，关闭应用程序集合中的应用程序时，由于应用程序具有同样的优先级，故在回收内存时未能区分哪些应用程序对用户意义更重要，用户体验效果较差。

发明内容

鉴于上述问题，提出了本发明实施例以便提供一种克服上述问题或者至少部分地解决上述问题的一种终端设备的内存回收方法和相应的一种终端设备的内存回收装置。

为了解决上述问题，本发明实施例公开了一种终端设备的内存回收方法，所述终端设备设置有一个或多个应用程序集合，所述应用程序集合中的应用程序具有对应的界面栈，所述界面栈处于运行状态时配置有相应的内存；

所述的方法包括：

当应用程序集合由前台界面切换到后台界面时，记录所述应用程序集合中处于运行状态的界面栈；

在所述界面栈中确定待回收的界面栈；

回收所述待回收的界面栈所配置的内存。

本发明实施例还公开了一种终端设备的内存回收装置，所述终端设备设置有一个或多个应用程序集合，所述应用程序集合中的应用程序具有对应的界面栈，所述界面栈处于运行状态时配置有相应的内存；

所述的装置包括：

界面栈记录模块，用于在应用程序集合由前台界面切换到后台界面时，记录所述应用程序集合中处于运行状态的界面栈；

待回收界面栈确定模块，用于在所述界面栈中确定待回收的界面栈；

界面栈内存回收模块，用于回收所述待回收的界面栈所配置的内存。

本发明实施例包括以下优点：

本发明实施例中，终端设备按照功能需求将应用程序进行分组，则可以得到各个功能场景下相应的应用程序集合，应用程序集合中的应用程序运行时，***为其分配界面栈以及内存，当任意的应用程序集合由前台界面切换到后台界面时，记录该应用程序集合处于运行状态的界面栈，并从中进一步确定待回收的界面栈，最后在应用程序集合成功切换到后台界面后，进行该待回收的界面栈内存的回收。应用本发明实施例，能够按照应用程序集合的切换来释放多余的内存，增加***中剩余内存，减少***回收内存引起的卡顿现象。本发明实施例对于内存较小的低配置产品而言，具有很高的实用性。

另外，本发明实施例中针对应用程序集合中的应用程序设置有回收优先级，当确定待回收的界面栈后，会根据其优先级按序进行回收操作，其中，若待回收的界面栈中包括有重要应用程序的重要服务界面栈，则不进行回收操作，从而保证***所需的应用程序切换到后台界面时，不因内存回收被杀。

附图说明

图1是本发明的一种终端设备的内存回收方法实施例的步骤流程图；

图2是本发明的一种终端设备Silo运行时产生的界面栈结构示意图；

图3是本发明的一种终端设备的内存回收装置实施例的结构框图。

具体实施方式

为使本发明的上述目的、特征和优点能够更加明显易懂，下面结合附图和具体实施方式对本发明作进一步详细的说明。

以远距离操作的电视产品为例，电视一般在远距离使用遥控器操作，一方面，用户希望通过尽量少的操作享受尽量多的内容展示，另一方面，电视有几种特定的互相独立的功能，例如观看直播电视视频，观看在线视频，玩游戏，查看***设备中的媒体资源，以及移动设备向电视推送媒体等等。

目前，在一种智能电视具有功能场景UI(UserInterface，用户界面)***，它直接向用户提供各种功能场景(下文中将功能场景简称Silo)，用户按照功能需求通过遥控器一键直达某个功能场景，每个功能场景内部聚合同一类型的资源、服务和应用程序。其中，该功能场景下同一类型的资源、服务和应用程序在本文中可统称为应用程序集合。典型的功能场景如直播电视、视频点播、游戏中心、应用中心、本地媒体等等，功能场景之间为平级状态，去除主页和Launcher，改变了传统的中心式星状UI关系架构。

SiloUI***将应用程序的组织细节简化，从而使产品更适合用户操作，功能场景之间可以通过一键切换瞬间保存状态和恢复运行状态。举例说明，用户可以在观看直播电视时一键切换到视频点播继续观看离开前的在线视频，或者一键切换到游戏中心继续游戏。

SiloUI***中各个功能场景的应用程序界面和状态，都一直在后台界面保存和维护，而操作***中应用程序界面和状态的维护需要占用运行内存(RAM，randomaccessmemory)，当开机后进入的Silo比较多时内存占用会比较大。在低配置产品上，运行内存由于市场定位和成本等原因不会太大，后台界面保存状态的应用程序增多时，运行内存会不足，因此，SiloUI***在低内存产品中碰到了如下问题：

问题一：回收内存的操作引起应用程序界面的卡顿和响应缓慢。为了让用户再次打开一个运行过的应用程序能够快速恢复界面，操作***在应用程序界面退出后，仍然会继续保留其占用的内存，而用户使用多个应用程序后***剩余内存会减少，当剩余内存少于一个预设的阈值时***进行内存回收操作，通过应用进程的类型、用户交互程度、使用时长、内存消耗大小等等，计算释放顺序，来逐一杀死应用程序的进程并回收内存。当***剩余内存处于阈值附近时，如果用户继续操作，应用程序界面就有可能因为频繁回收内存发生卡顿。在实验中还能发现，一些重要服务应用程序的进程和个别应用程序，被杀死后仍会自行重启，然后在***运行内存不足再次触发内存回收操作被杀死，该现象多次发生，引发***多次内存回收操作，将严重影响整机的应用程序界面响应速度。

问题二：***回收内存算法不完全适用于SiloUI***，Silo对应的应用程序在后台界面时有可能会被杀死，这将导致用户切换回功能场景时需要重新启动应用程序，不仅丢失了运行状态而且速度缓慢。目前所用的操作***中，对于后台界面类应用程序，使用相同的内存回收优先级数值，而且该优先级分组的应用程序经常被首先杀死以回收内存。

上述问题二的原因是，操作***面向通用产品设计，其假设所有界面类型应用都有同样的优先级，因此未能区分哪些界面类型应用对用户意义更重要，对所有后台界面的应用程序界面都保留了内存，回收算法计算时也没有考虑到这种需求。

目前，对于一般类型的智能产品，业内多家公司在推出低内存配置产品时，都会在***层面进行一些内存方面的优化。减少开机启动应用程序的数量，阻止多余的后台服务进程自行启动，减少后台保存的应用程序界面数量上限，限制后台服务进程的数量上限等等。

举例说明，业内存在的优化策略有：一、每次应用程序界面退到后台界面后，就立即对其进行内存回收操作，二、监听操作***任务栈调度，当任务栈移动到后台界面，并且其应用程序不包含前台界面时对其进行内存回收。这两种策略都是将Android***的内存回收操作进行提前，每当应用程序界面退到后台界面时就立即回收内存，优点是减少了内存占用，也避免了***直到剩余内存达到阈值才进行内存回收，所引发的卡顿和频繁回收等问题，缺点是违背了操作***加快后台界面恢复显示的初衷，当用户再次进入一个曾经打开的应用程序界面时，该界面需要重新加载，不仅速度慢而且之前运行时的状态和数据会丢失，用户体验较差。

针对上述的问题，本发明实施例提供了一种终端设备的内存回收策略，对于终端设备功能场景下的应用程序集合所对应的界面栈，有针对性地设置内存回收策略，具体来说，提前回收切换到后台界面的低恢复概率界面应用程序的内存，降低功能场景的界面栈被内存回收的概率，在保证功能场景的应用程序界面能够快速恢复显示的前提下，减少了内存消耗。下面，通过以下实施例进行详细描述。需要说明的是，本发明实施例中的终端设备可以为电视、机顶盒，当然也可以是智能手机、个人电脑等其他能够实现本发明的设备。

参照图1，示出了本发明的一种终端设备的内存回收方法实施例的步骤流程图，所述终端设备可以设置有一个或多个应用程序集合，所述应用程序集合中的应用程序可以具有对应的界面栈，所述界面栈处于运行状态时配置有相应的内存；

所述的方法具体可以包括如下步骤：

步骤101，当应用程序集合由前台界面切换到后台界面时，记录所述应用程序集合中处于运行状态的界面栈；

在本申请实施例中，终端设备按照功能需求预先配置多个Silo。Silo即功能场景，功能场景下具有对应的应用程序集合，应用程序集合包括了多个应用程序。

每个Silo的应用程序都配置有相应的应用程序界面，当启动该应用程序界面，使其处于运行状态时，会为其分配相应的界面栈，该界面栈分配有相应的内存，启动加载该界面，最后完成应用界面绘制。

在本发明的一种优选实施例中，应用程序包括特例应用程序，根应用程序，顶应用程序和中间应用程序，则对应的界面栈可以称为根界面栈，顶界面栈，特例界面栈和中间界面栈。具体地来说，根界面栈，顶界面栈，特例界面栈和中间界面栈的区分如下所示：

一、根界面栈：每个Silo配置一个根应用程序，该根应用程序具有对应的根应用界面。第一次启动某个Silo时由Silo管理器向操作***请求显示该根应用界面，操作***会启动该Silo的根应用程序的进程，然后为其分配的界面栈称为根界面栈，启动加载该界面，最后完成根应用界面绘制。

二、顶界面栈：在同一个Silo下可以运行多个界面栈，Silo的界面栈按照用户使用顺序划分有对应的运行级别，其中在前台界面中处于最顶部的界面栈为顶界面栈。

三、特例界面栈：有些应用程序为全部Silo下可以使用，例如，设置应用、***界面应用的某些界面，以及和其他整机交互控制界面，这些界面统称为特例界面，其对应的界面栈为特例界面栈。

四、中间界面栈：Silo的根应用界面位于根界面栈中，多个界面跳转生成多个界面栈，在前台界面与用户进行交互的界面位于顶界面栈中，从根界面栈到顶界面栈中运行过的其他界面栈在此称作中间界面栈。

从上述可知，根界面栈和特例界面栈通常是固定的界面栈，而中间界面栈和顶界面栈之间则可以互相置换，当处于前台顶部的界面栈则为顶界面栈。当然，根据不同的终端设备，界面栈的配置转换方式可能有所不同，本发明实施例对此无需加以限制。

本发明的一种优选示例中，在某个Silo由前台界面切换到后台界面时，将开始收集并区分处于运行状态的界面栈，具体来说是指特例界面栈，根界面栈，顶界面栈和中间界面栈，则所述步骤101可以包括如下子步骤：

子步骤S11，采用预置的应用程序集合配置文件确定所述应用程序集合的根界面栈；

并且，所述步骤101还可以包括如下子步骤：

子步骤S12，采用所述运行级别确定在所述应用程序集合中的顶界面栈和特例界面栈；

子步骤S13，记录所述特例界面栈，根界面栈和顶界面栈，以及，记录所述应用程序集合除所述特例界面栈，根界面栈和顶界面栈之外的界面栈记录为中间界面栈。

需要说明的是，上述确定根界面栈、顶界面栈和特例界面栈的步骤，也即是子步骤S11和子步骤S12并无先后之分，且无依存关系，按序编号仅仅是为了文字排版，方便人们阅读。

由于这些步骤并没有时间顺序，所以不可以分先后来写，能够独立进行，且互不影响，它们可以按照终端实际情况，选择异步执行或同时执行均可，本发明实施例对此不加以限制。

当然，在本发明实施例中的某些步骤同样可以采用异步执行或同时执行，本发明实施例对此同样无需加以限制。

在本发明的一种优选实施例中，所述子步骤S12可以包括如下子步骤：

子步骤a11，获取在所述应用程序集合中运行级别最高的界面栈；

子步骤a12，将所述运行级别最高的界面栈确定为待确定顶界面栈；

子步骤a13，采用预置的特例配置文件判断所述待确定顶界面栈是否为特例界面栈；若是，则执行子步骤a14；若否，则执行子步骤a18；

子步骤a14，记录所述待确定顶界面栈为特例界面栈；

子步骤a15，按照所述运行级别查找在所述待确定顶界面栈下一级的界面栈；

子步骤a16，将所述下一级的界面栈作为待确定顶界面栈；

子步骤a17，返回所述采用预置的特例配置文件判断所述待确定顶界面栈是否为特例界面栈的步骤；

子步骤a18，将所述待确定顶界面栈确定为顶界面栈。

步骤102，在所述界面栈中确定待回收的界面栈；

在本发明的一种优选实施例中，所述步骤102的步骤可以为如下子步骤：

子步骤S21，将所述界面栈中的特例界面栈和中间界面栈，确定为待回收的界面栈。

在具体应用中，由于特例界面栈和中间界面栈都是用户不太需要再继续使用的界面栈，故而即使对其回收内存，也不会影响用户的操作体验，故可以视为待回收的界面栈，用以后续的内存回收操作。

步骤103，回收所述待回收的界面栈所配置的内存。

当确定待回收的界面栈后，当完成Silo由前台界面切换到后台界面后，就可以针对待回收的界面栈进行回收内存的操作了。

在本发明的一种优选示例中，Silo可以理解为应用程序运行时的分组，每个Silo中包含有多个应用程序，每组应用程序一般都会有相关的业务联系，例如直播电视、视频点播、游戏中心、应用中心、本地媒体等等。每个Silo会定义一个根应用界面，第一次启动一个Silo实际上就是启动这个根应用界面，而该根应用界面分配有对应的根界面栈，该根界面栈分配有对应的内存。

其中，根应用界面上可以包括子界面或者应用程序界面，子界面上可以进一步包括有应用程序，因此用户可以在根应用界面上操作打开子界面，或者其他应用程序的界面，随后，根应用界面可以添加标志位，告知操作***打开的新界面需要运行在当前的界面栈或者一个新的界面栈，被启动界面的应用程序也可以自行指定该界面在启动时运行在当前界面栈或者新的界面栈中。因此，Silo运行时产生多个界面栈，这些界面可以来自于多个应用程序。

每个Silo都具有对应的应用程序集合。Silo管理***为每个Silo配置一个Silo界面栈集合，记录并管理其中运行的应用程序界面栈。具体如图2所示，Silo的根应用界面位于根界面栈中，多个界面跳转生成多个界面栈，在前台界面与用户进行交互的界面位于顶界面栈中，从根界面栈到顶界面栈中运行过的其他界面栈在此称作中间界面栈。每个Silo必然有根界面栈和顶界面栈。如果Silo只运行了根应用界面，根界面栈和顶界面栈为同一个栈，此时没有中间界面栈。

当用户切换功能场景时，Silo管理器在前台界面中启动转场动画，在后台界面进行新Silo的启动和旧Silo状态的保存。新Silo界面栈集合中的多个界面栈恢复到前台界面或者第一次时直接启动，旧Silo的界面栈集合会被移动到后台界面，需要说明的是，此时移动到后台界面的旧Silo的界面栈集合仍然占用内存。

可以理解，当多个Silo运行后内存中保留的界面栈会非常多，可能会造成***剩余内存紧张。大量测试发现，***剩余内存在阈值附近或低于阈值后，如果用户继续进操作会频繁触发***的内存回收操作，降低界面的响应速度发生卡顿。操作***仅在剩余内存低于阈值时才进行内存回收操作，释放出的少量内存很快被消耗又进行回收，频繁回收操作引发卡顿。这种内存回收方式不完全符合SiloUI***的使用需求。

通过收集分析用户行为和统计界面栈运行记录，可以发现，一个Silo的多个界面栈中，一般用户只会在根应用界面栈和顶应用界面栈上进行使用，中间产生的中间界面栈几乎不会再次进入，这是由SiloUI***的功能特性决定，根界面栈之上的其他界面栈都是由根应用界面启动的，结束使用退回后一般会返回根应用界面栈。因此，用户切换一个Silo后，可以只保留根界面栈和顶界面栈，将中间界面栈占用的内存进行提前回收，释放剩余内存。

具体地，Silo切换时主动释放内存的流程如下：

1)Silo切换开始时，记录前台界面运行状态所有界面栈的信息，根据Silo配置文件中当前Silo根应用界面信息确定根界面栈，根据操作***当前顶部活动界面信息确定顶部界面栈，其他界面栈记为中间界面栈。

2)顶界面栈再次确认。这是由SiloUI***特性决定的特殊操作。有些应用程序为全部Silo下可以使用，例如，设置应用、***界面应用的某些界面，以及和其他整机交互控制界面，这些界面统称为特例界面，其对应的界面栈为特例界面栈。它们不属于任何Silo，在Silo切换回来后将不再恢复显示，而是恢复该Silo运行时其下的下一级界面栈。因此，这些特例界面栈可以安全地进行回收。需要说明的是，Silo中的应用程序运行时，会按照用户使用顺序记录其运行的先后顺序，从而得到Silo运行级别，根据Silo运行级别可以获知运行在顶界面栈的应用程序。

特例界面栈的信息出厂前预置在应用程序中，Silo管理器初始化时进行加载。Silo管理器对比顶界面栈中界面的标识信息，如果为上述特例界面，就逐次向下查找下一级界面栈，直到找到非特例界面栈，将非特例界面栈重新记录为顶部界面栈。

3)确定待回收界面栈列表。中间界面栈和特例界面栈记录到待回收界面栈列表中，此时不直接进行回收操作，而是等到新Silo界面栈完成前台界面移动和显示绘制后再进行，原因如下：当操作***中运行的顶界面栈退出或消失时，操作***会恢复其下的界面栈以保证用户能够继续看到和操作界面，被恢复到前台界面的界面栈会执行一系列生命周期函数完成业务逻辑，有的业务逻辑会触发音视频播放或一些设置操作，造成Silo切换过程的异常。另一方面，Silo切换开始时还会同步触发截图操作，截图用作转场动画，此时切换界面可能会引发截图的混乱。

4)Silo切换，等待新Silo界面栈完成前台界面移动和显示绘制。

5)Silo切换完成后，回收界面栈的内存。对待回收界面栈列表的中界面栈逐个进行移除操作，并调用操作***接口杀死该界面对应的应用程序进程，进程被杀后其占用的内存会立即被释放出来成为可用内存。注意到有些应用程序进程内部有其他重要服务不能被杀死，此类应用程序的信息在Silo管理器软件中预置，仅对其进行界面栈移除操作。

在本发明实施例中，后台界面的各个Silo只会在内存中缓存根界面栈和顶界面栈，当前在前台界面运行的Silo则可以拥有多个中间界面栈，中间界面栈的存在保证了用户最近访问的其他界面可以被快速恢复。

从测试结果上来看，每杀死一个应用程序进程，能够回收内存十几MB到一百多MB不等，则平均每个应用程序的内存约在二十几MB左右。对比未使用此本发明实施例的同样产品，可以明显观察到改进后产品的剩余内存更加充足，***经过较高强度的复杂用户操作后才会触发剩余内存低于***阈值，对比机内存不足出现卡顿现象后，改进的产品仍然流畅运行。

在本发明的一种优选实施例中，所述界面栈可以包括重要服务界面栈，所述步骤103可以包括如下子步骤：

子步骤S31，当所述应用程序集合由前台界面切换到后台界面后，判断所述待回收的界面栈中是否为重要服务界面栈；若是，则执行子步骤S32，若否，则执行子步骤S33；

子步骤S32，不回收所述重要服务界面栈所配置的内存；

子步骤S33，回收所述待回收界面栈所配置的内存。

在本发明的一种优选实施例中，所述界面栈具有对应的回收优先级，所述子步骤S31可以包括如下子步骤：

子步骤a21，判断所述待回收的界面栈对应的回收优先级，是否高于预置回收优先级；若是，则执行子步骤a22；

子步骤a22，将所述高于预置回收优先级的待回收的界面栈确定为重要服务界面栈。

在低内存配置产品中，当用户启动过多Silo并深度使用后，仍然有可能会造成***剩余内存不足的现象，引发操作***回收内存杀死后台应用。为了保证用户在Silo之间切换时，Silo界面能够快速恢复并且保持之前的状态，即使***内存不足也需要尽量保留后台的Silo界面应用进程。每个Silo顶界面应用程序的进程应该比普通应用程序的进程(也即是非Silo应用程序)拥有略高的优先级。

在本发明的一种示例中，操作***进行应用程序的内存回收操作时，先计算一个回收优先级，其根据应用程序的应用组件类型、用户交互程度、是否***核心进程等等因素综合判断，得到对应的回收优先级。

其中，回收优先级按照重要程度从高到低可以分为：***(System)、常驻(Persistent)、前台(Foreground)、可视(Visible)、可感知(Perceptible)、服务(Service)、缓存(Cached)等等。一般的界面类型应用程序退到后台界面时会被分配为“缓存”级别，当内存紧张时会被先行回收。Silo各个界面的应用程序退到后台界面时***一般也会为其分配“缓存”级别。

为了保证Silo切换后界面快速恢复，需要提高Silo顶界面对应的应用程序的进程在后台界面时回收算法中优先级，具体方式如下：

1)在操作***应用程序的进程管理服务中向Silo管理器开放接口，该接口可以修改单个应用程序的进程内存回收算法中的优先级数值。

2)转换Silo后，Silo管理***查询操作***为前一Silo顶界面的应用程序的进程分配的优先级数值。如果该数值低于或等于“服务”级别，则调用上述接口修改为略高级别。实际使用中，为其设置了“可感知”级别，***回收完“缓存”和“服务”级别应用程序的进程后才会回收该级别，被杀死回收的概率很低。如果前一Silo顶界面的应用程序自身为高优先级应用程序，其优先级数值会为“***”或“常驻”，此种情况下不需要干预。当某个Silo界面显示到顶界面栈时，操作***会自动将其优先值数值设置为“前台”，此时可不做干预即可。

综上可知，本发明实施例中对于终端设备的内存回收策略的改进主要从两方面入手：

其一，Silo切换后，主动回收非Silo应用程序占用的内存；

其二，Silo切换时，提高后台的Silo顶界面应用程序在内存回收算法中的优先级，避免重要应用程序被回收。

本发明实施例中，终端设备按照功能需求将应用程序进行分组，则可以得到各个功能场景下相应的应用程序集合，应用程序集合中的应用程序运行时，***为其分配界面栈以及内存，当任意的应用程序集合由前台界面切换到后台界面时，记录该应用程序集合处于运行状态的界面栈，并从中进一步确定待回收的界面栈，最后在应用程序集合成功切换到后台界面后，进行该待回收的界面栈内存的回收。应用本发明实施例，能够按照应用程序集合的切换来释放多余的内存，增加***中剩余内存，减少***回收内存引起的卡顿现象。本发明实施例对于内存较小的低配置产品而言，具有很高的实用性。另外，本发明实施例中针对应用程序集合中的应用程序设置有回收优先级，当确定待回收的界面栈后，会根据其优先级按序进行回收操作，其中，若待回收的界面栈中包括有重要应用程序的重要服务界面栈，则不进行回收操作，从而保证***所需的应用程序切换到后台界面时，不因内存回收被杀。

在本发明的一种优选实施例中，在所述回收待回收的界面栈所配置的内存的步骤之后，也即是步骤103之后，还可以包括如下步骤：

当所述应用程序集合由后台界面再次切换到前台界面时，恢复所述应用程序集合的根界面栈和顶界面栈对应的应用程序界面到前台界面。

在本发明实施例中，当功能场景下的应用程序集合再次由后台界面切换回前台界面时，由于保留了该应用程序集合下根界面栈和顶界面栈所对应的内存，以及，重要应用程序的重要服务界面栈所对应的内存，因此再次切换到前台界面时，这些功能场景下的应用程序界面能够立马恢复在先运行状态，从而加快后台界面恢复显示的速度。

可以理解，这些应用程序的界面栈都不需要重新加载，不仅恢复速度快，而且之前运行时的状态和数据都不会丢失，用户体验比较好。

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

参照图3，示出了本发明的一种终端设备的内存回收装置实施例的结构框图，所述终端设备可以设置有一个或多个应用程序集合，所述应用程序集合中的应用程序可以具有对应的界面栈，所述界面栈处于运行状态时配置有相应的内存；

所述的装置具体可以包括如下模块：

界面栈记录模块201，用于在应用程序集合由前台界面切换到后台界面时，记录所述应用程序集合中处于运行状态的界面栈；

在本发明的一种优选实施例中，所述界面栈可以包括特例界面栈，根界面栈，顶界面栈和中间界面栈，所述应用程序集合的界面栈可以按照运行顺序划分有对应的运行级别，所述界面栈记录模块201可以包括如下子模块：

第一界面栈确定子模块，用于采用预置的应用程序集合配置文件确定所述应用程序集合的根界面栈；

并且，所述界面栈记录模块201可以包括如下子模块：

第二界面栈确定子模块，用于采用所述运行级别确定在所述应用程序集合中的顶界面栈和特例界面栈；

界面栈分类记录子模块，用于记录所述特例界面栈，根界面栈和顶界面栈，以及，记录所述应用程序集合除所述特例界面栈，根界面栈和顶界面栈之外的界面栈记录为中间界面栈。

在本发明的一种优选实施例中，所述第二界面栈确定子模块可以包括如下单元：

最高级别界面栈获取单元，用于获取在所述应用程序集合中运行级别最高的界面栈；

待确定顶界面栈确定单元，用于将所述运行级别最高的界面栈确定为待确定顶界面栈；

特例界面栈判断单元，用于采用预置的特例配置文件判断所述待确定顶界面栈是否为特例界面栈；若是，则调用特例界面栈记录单元，若否，则调用顶界面栈确定单元；

特例界面栈记录单元，用于记录所述待确定顶界面栈为特例界面栈；

下一级界面栈查找单元，用于按照所述运行级别查找在所述待确定顶界面栈下一级的界面栈；

待确定顶界面栈再确定单元，用于将所述下一级的界面栈作为待确定顶界面栈，并调用特例界面栈判断单元；

顶界面栈确定单元，用于将所述待确定顶界面栈确定为顶界面栈。

待回收界面栈确定模块202，用于在所述界面栈中确定待回收的界面栈；

在本发明的一种优选实施例中，所述待回收界面栈确定模块202可以包括如下子模块：

界面栈归类子模块，用于将所述界面栈中的特例界面栈和中间界面栈，确定为待回收的界面栈。

界面栈内存回收模块203，用于回收所述待回收的界面栈所配置的内存。

在本发明的一种优选实施例中，所述界面栈可以包括重要服务界面栈，所述界面栈内存回收模块203可以包括如下子模块：

重要服务界面栈判断子模块，用于当所述应用程序集合由前台界面切换到后台界面后，判断所述待回收的界面栈中是否为重要服务界面栈；若是，则调用内存回收子模块，若否，则调用内存不回收子模块；

内存回收子模块，用于不回收所述重要服务界面栈所配置的内存；

内存不回收子模块，用于回收所述待回收界面栈所配置的内存。

在本发明的一种优选实施例中，所述界面栈具有对应的回收优先级，所述回收优先级高于预置回收优先级的界面栈为重要服务界面栈，所述重要服务界面栈判断子模块可以包括如下单元：

回收优先级判断单元，用于判断所述待回收的界面栈对应的回收优先级，是否高于预置回收优先级；

在本发明的一种优选实施例中，所述的还可以包括如下模块：

应用程序恢复运行模块，用于在所述应用程序集合由后台界面再次切换到前台界面时，恢复所述应用程序集合的根界面栈和顶界面栈对应的应用程序界面到前台界面。

对于装置实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。

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

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

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

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

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

最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者终端设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者终端设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者终端设备中还存在另外的相同要素。

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

Claims (10)

1.一种终端设备的内存回收方法，其特征在于，所述终端设备设置有一个或多个应用程序集合，所述应用程序集合中的应用程序具有对应的界面栈，所述界面栈处于运行状态时配置有相应的内存；

所述的方法包括：

当应用程序集合由前台界面切换到后台界面时，记录所述应用程序集合中处于运行状态的界面栈；

在所述界面栈中确定待回收的界面栈；

回收所述待回收的界面栈所配置的内存。

2.根据权利要求1所述的方法，其特征在于，所述界面栈包括特例界面栈，根界面栈，顶界面栈和中间界面栈，所述应用程序集合的界面栈按照运行顺序划分有对应的运行级别，所述记录应用程序集合中处于运行状态的界面栈的步骤包括：

采用预置的应用程序集合配置文件确定所述应用程序集合的根界面栈；

并且，采用所述运行级别确定在所述应用程序集合中的顶界面栈和特例界面栈；

记录所述特例界面栈，根界面栈和顶界面栈，以及，记录所述应用程序集合除所述特例界面栈，根界面栈和顶界面栈之外的界面栈为中间界面栈。

3.根据权利要求2所述的方法，其特征在于，所述采用运行级别确定在所述应用程序集合中的顶界面栈和特例界面栈的步骤包括：

获取在所述应用程序集合中运行级别最高的界面栈；

将所述运行级别最高的界面栈确定为待确定顶界面栈；

采用预置的特例配置文件判断所述待确定顶界面栈是否为特例界面栈；

若是，则记录所述待确定顶界面栈为特例界面栈；

按照所述运行级别查找在所述待确定顶界面栈下一级的界面栈；

将所述下一级的界面栈作为待确定顶界面栈；

返回所述采用预置的特例配置文件判断所述待确定顶界面栈是否为特例界面栈的步骤；

若否，则将所述待确定顶界面栈确定为顶界面栈。

4.根据权利要求1所述的方法，其特征在于，所述在界面栈中确定待回收的界面栈的步骤为：

将所述界面栈中的特例界面栈和中间界面栈，确定为待回收的界面栈。

5.根据权利要求1或2或3或4所述的方法，其特征在于，所述界面栈包括重要服务界面栈，所述回收待回收的界面栈所配置的内存的步骤包括：

当所述应用程序集合由前台界面切换到后台界面后，判断所述待回收的界面栈中是否为重要服务界面栈；

若是，则不回收所述重要服务界面栈所配置的内存；

若否，则回收所述待回收界面栈所配置的内存。

6.根据权利要求5所述的方法，其特征在于，所述界面栈具有对应的回收优先级，所述判断待回收的界面栈中是否为重要服务界面栈的步骤包括：

判断所述待回收的界面栈对应的回收优先级，是否高于预置回收优先级；

若是，则将所述高于预置回收优先级的待回收的界面栈确定为重要服务界面栈。

7.根据权利要求1或2所述的方法，其特征在于，在所述回收待回收的界面栈所配置的内存的步骤之后，还包括：

当所述应用程序集合由后台界面再次切换到前台界面时，恢复所述应用程序集合的根界面栈和顶界面栈对应的应用程序界面到前台界面。

8.一种终端设备的内存回收装置，其特征在于，所述终端设备设置有一个或多个应用程序集合，所述应用程序集合中的应用程序具有对应的界面栈，所述界面栈处于运行状态时配置有相应的内存；

所述的装置包括：

界面栈记录模块，用于在应用程序集合由前台界面切换到后台界面时，记录所述应用程序集合中处于运行状态的界面栈；

待回收界面栈确定模块，用于在所述界面栈中确定待回收的界面栈；

界面栈内存回收模块，用于回收所述待回收的界面栈所配置的内存。

9.根据权利要求8所述的装置，其特征在于，所述界面栈包括特例界面栈，根界面栈，顶界面栈和中间界面栈，所述应用程序集合的界面栈按照运行顺序划分有对应的运行级别，所述界面栈记录模块包括：

第一界面栈确定子模块，用于采用预置的应用程序集合配置文件确定所述应用程序集合的根界面栈；

并且，所述界面栈记录模块还包括：

第二界面栈确定子模块，用于采用所述运行级别确定在所述应用程序集合中的顶界面栈和特例界面栈；

界面栈分类记录子模块，用于记录所述特例界面栈，根界面栈和顶界面栈，以及，记录所述应用程序集合除所述特例界面栈，根界面栈和顶界面栈之外的界面栈记录为中间界面栈。

10.根据权利要求9所述的装置，其特征在于，所述第二界面栈确定子模块包括：

最高级别界面栈获取单元，用于获取在所述应用程序集合中运行级别最高的界面栈；

待确定顶界面栈确定单元，用于将所述运行级别最高的界面栈确定为待确定顶界面栈；

特例界面栈判断单元，用于采用预置的特例配置文件判断所述待确定顶界面栈是否为特例界面栈；若是，则调用特例界面栈记录单元，若否，则调用顶界面栈确定单元；

特例界面栈记录单元，用于记录所述待确定顶界面栈为特例界面栈；

下一级界面栈查找单元，用于按照所述运行级别查找在所述待确定顶界面栈下一级的界面栈；

待确定顶界面栈再确定单元，用于将所述下一级的界面栈作为待确定顶界面栈，并调用特例界面栈判断单元；

顶界面栈确定单元，用于将所述待确定顶界面栈确定为顶界面栈。