CN107153585A - 恢复方法及相关装置 - Google Patents

Abstract

本发明实施例提供恢复方法及相关装置，以在关键业务出现故障时对其进行自动恢复。该恢复方法包括：在终端启动后，获取正在运行的关键业务的列表；监测所述列表中各关键业务的运行状态；所述运行状态包括正常状态和异常状态；判断所述列表中的关键业务是否处于异常状态；响应于所述列表中至少一个关键业务处于异常状态，获取存储在所述终端中的相应安装包；使用获取的安装包对相应的、处于异常状态的关键业务进行恢复。基于上述恢复技术方案，本发明实施例在终端启动后，可自动监测正在运行的关键业务的运行状态，并可自动使用安装包恢复处于异常状态的关键业务，进而实现在关键业务出现故障时对其进行自动恢复。在此过程中，不需人工干预。

Description

恢复方法及相关装置

技术领域

本发明涉及数据处理技术领域，具体涉及恢复方法及相关装置。

背景技术

终端(例如智能手机)在运行过程中，如关键业务(服务)出现故障，需要进行人为干预，例如，用户通过手工操作对终端的操作系统进行重装(俗称刷机)，或进行返修。

发明内容

有鉴于此，本发明实施例提供一种恢复方法及相关装置，以在关键业务出现故障时对其进行自动恢复。

为实现上述目的，本发明实施例提供如下技术方案：

一种恢复方法，应用于终端，所述恢复方法包括：

在所述终端启动后，获取正在运行的关键业务的列表；

监测所述列表中各关键业务的运行状态；所述运行状态包括正常状态和异常状态；

判断所述列表中的关键业务是否处于异常状态；

响应于所述列表中至少一个关键业务处于异常状态，获取存储在所述终端中的相应安装包；

使用获取的安装包对相应的、处于异常状态的关键业务进行恢复。

一种恢复装置，应用于终端，所述恢复装置包括：

获取单元，用于在所述终端启动后，获取正在运行的关键业务的列表；

监测单元，用于监测所述列表中各关键业务的运行状态；所述运行状态包括正常状态和异常状态；

判断单元，用于判断所述列表中的关键业务是否处于异常状态；

安装包获取单元，用于响应于所述列表中至少一个关键业务处于异常状态，获取存储在所述终端中的相应安装包；

恢复单元，用于使用获取的安装包对相应的、处于异常状态的关键业务进行恢复。

一种终端，包括上述的恢复装置。

基于上述恢复技术方案，本发明实施例在终端启动后，可自动监测正在运行的关键业务的运行状态，并可自动使用安装包恢复处于异常状态的关键业务，进而实现在关键业务出现故障时对其进行自动恢复。在此过程中，不需人工干预。

附图说明

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

图1、2、3a、3b为本发明实施例提供的恢复方法示例性流程图；

图4为本发明实施例提供的恢复装置的示例性结构图；

图5为本发明实施例提供的终端的计算机架构示例图。

具体实施方式

本发明提供恢复方法、恢复装置及终端。

上述恢复方法或装置可应用于诸如移动终端(例如智能手机)、miniStation微游戏机等的终端中。

更具体的，上述恢复装置可为操作系统(例如Android系统)的监测模块。

图1示出了上述恢复方法的一种示例性流程，其至少可包括如下步骤：

S1：在终端启动后，获取正在运行的关键业务的列表；

上述关键业务可为操作系统的关键业务(或称为关键模块、核心模块)，在出厂前，可配置操作系统中的哪些业务为关键业务，哪些业务不是关键业务。

此外，除操作系统的关键业务外，也可允许用户设置终端上的应用为关键业务。

在一个示例中，可在终端启动后获取一次列表，然后不再获取。

操作系统的关键业务一般开机后就运行，不过有些关键业务运行一段时间后，休眠或者不再运行，有些关键业务则会一直运行。因此，在另一个示例中，也可周期性获取列表。

S2：监测上述列表中各关键业务的运行状态；上述运行状态包括正常状态和异常状态。

更具体的，恢复装置可维护监测表，在监测表中记录着上述列表中各关键业务对应的运行状态信息。运行状态信息用于表征运行状态。

