CN106648971A - 一种崩溃crash恢复装置、终端及方法 - Google Patents

Abstract

本发明公开了一种崩溃crash恢复装置、终端及方法，应用于终端，该崩溃crash恢复装置包括监测模块，用于监测目标应用的运行状态；第一获取模块，用于监测模块监测到目标应用发生crash时，获取目标应用最新的缓存信息；处理模块，用于根据缓存信息恢复目标应用；采用上述方案，当目标应用发生crash时，根据目标应用最新的缓存信息恢复目标应用，使得用户感知不到应用发生过crash，提升了用户体验。

Description

一种崩溃crash恢复装置、终端及方法

技术领域

本发明涉及终端技术领域，更具体地说，涉及一种崩溃crash恢复装置、终端及方法。

背景技术

目前，智能终端中，用户安装的应用的数量越来越多，应用的来源也是各不相同，这些应用的稳定程度也不一样。对于很多android应用来说，不可避免的会发生crash(闪退)，无论开发者将程序写得多完美，总是无法完全避免crash的发生，导致应用出现crash的原因也多种多样，当crash发生时，系统会kill掉程序，表现就是闪退或者程序已停止运行，这对用户来说是很不友好的，也是开发者所不愿意看到的。

发明内容

本发明的主要目的在于提出一种崩溃crash恢复装置、终端及方法，旨在解决现有技术中，应用发生crash后，出现闪退或者程序已停止运行的问题。

为解决上述技术问题，本发明提供一种崩溃crash恢复装置，应用于终端，崩溃crash恢复装置包括：

监测模块，用于监测目标应用的运行状态；

第一获取模块，用于监测模块监测到目标应用发生crash时，获取目标应用最新的缓存信息；

处理模块，用于根据缓存信息恢复目标应用。

其中，处理模块用于启动目标应用，根据缓存信息跳转至crash发生时的页面并还原页面上的操作数据。

其中，还包括：

第二获取模块，用于获取目标应用发生crash时的异常运行状态信息；

第一获取模块用于第二获取模块获取到的异常运行状态信息满足预设的可恢复条件时，获取目标应用最新的缓存信息。

其中，还包括：

第三获取模块，用于获取目标应用发生crash时的异常运行状态信息；

发送模块，用于将第三获取模块获取的异常运行状态信息发送至服务器。

进一步地，本发明提供一种终端，包括上述的崩溃crash恢复装置。

进一步地，本发明提供一种崩溃crash恢复方法，应用于终端，崩溃crash恢复方法包括：

监测目标应用的运行状态；

若目标应用发生crash，则获取目标应用最新的缓存信息；

根据缓存信息恢复目标应用。

其中，根据缓存信息恢复目标应用包括：

启动目标应用，根据缓存信息跳转至crash发生时的页面并还原页面上的操作数据。

其中，获取目标应用最新的缓存信息之前，还包括：

获取目标应用发生crash时的异常运行状态信息；

若异常运行状态信息满足预设的可恢复条件，则进入获取目标应用最新的缓存信息的步骤。

其中，目标应用为终端操作系统中任一预安装的应用或任一第三方应用。

其中，若目标应用发生crash，还包括：

获取目标应用发生crash时的异常运行状态信息；

将异常运行状态信息发送至服务器。

有益效果

本发明提供了一种崩溃crash恢复装置、终端及方法，应用于终端，该崩溃crash恢复装置包括监测模块，用于监测目标应用的运行状态；第一获取模块，用于监测模块监测到目标应用发生crash时，获取目标应用最新的缓存信息；处理模块，用于根据缓存信息恢复目标应用；采用上述方案，当目标应用发生crash时，根据目标应用最新的缓存信息恢复目标应用，使得用户感知不到应用发生过crash，提升了用户体验。

附图说明

下面将结合附图及实施例对本发明作进一步说明，附图中：

图1为实现本发明各个实施例一个可选的终端的硬件结构示意图；

