CN104317673B - 应用程序的回收方法、装置及其恢复方法、装置 - Google Patents

Abstract

本发明公开了一种应用程序的回收方法、装置及其恢复方法、装置。其中，该应用程序的回收方法包括：检测当前待回收应用程序中的类成员，当前待回收应用程序为在后台运行的应用程序；判断检测到的当前待回收应用程序中的类成员是否含有注解信息，含有注解信息的类成员为需要回收的类成员；以及如果判断出检测到的当前待回收应用程序中的类成员含有注解信息，则在回收当前待回收应用程序的过程中保存类成员。通过本发明，解决了相关技术在对后台运行的应用程序进行回收/恢复时效率低的问题。

Description

应用程序的回收方法、装置及其恢复方法、装置

技术领域

本发明涉及通信领域，具体而言，涉及一种应用程序的回收方法、装置及其恢复方法、装置。

背景技术

目前，随着移动互联网技术的日益发展，应用程序(Application，简称为APP)的功能也日趋复杂，应用程序所占的内存空间也越来越大。但由于Android设备的内存有限，因此系统在内存不够时会采取回收内存中处于后台运行的应用程序来释放内存空间，并且在用户再次使用该应用程序时对其进行恢复。

应用程序的功能越复杂，在回收/恢复时所涉及到的处理内容就越多，在相关技术中，在对应用程序回收/恢复时，不仅需要保存该应用程序的用户数据，还要保存应用程序中各个用户界面(User interface，简称为UI)的运行状态，有时还需要保存纷繁复杂的自定义类型，因此，需要复杂而冗余的逻辑来实现上述功能。这不仅需要耗费大量的时间成本和人力成本，而且效率低。

针对相关技术在对后台运行的应用程序进行回收/恢复时效率低的问题，目前尚未提出有效的解决方案。

发明内容

本发明的主要目的在于提供一种应用程序的回收方法、装置及其恢复方法、装置，以解决相关技术在对后台运行的应用程序进行回收/恢复时效率低的问题。

为了实现上述目的，根据本发明的一个方面，提供了一种应用程序的回收方法。该方法包括：检测当前待回收应用程序中的类成员，所述当前待回收应用程序为在后台运行的应用程序；判断检测到的所述当前待回收应用程序中的所述类成员是否含有注解信息，含有所述注解信息的类成员为需要回收的类成员；以及如果判断出检测到的所述当前待回收应用程序中的所述类成员含有所述注解信息，则在回收所述当前待回收应用程序的过程中保存所述类成员。

进一步地，在检测当前待回收应用程序中的类成员之前，所述回收方法还包括：检测所述当前待回收应用程序的运行状态是否被切换为后台运行状态，其中，如果检测到所述待回收当前应用程序的运行状态被切换为所述后台运行状态，则检测所述当前待回收应用程序中的所述类成员。

进一步地，在回收所述当前待回收应用程序的过程中保存所述类成员包括：检测所保存的所述类成员的类型；判断检测到的所保存的所述类成员的类型是否为预设类型，所述预设类型包括第一类型、第二类型和第三类型；如果判断出检测到的所保存的所述类成员的类型为所述第一类型，则在回收所述当前待回收应用程序的过程中直接保存所述类成员；和/或如果判断出检测到的所保存的所述类成员的类型为所述第二类型，则在回收所述当前待回收应用程序的过程中保存所述类成员的当前状态值；和/或如果判断出检测到的所保存的所述类成员的类型为所述第三类型，则在回收所述当前待回收应用程序的过程中先对所述类成员执行预处理，得到预处理结果，再保存所述预处理结果。

为了实现上述目的，根据本发明的一个方面，提供了一种应用程序的恢复方法。该方法包括：检测当前待恢复应用程序中的类成员，所述当前待恢复应用程序为已经被回收的应用程序；判断检测到的所述当前待恢复应用程序中的所述类成员是否含有注解信息，含有所述注解信息的类成员为需要恢复的类成员；以及如果判断出检测到的所述当前待恢复应用程序中的所述类成员含有所述注解信息，则在恢复所述当前待恢复应用程序的过程中恢复所述类成员。

进一步地，在检测当前待恢复应用程序中的类成员之前，所述恢复方法还包括：检测所述当前待恢复应用程序的运行状态是否被切换为前台运行状态，其中，如果检测到所述待恢复当前应用程序的运行状态被切换为所述前台运行状态，则检测所述当前待恢复应用程序中的所述类成员。

进一步地，在恢复所述当前待恢复应用程序的过程中恢复所述类成员包括：检测所保存的所述类成员的类型；判断检测到的所保存的所述类成员的类型是否为预设类型，所述预设类型包括第一类型、第二类型和第三类型；如果判断出检测到的所保存的所述类成员的类型为所述第一类型，则在恢复所述当前待恢复应用程序的过程中直接恢复所述类成员；和/或如果判断出检测到的所保存的所述类成员的类型为所述第二类型，则在恢复所述当前待恢复应用程序的过程中恢复所述类成员的当前状态值；和/或如果判断出检测到的所保存的所述类成员的类型为所述第三类型，则在恢复所述当前待恢复应用程序的过程中先获取所述类成员的预处理结果，再根据所述预处理结果恢复所述类成员。

为了实现上述目的，根据本发明的另一方面，提供了一种应用程序的回收装置。该装置包括：第一检测单元，用于检测当前待回收应用程序中的类成员，所述当前待回收应用程序为在后台运行的应用程序；第一判断单元，用于判断检测到的所述当前待回收应用程序中的所述类成员是否含有注解信息，含有所述注解信息的类成员为需要回收的类成员；以及保存单元，用于在判断出检测到的所述当前待回收应用程序中的所述类成员含有所述注解信息时，在回收所述当前待回收应用程序的过程中保存所述类成员。

进一步地，所述回收装置还包括：第二检测单元，用于在检测当前待回收应用程序中的类成员之前，检测所述当前待回收应用程序的运行状态是否被切换为后台运行状态，其中，所述第一检测单元还用于在检测到所述待回收当前应用程序的运行状态被切换为所述后台运行状态时，检测所述当前待回收应用程序中的所述类成员。

进一步地，所述保存单元包括：第一检测模块，用于检测所保存的所述类成员的类型；第一判断模块，用于判断检测到的所保存的所述类成员的类型是否为预设类型，所述预设类型包括第一类型、第二类型和第三类型；第一保存模块，用于在判断出检测到的所保存的所述类成员的类型为所述第一类型时，在回收所述当前待回收应用程序的过程中直接保存所述类成员；和/或第二保存模块，用于在判断出检测到的所保存的所述类成员的类型为所述第二类型时，在回收所述当前待回收应用程序的过程中保存所述类成员的当前状态值；和/或第三保存模块，用于在判断出检测到的所保存的所述类成员的类型为所述第三类型时，在回收所述当前待回收应用程序的过程中先对所述类成员执行预处理，得到预处理结果，再保存所述预处理结果。