进一步的，上述监测表中的运行状态信息可包括第一取值和第二取值，上述第二取值用于表征正常状态。第二取值具体可为1。第一取值具体可为0，或者第二取值具体可为0，第一取值具体可为1。当然，第一取值、第二取值的具体数值还可有其他选择，只要二者可相互区分即可。

此外，监测表中的运行状态信息还可包括第三取值，第三取值用于表征运行终止。第三取值具体可为2。当然，第三取值的具体数值还可有其他选择，只要与第一取值、第二取值可相互区分即可。

S3：判断上述列表中的关键业务是否处于异常状态。

可选的，可周期性执行步骤S2和S3。

恢复装置可以计时器进行计时。

计时器启动，一个监测周期开始，计时器计时到达设定的时长，则该监测周期结束。在监测周期内，恢复装置可监测上述列表中各关键业务的运行状态，在监测周期结束时，恢复装置判断列表中的关键业务是否处于异常状态。

此外，对于周期性获取列表的场景，可在监测周期开始时获取列表。

可选的，用户可设置计时器的时长，从而控制一个监测周期的时长。

进一步的，可根据监测表判断上述列表中的关键业务是否处于异常状态。

S4：响应于上述列表中至少一个关键业务处于异常状态，获取存储在上述终端中的相应安装包。

上述安装包可存储在终端的Flash中。也可存储在终端的其他存储介质中。

更具体的，恢复装置可调用系统安装/恢复业务，由系统安装/恢复业务获取安装包。

S5：使用获取的安装包对相应的、处于异常状态的关键业务进行恢复。

相应的，可由系统安装/恢复业务在恢复装置的指示下使用安装包进行重装。

上述安装包可为操作系统安装包。也即，一旦某一关键业务故障，则重新安装整个操作系统。在重新安装过程中，可选择保留用户数据(例如普通手机APP的数据)，这样，操作系统重装后，用户不用再重装手机APP。当然，也可选择不保留用户数据。

此外，上述安装包也可为针对关键业务的安装包。也即，哪个关键业务故障了，仅安装该关键业务，不会对整个操作系统进行重装。

无论是哪种安装包，可以是出厂时即存储在终端中，这样重装后就恢复到了出厂设置。

也可定期下载最新版本的安装包，这样重新安装后，用户将无需进一步升级。

基于上述恢复技术方案，本发明实施例在终端启动后，可自动监测正在运行的关键业务的运行状态，并可自动使用安装包恢复处于异常状态的关键业务，进而实现在关键业务出现故障时对其进行自动恢复。在此过程中，不需人工干预。

需要说明的是，现有的笔记本或台式机中，有任务管理器一项功能。但任务管理器需要用户手动启用，并且，其在启动后虽可显示各进程的运行状态，但只能用户手动选择关闭某一进程。

与之相比，本发明实施例所提供的技术方案，在终端启动后，可执行自动监测及自动恢复关键业务。并不需要用户的参与。

下面，将对上述恢复方法的关键步骤进行详细介绍。

在本发明其他实施例中，请参见图2，上述步骤S2可具体包括：

S21：获取状态报告信息。

上述状态报告信息由关键业务生成。

在一个示例中，若关键业务运行正常，则会生成并上报状态报告信息，否则将不生成或不上报状态报告信息。则在此示例中，状态报告信息具体可包含相应关键业务的唯一标识，以便于恢复装置识别是由哪个关键业务发送的状态报告信息。

在另一个示例中，除唯一标识外，上述状态报告信息还可包括相关的关键业务的上报类型。更具体的，上述上报类型可为周期性上报类型或非周期性上报类型。其中，非周期性上报类型的关键业务仅上报一次状态报告信息；周期性上报类型的关键业务按设定的发送周期，周期性生成并上报状态报告信息。

前述提及了，有些关键业务运行一段时间后将休眠或者不再运行，有些关键业务则会一直运行。只运行一段时间的关键业务，其上报类型为非周期性上报类型，也即，该关键业务启动后只上报一次状态报告信息。