图2为本发明第一实施例提供的一种崩溃crash恢复装置的示意图；

图3为本发明第一实施例提供的另一种崩溃crash恢复装置的示意图；

图4为本发明第二实施例提供的一种终端的示意图；

图5为本发明第三实施例提供的一种崩溃crash恢复方法的流程图；

图6为本发明第四实施例提供的一种崩溃crash恢复方法的流程图。

具体实施方式

应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。

现在将参考附图描述实现本发明各个实施例的终端。在后续的描述中，使用用于表示元件的诸如“模块”、“部件”或“单元”的后缀仅为了有利于本发明的说明，其本身并没有特定的意义。因此，"模块"与"部件"可以混合地使用。

终端可以以各种形式来实施。例如，本发明中描述的终端可以包括诸如移动电话、智能电话、笔记本电脑、数字广播接收器、PDA(个人数字助理)、PAD(平板电脑)、PMP(便携式多媒体播放器)、导航装置等等的终端以及诸如数字TV、台式计算机等等的固定终端。下面，假设终端是终端，然而，本领域技术人员将理解的是，除了特别用于移动目的的元件之外，根据本发明的实施方式的构造也能够应用于固定类型的终端。

图1为实现本发明各个实施例一个可选的终端的硬件结构示意图。

终端100可以包括无线通信单元110、存储器120、控制器130和电源单元140等等。图1示出了具有各种组件的终端，但是应理解的是，并不要求实施所有示出的组件，可以替代地实施更多或更少的组件，将在下面详细描述终端的元件。

无线通信单元110通常包括一个或多个组件，其允许终端100与无线通信系统或网络之间的无线电通信。例如，无线通信单元可以包括移动通信模块111等。

移动通信模块111将无线电信号发送到基站(例如，接入点等等)、外部终端以及服务器中的至少一个和/或从其接收无线电信号。这样的无线电信号可以包括语音通话信号、视频通话信号、或者根据文本和/或多媒体消息发送和/或接收的各种类型的数据。

存储器120可以存储由控制器130执行的处理和控制操作的软件程序等等，或者可以暂时地存储己经输出或将要输出的数据(例如，电话簿、消息、静态图像、视频等等)。而且，存储器120可以存储关于当触摸施加到触摸屏时输出的各种方式的振动和音频信号的数据。