为了实现上述目的，根据本发明的另一方面，提供了一种应用程序的恢复方法装置。该装置包括：第三检测单元，用于检测当前待恢复应用程序中的类成员，所述当前待恢复应用程序为已经被回收的应用程序；第二判断单元，用于判断检测到的所述当前待恢复应用程序中的所述类成员是否含有注解信息，含有所述注解信息的类成员为需要恢复的类成员；以及恢复单元，用于在判断出检测到的所述当前待恢复应用程序中的所述类成员含有所述注解信息时，在恢复所述当前待恢复应用程序的过程中恢复所述类成员。

进一步地，所述恢复装置还包括：第四检测单元，用于在检测当前待恢复应用程序中的类成员之前，检测所述当前待恢复应用程序的运行状态是否被切换为前台运行状态，其中，所述第三检测单元还用于在检测到所述待恢复当前应用程序的运行状态被切换为所述前台运行状态时，检测所述当前待恢复应用程序中的所述类成员。

进一步地，所述恢复单元包括：第二检测模块，用于检测所保存的所述类成员的类型；第二判断模块，用于判断检测到的所保存的所述类成员的类型是否为预设类型，所述预设类型包括第一类型、第二类型和第三类型；第一恢复模块，用于在判断出检测到的所保存的所述类成员的类型为所述第一类型时，在恢复所述当前待恢复应用程序的过程中直接恢复所述类成员；和/或第二恢复模块，用于在判断出检测到的所保存的所述类成员的类型为所述第二类型时，在恢复所述当前待恢复应用程序的过程中恢复所述类成员的当前状态值；和/或第三恢复模块，用于在判断出检测到的所保存的所述类成员的类型为所述第三类型时，在恢复所述当前待恢复应用程序的过程中先获取所述类成员的预处理结果，再根据所述预处理结果恢复所述类成员。

通过本发明，采用检测当前待回收应用程序中的类成员，当前待回收应用程序为在后台运行的应用程序；判断检测到的当前待回收应用程序中的类成员是否含有注解信息，含有注解信息的类成员为需要回收的类成员；以及如果判断出检测到的当前待回收应用程序中的类成员含有注解信息，则在回收当前待回收应用程序的过程中保存类成员，解决了相关技术在对后台运行的应用程序进行回收/恢复时效率低的问题，进而达到了提高应用程序的回收/恢复效率的效果。

附图说明

构成本申请的一部分的附图用来提供对本发明的进一步理解，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：

图1是根据本发明实施例的应用程序的回收方法的流程图；

图2是根据本发明实施例的应用程序的恢复方法的流程图；

图3是根据本发明实施例的应用程序的回收装置的示意图；以及

图4是根据本发明实施例的应用程序的恢复装置的示意图。

具体实施方式

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

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

需要说明的是，本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本发明的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含。

需要说明的是，本发明可以应用于Android系统设备，以下以对Android系统的应用程序进行回收和恢复为例详细阐述本发明。

实施例1

根据本发明的实施例，提供了一种应用程序的回收方法，该应用程序的回收方法用于基于应用程序中类成员的注解信息对后台运行的应用程序进行回收，以提高应用程序的回收效率，并避免了由于需要编辑大量的用于回收应用程序的逻辑代码而降低编程人员的工作效率的弊端。

图1是根据本发明实施例的应用程序的回收方法的流程图。如图1所示，该应用程序的回收方法包括步骤S102至步骤S106：

步骤S102：检测当前待回收应用程序中的类成员。

其中，当前待回收应用程序为在后台运行的应用程序。进一步地，在后台运行的应用程序可以包括：正在后台运行的应用程序和正由前台运行状态转换为后台运行的应用程序。在后台运行的应用程序可以是系统在执行前台运行的应用程序时，暂时不用但需要放在后台运行的应用程序。对于后台运行的应用程序需要保存该应用程序的相关数据(如，用户数据和各个界面的运行状态)，当需要将后台运行的应用程序切换至前台运行时，由于之前保存了后台运行的应用程序的相关数据，因此无需重新加载之前加载过的数据，提高了打开后台运行的应用程序的速度。

需要说明的是，在程序运行时，可以在当前待回收应用程序由前台运行状态转换为后台运行状态时，系统触发回收应用程序的过程；或者，在内存不足时，系统才触发回收应用程序的过程。

具体地，在检测当前待回收应用程序中的类成员时，可以对当前待回收应用程序中所有的类成员进行检测，或者，可以仅仅对当前待回收应用程序中处于当前界面上的所有的类成员进行检测。优选地，可以只检测后者中的类成员，这样，可以减轻系统的负担，提高系统的检测效率。

需要说明的是，在第一次检测当前待回收应用程序中的类成员之后，可以缓存检测到的每一个类成员，这样，在下次使用时，可以直接从缓存中读出相应的类成员，从而可以避免再次检测所消耗的花销。

步骤S104：判断检测到的当前待回收应用程序中的类成员是否含有注解信息。

需要说明的是，为了节省用于回收应用程序的代码，防止代码冗余，在编程时，可以对应用程序中各个类成员进行预处理。例如，可以预先设定回收应用程序时需要保存的类成员和不需要保存的类成员，为了区别不同属性的类成员，可以采用如下可选的预处理方式：方式一，回收时，对需要保存的类成员标注注解信息，也即，含有注解信息的类成员为需要回收的类成员，而对不需要保存的类成员不做任何处理；方式二，回收时，对需要保存的类成员标注第一注解信息，而对不需要保存的类成员标注第二注解信息。优选地，可以采用方式一中的预处理方式，这样，可以更有效的节省用于回收应用程序的代码，防止代码冗余。并且，在回收含有注解信息的类成员时，可以释放内存空间，防止系统的内存空间不足，加快前台运行程序的运行速度。

需要说明的是，所谓注解，也即元数据，它是一种代码级别的说明，它可以声明在包、类、字段、方法、局部变量、方法参数等的前面，用来对这些元素进行说明、注释。注解可以是以“@注解名(参数1，参数2，参数3......)”的形式在程序代码中存在的，它们不会直接影响到程序的语义，只是作为注解(标识)存在。注解可以生成文档，可以跟踪代码，实现替代配置文件功能。在编译时，注解可以进行格式检查。

步骤S106：如果判断出检测到的当前待回收应用程序中的类成员含有注解信息，则在回收当前待回收应用程序的过程中保存类成员。