而开机后一直运行的关键业务，其上报类型为周期性上报类型，也即，如运行正常，此类关键业务将周期性上报状态报告信息。可将上报状态报告信息的周期称为上报周期。

在又一个示例中，即使关键业务运行异常，只要还可上报状态报告信息，便会进行上报。此时，状态报告信息中除包含相应关键业务的唯一标识外，还可包括运行状态信息。其中，该状态报告信息中的运行状态信息可为第一取值、第二取值或第三取值，第一取值用于表征异常状态，第二取值用于表征正常状态，第三取值用于表征运行终止。也就是说，关键业务会通过状态报告信息报告自己是处于正常状态还是处于异常状态，在运行终止时，其也可发送包含第三取值的状态报告信息，以便于恢复装置知晓其运行终止。

S22：根据上述状态报告信息维护监测表。

相应的，步骤S3可进一步包括如下步骤：

在本监测周期结束时，判定监测表中运行状态信息为第一取值的关键业务的运行状态为异常状态，判定监测表中运行状态信息为其他取值(例如第二取值、第三取值)的关键业务的运行状态为正常状态。

下面，将对本技术方案进行更为详细的介绍。

请参见图3a，上述恢复方法可具体包括：

S301：在终端启动后，获取正在运行的关键业务的列表。

301部分与上述步骤S1相类似，在此不作赘述。

S302：计时器清零，进入监测周期。

S303：在本监测周期开始时，将列表中的关键业务在监测表中对应的运行状态信息设置为第一取值。

可采用一个监测表记录列表中所有关键业务对应的运行状态信息，也可采用两个监测表分别记录周期性上报类型的关键业务的运行状态信息以及非周期性上报类型的关键业务的运行状态信息。

假设列表中正在运行的关键业务有N个，并且第一取值具体为1，则本监测周期开始时，所有关键业务的运行状态信息如下表1所示。

表1

S304：在本监测周期开始时，对非周期性上报类型的关键业务，如在本监测周期之前已获取到了状态报告信息，则修改对应的运行状态信息为第二取值(例如0)，否则，将运行状态信息保持为第一取值(例如1)。

假设列表中第M个关键业务为非周期性上报类型，并且在本监测周期之前已获取到其状态报告信息，则将表1修改为如下表2所示。

表2

S305：在本监测周期内，获取状态报告信息。

获取到的某一状态报告信息可来自周期性上报类型的关键业务，也可来自非周期性上报类型的关键业务。

在一个示例中，恢复装置可与操作系统中的关键业务直接通讯，从而可直接接收关键业务上报的状态报告信息。

在另一个示例中，关键业务可将状态报告信息上报(存储)到共享缓存区域中，恢复装置可读取出共享缓存区域中的状态报告信息，从而获取到状态报告信息。

状态报告信息的发送周期的时长需小于监测周期的时长。

在又一个示例中，在本监测周期内，恢复装置可向列表中未上报状态报告信息的关键业务发送问询消息，收到问询消息的关键业务可反馈状态报告信息。

S306：将本监测周期内获取到的状态报告信息所对应的关键业务、在监测表中的运行状态信息设置为第二取值。

仍沿用前例，假定获取到了表2中的第M个非周期性上报类型的关键业务的状态报告信息，则将其运行状态信息设置为第二取值(0)。此时，非周期性上报类型的关键业务的运行状态信息如下表3所示。

表3

S307：在本监测周期结束时，判定运行状态信息为第二取值的关键业务处于正常状态，判定运行状态信息为第一取值的关键业务处于异常状态。

S308：判断上述列表中的各关键业务是否均处于正常状态(也即判断监测表中的运行状态信息是否均为第二取值)，如果是，返回S302，否则，进入S309。

S309：响应于上述列表中至少一个关键业务处于异常状态，获取存储在上述终端中的相应安装包。

309部分与前述的S4相同，在此不作赘述。

S310：使用获取的安装包对相应的、处于异常状态的关键业务进行恢复。

310部分与前述的S5相同，在此不作赘述。

在另一个实施例中，请参见图3b，上述恢复方法可具体包括：

S3001：在终端启动后，获取正在运行的关键业务的列表。