存储器120可以包括至少一种类型的存储介质，所述存储介质包括闪存、硬盘、多媒体卡、卡型存储器(例如，SD或DX存储器等等)、随机访问存储器(RAM)、静态随机访问存储器(SRAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、可编程只读存储器(PROM)、磁性存储器、磁盘、光盘等等。而且，终端100可以与通过网络连接执行存储器120的存储功能的网络存储装置协作。

控制器130通常控制终端的总体操作。例如，控制器130执行与语音通话、数据通信、视频通话等等相关的控制和处理。

电源单元140在控制器140的控制下接收外部电力或内部电力并且提供操作各元件和组件所需的适当的电力。

这里描述的各种实施方式可以以使用例如计算机软件、硬件或其任何组合的计算机可读介质来实施。对于硬件实施，这里描述的实施方式可以通过使用特定用途集成电路(ASIC)、数字信号处理器(DSP)、数字信号处理装置(DSPD)、可编程逻辑装置(PLD)、现场可编程门阵列(FPGA)、处理器、控制器、微控制器、微处理器、被设计为执行这里描述的功能的电子单元中的至少一种来实施，在一些情况下，这样的实施方式可以在控制器180中实施。对于软件实施，诸如过程或功能的实施方式可以与允许执行至少一种功能或操作的单独的软件模块来实施。软件代码可以由以任何适当的编程语言编写的软件应用程序(或程序)来实施，软件代码可以存储在存储器120中并且由控制器130执行。

至此，己经按照其功能描述了终端。下面，为了简要起见，将描述诸如折叠型、直板型、摆动型、滑动型终端等等的各种类型的终端中的滑动型终端作为示例。因此，本发明能够应用于任何类型的终端，并且不限于滑动型终端。

基于上述终端硬件结构，以下通过具体实施例对本发明进行详细说明。

第一实施例

本实施例提供了一种崩溃crash恢复装置，应用于终端，参见图2，图2为本发明第一实施例提供的崩溃crash恢复装置的示意图，该崩溃crash恢复装置包括：监测模块201，第一获取模块202，处理模块203，其中，

监测模块201，用于监测目标应用的运行状态。

其中，目标应用可以是终端操作系统中任一预安装的应用，例如终端自带的相机、音乐播放器、视频播放器、日历、天气等应用；

目标应用也可以是终端操作系统中任一第三方应用，例如百度糯米、百度地图、酷狗音乐、网易云音乐、手机淘宝等应用。

其中，操作系统包括Android等。

现有技术中，应用发生crash后都是由应用自己处理，应用仍会表现为闪退或者程序已停止运行，处理效果不够好，所以为了避免此种情况的发生，本实施例采取对Android原生系统的crash处理架构进行优化的方案，监测模块201从底层对终端运行的所有应用的运行状态进行监测，使得用户感知不到应用发生过crash，提升用户体验。

目标应用的运行状态包括目标应用运行正常、目标应用运行异常，其中，目标应用运行异常造成的原因可能是目标应用发生crash。

由于终端环境和使用场景的复杂性，应用的异常处理不可能完全覆盖，终端应用发生crash的情况是比较常见的。

监测模块201监测到目标应用的运行状态为运行异常时，捕获目标应用发生crash时的异常运行状态信息，还可以对发生crash时的异常运行状态信息进行分析。

不论目标应用因为什么原因闪退，只要能够捕获引起闪退的异常，那么就对异常进行处理。

可选的，参见图3，图3为本发明第一实施例提供的另一种崩溃crash恢复装置的示意图，该崩溃crash恢复装置还包括：注册模块204，

注册模块204，用于在终端操作系统启动时，将监测模块201注册至系统活动管理模块，监测模块201通过系统活动管理模块获取到每个应用的运行状态。

首先注册模块204在框架层将监测模块201注册至系统活动管理模块，实时监测所有应用的运行状态。

可选的，该崩溃crash恢复装置还包括：第二获取模块205，

第二获取模块205，用于获取目标应用发生crash时的异常运行状态信息；

第一获取模块202用于当第二获取模块205获取到的异常运行状态信息满足预设的可恢复条件时，获取目标应用最新的缓存信息。

当第二获取模块205获取到的异常运行状态信息不满足预设的可恢复条件时，可以放弃恢复目标应用。

第一获取模块202，用于监测模块201监测到目标应用发生crash时，获取目标应用最新的缓存信息；

在第一获取模块202接收到目标应用发生crash的通知后，第一获取模块202调用系统包管理器，进而查询目标应用最新的缓存信息，目标应用最新的缓存信息包括该应用崩溃crash发生时的缓存信息。

处理模块203，用于根据缓存信息恢复目标应用。

其中，处理模块203用于启动目标应用，根据缓存信息跳转至crash发生时的页面并还原页面上的操作数据。

当目标应用发生crash时，系统会kill掉目标应用程序，若不及时处理，则目标应用会表现为闪退或者程序已停止运行，这对用户来说是很不友好的，所以为了避免此种情况的发生，当监测模块201监测到目标应用发生crash时，则第一获取模块202去获取目标应用最新的缓存信息，以供处理模块203根据第一获取模块202获取的缓存信息恢复目标应用，使得用户感知不到应用发生过crash，提升了用户体验。

可选的，该崩溃crash恢复装置还包括：第三获取模块206，发送模块207，

第三获取模块206，用于获取目标应用发生crash时的异常运行状态信息；

发送模块207，用于将第三获取模块205获取的异常运行状态信息发送至服务器，以供开发人员分析，以便修复目标应用。

其中，第二获取模块205和第三获取模块206可以为同一模块。

下面例举一个具体的例子对本发明的方案进行说明。

首先在终端操作系统启动时，注册模块204在框架层将监测模块201注册至系统活动管理模块，监测模块201通过系统活动管理模块获取到每个应用的运行状态。

监测模块201监测到有应用发生crash，捕获发生crash时的异常运行状态信息，并将发生crash时的异常运行状态信息发送至异常分析模块。

异常分析模块在接收到监测模块201发来的发生crash时的异常运行状态信息后，对其进行解析，解析出是应用A发生crash，然后解析出应用A的包名，并将解析出的应用A的包名发送给第一获取模块202；并可以解析出发生crash是由系统导致的还是由应用A本身导致的。

若应用A发生crash是由系统导致的，则将应用A发生crash时的异常运行状态信息发送至系统厂商；若应用A发生crash是由应用A本身导致的，则将应用A发生crash时的异常运行状态信息发送至应用A厂商。

例如若品牌B手机中的应用A发生crash，若异常分析模块分析出应用A发生crash是由系统导致的，则将应用A发生crash时的异常运行状态信息发送至品牌B手机的厂商，以供品牌B手机厂商的开发人员分析，以便修复应用A；若应用A发生crash是由应用A本身导致的，则将应用A发生crash时的异常运行状态信息发送至应用A厂商，以供应用A厂商的开发人员分析，以便修复应用A。

第一获取模块202在接收到异常分析模块发来的应用A的包名后，调用系统包管理器，进而查询应用A崩溃crash时的缓存信息。

处理模块203重新启动目标应用，根据缓存信息直接跳转至crash发生时的页面并还原页面上的操作数据。

通过本实施例的实施，从框架层面监测目标应用的crash，当目标应用发生crash时，根据所述目标应用最新的缓存信息恢复所述目标应用，使得用户感知不到应用发生过crash，提升了用户体验。

另外，还可以将目标应用发生crash时的异常运行状态信息发送至服务器，以供开发人员对crash问题进行分析解决，以便修复目标应用。这样，不管目标应用是终端操作系统中预安装的应用还是第三方应用，都能得到处理恢复，从而提升用户的体验。

第二实施例

本实施例提供一种终端，参见图4，图4为本实施例提供的一种终端的示意图，该终端包括第一实施例中的崩溃crash恢复装置。上述崩溃crash恢复装置的各功能模块执行的功能可通过图1中的部分硬件来实现，当然，各硬件执行的功能也可由上述功能模块实现。上述各功能模块的功能具体由如下硬件实现：

监测模块201、第一获取模块202、处理模块203、注册模块204、第二获取模块205、第三获取模块206的功能均可通过控制器130来实现。

发送模块207的功能可通过移动通信模块111来实现，移动通信模块111将无线电信号发送到服务器，这样的无线电信号可以包括语音通话信号、视频通话信号、或者根据文本和/或多媒体消息发送和/或接收的各种类型的数据。

控制器130用于监测目标应用的运行状态。

其中，目标应用可以是终端操作系统中任一预安装的应用，例如终端自带的相机、音乐播放器、视频播放器、日历、天气等应用；

目标应用也可以是终端操作系统中任一第三方应用，例如百度糯米、百度地图、酷狗音乐、网易云音乐、手机淘宝等应用。

其中，操作系统包括Android等。

现有技术中，应用发生crash后都是由应用自己处理，应用仍会表现为闪退或者程序已停止运行，处理效果不够好，所以为了避免此种情况的发生，本实施例采取对Android原生系统的crash处理架构进行优化的方案，控制器130从底层对终端运行的所有应用的运行状态进行监测，使得用户感知不到应用发生过crash，提升用户体验。

目标应用的运行状态包括目标应用运行正常、目标应用运行异常，其中，目标应用运行异常造成的原因可能是目标应用发生crash。

由于终端环境和使用场景的复杂性，应用的异常处理不可能完全覆盖，终端应用发生crash的情况是比较常见的。

控制器130监测到目标应用的运行状态为运行异常时，捕获目标应用发生crash时的异常运行状态信息，还可以对发生crash时的异常运行状态信息进行分析。

不论目标应用因为什么原因闪退，只要能够捕获引起闪退的异常，那么就对异常进行处理。

控制器130用于在终端操作系统启动时，将控制器130注册至系统活动管理模块，控制器130通过系统活动管理模块获取到每个应用的运行状态。

首先在框架层将控制器130注册至系统活动管理模块，实时监测所有应用的运行状态。

控制器130获取目标应用发生crash时的异常运行状态信息；当获取到的异常运行状态信息满足预设的可恢复条件时，获取目标应用最新的缓存信息。

当获取到的异常运行状态信息不满足预设的可恢复条件时，可以放弃恢复目标应用。

控制器130用于监测到目标应用发生crash时，获取目标应用最新的缓存信息；

在接收到目标应用发生crash的通知后，控制器130调用系统包管理器，进而查询目标应用最新的缓存信息，目标应用最新的缓存信息包括该应用崩溃crash发生时的缓存信息。

控制器130用于根据缓存信息恢复目标应用。

其中，控制器130具体用于启动目标应用，根据缓存信息跳转至crash发生时的页面并还原页面上的操作数据。

当目标应用发生crash时，系统会kill掉目标应用程序，若不及时处理，则目标应用会表现为闪退或者程序已停止运行，这对用户来说是很不友好的，所以为了避免此种情况的发生，当控制器130监测到目标应用发生crash时，则去获取目标应用最新的缓存信息，根据获取的缓存信息恢复目标应用，使得用户感知不到应用发生过crash，提升了用户体验。

控制器130用于获取目标应用发生crash时的异常运行状态信息；移动通信模块111用于将控制器130获取的异常运行状态信息发送至服务器，以供开发人员分析，以便修复目标应用。

下面例举一个具体的例子对本发明的方案进行说明。

首先在终端操作系统启动时，在框架层将控制器130注册至系统活动管理模块，控制器130通过系统活动管理模块获取到每个应用的运行状态。

控制器130监测到有应用发生crash，捕获发生crash时的异常运行状态信息，并对其进行解析，解析出是应用A发生crash，然后解析出应用A的包名；并可以解析出发生crash是由系统导致的还是由应用A本身导致的。

若应用A发生crash是由系统导致的，则移动通信模块111将应用A发生crash时的异常运行状态信息发送至系统厂商；若应用A发生crash是由应用A本身导致的，则移动通信模块111将应用A发生crash时的异常运行状态信息发送至应用A厂商。

例如若品牌B手机中的应用A发生crash，若分析出应用A发生crash是由系统导致的，则移动通信模块111将应用A发生crash时的异常运行状态信息发送至品牌B手机的厂商，以供品牌B手机厂商的开发人员分析，以便修复应用A；若应用A发生crash是由应用A本身导致的，则移动通信模块111将应用A发生crash时的异常运行状态信息发送至应用A厂商，以供应用A厂商的开发人员分析，以便修复应用A。

控制器130在解析出应用A的包名后，调用系统包管理器，进而查询应用A崩溃crash时的缓存信息。

控制器130重新启动目标应用，根据缓存信息直接跳转至crash发生时的页面并还原页面上的操作数据。

通过本实施例的实施，从框架层面监测目标应用的crash，当目标应用发生crash时，根据所述目标应用最新的缓存信息恢复所述目标应用，使得用户感知不到应用发生过crash，提升了用户体验。

另外，还可以将目标应用发生crash时的异常运行状态信息发送至服务器，以供开发人员对crash问题进行分析解决，以便修复目标应用。这样，不管目标应用是终端操作系统中预安装的应用还是第三方应用，都能得到处理恢复，从而提升用户的体验。

第三实施例

本实施例提供了一种崩溃crash恢复方法，应用于终端，参见图5，图5为本实施例提供的崩溃crash恢复方法的流程图，该方法包括以下步骤：

S501：监测目标应用的运行状态。

其中，目标应用可以是终端操作系统中任一预安装的应用，例如终端自带的相机、音乐播放器、视频播放器、日历、天气等应用；

目标应用也可以是终端操作系统中任一第三方应用，例如百度糯米、百度地图、酷狗音乐、网易云音乐、手机淘宝等应用。

其中，操作系统包括Android等。

现有技术中，应用发生crash后都是由应用自己处理，应用仍会表现为闪退或者程序已停止运行，处理效果不够好，所以为了避免此种情况的发生，本实施例采取对Android原生系统的crash处理架构进行优化的方案，从底层对终端运行的所有应用的运行状态进行监测，使得用户感知不到应用发生过crash，提升用户体验。

目标应用的运行状态包括目标应用运行正常、目标应用运行异常，其中，目标应用运行异常造成的原因可能是目标应用发生crash。

由于终端环境和使用场景的复杂性，应用的异常处理不可能完全覆盖，终端应用发生crash的情况是比较常见的。

监测到目标应用的运行状态为运行异常时，捕获目标应用发生crash时的异常运行状态信息，还可以对发生crash时的异常运行状态信息进行分析。

不论目标应用因为什么原因闪退，只要能够捕获引起闪退的异常，那么就对异常进行处理。

其中，获取所述目标应用最新的缓存信息之前，还包括：

获取目标应用发生crash时的异常运行状态信息；

当获取到的异常运行状态信息满足预设的可恢复条件时，则进入S502的步骤。

当获取到的异常运行状态信息不满足预设的可恢复条件时，可以放弃恢复目标应用。

S502：监测到目标应用发生crash时，获取目标应用最新的缓存信息。

在接收到目标应用发生crash的通知后，调用系统包管理器，进而查询目标应用最新的缓存信息，目标应用最新的缓存信息包括该应用崩溃crash发生时的缓存信息。

S503：根据缓存信息恢复目标应用。

其中，根据缓存信息恢复目标应用包括：启动目标应用，根据缓存信息跳转至crash发生时的页面并还原页面上的操作数据。

当目标应用发生crash时，系统会kill掉目标应用程序，若不及时处理，则目标应用会表现为闪退或者程序已停止运行，这对用户来说是很不友好的，所以为了避免此种情况的发生，当监测到目标应用发生crash时，则去获取目标应用最新的缓存信息，根据获取的缓存信息恢复目标应用，使得用户感知不到应用发生过crash，提升了用户体验。

可选的，若所述目标应用发生crash，该崩溃crash恢复方法还包括：

获取目标应用发生crash时的异常运行状态信息；

将获取的异常运行状态信息发送至服务器，以供开发人员分析，以便修复目标应用。

通过本实施例的实施，从框架层面监测目标应用的crash，当目标应用发生crash时，根据所述目标应用最新的缓存信息恢复所述目标应用，使得用户感知不到应用发生过crash，提升了用户体验。

另外，还可以将目标应用发生crash时的异常运行状态信息发送至服务器，以供开发人员对crash问题进行分析解决，以便修复目标应用。这样，不管目标应用是终端操作系统中预安装的应用还是第三方应用，都能得到处理恢复，从而提升用户的体验。

第四实施例

本实施例提供了一种崩溃crash恢复方法，应用于终端，参见图6，图6为本实施例提供的崩溃crash恢复方法的流程图，该方法包括以下步骤：

S601：监测到有应用发生crash，捕获发生crash时的异常运行状态信息。

S602：对发生crash时的异常运行状态信息进行解析，解析出是应用A发生crash，然后解析出应用A的包名；并可以解析出发生crash是由系统导致的还是由应用A本身导致的。

若应用A发生crash是由系统导致的，则将应用A发生crash时的异常运行状态信息发送至系统厂商；若应用A发生crash是由应用A本身导致的，则将应用A发生crash时的异常运行状态信息发送至应用A厂商。

例如若品牌B手机中的应用A发生crash，若分析出应用A发生crash是由系统导致的，则将应用A发生crash时的异常运行状态信息发送至品牌B手机的厂商，以供品牌B手机厂商的开发人员分析，以便修复应用A；若应用A发生crash是由应用A本身导致的，则将应用A发生crash时的异常运行状态信息发送至应用A厂商，以供应用A厂商的开发人员分析，以便修复应用A。

S603：在解析出应用A的包名后，调用系统包管理器，进而查询应用A崩溃crash时的缓存信息。

S604：重新启动目标应用，根据缓存信息直接跳转至crash发生时的页面并还原页面上的操作数据。

通过本实施例的实施，从框架层面监测目标应用的crash，当目标应用发生crash时，根据所述目标应用最新的缓存信息恢复所述目标应用，使得用户感知不到应用发生过crash，提升了用户体验。

另外，还可以将目标应用发生crash时的异常运行状态信息发送至服务器，以供开发人员对crash问题进行分析解决，以便修复目标应用。这样，不管目标应用是终端操作系统中预安装的应用还是第三方应用，都能得到处理恢复，从而提升用户的体验。

需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者装置中还存在另外的相同要素。

上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，空调器，或者网络设备等)执行本发明各个实施例的方法。