具体地，可以将含有注解信息的类成员保存至实例中。该实例即为存储空间，例如，其可以是用于存储类成员的容器。需要说明的是，由于任何一个待回收应用程序都可以包括一个或者多个类成员，所有类成员的集合用于描述待回收应用程序的全部功能。每个类成员都可以用于将相应的数据和操作封装在一个集合体里，并且可以在类成员的类体变量部分中声明变量以描述对象状态。

另外，对于任一应用程序而言，其可以包括一种或者多种类型的类成员，这样，在保存类成员时，可以对不同类型的类成员执行不同的保存处理。

例如，在Android系统中，假设用户当前正在执行的应用程序为应用程序A，如果用户需要暂时由应用程序A切换至其他应用程序，则系统会将应用程序A设置为后台运行方式，此时，Android系统会对应用程序A进行如下操作：保存应用程序A中的数据，待到系统内存不足时，逐个回收未被使用的APP，直到内存足够。优选地，在逐个回收未被使用的APP时，可以首先回收最久未被使用的APP。并且在上述过程中，需要保存应用程序A中含有注解信息的类成员(如，用户数据和用户界面的运行状态)。这样，可以避免应用程序A中用户数据和用户界面的运行状态丢失，并且在用户再次切换至应用程序A时，可以直接得到之前的用户数据和各用户界面的运行状态，无需重新加载之前加载过的数据，达到了加快恢复后台运行的应用程序的效果。

需要说明的是，在APP由前台运行状态切换至后台运行状态时，可以触发本发明的应用程序的回收方法运行，从而自动保存各个类成员，例如，在保存各个类成员时，可以保存各个成员变量，并将各个成员变量的值包装起来存入存储空间中，从而达到自动保存状态的功能。

通过本发明实施例，采用检测当前待回收应用程序中的类成员；判断检测到的当前待回收应用程序中的类成员是否含有注解信息；以及如果判断出检测到的当前待回收应用程序中的类成员含有注解信息，则在回收当前待回收应用程序的过程中保存类成员，达到了提高应用程序的回收效率的效果，实现了快速保存现场状态的目的。

另外，由于本发明封装了回收时处理状态的功能，省去了重复编写回收功能的处理逻辑。在程序开发中，开发人员只需要熟悉一下简单的使用方法就可以马上配置好需要回收的数据，而不用去关心如何编写怎么保存、怎么恢复的功能，将开发人员从琐碎的重复劳动中解放出来，不仅节省了时间成本，而且节约了人力成本，达到了提高生产效率的效果。

优选地，在本发明实施例中，前述的在检测当前待回收应用程序中的类成员之前，该回收方法还可以包括：检测当前待回收应用程序的运行状态是否被切换为后台运行状态，其中，如果检测到待回收当前应用程序的运行状态被切换为所述后台运行状态，则检测当前待回收应用程序中的类成员。

通过本发明实施例，由于在应用程序由前台运行状态切换至后台运行状态的时间点就触发本发明的应用程序的回收方法的执行，达到了及时回收应用程序的效果，并且由于可以及时回收应用程序，达到了及时释放该应用程序所占用的内存空间的效果。

优选地，在本发明实施例中，前述的在回收当前待回收应用程序的过程中保存类成员可以包括：检测所保存的类成员的类型；判断检测到的所保存的类成员的类型是否为预设类型，预设类型包括第一类型、第二类型和第三类型；如果判断出检测到的所保存的类成员的类型为第一类型，则在回收当前待回收应用程序的过程中直接保存类成员；和/或，如果判断出检测到的所保存的类成员的类型为第二类型，则在回收当前待回收应用程序的过程中保存类成员的当前状态值；和/或，如果判断出检测到的所保存的类成员的类型为第三类型，则在回收当前待回收应用程序的过程中先对类成员执行预处理，得到预处理结果，再保存预处理结果。

其中，第一类型可以为基础类型和/或普通类型(Plain Old Java Object，简称为POJO)，其中，基础类型为不可以分解的最小单位的类型，普通类型为基础类型的简单组合。在回收时，可以直接将属于这些类型的类成员保存至存储空间中，其中，对于普通类型，可以使用序列化/反序列化来整体存储它本身。第二类型可以为复杂的用户界面类型，例如，复杂的UI可以是列表类型的UI或者图片组合的UI，在回收时，可以仅仅保存属于第二类型的类成员的关键信息，即，保存属于第二类型的类成员的当前状态值。第三类型可以为用户自定义的类型，在回收时，可以先对属于第三类型的类成员执行预处理，得到预处理结果，再保存预处理结果。例如，可以对第三类型的类成员按照预先规定的序列化/反序列化方式进行预处理，并将序列化/反序列化结果保存至保存实例中。其中，序列化/反序列化为：将对象转换为字节序列的过程称为对象的序列化，将字节序列恢复对象的过程称为对象的反序列化。

需要说明的是，前述的用户自定义的类型可以包含：基础类型和普通类型，其中，基础类型可以直接存储，普通类型可以使用序列化/反序列化存储。此外，用户自定义的类型还可以包含用户自定义的类型，也即，其可以是和本身不同的类型，也可以是和本身同样的类型。自定义类型还可以包含有自身特有的逻辑代码。该逻辑代码固化在APP内部，不会消失，而且永远存在。对于该类型，可以按照递归的方式来回收，例如，当扫描到这个复杂类型时，会逐个扫描它所包含的数据，如果发现了复杂类型就还会递归的扫描这个复杂类型。

进一步地，在保存第二类型和第三类型的类成员时，可以先将这些类成员存储在一个包装类中，再将该包装类作为一个整体存储在保存实例中。具体地，在实际回收应用程序时，虽然前述的3种类型的类成员都可以保存至同一保存实例中，但是针对不同类型的类成员，可以执行不同的存储方式。

实施例2

根据本发明的实施例，提供了一种应用程序的恢复方法，该应用程序的恢复方法用于基于应用程序中类成员的注解信息对已经回收的后台运行的应用程序进行恢复，以提高应用程序的回收/恢复效率，并避免了由于需要编辑大量的用于回收/恢复应用程序的逻辑代码而降低编程人员的工作效率的弊端。

图2是根据本发明实施例的应用程序的恢复方法的流程图。如图2所示，该应用程序的恢复方法包括步骤S202至步骤S206：

步骤S202：检测当前待恢复应用程序中的类成员。

其中，当前待恢复应用程序为已经被回收的应用程序。进一步地，在后台运行的应用程序可以包括：正在后台运行的应用程序和正由前台运行状态转换为后台运行的应用程序。在后台运行的应用程序可以是系统在执行前台运行的应用程序时，暂时不用但需要放在后台运行的应用程序。后台运行的应用程序需要保存该应用程序的相关数据(如，用户数据和各个界面的运行状态)，当需要将后台运行的应用程序切换至前台运行时，也即，需要恢复该已经回收过的应用程序时，由于之前保存了后台运行的应用程序的相关数据，因此无需重新加载之前加载过的数据，提高了恢复后台运行的应用程序的速度。