3001部分与上述步骤S1相类似，在此不作赘述。

S3002：计时器清零，进入监测周期。

S3003：在本监测周期开始时，将列表中的关键业务在监测表中对应的运行状态信息设置为第一取值。

假设列表中正在运行的关键业务有N个，并且第一取值具体为1，则本监测周期开始时，所有关键业务的运行状态信息如下表4所示。

表4

S3004：在本监测周期内，获取状态报告信息。

其中，状态报告信息中包含相应关键业务的唯一标识及运行状态信息。状态报告信息中的运行状态信息可为第一取值、第二取值或第三取值：第一取值用于表征异常状态，第二取值用于表征正常状态，第三取值用于表征运行终止。在本实施例中，第一取值具体为1，第二取值具体为0，第三取值具体为2。

在一个示例中，恢复装置可与操作系统中的关键业务直接通讯，从而可直接接收关键业务上报的状态报告信息。

在另一个示例中，关键业务可将状态报告信息上报(存储)到共享缓存区域中，恢复装置可读取出共享缓存区域中的状态报告信息，从而获取到状态报告信息。

状态报告信息的发送周期的时长需小于监测周期的时长。

在又一个示例中，在本监测周期内，恢复装置可向列表中未上报状态报告信息的关键业务发送问询消息，收到问询消息的关键业务可反馈状态报告信息。

S3005：提取状态报告信息中的运行状态信息。

S3006：根据提取出的运行状态信息更改监测表中相应关键业务的运行状态信息。

仍沿用前例，假定，第1个关键业务上报的状态报告信息中的运行状态信息为1，第M个关键业务上报的状态报告信息中的运行状态信息为2，未收到第N个关键业务上报的状态报告信息，其他关键业务上报的状态报告信息中的运行状态信息均为0。则表4更改为如下表5所示。

表5

S3007：在本监测周期结束时，判定运行状态信息为第一取值的关键业务处于异常状态，判定运行状态信息为其他取值(例如2、0)的关键业务处于正常状态。

S3008：判断上述列表中的各关键业务是否均处于正常状态(也即判断上述列表中的各关键业务的运行状态信息是否均不为第一取值)，如果是，返回S3002，否则，进入S3009。

S3009：响应于上述列表中至少一个关键业务处于异常状态，获取存储在上述终端中的相应安装包。

3009部分与前述的S4相同，在此不作赘述。

S3010：使用获取的安装包对相应的、处于异常状态的关键业务进行恢复。

3010部分与前述的S5相同，在此不作赘述。

在本发明其他实施例中，当本监测周期结束时，若各关键业务均处于正常状态，恢复装置还可对操作系统及运行中的各APP的状态进行快照，并保存快照数据。

而在某次监测周期结束时，如任一关键业务处于异常状态，除使用安装包恢复外，还可在恢复后，查找存储的快照数据，将操作系统及各APP的状态恢复成前一监测周期结束时的状态。

下面将介绍恢复装置。前已述及，该恢复装置可应用于终端。

图4示出了上述恢复装置的一种示例性结构，可包括：

获取单元1，用于在上述终端启动后，获取正在运行的关键业务的列表；

监测单元2，用于监测上述列表中各关键业务的运行状态；上述运行状态包括正常状态和异常状态；

判断单元3，用于判断上述列表中的关键业务是否处于异常状态；

安装包获取单元4，用于响应于上述列表中至少一个关键业务处于异常状态，获取存储在上述终端中的相应安装包；

恢复单元5，用于使用获取的安装包对相应的、处于异常状态的关键业务进行恢复。

具体细节请参照本文方法部分的介绍，在此不作赘述。

在本发明其他实施例中，在上述监测上述列表中各关键业务的运行状态的方面，上述所有实施例中的监测单元1可具体用于：

获取状态报告信息；上述状态报告信息由关键业务生成；

根据上述状态报告信息维护监测表；上述监测表中包括上述列表中各关键业务对应的运行状态信息。

具体细节请参照本文方法部分的介绍，在此不作赘述。

上述关键业务对应有上报类型；上述状态报告信息中包含相应关键业务的唯一标识及上报类型；上述上报类型为周期性上报类型或非周期性上报类型。