以上仅为本发明的优选实施例，并非因此限制本发明的专利范围，凡是利用本发明说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本发明的专利保护范围内。

Claims (10)

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

监测模块，用于监测目标应用的运行状态；

第一获取模块，用于所述监测模块监测到所述目标应用发生crash时，获取所述目标应用最新的缓存信息；

处理模块，用于根据所述缓存信息恢复所述目标应用。

2.如权利要求1所述的崩溃crash恢复装置，其特征在于，所述处理模块用于启动所述目标应用，根据所述缓存信息跳转至crash发生时的页面并还原所述页面上的操作数据。

3.如权利要求1所述的崩溃crash恢复装置，其特征在于，还包括：

第二获取模块，用于获取所述目标应用发生crash时的异常运行状态信息；

所述第一获取模块用于所述第二获取模块获取到的所述异常运行状态信息满足预设的可恢复条件时，获取所述目标应用最新的缓存信息。

4.如权利要求1至3任一项所述的崩溃crash恢复装置，其特征在于，还包括：

第三获取模块，用于获取所述目标应用发生crash时的异常运行状态信息；

发送模块，用于将所述第三获取模块获取的所述异常运行状态信息发送至服务器。

5.一种终端，其特征在于，包括如权利要求1至4任一项所述的崩溃crash恢复装置。

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

监测目标应用的运行状态；

若所述目标应用发生crash，则获取所述目标应用最新的缓存信息；

根据所述缓存信息恢复所述目标应用。

7.如权利要求6所述的崩溃crash恢复方法，其特征在于，根据所述缓存信息恢复所述目标应用包括：

启动所述目标应用，根据所述缓存信息跳转至crash发生时的页面并还原所述页面上的操作数据。

8.如权利要求6所述的崩溃crash恢复方法，其特征在于，获取所述目标应用最新的缓存信息之前，还包括：

获取所述目标应用发生crash时的异常运行状态信息；

若所述异常运行状态信息满足预设的可恢复条件，则进入获取所述目标应用最新的缓存信息的步骤。

9.如权利要求6所述的崩溃crash恢复方法，其特征在于，所述目标应用为终端操作系统中任一预安装的应用或任一第三方应用。

10.如权利要求6至9任一项所述的崩溃crash恢复方法，其特征在于，若所述目标应用发生crash，还包括：

获取所述目标应用发生crash时的异常运行状态信息；

将所述异常运行状态信息发送至服务器。