具体地，在检测当前待恢复应用程序中的类成员时，可以对当前待恢复应用程序中所有的类成员进行检测，或者，可以仅仅对当前待恢复应用程序中处于切换时刻的用户界面上的所有的类成员进行检测。优选地，可以只检测后者中的类成员，这样，可以减轻系统的负担，提高系统的检测效率。

需要说明的是，在第一次检测当前待回收应用程序中的类成员之后，可以缓存检测到的每一个类成员，这样，在下次使用时，可以直接从缓存中读出相应的类成员，从而可以避免再次检测所消耗的花销。

步骤S204：判断检测到的当前待恢复应用程序中的类成员是否含有注解信息，含有注解信息的类成员为需要恢复的类成员。

需要说明的是，为了节省用于恢复应用程序的代码，防止代码冗余，在编程时，可以对应用程序中各个类成员进行预处理。例如，可以预先设定恢复应用程序时需要恢复的类成员和不需要恢复的类成员，为了区别不同属性的类成员，可以采用如下可选的预处理方式：方式一，恢复时，对需要恢复的类成员标注注解信息，也即，含有注解信息的类成员为需要恢复的类成员，而对不需要恢复的类成员不做任何处理；方式二，恢复时，对需要恢复的类成员标注第一注解信息，而对不需要恢复的类成员标注第二注解信息。优选地，可以采用方式一中的预处理方式，这样，可以更有效的节省用于恢复应用程序的代码，防止代码冗余。并且，在恢复含有注解信息的类成员时，可以完全恢复应用程序被切换为后台运行状态时刻之前该应用程序的所有现场状态，防止由于应用程序恢复不完全而给用户带来不便。

需要说明的是，所谓注解，也即元数据，它是一种代码级别的说明，它可以声明在包、类、字段、方法、局部变量、方法参数等的前面，用来对这些元素进行说明、注释。注解是以“@注解名(参数1，参数2，参数3......)”的形式在程序代码中存在的，它们不会直接影响到程序的语义，只是作为注解(标识)存在。注解可以生成文档，可以跟踪代码，实现替代配置文件功能。在编译时，注解可以进行格式检查。

步骤S206：如果判断出检测到的当前待恢复应用程序中的类成员含有注解信息，则在恢复当前待恢复应用程序的过程中恢复类成员。

具体地，可以将含有注解信息的类成员从保存实例中恢复出来。该保存实例即为存储空间，例如，其可以是用于存储类成员的容器。需要说明的是，由于任何一个待恢复应用程序都可以包括一个或者多个类成员，所有类成员的集合用于描述待恢复应用程序的全部功能。每个类成员都可以用于将相应的数据和操作封装在一个集合体里，并且可以在类成员的类体变量部分中声明变量以描述对象状态。

另外，对于任一应用程序而言，其可以包括一种或者多种类型的类成员，这样，在恢复类成员时，可以对不同类型的类成员执行不同的恢复处理。

例如，在Android系统中，假设用户当前正在执行的应用程序为应用程序A，如果用户需要由前台运行的其他应用程序切换至应经回收了的在后台运行的应用程序A，则系统会将应用程序A设置为前台运行方式，并将其他应用程序设置为后台运行的应用程序，此时，Android系统会对应用程序A进行恢复，并且在恢复过程中，需要恢复应用程序A中含有注解信息的类成员(如，用户数据和用户界面的运行状态)。这样，可以避免应用程序A中用户数据和用户界面的运行状态无法恢复，并且可以直接恢复出之前回收过的用户数据和各用户界面的运行状态，无需重新加载之前加载过的数据，达到了加快恢复后台运行的应用程序的现场的效果。

需要说明的是，在APP由后台运行状态切换至前台运行状态时，可以触发本发明的应用程序的恢复方法运行，从而自动恢复各个类成员，例如，在恢复各个类成员时，可以恢复各个成员变量，并给各个成员变量进行赋值，具体地，可以将会收时保存的值一一取出赋值给相应的类成员，从而达到自动恢复状态的功能。

通过本发明实施例，采用检测当前待恢复应用程序中的类成员；判断检测到的当前待恢复应用程序中的类成员是否含有注解信息；以及如果判断出检测到的当前待恢复应用程序中的类成员含有注解信息，则在恢复当前待恢复应用程序的过程中恢复类成员，达到了提高应用程序的恢复效率的效果，实现了快速恢复现场状态的目的。

另外，由于本发明封装了恢复时处理状态的功能，省去了重复编写恢复功能的处理逻辑。在程序开发中，开发人员只需要熟悉一下简单的使用方法就可以马上配置好需要恢复的数据，而不用去关心如何编写怎么保存、怎么恢复的功能，将开发人员从琐碎的重复劳动中解放出来，不仅节省了时间成本，而且节约了人力成本，达到了提高生产效率的效果。

优选地，在本发明实施例中，前述的在检测当前待恢复应用程序中的类成员之前，该恢复方法还包括：检测当前待恢复应用程序的运行状态是否被切换为前台运行状态，其中，如果检测到待恢复当前应用程序的运行状态被切换为所述前台运行状态，则检测当前待恢复应用程序中的类成员。

通过本发明实施例，由于在应用程序由后台运行状态切换至前台运行状态的时间点才触发本发明的应用程序的恢复方法的执行，达到了准时回收应用程序的效果，并且由于可以准时恢复应用程序，达到了提高恢复应用程序的恢复时机的准确性的效果。

优选地，在本发明实施例中，前述的在恢复当前待恢复应用程序的过程中保存类成员可以包括：检测所保存的类成员的类型；判断检测到的所保存的类成员的类型是否为预设类型，预设类型包括第一类型、第二类型和第三类型；如果判断出检测到的所保存的类成员的类型为第一类型，则在恢复当前待恢复应用程序的过程中直接恢复类成员；和/或，如果判断出检测到的所保存的类成员的类型为第二类型，则在恢复当前待恢复应用程序的过程中恢复类成员的当前状态值；和/或，如果判断出检测到的所保存的类成员的类型为第三类型，则在恢复当前待恢复应用程序的过程中先获取类成员的预处理结果，再根据预处理结果恢复类成员。

其中，第一类型可以为基础类型和/或普通类型(Plain Old Java Object，简称为POJO)，其中，基础类型为不可以分解的最小单位的类型，普通类型为基础类型的简单组合，因此，在恢复时，可以直接将属于这些类型的类成员从保存实例中恢复出来。第二类型可以为复杂的用户界面(User interface，简称为UI)类型，例如，复杂的UI可以是列表类型的UI或者图片组合的UI，在恢复时，可以仅仅恢复属于第二类型的类成员的关键信息，即，恢复属于第二类型的类成员的当前状态值。第三类型可以为用户自定义的类型，在恢复时，可以先对属于第三类型的类成员执行预处理，得到预处理结果，再恢复预处理结果。例如，可以对第三类型的类成员按照预先规定的序列化/反序列化方式进行预处理，并将序列化/反序列化结果恢复出来。其中，序列化/反序列化为：将对象转换为字节序列的过程称为对象的序列化，将字节序列恢复对象的过程称为对象的反序列化。