其中，非周期性上报类型的关键业务仅上报一次状态报告信息；周期性上报类型的关键业务按设定的发送周期，周期性生成并上报状态报告信息。

上述监测表中的运行状态信息可至少包括第一取值和第二取值，其中，第二取值用于表征正常状态；

在本发明其他实施例中，在上述根据所述状态报告信息维护监测表的方面，上述所有实施例中的监测单元1可用于：

在本监测周期开始时，将各关键业务在监测表中的运行状态信息设置为第一取值；

如在本监测周期之前已获取到了非周期性上报类型的关键业务的状态报告信息，则修改监测表中对应的运行状态信息为第二取值。

具体细节请参照本文方法部分的介绍，例如图3a所示实例的介绍，在此不作赘述。

在本发明其他实施例中，在上述根据所述状态报告信息维护监测表的方面，上述所有实施例中的监测单元1还可用于：

将本监测周期内获取到的状态报告信息所对应的关键业务、在监测表中的运行状态信息设置为第二取值；

上述发送周期的时长小于上述监测周期的时长。

具体细节请参照本文方法部分的介绍，例如图3a所示部分的介绍，在此不作赘述。

在本发明其他实施例中，上述所有实施例中的状态报告信息可包含相应关键业务的唯一标识及运行状态信息；所述状态报告信息中的运行状态信息为第一取值、第二取值或第三取值。其中，所述第一取值用于表征异常状态，所述第二取值用于表征正常状态，所述第三取值用于表征运行终止。

相应的，在上述根据所述状态报告信息维护监测表的方面，上述所有实施例中的监测单元1可用于：

在本监测周期开始时，将所述列表中关键业务的运行状态信息设置为第一取值；

在本监测周期内，接收状态报告信息；

提取接收到的状态报告信息中的运行状态信息；

根据提取出的运行状态信息更改所述监测表中相应关键业务的运行状态信息。

具体细节请参照本文方法部分的介绍，例如图3b所示部分的介绍，在此不作赘述。

在本发明其他实施例中，在监测上述列表中各关键业务的运行状态的方面，上述所有实施例中的监测单元1还可用于：

在本监测周期结束时，当上述列表中的各关键业务均处于正常状态时，进入下一监测周期。

具体细节请参照本文方法部分的介绍，例如图3a和图3b所示部分的介绍，在此不作赘述。

在本发明其他实施例中，在判断述列表中的关键业务是否处于异常状态的方面，判断单元3可用于：

在本监测周期结束时，判定监测表中运行状态信息为第一取值的关键业务处于异常状态，判定监测表中运行状态信息为其他取值的关键业务处于正常状态。

具体细节请参照本文方法部分的介绍，例如图3a和图3b所示部分的介绍，在此不作赘述。

图5示出了上述终端的一种通用计算机系统结构。

上述计算机系统可包括总线、处理器501、存储器502、通信接口503、输入设备504和输出设备505。处理器501、存储器502、通信接口503、输入设备504和输出设备505通过总线相互连接。其中：

总线可包括一通路，在计算机系统各个部件之间传送信息。