进一步地，在恢复第二类型和第三类型的类成员时，可以先将这些类成员从一个包装类中恢复出来，再将该包装类作为一个整体从保存实例中恢复出来。具体地，在实际恢复应用程序时，可以对前述的3种类型的类成员执行不同的恢复方式。

需要说明的是，在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行，并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

实施例3

根据本发明的实施例，提供了一种应用程序的回收装置，该应用程序的回收装置用于基于应用程序中类成员的注解信息对后台运行的应用程序进行回收，以提高应用程序的回收效率，并避免了由于需要编辑大量的用于回收应用程序的逻辑代码而降低编程人员的工作效率的弊端。该应用程序的回收方法可以运行在计算机处理设备上。需要说明的是，本发明实施例所提供的应用程序的回收方法可以通过本发明实施例的应用程序的回收装置来执行，本发明实施例的应用程序的回收装置也可以用于执行本发明实施例的应用程序的回收方法。

图3是根据本发明实施例的应用程序的回收装置的流程图。如图3所示，该应用程序的回收装置包括：第一检测单元302、第一判断单元304和保存单元306。

第一检测单元302用于检测当前待回收应用程序中的类成员。当前待回收应用程序为在后台运行的应用程序。

其中，当前待回收应用程序为在后台运行的应用程序。进一步地，在后台运行的应用程序可以包括：正在后台运行的应用程序和正由前台运行状态转换为后台运行的应用程序。在后台运行的应用程序可以是系统在执行前台运行的应用程序时，暂时不用但需要放在后台运行的应用程序。后台运行的应用程序需要保存该应用程序的相关数据(如，用户数据和各个界面的运行状态)，当需要将后台运行的应用程序切换至前台运行时，由于之前保存了后台运行的应用程序的相关数据，因此无需重新加载之前加载过的数据，提高了打开后台运行的应用程序的速度。

需要说明的是，在程序运行时，可以在当前待回收应用程序由前台运行状态转换为后台运行状态时，系统触发回收应用程序的过程；或者，在内存不足时，系统才触发回收应用程序的过程。

具体地，在检测当前待回收应用程序中的类成员时，可以对当前待回收应用程序中所有的类成员进行检测，或者，可以仅仅对当前待回收应用程序中处于当前界面上的所有的类成员进行检测。优选地，可以只检测后者中的类成员，这样，可以减轻系统的负担，提高系统的检测效率。

需要说明的是，在第一次检测当前待回收应用程序中的类成员之后，可以缓存检测到的每一个类成员，这样，在下次使用时，可以直接从缓存中读出相应的类成员，从而可以避免再次检测所消耗的花销。

第一判断单元304用于判断检测到的当前待回收应用程序中的类成员是否含有注解信息，含有注解信息的类成员为需要回收的类成员。

需要说明的是，为了节省用于回收应用程序的代码，防止代码冗余，在编程时，可以对应用程序中各个类成员进行预处理。例如，可以预先设定回收应用程序时需要保存的类成员和不需要保存的类成员，为了区别不同属性的类成员，可以采用如下可选的预处理方式：方式一，回收时，对需要保存的类成员标注注解信息，也即，含有注解信息的类成员为需要回收的类成员，而对不需要保存的类成员不做任何处理；方式二，回收时，对需要保存的类成员标注第一注解信息，而对不需要保存的类成员标注第二注解信息。优选地，可以采用方式一中的预处理方式，这样，可以更有效的节省用于回收应用程序的代码，防止代码冗余。并且，在回收含有注解信息的类成员时，可以释放内存空间，防止系统的内存空间不足，加快前台运行程序的运行速度。

需要说明的是，所谓注解，也即元数据，它是一种代码级别的说明，它可以声明在包、类、字段、方法、局部变量、方法参数等的前面，用来对这些元素进行说明、注释。注解是以“@注解名(参数1，参数2，参数3......)”的形式在程序代码中存在的，它们不会直接影响到程序的语义，只是作为注解(标识)存在。注解可以生成文档，可以跟踪代码，实现替代配置文件功能。在编译时，注解可以进行格式检查。

保存单元306用于在判断出检测到的当前待回收应用程序中的类成员含有注解信息时，在回收当前待回收应用程序的过程中保存类成员。

具体地，可以将含有注解信息的类成员保存至实例中。该实例即为存储空间，例如，其可以是用于存储类成员的容器。需要说明的是，由于任何一个待回收应用程序都可以包括一个或者多个类成员，所有类成员的集合用于描述待回收应用程序的全部功能。每个类成员都可以用于将相应的数据和操作封装在一个集合体里，并且可以在类成员的类体变量部分中声明变量以描述对象状态。

另外，对于任一应用程序而言，其可以包括一种或者多种类型的类成员，这样，在保存类成员时，可以对不同类型的类成员执行不同的保存处理。

例如，在Android系统中，假设用户当前正在执行的应用程序为应用程序A，如果用户需要暂时由应用程序A切换至其他应用程序，则系统会将应用程序A设置为后台运行方式，此时，Android系统会对应用程序A进行如下操作：保存应用程序A中的数据，待到系统内存不足时，逐个回收未被使用的APP，直到内存足够。优选地，在逐个回收未被使用的APP时，可以首先回收最久未被使用的APP。并且在回收过程中，需要保存应用程序A中含有注解信息的类成员(如，用户数据和用户界面的运行状态)。这样，可以避免应用程序A中用户数据和用户界面的运行状态丢失，并且在用户再次切换至应用程序A时，可以直接得到之前的用户数据和各用户界面的运行状态，无需重新加载之前加载过的数据，达到了加快恢复后台运行的应用程序的效果。

需要说明的是，在APP由前台运行状态切换至后台运行状态时，可以触发本发明的应用程序的回收方法运行，从而自动保存各个类成员，例如，在保存各个类成员时，可以保存各个成员变量，并将各个成员变量的值包装起来存入存储空间中，从而达到自动保存状态的功能。

通过本发明实施例，达到了提高应用程序的回收效率的效果，实现了快速保存现场状态的目的。

另外，由于本发明封装了回收时处理状态的功能，省去了重复编写回收功能的处理逻辑。在程序开发中，开发人员只需要熟悉一下简单的使用方法就可以马上配置好需要回收的数据，而不用去关心如何编写怎么保存、怎么恢复的功能，将开发人员从琐碎的重复劳动中解放出来，不仅节省了时间成本，而且节约了人力成本，达到了提高生产效率的效果。

优选地，在本发明实施例中，在第一检测单元之前，前述回收装置还可以包括：第二检测单元。第二检测单元用于在检测当前待回收应用程序中的类成员之前，检测当前待回收应用程序的运行状态是否被切换为后台运行状态，其中，第一检测单元还用于在检测到待回收当前应用程序的运行状态被切换为后台运行状态时，检测当前待回收应用程序中的类成员。

通过本发明实施例，由于在应用程序由前台运行状态切换至后台运行状态的时间点就触发本发明的应用程序的回收方法的执行，达到了及时回收应用程序的效果，并且由于可以及时回收应用程序，达到了及时释放该应用程序所占用的内存空间的效果。

优选地，在本发明实施例中，前述保存单元还可以包括：第一检测模块、第一判断模块、第一保存模块和/或第二保存模块和/或第三保存模块。第一检测模块用于检测所保存的类成员的类型；第一判断模块用于判断检测到的所保存的类成员的类型是否为预设类型，预设类型包括第一类型、第二类型和第三类型；第一保存模块用于在判断出检测到的所保存的类成员的类型为第一类型时，其中，在回收当前待回收应用程序的过程中，直接保存类成员；第二保存模块用于在判断出检测到的所保存的类成员的类型为第二类型时，其中，在回收当前待回收应用程序的过程中，保存类成员的当前状态值；第三保存模块用于在判断出检测到的所保存的类成员的类型为第三类型时，其中在回收当前待回收应用程序的过程中，先对类成员执行预处理，得到预处理结果，再保存预处理结果。

其中，第一类型可以为基础类型和/或普通类型，其中，基础类型为不可以分解的最小单位的类型，普通类型为基础类型的简单组合，因此，在回收时，可以直接将属于这些类型的类成员保存至存储空间中，其中，对于普通类型，可以使用序列化/反序列化来整体存储它本身。第二类型可以为复杂的用户界面类型，例如，复杂的UI可以是列表类型的UI或者图片组合的UI，在回收时，可以仅仅保存属于第二类型的类成员的关键信息，即，保存属于第二类型的类成员的当前状态值。第三类型可以为用户自定义的类型，在回收时，可以先对属于第三类型的类成员执行预处理，得到预处理结果，再保存预处理结果。例如，可以对第三类型的类成员按照预先规定的序列化/反序列化方式进行预处理，并将序列化/反序列化结果保存至保存实例中。其中，序列化/反序列化为：将对象转换为字节序列的过程称为对象的序列化，将字节序列恢复对象的过程称为对象的反序列化。

需要说明的是，前述的用户自定义的类型可以包含：基础类型和普通类型，其中，基础类型可以直接存储，普通类型可以使用序列化/反序列化存储。此外，用户自定义的类型还可以包含用户自定义的类型，也即，其可以是和本身不同的类型，也可以是和本身同样的类型。自定义类型还可以包含有自身特有的逻辑代码。该逻辑代码固化在APP内部，不会消失，而且永远存在。对于该类型，可以按照递归的方式来回收，例如，当扫描到这个复杂类型时，会逐个扫描它所包含的数据，如果发现了复杂类型就还会递归的扫描这个复杂类型。

进一步地，在保存第二类型和第三类型的类成员时，可以先将这些类成员存储在一个包装类中，再将该包装类作为一个整体存储在保存实例中。具体地，在实际回收应用程序时，虽然前述的3种类型的类成员都可以保存至同一保存实例中，但是针对不同类型的类成员，可以执行不同的存储方式。

实施例4

根据本发明的实施例，提供了一种应用程序的恢复装置，该应用程序的恢复装置用于基于应用程序中类成员的注解信息对已经回收的应用程序进行恢复，以提高应用程序的回收效率，并避免了由于需要编辑大量的用于恢复应用程序的逻辑代码而降低编程人员的工作效率的弊端。该应用程序的恢复方法可以运行在计算机处理设备上。需要说明的是，本发明实施例所提供的应用程序的恢复方法可以通过本发明实施例的应用程序的恢复装置来执行，本发明实施例的应用程序的恢复装置也可以用于执行本发明实施例的应用程序的恢复方法。

图4是根据本发明实施例的应用程序的恢复装置的流程图。如图4所示，该应用程序的恢复装置包括：第三检测单元402、第二判断单元404和恢复单元406。

第三检测单元402用于检测当前待恢复应用程序中的类成员。

其中，当前待恢复应用程序为已经被回收的应用程序。进一步地，在后台运行的应用程序可以包括：正在后台运行的应用程序和正由前台运行状态转换为后台运行的应用程序。在后台运行的应用程序可以是系统在执行前台运行的应用程序时，暂时不用但需要放在后台运行的应用程序。后台运行的应用程序需要保存该应用程序的相关数据(如，用户数据和各个界面的运行状态)，当需要将后台运行的应用程序切换至前台运行时，也即，需要恢复该已经回收过的应用程序时，由于之前保存了后台运行的应用程序的相关数据，因此无需重新加载之前加载过的数据，提高了恢复后台运行的应用程序的速度。

具体地，在检测当前待恢复应用程序中的类成员时，可以对当前待恢复应用程序中所有的类成员进行检测，或者，可以仅仅对当前待恢复应用程序中处于切换时刻的用户界面上的所有的类成员进行检测。优选地，可以只检测后者中的类成员，这样，可以减轻系统的负担，提高系统的检测效率。

第二判断单元404，用于判断检测到的当前待恢复应用程序中的类成员是否含有注解信息，含有注解信息的类成员为需要恢复的类成员。

需要说明的是，为了节省用于恢复应用程序的代码，防止代码冗余，在编程时，可以对应用程序中各个类成员进行预处理。例如，可以预先设定恢复应用程序时需要恢复的类成员和不需要恢复的类成员，为了区别不同属性的类成员，可以采用如下可选的预处理方式：方式一，恢复时，对需要恢复的类成员标注注解信息，也即，含有注解信息的类成员为需要恢复的类成员，而对不需要恢复的类成员不做任何处理；方式二，恢复时，对需要恢复的类成员标注第一注解信息，而对不需要恢复的类成员标注第二注解信息。优选地，可以采用方式一中的预处理方式，这样，可以更有效的节省用于恢复应用程序的代码，防止代码冗余。并且，在恢复含有注解信息的类成员时，可以完全恢复应用程序被切换为后台运行状态时刻之前该应用程序的所有现场状态，防止由于应用程序恢复不完全而给用户带来不便。