处理器501可以是通用处理器，例如通用中央处理器(CPU)、网络处理器(NetworkProcessor，简称NP)、微处理器等，也可以是特定应用集成电路(application-specific integrated circuit，ASIC)，或一个或多个用于控制本发明方案程序执行的集成电路。还可以是数字信号处理器(DSP)、专用集成电路(ASIC)、现成可编程门阵列(FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。

处理器501可包括主处理器，还可包括基带芯片、调制解调器等。

存储器502中保存有执行本发明技术方案的程序，还可以保存有操作系统和其他关键业务。具体地，程序可以包括程序代码，程序代码包括计算机操作指令。更具体的，存储器502可以包括只读存储器(read-only memory，ROM)、可存储静态信息和指令的其他类型的静态存储设备、随机存取存储器(random access memory，RAM)、可存储信息和指令的其他类型的动态存储设备、磁盘存储器、flash等等。此外，存储器502可存储安装包。

输入设备504可包括接收用户输入的数据和信息的装置，例如键盘、鼠标、摄像头、扫描仪、光笔、语音输入装置、触摸屏、计步器或重力感应器等。

输出设备505可包括允许输出信息给用户的装置，例如显示屏、打印机、扬声器等。

通信接口503可包括使用任何收发器一类的装置，以便与其他设备或通信网络通信，如以太网，无线接入网(RAN)，无线局域网(WLAN)等。

处理器501执行存储器502中所存放的程序，以及调用其他设备，可用于实现本发明前述实施例所提供的恢复方法中的各个步骤。

本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。对于实施例公开的装置而言，由于其与实施例公开的方法相对应，所以描述的比较简单，相关之处参见方法部分说明即可。

专业人员还可以进一步意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本发明的范围。

结合本文中所公开的实施例描述的方法或算法的步骤可以直接用硬件、处理器执行的软件模块，或者二者的结合来实施。软件模块可以置于随机存储器(RAM)、内存、只读存储器(ROM)、电可编程ROM、电可擦除可编程ROM、寄存器、硬盘、可移动磁盘、CD-ROM、或技术领域内所公知的任意其它形式的存储介质中。

对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本发明。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本发明的精神或范围的情况下，在其它实施例中实现。因此，本发明将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。

Claims (20)

1.一种恢复方法，其特征在于，应用于终端，所述恢复方法包括：

在所述终端启动后，获取正在运行的关键业务的列表；

监测所述列表中各关键业务的运行状态；所述运行状态包括正常状态和异常状态；

判断所述列表中的关键业务是否处于异常状态；

响应于所述列表中至少一个关键业务处于异常状态，获取存储在所述终端中的相应安装包；

使用获取的安装包对相应的、处于异常状态的关键业务进行恢复。

2.如权利要求1所述的方法，其特征在于，所述监测所述列表中各关键业务的运行状态包括：

获取状态报告信息；所述状态报告信息由所述正在运行的关键业务生成；

根据所述状态报告信息维护监测表；所述监测表中包括所述列表中各关键业务对应的运行状态信息。

3.如权利要求2所述方法，其特征在于，

所述关键业务对应有上报类型；

所述状态报告信息中包含相应关键业务的唯一标识及上报类型；

所述上报类型为周期性上报类型或非周期性上报类型；

其中，非周期性上报类型的关键业务仅上报一次状态报告信息；周期性上报类型的关键业务按设定的发送周期，周期性生成并上报状态报告信息。

4.如权利要求3所述的方法，其特征在于，

所述监测表中的运行状态信息至少包括第一取值和第二取值，所述第二取值用于表征正常状态；

所述根据所述状态报告信息维护监测表包括：

在本监测周期开始时，将各关键业务在监测表中的运行状态信息设置为第一取值；

如在本监测周期之前已获取到了非周期性上报类型的关键业务的状态报告信息，则修改监测表中对应的运行状态信息为第二取值。

5.如权利要求4所述的方法，其特征在于，所述根据所述状态报告信息维护监测表还包括：

在本监测周期内，将获取到的状态报告信息对应的关键业务的运行状态信息设置为第二取值；

所述发送周期的时长小于所述监测周期的时长。

6.如权利要求2所述方法，其特征在于，

所述状态报告信息中包含相应关键业务的唯一标识及运行状态信息；所述状态报告信息中的运行状态信息为第一取值、第二取值或第三取值，所述第一取值用于表征异常状态，所述第二取值用于表征正常状态，所述第三取值用于表征运行终止；

所述根据所述状态报告信息维护监测表包括：

在本监测周期开始时，将所述列表中关键业务的运行状态信息设置为第一取值；

在本监测周期内，接收状态报告信息；

提取接收到的状态报告信息中的运行状态信息；

根据提取出的运行状态信息更改所述监测表中相应关键业务的运行状态信息。

7.如权利要求4-6任一项所述的方法，其特征在于，所述监测所述列表中各关键业务的运行状态还包括：

在本监测周期结束时，当所述列表中的各关键业务均处于正常状态时，进入下一监测周期。

8.如权利要求7所述的方法，其特征在于，所述判断所述列表中的关键业务是否处于异常状态包括：

在本监测周期结束时，判定监测表中运行状态信息为第一取值的关键业务处于异常状态，判定监测表中运行状态信息为其他取值的关键业务处于正常状态。

9.如权利要求2所述的方法，其特征在于，所述获取状态报告信息包括：

读取共享缓存区域中的状态报告信息，所述共享缓存区域用于存储关键业务上报的状态报告信息。

10.如权利要求2所述的方法，其特征在于，所述获取状态报告信息包括：

直接接收所述关键业务上报的状态报告信息。

11.如权利要求1所述的方法，其特征在于，所述安装包具体为系统安装包。

12.一种恢复装置，其特征在于，应用于终端，所述恢复装置包括：

获取单元，用于在所述终端启动后，获取正在运行的关键业务的列表；

监测单元，用于监测所述列表中各关键业务的运行状态；所述运行状态包括正常状态和异常状态；

判断单元，用于判断所述列表中的关键业务是否处于异常状态；

安装包获取单元，用于响应于所述列表中至少一个关键业务处于异常状态，获取存储在所述终端中的相应安装包；

恢复单元，用于使用获取的安装包对相应的、处于异常状态的关键业务进行恢复。

13.如权利要求12所述的装置，其特征在于，在所述监测所述列表中各关键业务的运行状态的方面，所述监测单元具体用于：

获取状态报告信息；所述状态报告信息由由所述正在运行的关键业务生成；

根据所述状态报告信息维护监测表；所述监测表中包括所述列表中各关键业务对应的运行状态信息。

14.如权利要求13所述装置，其特征在于，

所述关键业务对应有上报类型；

所述状态报告信息中包含相应关键业务的唯一标识及上报类型；

所述上报类型为周期性上报类型或非周期性上报类型；

其中，非周期性上报类型的关键业务仅上报一次状态报告信息；周期性上报类型的关键业务按设定的发送周期，周期性生成并上报状态报告信息。

15.如权利要求14所述的装置，其特征在于，所述监测表中的运行状态信息至少包括第一取值和第二取值，所述第二取值用于表征正常状态；

在所述根据所述状态报告信息维护监测表的方面，所述监测单元用于：

在本监测周期开始时，将各关键业务在监测表中的运行状态信息设置为第一取值；

如在本监测周期之前已获取到了非周期性上报类型的关键业务的状态报告信息，则修改监测表中对应的运行状态信息为第二取值。

16.如权利要求15所述的装置，其特征在于，在所述根据所述状态报告信息维护监测表的方面，所述监测单元还用于：

将本监测周期内获取到的状态报告信息所对应的关键业务、在监测表中的运行状态信息设置为第二取值；

所述发送周期的时长小于所述监测周期的时长。

17.如权利要求13所述装置，其特征在于，

所述状态报告信息中包含相应关键业务的唯一标识及运行状态信息；所述状态报告信息中的运行状态信息为第一取值、第二取值或第三取值，所述第一取值用于表征异常状态，所述第二取值用于表征正常状态，所述第三取值用于表征运行终止；

在所述根据所述状态报告信息维护监测表的方面，所述监测单元用于：

在本监测周期开始时，将所述列表中关键业务的运行状态信息设置为第一取值；

在本监测周期内，接收状态报告信息；

提取接收到的状态报告信息中的运行状态信息；

根据提取出的运行状态信息更改所述监测表中相应关键业务的运行状态信息。

18.如权利要求15-17任一项所述的装置，其特征在于，在监测所述列表中各关键业务的运行状态的方面，所述监测单元还用于：

在本监测周期结束时，当所述列表中的各关键业务的运行状态信息均处于正常状态时，进入下一监测周期。

19.如权利要求18所述的装置，其特征在于，在所述判断所述列表中的关键业务是否处于异常状态的方面，所述判断单元用于：

在本监测周期结束时，判定监测表中运行状态信息为第一取值的关键业务处于异常状态，判定监测表中运行状态信息为其他取值的关键业务处于正常状态。

20.一种终端，其特征在于，包括如权利要求12-19所述的恢复装置。