需要说明的是，所谓注解，也即元数据，它是一种代码级别的说明，它可以声明在包、类、字段、方法、局部变量、方法参数等的前面，用来对这些元素进行说明、注释。注解是以“@注解名(参数1，参数2，参数3......)”的形式在程序代码中存在的，它们不会直接影响到程序的语义，只是作为注解(标识)存在。注解可以生成文档，可以跟踪代码，实现替代配置文件功能。在编译时，注解可以进行格式检查。

恢复单元406，用于在判断出检测到的当前待恢复应用程序中的类成员含有注解信息时，在恢复当前待恢复应用程序的过程中恢复类成员。

具体地，可以将含有注解信息的类成员从保存实例中恢复出来。该保存实例即为存储空间，例如，其可以是用于存储类成员的容器。需要说明的是，由于任何一个待恢复应用程序都可以包括一个或者多个类成员，所有类成员的集合用于描述待恢复应用程序的全部功能。每个类成员都可以用于将相应的数据和操作封装在一个集合体里，并且可以在类成员的类体变量部分中声明变量以描述对象状态。

另外，对于任一应用程序而言，其可以包括一种或者多种类型的类成员，这样，在恢复类成员时，可以对不同类型的类成员执行不同的恢复处理。

例如，在Android系统中，假设用户当前正在执行的应用程序为应用程序A，如果用户需要由前台运行的其他应用程序切换至应经回收了的在后台运行的应用程序A，则系统会将应用程序A设置为前台运行方式，并将其他应用程序设置为后台运行的应用程序，此时，Android系统会对应用程序A进行恢复，并且在恢复过程中，需要恢复应用程序A中含有注解信息的类成员(如，用户数据和用户界面的运行状态)。这样，可以避免应用程序A中用户数据和用户界面的运行状态无法恢复，并且可以直接恢复出之前回收过的用户数据和各用户界面的运行状态，无需重新加载之前加载过的数据，达到了加快恢复后台运行的应用程序的现场的效果。

需要说明的是，在APP由后台运行状态切换至前台运行状态时，可以触发本发明的应用程序的恢复方法运行，从而自动恢复各个类成员，例如，在恢复各个类成员时，可以恢复各个成员变量，并给各个成员变量进行赋值，具体地，可以将会收时保存的值一一取出赋值给相应的类成员，从而达到自动恢复状态的功能。

通过本发明实施例，采用检测当前待恢复应用程序中的类成员；判断检测到的当前待恢复应用程序中的类成员是否含有注解信息；以及如果判断出检测到的当前待恢复应用程序中的类成员含有注解信息，则在恢复当前待恢复应用程序的过程中恢复类成员，达到了提高应用程序的恢复效率的效果，实现了快速恢复现场状态的目的。

另外，由于本发明封装了恢复时处理状态的功能，省去了重复编写恢复功能的处理逻辑。在程序开发中，开发人员只需要熟悉一下简单的使用方法就可以马上配置好需要恢复的数据，而不用去关心如何编写怎么保存、怎么恢复的功能，将开发人员从琐碎的重复劳动中解放出来，不仅节省了时间成本，而且节约了人力成本，达到了提高生产效率的效果。

优选地，在本发明实施例中，前述恢复装置还可以包括：第四检测单元。第四检测单元用于在检测当前待恢复应用程序中的类成员之前，检测当前待恢复应用程序的运行状态是否被切换为前台运行状态，其中，第三检测单元还用于在检测到待恢复当前应用程序的运行状态被切换为前台运行状态时，检测当前待恢复应用程序中的类成员。

通过本发明实施例，由于在应用程序由后台运行状态切换至前台运行状态的时间点才触发本发明的应用程序的恢复方法的执行，达到了准时回收应用程序的效果，并且由于可以准时恢复应用程序，达到了提高恢复应用程序的恢复时机的准确性的效果。

优选地，在本发明实施例中，前述回复单元还可以包括：第二检测模块、第二判断模块、第一恢复模块和/或第二恢复模块和/或第三恢复模块。第二检测模块用于检测所保存的类成员的类型；第二判断模块用于判断检测到的所保存的类成员的类型是否为预设类型，预设类型包括第一类型、第二类型和第三类型；第一恢复模块用于在判断出检测到的所保存的类成员的类型为第一类型时，在恢复当前待恢复应用程序的过程中直接恢复类成员；第二恢复模块用于在判断出检测到的所保存的类成员的类型为第二类型时，在恢复当前待恢复应用程序的过程中恢复类成员的当前状态值；第三恢复模块用于在判断出检测到的所保存的类成员的类型为第三类型时，在恢复当前待恢复应用程序的过程中先获取类成员的预处理结果，再根据预处理结果恢复类成员。

其中，第一类型可以为基础类型和/或普通类型，其中，基础类型为不可以分解的最小单位的类型，普通类型为基础类型的简单组合，因此，在恢复时，可以直接将属于这些类型的类成员从保存实例中恢复出来。第二类型可以为复杂的用户界面类型，例如，复杂的UI可以是列表类型的UI或者图片组合的UI，在恢复时，可以仅仅恢复属于第二类型的类成员的关键信息，即，恢复属于第二类型的类成员的当前状态值。第三类型可以为用户自定义的类型，在恢复时，可以先对属于第三类型的类成员执行预处理，得到预处理结果，再恢复预处理结果。例如，可以对第三类型的类成员按照预先规定的序列化/反序列化方式进行预处理，并将序列化/反序列化结果恢复出来。其中，序列化/反序列化为：将对象转换为字节序列的过程称为对象的序列化，将字节序列恢复对象的过程称为对象的反序列化。

进一步地，在恢复第二类型和第三类型的类成员时，可以先将这些类成员从一个包装类中恢复出来，再将该包装类作为一个整体从保存实例中恢复出来。具体地，在实际恢复应用程序时，可以对前述的3种类型的类成员执行不同的恢复方式。

显然，本领域的技术人员应该明白，上述的本发明的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本发明不限制于任何特定的硬件和软件结合。

以上所述仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (12)

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

检测当前待回收应用程序中的类成员，所述当前待回收应用程序为在后台运行的应用程序；

判断检测到的所述当前待回收应用程序中的所述类成员是否含有注解信息，含有所述注解信息的类成员为需要回收的类成员；以及

如果判断出检测到的所述当前待回收应用程序中的所述类成员含有所述注解信息，则在回收所述当前待回收应用程序的过程中保存所述类成员。

2.根据权利要求1所述的应用程序的回收方法，其特征在于，在检测当前待回收应用程序中的类成员之前，所述回收方法还包括：

检测所述当前待回收应用程序的运行状态是否被切换为后台运行状态，

其中，如果检测到所述待回收当前应用程序的运行状态被切换为所述后台运行状态，则检测所述当前待回收应用程序中的所述类成员。

3.根据权利要求1所述的应用程序的回收方法，其特征在于，在回收所述当前待回收应用程序的过程中保存所述类成员包括：检测所保存的所述类成员的类型；判断检测到的所保存的所述类成员的类型是否为预设类型，所述预设类型包括第一类型、第二类型和第三类型，其中，所述第一类型为基础类型和/或普通类型，所述第二类型为用户界面类型，所述第三类型为用户自定义的类型，

如果判断出检测到的所保存的所述类成员的类型为所述第一类型，则在回收所述当前待回收应用程序的过程中直接保存所述类成员；和/或

如果判断出检测到的所保存的所述类成员的类型为所述第二类型，则在回收所述当前待回收应用程序的过程中保存所述类成员的当前状态值；和/或

如果判断出检测到的所保存的所述类成员的类型为所述第三类型，则在回收所述当前待回收应用程序的过程中先对所述类成员执行预处理，得到预处理结果，再保存所述预处理结果。

4.一种应用程序的恢复方法，其特征在于，包括：

检测当前待恢复应用程序中的类成员，所述当前待恢复应用程序为已经被回收的应用程序；

判断检测到的所述当前待恢复应用程序中的所述类成员是否含有注解信息，含有所述注解信息的类成员为需要恢复的类成员；以及

如果判断出检测到的所述当前待恢复应用程序中的所述类成员含有所述注解信息，则在恢复所述当前待恢复应用程序的过程中恢复所述类成员。

5.根据权利要求4所述的应用程序的恢复方法，其特征在于，在检测当前待恢复应用程序中的类成员之前，所述恢复方法还包括：

检测所述当前待恢复应用程序的运行状态是否被切换为前台运行状态，

其中，如果检测到所述待恢复当前应用程序的运行状态被切换为所述前台运行状态，则检测所述当前待恢复应用程序中的所述类成员。

6.根据权利要求4所述的应用程序的恢复方法，其特征在于，在恢复所述当前待恢复应用程序的过程中恢复所述类成员包括：检测所保存的所述类成员的类型；判断检测到的所保存的所述类成员的类型是否为预设类型，所述预设类型包括第一类型、第二类型和第三类型，其中，所述第一类型为基础类型和/或普通类型，所述第二类型为用户界面类型，所述第三类型为用户自定义的类型，

如果判断出检测到的所保存的所述类成员的类型为所述第一类型，则在恢复所述当前待恢复应用程序的过程中直接恢复所述类成员；和/或

如果判断出检测到的所保存的所述类成员的类型为所述第二类型，则在恢复所述当前待恢复应用程序的过程中恢复所述类成员的当前状态值；和/或

如果判断出检测到的所保存的所述类成员的类型为所述第三类型，则在恢复所述当前待恢复应用程序的过程中先获取所述类成员的预处理结果，再根据所述预处理结果恢复所述类成员。

7.一种应用程序的回收装置，其特征在于，包括：

第一检测单元，用于检测当前待回收应用程序中的类成员，所述当前待回收应用程序为在后台运行的应用程序；

第一判断单元，用于判断检测到的所述当前待回收应用程序中的所述类成员是否含有注解信息，含有所述注解信息的类成员为需要回收的类成员；以及

保存单元，用于在判断出检测到的所述当前待回收应用程序中的所述类成员含有所述注解信息时，在回收所述当前待回收应用程序的过程中保存所述类成员。

8.根据权利要求7所述的应用程序的回收装置，其特征在于，所述回收装置还包括：

第二检测单元，用于在检测当前待回收应用程序中的类成员之前，检测所述当前待回收应用程序的运行状态是否被切换为后台运行状态，

其中，所述第一检测单元还用于在检测到所述待回收当前应用程序的运行状态被切换为所述后台运行状态时，检测所述当前待回收应用程序中的所述类成员。

9.根据权利要求7所述的应用程序的回收装置，其特征在于，所述保存单元包括：

第一检测模块，用于检测所保存的所述类成员的类型；

第一判断模块，用于判断检测到的所保存的所述类成员的类型是否为预设类型，所述预设类型包括第一类型、第二类型和第三类型，其中，所述第一类型为基础类型和/或普通类型，所述第二类型为用户界面类型，所述第三类型为用户自定义的类型；

第一保存模块，用于在判断出检测到的所保存的所述类成员的类型为所述第一类型时，在回收所述当前待回收应用程序的过程中直接保存所述类成员；和/或第二保存模块，用于在判断出检测到的所保存的所述类成员的类型为所述第二类型时，在回收所述当前待回收应用程序的过程中保存所述类成员的当前状态值；和/或第三保存模块，用于在判断出检测到的所保存的所述类成员的类型为所述第三类型时，在回收所述当前待回收应用程序的过程中先对所述类成员执行预处理，得到预处理结果，再保存所述预处理结果。

10.一种应用程序的恢复装置，其特征在于，包括：

第三检测单元，用于检测当前待恢复应用程序中的类成员，所述当前待恢复应用程序为已经被回收的应用程序；

第二判断单元，用于判断检测到的所述当前待恢复应用程序中的所述类成员是否含有注解信息，含有所述注解信息的类成员为需要恢复的类成员；以及

恢复单元，用于在判断出检测到的所述当前待恢复应用程序中的所述类成员含有所述注解信息时，在恢复所述当前待恢复应用程序的过程中恢复所述类成员。

11.根据权利要求10所述的应用程序的恢复装置，其特征在于，所述恢复装置还包括：

第四检测单元，用于在检测当前待恢复应用程序中的类成员之前，检测所述当前待恢复应用程序的运行状态是否被切换为前台运行状态，

其中，所述第三检测单元还用于在检测到所述待恢复当前应用程序的运行状态被切换为所述前台运行状态时，检测所述当前待恢复应用程序中的所述类成员。

12.根据权利要求10所述的应用程序的恢复装置，其特征在于，所述恢复单元包括：

第二检测模块，用于检测所保存的所述类成员的类型；

第二判断模块，用于判断检测到的所保存的所述类成员的类型是否为预设类型，所述预设类型包括第一类型、第二类型和第三类型，所述第一类型为基础类型和/或普通类型，所述第二类型为用户界面类型，所述第三类型为用户自定义的类型；

第一恢复模块，用于在判断出检测到的所保存的所述类成员的类型为所述第一类型时，在恢复所述当前待恢复应用程序的过程中直接恢复所述类成员；和/或第二恢复模块，用于在判断出检测到的所保存的所述类成员的类型为所述第二类型时，在恢复所述当前待恢复应用程序的过程中恢复所述类成员的当前状态值；和/或第三恢复模块，用于在判断出检测到的所保存的所述类成员的类型为所述第三类型时，在恢复所述当前待恢复应用程序的过程中先获取所述类成员的预处理结果，再根据所述预处理结果恢复所述类成员。