CN104714861A - 场景恢复数据保存方法、应用运行方法、装置及系统 - Google Patents

Abstract

本申请公开了一种场景恢复数据保存方法、应用运行方法、装置及系统，包括：辅助应用当主应用运行崩溃时，从与主应用的共享内存中获取该主应用的场景恢复数据，场景恢复数据为该主应用在运行过程中实时缓存的表征该主应用运行的最新场景的数据；并将获取的该场景恢复数据保存到磁盘中；以及记录表征主应用运行崩溃的崩溃标记。采用本申请实施例提供的方案，提高了场景恢复效果，以及降低了对应用本身性能影响。

Description

场景恢复数据保存方法、应用运行方法、装置及系统

技术领域

本申请涉及计算机技术领域，尤其涉及一种场景恢复数据保存方法及装置，一种应用运行方法及装置，以及一种应用场景恢复系统。

背景技术

随着互联网技术和计算机技术的快速发展，出现了大量的业务应用，以便为用户提供各种丰富的业务服务。然而，在应用的使用过程中，由于用户操作不当，应用所处的操作系统运行异常，以及应用自身运行异常等原因，会导致出现致命错误，从而导致应用运行崩溃。

应用运行崩溃，将导致用户对应用使用的突然中断，从而对用户造成较大影响。例如，对于即时通信应用，应用运行崩溃将导致用户与对方的通信中断，对于商机助理类应用，应用运行崩溃将导致用户输入内容的丢失。

为了缓解应用运行崩溃对用户造成的影响，现有技术中出现了在应用运行崩溃后，恢复应用场景的方法，即在应用运行的过程中，将表征应用运行的场景的数据进行保存，该数据作为场景恢复数据，在应用重新启动后，用于使用保存的该场景恢复数据，进行应用运行的场景的恢复。例如，恢复应用运行的交互界面、用户输入的数据内容等。

目前，在上述方案中，应用是按照预设的时间间隔自动保存场景恢复数据，然而，该时间间隔如果设置的较长，将导致在场景恢复后，丢失较多的场景内容，该时间间隔如果设置的较短，则需要频繁的保存场景恢复数据，从而严重降低了应用本身的性能。

综上可知，现有技术中在针对应用运行崩溃的情况进行应用场景恢复时，存在场景恢复效果较差，以及对应用本身性能影响较大的问题。

发明内容

有鉴于此，本申请实施例提供一种场景恢复数据保存方法、应用运行方法、装置及系统，用于解决现有技术中存在的针对应用运行崩溃的情况进行应用场景恢复时，场景恢复效果较差，以及对应用本身性能影响较大的问题。

本申请实施例通过如下技术方案实现：

本申请实施例提供一种场景恢复数据保存方法，包括：

辅助应用当主应用运行崩溃时，从与所述主应用的共享内存中获取所述主应用的场景恢复数据，所述场景恢复数据为所述主应用在运行过程中实时缓存的表征所述主应用运行的最新场景的数据；

将获取的所述场景恢复数据保存到磁盘中；

记录表征所述主应用运行崩溃的崩溃标记。

本申请实施例还提供一种应用运行方法，包括：

主应用在运行的过程中，实时将表征所述主应用运行的最新场景的数据，缓存到与辅助应用的共享内存中，所述数据作为场景恢复数据用于在所述主应用运行崩溃时，由辅助应用保存到磁盘中；

所述主应用在启动后，当确定记录有表征所述主应用在上一次运行时崩溃的崩溃标记时，从磁盘中获取保存的所述场景恢复数据；

使用所述场景恢复数据，将所述主应用运行的场景恢复到所述主应用崩溃之前的场景。

本申请实施例还提供一种场景恢复数据保存装置，集成于辅助应用，包括：

数据获取单元，用于当主应用运行崩溃时，从与所述主应用的共享内存中获取所述主应用的场景恢复数据，所述场景恢复数据为所述主应用在运行过程中实时缓存的表征所述主应用运行的最新场景的数据；

数据保存单元，用于将获取的所述场景恢复数据保存到磁盘中；

标记记录单元，用于记录表征所述主应用运行崩溃的崩溃标记。

本申请实施例还提供一种应用运行装置，集成于主应用，包括：

数据缓存单元，用于在所述主应用运行的过程中，实时将表征所述主应用运行的最新场景的数据，缓存到与辅助应用的共享内存中，所述数据作为场景恢复数据用于在所述主应用运行崩溃时，由辅助应用保存到磁盘中；

数据获取单元，用于在所述主应用启动后，当确定记录有表征所述主应用在上一次运行时崩溃的崩溃标记时，从磁盘中获取保存的所述场景恢复数据；

场景恢复单元，用于使用所述场景恢复数据，将所述主应用运行的场景恢复到所述主应用崩溃之前的场景。

本申请实施例还提供一种应用场景恢复系统，包括：主应用和辅助应用，其中：

所述辅助应用，用于在所述主应用运行崩溃时，从与所述主应用的共享内存中获取所述主应用的场景恢复数据；并将获取的所述场景恢复数据保存到磁盘中；以及记录表征所述主应用运行崩溃的崩溃标记；

所述主应用，用于在运行的过程中，实时将表征所述主应用运行的最新场景的数据作为所述场景恢复数据，缓存到与所述辅助应用的共享内存中；并在启动后，当确定记录有表征所述主应用在上一次运行时崩溃的所述崩溃标记时，从磁盘中获取保存的所述场景恢复数据；以及使用所述场景恢复数据，将所述主应用运行的场景恢复到所述主应用崩溃之前的场景。

采用本申请实施例提供的上述方案，主应用在运行过程中是实时缓存场景恢复数据，且场景恢复数据能够表征主应用运行的最新场景，从而使得使用该场景恢复数据能够将主应用运行的场景恢复到主应用崩溃之前的场景，即减少了场景内容的丢失；并且，主应用是将场景恢复数据缓存到内存中，而并非是保存到磁盘中，是由辅助应用将场景恢复数据保存到磁盘中，从而即便是频繁的缓存场景恢复数据，也不会对主应用本身的性能造成较大影响，即降低了对主应用性能的影响。

本申请实施例还提供一种场景恢复数据保存方法，包括：

辅助应用接收主应用在运行过程中实时发送的表征所述主应用运行的最新场景的数据；

将接收的所述数据作为场景恢复数据缓存到内存中；

当所述主应用运行崩溃时，从所述内存中获取所述场景恢复数据并保存到磁盘中；

记录表征所述主应用运行崩溃的崩溃标记。

本申请实施例还提供一种应用运行方法，包括：

主应用在运行的过程中，实时向辅助应用发送表征所述主应用运行的最新场景的数据，由所述辅助应用将接收的所述数据作为场景恢复数据缓存到内存中，并由所述辅助应用当所述主应用运行崩溃时，从所述内存中获取所述场景恢复数据并保存到磁盘中；

所述主应用在启动后，当确定记录有表征所述主应用在上一次运行时崩溃的崩溃标记时，从磁盘中获取保存的所述场景恢复数据；

使用所述场景恢复数据，将所述主应用运行的场景恢复到所述主应用崩溃之前的场景。

本申请实施例还提供一种场景恢复数据保存装置，集成于辅助应用，包括：

数据接收单元，用于接收主应用在运行过程中实时发送的表征所述主应用运行的最新场景的数据；

缓存单元，用于将接收的所述数据作为场景恢复数据缓存到内存中；

数据保存单元，用于当所述主应用运行崩溃时，从所述内存中获取所述场景恢复数据并保存到磁盘中；

标记记录单元，用于记录表征所述主应用运行崩溃的崩溃标记。

本申请实施例还提供一种应用运行装置，集成于主应用，包括：

数据发送单元，用于在运行的过程中，实时向辅助应用发送表征所述主应用运行的最新场景的数据，由所述辅助应用将接收的所述数据作为场景恢复数据缓存到内存中，并由所述辅助应用当所述主应用运行崩溃时，从所述内存中获取所述场景恢复数据并保存到磁盘中；

数据获取单元，用于所述主应用在启动后，当确定记录有表征所述主应用在上一次运行时崩溃的崩溃标记时，从磁盘中获取保存的所述场景恢复数据；

场景恢复单元，用于使用所述场景恢复数据，将所述主应用运行的场景恢复到所述主应用崩溃之前的场景。

本申请实施例还提供一种应用场景恢复系统，包括：主应用和辅助应用，其中：

所述辅助应用，用于接收所述主应用在运行过程中实时发送的表征所述主应用运行的最新场景的数据；并将接收的所述数据作为场景恢复数据缓存到内存中；并当所述主应用运行崩溃时，从所述内存中获取所述场景恢复数据并保存到磁盘中；以及记录表征所述主应用运行崩溃的崩溃标记；

所述主应用，用于在运行的过程中，实时向所述辅助应用发送表征所述主应用运行的最新场景的数据；并在启动后，当确定记录有表征所述主应用在上一次运行时崩溃的崩溃标记时，从磁盘中获取保存的所述场景恢复数据；以及使用所述场景恢复数据，将所述主应用运行的场景恢复到所述主应用崩溃之前的场景。

采用本申请实施例提供的上述方案，主应用在运行过程中是实时缓存场景恢复数据，且场景恢复数据能够表征主应用运行的最新场景，从而使得使用该场景恢复数据能够将主应用运行的场景恢复到主应用崩溃之前的场景，即减少了场景内容的丢失；并且，主应用是将场景恢复数据缓存到内存中，而并非是保存到磁盘中，是由辅助应用将场景恢复数据保存到磁盘中，从而即便是频繁的缓存场景恢复数据，也不会对主应用本身的性能造成较大影响，即降低了对主应用性能的影响。

本申请的其它特征和优点将在随后的说明书中阐述，并且，部分地从说明书中变得显而易见，或者通过实施本申请而了解。本申请的目的和其他优点可通过在所写的说明书、权利要求书、以及附图中所特别指出的结构来实现和获得。

附图说明

附图用来提供对本申请的进一步理解，并且构成说明书的一部分，与本申请实施例一起用于解释本申请，并不构成对本申请的限制。在附图中：

图1为本申请实施例1提供的场景恢复数据保存方法的流程图；

图2为本申请实施例1提供的应用运行方法的流程图；

图3为本申请实施例1提供的应用运行过程中保存场景恢复数据的流程图之一；

图4为本申请实施例1提供的应用运行过程中保存场景恢复数据的流程图之二；

图5为本申请实施例1提供的在应用运行崩溃后恢复应用场景的流程图；

图6为本申请实施例1提供的场景恢复数据保存装置的结构示意图；

图7为本申请实施例1提供的应用运行装置的结构示意图；

图8为本申请实施例1提供的应用场景恢复系统的结构示意图；

图9为本申请实施例2提供的场景恢复数据保存方法的流程图；

图10为本申请实施例2提供的应用运行方法的流程图；

图11为本申请实施例2提供的应用运行过程中保存场景恢复数据的流程图；

图12为本申请实施例2提供的场景恢复数据保存装置的结构示意图；

图13为本申请实施例2提供的应用运行装置的结构示意图；

图14为本申请实施例2提供的应用场景恢复系统的结构示意图。

具体实施方式

为了给出针对应用运行崩溃的情况进行应用场景恢复时，提高场景恢复效果，以及降低对应用本身性能影响的实现方案，本申请实施例提供了一种场景恢复数据保存方法、应用运行方法、装置及系统，该技术方案可以应用于对应用场景进行恢复的过程，既可以实现为一种方法，也可以实现为一种装置和系统。以下结合说明书附图对本申请的优选实施例进行说明，应当理解，此处所描述的优选实施例仅用于说明和解释本申请，并不用于限定本申请。并且在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。

实施例1：

本申请实施1提供一种场景恢复数据保存方法，如图1所示，包括：

步骤101、辅助应用当主应用运行崩溃时，从与主应用的共享内存中获取主应用的场景恢复数据，场景恢复数据为主应用在运行过程中实时缓存的表征主应用运行的最新场景的数据。

步骤102、将获取的该场景恢复数据保存到磁盘中。

步骤103、记录表征主应用运行崩溃的崩溃标记。

通过上述场景恢复数据保存方法，可以当主应用运行崩溃时，将内存中缓存的场景恢复数据保存到磁盘中，以便后续在主应用重新启动后，使用该场景恢复数据，将主应用运行的场景恢复到主应用崩溃之前的场景。

相应的，本申请实施例1还提供了一种应用运行方法，如图2所示，包括：

步骤201、主应用在运行的过程中，实时将表征主应用运行的最新场景的数据，缓存到与辅助应用的共享内存中，该数据作为场景恢复数据用于在主应用运行崩溃时，被保存到磁盘中。

步骤202、主应用在启动后，当确定记录有表征主应用在上一次运行时崩溃的崩溃标记时，从磁盘中获取保存的该场景恢复数据。

步骤203、使用该场景恢复数据，将主应用运行的场景恢复到主应用崩溃之前的场景。

进一步的，在上述图1和图2所述的方法中，主应用在启动后，可以设置回调函数，用于在主应用运行崩溃时，通过该回调函数触发辅助应用保存该场景恢复数据到磁盘中。

在上述图1和图2所述的方法中，主应用也可以与辅助应用之间执行心跳机制，由辅助应用检测主应用的运行状态，并在根据与主应用之间的心跳机制，在监测到主应用运行崩溃时，从与主应用的共享内存中获取主应用的场景恢复数据，并保存到磁盘中。

下面结合附图，用具体实施例对本申请提供的方法及装置和相应系统进行详细描述。

图3为本申请实施例1提供的应用运行过程中保存场景恢复数据的流程图，在图3所示流程中，是通过主应用预设的回调函数触发辅助应用的启动，具体包括如下处理步骤：

步骤301、主应用在启动后，设置回调函数。

该回调函数用于在该主应用运行崩溃后，触发保存场景恢复数据到磁盘中，详见后续描述，该回调函数可以称作崩溃（crash）回调函数。

步骤302、该主应用在运行的过程中，实时将表征该主应用运行的最新场景的数据，缓存到与辅助应用的共享内存中，该数据即作为场景恢复数据。

本步骤中，实时缓存具体可以为每当主应用运行的场景发生变化时，即缓存表征该主应用运行的最新场景的数据。

其中，场景恢复数据可以根据主应用的实际特性和使用中的实际需要进行灵活设置。例如，场景恢复数据中可以包括窗口唯一标识；以及窗口状态信息，如聊天窗口是否为合并模式，聊天记录是否展开等；以及数据内容，如聊天记录，文本编辑框中已经输入的内容等。

本步骤中，在缓存场景恢复数据时，可以采用重新覆盖和增量更新相结合的方式缓存，例如，场景恢复数据的存储方式可以为key-value（键值对）的方式，在每次缓存时，根据当前已定义的key-value的方式，查找key对应的value进行覆盖更新，如果存在未定义的key，则增加该key，并缓存该key对应的value。

本步骤中，为了降低对应用本身运行性能的影响，是将场景恢复数据缓存到内存中，并且是与辅助应用的共享内存，相当于在应用进程中通过文件映射（内存共享）的方式，在内存中缓存场景恢复数据。

步骤303、当该主应用运行崩溃时，通过crash回调函数触发辅助应用启动，具体的，也可以是触发辅助进程启动。

步骤304、辅助应用在通过crash回调函数被触发启动后，即表示该主应用运行崩溃，则辅助应用从与该主应用的共享内存中获取该主应用的场景恢复数据。

本步骤中，辅助应用具体可以通过读内存映射的方式，从与主应用的共享内存中获取该主应用的场景恢复数据。

步骤305、辅助应用将获取的该主应用的场景恢复数据保存到磁盘中。

具体可以将获取的该主应用的场景恢复数据写入磁盘文件中。

步骤306、辅助应用记录表征该主应用运行崩溃的崩溃标记。

通过上述图3所示流程，主应用在运行过程中是实时缓存场景恢复数据，且场景恢复数据能够表征主应用运行的最新场景，从而使得使用该场景恢复数据能够将主应用运行的场景恢复到应用崩溃之前的场景，即减少了场景内容的丢失。

并且，是将场景恢复数据缓存到内存中，而并非是保存到磁盘中，从而即便是频繁的缓存场景恢复数据，也不会对主应用本身的性能造成较大影响，相比现有技术中由该主应用将场景恢复数据保存到磁盘中，降低了对应用性能的影响。

图4为本申请实施例1提供的应用运行过程中保存场景恢复数据的流程图，在图4所示流程中，是通过主应用辅助应用之间执行的心跳机制，由辅助应用监测主应用的运行状态，并在主应用运行崩溃时，触发从与主应用的共享内存中获取主应用的场景恢复数据，并保存到磁盘中，具体包括如下处理步骤：

步骤401、主应用在运行的过程中，与辅助应用之间执行心跳机制。

具体可以为主应用定时向辅助应用发送心跳信息，以便辅助应用可以基于是否能够定时收到来自主应用的心跳信息，确定主应用的运行状态为正常，或者运行崩溃。

步骤402、主应用在运行的过程中，实时将表征该主应用运行的最新场景的数据，缓存到与辅助应用的共享内存中，该数据即作为场景恢复数据。

本步骤中，实时缓存具体可以为每当主应用运行的场景发生变化时，即缓存表征该主应用运行的最新场景的数据。

其中，场景恢复数据可以根据主应用的实际特性和使用中的实际需要进行灵活设置。例如，场景恢复数据中可以包括窗口唯一标识；以及窗口状态信息，如聊天窗口是否为合并模式，聊天记录是否展开等；以及数据内容，如聊天记录，文本编辑框中已经输入的内容等。

本步骤中，在缓存场景恢复数据时，可以采用重新覆盖和增量更新相结合的方式缓存，例如，场景恢复数据的存储方式可以为key-value（键值对）的方式，在每次缓存时，根据当前已定义的key-value的方式，查找key对应的value进行覆盖更新，如果存在未定义的key，则增加该key，并缓存该key对应的value。

本步骤中，为了降低对应用本身运行性能的影响，是将场景恢复数据缓存到内存中，并且是与辅助应用的共享内存，相当于在应用进程中通过文件映射（内存共享）的方式，在内存中缓存场景恢复数据。

步骤403、辅助应用在启动后，通过与主应用之间执行的心跳机制，监测主应用的运行状态，当监测结果为运行正常时，返回本步骤继续监测，当监测结果为主应用运行崩溃时，进入步骤404。

本步骤中，当该主应用运行崩溃时，则无法再继续定时向辅助应用发送心跳信息，辅助应用在经过预设时长为接收到来自主应用的心跳信息时，可以确定主应用运行崩溃。

步骤404、为了进一步更准确的确定主应用是否崩溃，还可以查看当前系统程序表，确定当前系统程序表中是否存在主应用的应用标识，如果存在，表示主应用的运行状态可能是正常的，只是心跳机制出现异常，所以，此时可以返回上述步骤403继续监测，如果不存在，表示主应用运行崩溃，进入步骤405。

进一步的，也可以在确定不存在时，统计连续执行本步骤的确定结果均为不存在的次数，并当该次数达到预设次数阈值，进入步骤405。

本步骤404为可选步骤，也可以在上述步骤403中，当监测结果为主应用运行崩溃时，直接进入后续步骤405。

步骤405、辅助应用从与该主应用的共享内存中获取该主应用的场景恢复数据。

本步骤中，辅助应用具体可以通过读内存映射的方式，从与主应用的共享内存中获取该主应用的场景恢复数据。

步骤406、辅助应用将获取的该主应用的场景恢复数据保存到磁盘中。

具体可以将获取的该主应用的场景恢复数据写入磁盘文件中。

步骤407、辅助应用记录表征该主应用运行崩溃的崩溃标记。

通过上述图4所示流程，主应用在运行过程中是实时缓存场景恢复数据，且场景恢复数据能够表征主应用运行的最新场景，从而使得使用该场景恢复数据能够将主应用运行的场景恢复到应用崩溃之前的场景，即减少了场景内容的丢失。

并且，是将场景恢复数据缓存到内存中，而并非是保存到磁盘中，从而即便是频繁的缓存场景恢复数据，也不会对主应用本身的性能造成较大影响，相比现有技术中由该主应用将场景恢复数据保存到磁盘中，降低了对应用性能的影响。

图5为本申请实施例1提供的在应用运行崩溃后恢复应用场景的流程图，具体包括如下处理步骤：

步骤501、主应用在启动后，判断是否记录有表征该主应用在上一次运行时崩溃的崩溃标记，如果有，进入步骤502，否则，进入步骤505。

步骤502、主应用提示用户是否需要进行场景恢复，当用户选择进行场景恢复时，进入步骤503，当用户选择不进行场景恢复时，进入步骤505。

步骤503、主应用从磁盘中获取保存的该主应用的场景恢复数据，使用该场景恢复数据，将该主应用运行的场景恢复到该主应用崩溃之前的场景。

步骤504、在完成主应用的场景恢复之后，删除记录的该崩溃标记，然后进入步骤505。

步骤505、主应用进入正常的启动运行流程。

基于同一发明构思，根据本申请上述实施例1提供的场景恢复数据保存方法，相应地，本申请实施例1还提供了一种场景恢复数据保存装置，集成于辅助应用，其结构示意图如图6所示，具体包括：

数据获取单元601，用于当主应用运行崩溃时，从与所述主应用的共享内存中获取所述主应用的场景恢复数据，所述场景恢复数据为所述主应用在运行过程中实时缓存的表征所述主应用运行的最新场景的数据；

数据保存单元602，用于将获取的所述场景恢复数据保存到磁盘中；

标记记录单元603，用于记录表征所述主应用运行崩溃的崩溃标记。

进一步的，数据获取单元601，具体用于由主应用在启动后设置的回调函数在所述主应用运行崩溃时触发启动，并在启动后从与所述主应用的共享内存中获取所述主应用的场景恢复数据。

进一步的，数据获取单元601，具体用于根据与主应用之间的心跳机制，在监测到所述主应用运行崩溃时，从与所述主应用的共享内存中获取所述主应用的场景恢复数据。

进一步的，数据获取单元601，还用于在从与所述主应用的共享内存中获取所述主应用的场景恢复数据之前，确定当前系统程序表中不存在所述主应用的应用标识。

上述各单元的功能可对应于图1至图5所示流程中的相应处理步骤，在此不再赘述。

基于同一发明构思，根据本申请上述实施例1提供的应用运行方法，相应地，本申请实施例1还提供了一种应用运行装置，集成于主应用，其结构示意图如图7所示，具体包括：

数据缓存单元701，用于在所述主应用运行的过程中，实时将表征所述主应用运行的最新场景的数据，缓存到与辅助应用的共享内存中，所述数据作为场景恢复数据用于在所述主应用运行崩溃时，由辅助应用保存到磁盘中；

数据获取单元702，用于在所述主应用启动后，当确定记录有表征所述主应用在上一次运行时崩溃的崩溃标记时，从磁盘中获取保存的所述场景恢复数据；

场景恢复单元703，用于使用所述场景恢复数据，将所述主应用运行的场景恢复到所述主应用崩溃之前的场景。

进一步的，上述应用运行装置，还包括：

函数设置单元704，用于在所述主应用启动后，设置回调函数，用于在所述主应用运行崩溃时，通过所述回调函数触发所述辅助应用保存所述场景恢复数据到磁盘中。

进一步的，上述应用运行装置，还包括：

心跳执行单元705，用于与所述辅助应用之间执行心跳机制，并由所述辅助应用根据心跳机制在监测到所述主应用运行崩溃时保存所述场景恢复数据到磁盘中。

进一步的，场景恢复单元703，还用于在使用所述场景恢复数据，将所述主应用运行的场景恢复到所述主应用崩溃之前的场景之后，删除所述崩溃标记。

上述各单元的功能可对应于图1至图5所示流程中的相应处理步骤，在此不再赘述。

基于同一发明构思，根据本申请上述实施例1提供的场景恢复数据保存方法和应用运行方法，相应地，本申请实施例1还提供了一种应用场景恢复系统，其结构示意图如图8所示，具体包括：包括：主应用801和辅助应用802，其中：

辅助应用802，用于在主应用801运行崩溃时，从与所述主应用801的共享内存中获取所述主应用801的场景恢复数据；并将获取的所述场景恢复数据保存到磁盘中；以及记录表征所述主应用801运行崩溃的崩溃标记；

主应用801，用于在运行的过程中，实时将表征所述主应用801运行的最新场景的数据作为所述场景恢复数据，缓存到与所述辅助应用802的共享内存中；并在启动后，当确定记录有表征所述主应用801在上一次运行时崩溃的所述崩溃标记时，从磁盘中获取保存的所述场景恢复数据；以及使用所述场景恢复数据，将所述主应用801运行的场景恢复到所述主应用801崩溃之前的场景。

进一步的，上述主应用801和辅助应用802的其他功能和所执行的处理流程可对应于图1至图5所示流程中的相应处理步骤，在此不再赘述。

综上所述，本申请实施例提供的方案，包括：辅助应用当主应用运行崩溃时，从与主应用的共享内存中获取该应用的场景恢复数据，场景恢复数据为该主应用在运行过程中实时缓存的表征该主应用运行的最新场景的数据；并将获取的该场景恢复数据保存到磁盘中；以及记录表征该主应用运行崩溃的崩溃标记。采用本申请实施例提供的方案，提高了场景恢复效果，以及降低了对应用本身性能影响。

实施例2：

本申请实施2提供一种场景恢复数据保存方法，如图9所示，包括：

步骤901、辅助应用接收主应用在运行过程中实时发送的表征主应用运行的最新场景的数据。

步骤902、将接收的数据作为场景恢复数据缓存到内存中。

步骤903、当主应用运行崩溃时，从内存中获取该场景恢复数据并保存到磁盘中。

步骤904、记录表征主应用运行崩溃的崩溃标记。

通过上述场景恢复数据保存方法，可以当主应用运行崩溃时，将内存中缓存的场景恢复数据保存到磁盘中，以便后续在主应用重新启动后，使用该场景恢复数据，将主应用运行的场景恢复到主应用崩溃之前的场景。

相应的，本申请实施例2还提供了一种应用运行方法，如图10所示，包括：

步骤1001、主应用在运行的过程中，实时向辅助应用发送表征主应用运行的最新场景的数据，由辅助应用将接收的数据作为场景恢复数据缓存到内存中，并由辅助应用当主应用运行崩溃时，从内存中获取该场景恢复数据并保存到磁盘中。

步骤1002、主应用在启动后，当确定记录有表征主应用在上一次运行时崩溃的崩溃标记时，从磁盘中获取保存的该场景恢复数据。

步骤1003、使用该场景恢复数据，将主应用运行的场景恢复到主应用崩溃之前的场景。

下面结合附图，用具体实施例对本申请提供的方法及装置和相应系统进行详细描述。

图11为本申请实施例2提供的应用运行过程中保存场景恢复数据的流程图，在图11所示流程中，是通过主应用辅助应用之间执行的心跳机制，由辅助应用监测主应用的运行状态，确定主应用是否运行崩溃，具体包括如下处理步骤：

步骤1101、主应用在运行的过程中，与辅助应用之间执行心跳机制。

具体可以为主应用定时向辅助应用发送心跳信息，以便辅助应用可以基于是否能够定时收到来自主应用的心跳信息，确定主应用的运行状态为正常，或者运行崩溃。

步骤1102、主应用在运行的过程中，实时向辅助应用发送表征该主应用运行的最新场景的数据。

步骤1103、辅助应用在接收到主应用发送的数据后，将接收的数据作为场景恢复数据缓存到内存中。

本步骤中，实时缓存具体可以为每次接收到主应用发送的数据时，即缓存表征该主应用运行的最新场景的数据。

其中，场景恢复数据可以根据主应用的实际特性和使用中的实际需要进行灵活设置。例如，场景恢复数据中可以包括窗口唯一标识；以及窗口状态信息，如聊天窗口是否为合并模式，聊天记录是否展开等；以及数据内容，如聊天记录，文本编辑框中已经输入的内容等。

本步骤中，在缓存场景恢复数据时，可以采用重新覆盖和增量更新相结合的方式缓存，例如，场景恢复数据的存储方式可以为key-value（键值对）的方式，在每次缓存时，根据当前已定义的key-value的方式，查找key对应的value进行覆盖更新，如果存在未定义的key，则增加该key，并缓存该key对应的value。

本发明实施例2中，主应用与辅助应用可以运行在不同的设备上，所以，辅助应用缓存场景恢复数据的内存，可以为与主应用运行的设备不同的设备的内存。

步骤1104、辅助应用在启动后，通过与主应用之间执行的心跳机制，监测主应用的运行状态，当监测结果为运行正常时，返回本步骤继续监测，当监测结果为主应用运行崩溃时，进入步骤1105。

本步骤中，当该主应用运行崩溃时，则无法再继续定时向辅助应用发送心跳信息，辅助应用在经过预设时长为接收到来自主应用的心跳信息时，可以确定主应用运行崩溃。

步骤1105、为了进一步更准确的确定主应用是否崩溃，还可以查看当前系统程序表，确定当前系统程序表中是否存在主应用的应用标识，如果存在，表示主应用的运行状态可能是正常的，只是心跳机制出现异常，所以，此时可以返回上述步骤1104继续监测，如果不存在，表示主应用运行崩溃，进入步骤11006。

进一步的，也可以在确定不存在时，统计连续执行本步骤的确定结果均为不存在的次数，并当该次数达到预设次数阈值，进入步骤1106。

本步骤1105为可选步骤，也可以在上述步骤1104中，当监测结果为主应用运行崩溃时，直接进入后续步骤1106。

步骤1106、辅助应用从内存中获取该主应用的场景恢复数据。

步骤1107、辅助应用将获取的该主应用的场景恢复数据保存到磁盘中。

具体可以将获取的该主应用的场景恢复数据写入磁盘文件中。

步骤1108、辅助应用记录表征该主应用运行崩溃的崩溃标记。

通过上述图11所示流程，主应用在运行过程中是实时缓存场景恢复数据，且场景恢复数据能够表征主应用运行的最新场景，从而使得使用该场景恢复数据能够将主应用运行的场景恢复到应用崩溃之前的场景，即减少了场景内容的丢失。

并且，是将场景恢复数据缓存到内存中，而并非是保存到磁盘中，从而即便是频繁的缓存场景恢复数据，也不会对主应用本身的性能造成较大影响，相比现有技术中由该主应用将场景恢复数据保存到磁盘中，降低了对应用性能的影响。

并且，主应用与辅助应用可以运行在不同的设备上，从而使得即便主应用由于所运行的设备死机导致崩溃，也可以进行有效的场景恢复。

在本发明实施例2中，在使用磁盘中存储的场景恢复数据，在应用运行崩溃后恢复应用场景时，可以采用上述实施例1中图5所示的流程，当主应用与辅助应用运行在不同的设备上时，主应用可以直接从辅助应用运行的设备的磁盘中获取场景恢复数据，也可以通过辅助应用获取，并发送给主应用。

基于同一发明构思，根据本申请上述实施例2提供的场景恢复数据保存方法，相应地，本申请实施例2还提供了一种场景恢复数据保存装置，集成于辅助应用，其结构示意图如图12所示，具体包括：

数据接收单元1201，用于接收主应用在运行过程中实时发送的表征所述主应用运行的最新场景的数据；

缓存单元1202，用于将接收的所述数据作为场景恢复数据缓存到内存中；

数据保存单元1203，用于当所述主应用运行崩溃时，从所述内存中获取所述场景恢复数据并保存到磁盘中；

标记记录单元1204，用于记录表征所述主应用运行崩溃的崩溃标记。

进一步的，数据保存单元1203，具体用于根据与主应用之间的心跳机制，在监测到所述主应用运行崩溃时，从所述内存中获取所述场景恢复数据并保存到磁盘中。

进一步的，数据保存单元1203，还用于在从所述内存中获取所述场景恢复数据并保存到磁盘中之前，确定当前系统程序表中不存在所述主应用的应用标识。

上述各单元的功能可对应于图9至图11所示流程中的相应处理步骤，在此不再赘述。

基于同一发明构思，根据本申请上述实施例2提供的应用运行方法，相应地，本申请实施例2还提供了一种应用运行装置，集成于主应用，其结构示意图如图13所示，具体包括：

数据发送单元1301，用于在运行的过程中，实时向辅助应用发送表征所述主应用运行的最新场景的数据，由所述辅助应用将接收的所述数据作为场景恢复数据缓存到内存中，并由所述辅助应用当所述主应用运行崩溃时，从所述内存中获取所述场景恢复数据并保存到磁盘中；

数据获取单元1302，用于所述主应用在启动后，当确定记录有表征所述主应用在上一次运行时崩溃的崩溃标记时，从磁盘中获取保存的所述场景恢复数据；

场景恢复单元1303，用于使用所述场景恢复数据，将所述主应用运行的场景恢复到所述主应用崩溃之前的场景。

进一步的，上述应用运行装置，还包括：

心跳执行单元1304，用于与所述辅助应用之间执行心跳机制，并由所述辅助应用根据心跳机制在监测到所述主应用运行崩溃时保存所述场景恢复数据到磁盘中。

进一步的，场景恢复单元1303，还用于在使用所述场景恢复数据，将所述主应用运行的场景恢复到所述主应用崩溃之前的场景之后，删除所述崩溃标记。

上述各单元的功能可对应于图9至图11所示流程中的相应处理步骤，在此不再赘述。

基于同一发明构思，根据本申请上述实施例2提供的场景恢复数据保存方法和应用运行方法，相应地，本申请实施例2还提供了一种应用场景恢复系统，其结构示意图如图14所示，具体包括：包括：主应用1401和辅助应用1402，其中：

辅助应用1402，用于接收所述主应用1401在运行过程中实时发送的表征所述主应用1401运行的最新场景的数据；并将接收的所述数据作为场景恢复数据缓存到内存中；并当所述主应用1401运行崩溃时，从所述内存中获取所述场景恢复数据并保存到磁盘中；以及记录表征所述主应用1401运行崩溃的崩溃标记；

主应用1401，用于在运行的过程中，实时向所述辅助应用1402发送表征所述主应用1401运行的最新场景的数据；并在启动后，当确定记录有表征所述主应用1401在上一次运行时崩溃的崩溃标记时，从磁盘中获取保存的所述场景恢复数据；以及使用所述场景恢复数据，将所述主应用1401运行的场景恢复到所述主应用1401崩溃之前的场景。

进一步的，上述主应用1401和辅助应用1402的其他功能和所执行的处理流程可对应于图9至图11所示流程中的相应处理步骤，在此不再赘述。

综上所述，本申请实施例提供的方案，包括：辅助应用接收主应用在运行过程中实时发送的表征主应用运行的最新场景的数据；并将接收的数据作为场景恢复数据缓存到内存中；并当主应用运行崩溃时，从内存中获取该场景恢复数据并保存到磁盘中；以及记录表征主应用运行崩溃的崩溃标记。采用本申请实施例提供的方案，提高了场景恢复效果，以及降低了对应用本身性能影响。

本申请的实施例所提供的场景恢复数据保存装置和应用运行装置可通过计算机程序实现。本领域技术人员应该能够理解，上述的模块划分方式仅是众多模块划分方式中的一种，如果划分为其他模块或不划分模块，只要场景恢复数据保存装置和应用运行装置具有上述功能，都应该在本申请的保护范围之内。

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

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

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

在一个典型的配置中，所述计算机设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括非持续性的电脑可读媒体(transitory media)，如调制的数据信号和载波。

显然，本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精神和范围。这样，倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。

Claims (31)

1.一种场景恢复数据保存方法，其特征在于，包括：

辅助应用当主应用运行崩溃时，从与所述主应用的共享内存中获取所述主应用的场景恢复数据，所述场景恢复数据为所述主应用在运行过程中实时缓存的表征所述主应用运行的最新场景的数据；

将获取的所述场景恢复数据保存到磁盘中；

记录表征所述主应用运行崩溃的崩溃标记。

2.如权利要求1所述的方法，其特征在于，辅助应用当主应用运行崩溃时，从与所述主应用的共享内存中获取所述主应用的场景恢复数据，具体包括：

辅助应用由主应用在启动后设置的回调函数在所述主应用运行崩溃时触发启动，并在启动后从与所述主应用的共享内存中获取所述主应用的场景恢复数据。

3.如权利要求1所述的方法，其特征在于，辅助应用当主应用运行崩溃时，从与所述主应用的共享内存中获取所述主应用的场景恢复数据，具体包括：

辅助应用根据与主应用之间的心跳机制，在监测到所述主应用运行崩溃时，从与所述主应用的共享内存中获取所述主应用的场景恢复数据。

4.如权利要求3所述的方法，其特征在于，在从与所述主应用的共享内存中获取所述主应用的场景恢复数据之前，还包括：

确定当前系统程序表中不存在所述主应用的应用标识。

5.一种应用运行方法，其特征在于，包括：

主应用在运行的过程中，实时将表征所述主应用运行的最新场景的数据，缓存到与辅助应用的共享内存中，所述数据作为场景恢复数据用于在所述主应用运行崩溃时，由辅助应用保存到磁盘中；

所述主应用在启动后，当确定记录有表征所述主应用在上一次运行时崩溃的崩溃标记时，从磁盘中获取保存的所述场景恢复数据；

使用所述场景恢复数据，将所述主应用运行的场景恢复到所述主应用崩溃之前的场景。

6.如权利要求5所述的方法，其特征在于，还包括：

所述主应用在启动后，设置回调函数，用于在所述主应用运行崩溃时，通过所述回调函数触发所述辅助应用保存所述场景恢复数据到磁盘中。

7.如权利要求5所述的方法，其特征在于，还包括：

所述主应用与所述辅助应用之间执行心跳机制，并由所述辅助应用根据心跳机制在监测到所述主应用运行崩溃时保存所述场景恢复数据到磁盘中。

8.如权利要求5-7任一所述的方法，其特征在于，在使用所述场景恢复数据，将所述主应用运行的场景恢复到所述主应用崩溃之前的场景之后，还包括：

删除所述崩溃标记。

9.一种场景恢复数据保存装置，集成于辅助应用，其特征在于，包括：

数据获取单元，用于当主应用运行崩溃时，从与所述主应用的共享内存中获取所述主应用的场景恢复数据，所述场景恢复数据为所述主应用在运行过程中实时缓存的表征所述主应用运行的最新场景的数据；

数据保存单元，用于将获取的所述场景恢复数据保存到磁盘中；

标记记录单元，用于记录表征所述主应用运行崩溃的崩溃标记。

10.如权利要求9所述的装置，其特征在于，所述数据获取单元，具体用于由主应用在启动后设置的回调函数在所述主应用运行崩溃时触发启动，并在启动后从与所述主应用的共享内存中获取所述主应用的场景恢复数据。

11.如权利要求9所述的装置，其特征在于，所述数据获取单元，具体用于根据与主应用之间的心跳机制，在监测到所述主应用运行崩溃时，从与所述主应用的共享内存中获取所述主应用的场景恢复数据。

12.如权利要求11所述的装置，其特征在于，所述数据获取单元，还用于在从与所述主应用的共享内存中获取所述主应用的场景恢复数据之前，确定当前系统程序表中不存在所述主应用的应用标识。

13.一种应用运行装置，集成于主应用，其特征在于，包括：

数据缓存单元，用于在所述主应用运行的过程中，实时将表征所述主应用运行的最新场景的数据，缓存到与辅助应用的共享内存中，所述数据作为场景恢复数据用于在所述主应用运行崩溃时，由辅助应用保存到磁盘中；

数据获取单元，用于在所述主应用启动后，当确定记录有表征所述主应用在上一次运行时崩溃的崩溃标记时，从磁盘中获取保存的所述场景恢复数据；

场景恢复单元，用于使用所述场景恢复数据，将所述主应用运行的场景恢复到所述主应用崩溃之前的场景。

14.如权利要求13所述的装置，其特征在于，还包括：

函数设置单元，用于在所述主应用启动后，设置回调函数，用于在所述主应用运行崩溃时，通过所述回调函数触发所述辅助应用保存所述场景恢复数据到磁盘中。

15.如权利要求13所述的装置，其特征在于，还包括：

心跳执行单元，用于与所述辅助应用之间执行心跳机制，并由所述辅助应用根据心跳机制在监测到所述主应用运行崩溃时保存所述场景恢复数据到磁盘中。

16.如权利要求13-15任一所述的装置，其特征在于，所述场景恢复单元，还用于在使用所述场景恢复数据，将所述主应用运行的场景恢复到所述主应用崩溃之前的场景之后，删除所述崩溃标记。

17.一种应用场景恢复系统，其特征在于，包括：主应用和辅助应用，其中：

所述辅助应用，用于在所述主应用运行崩溃时，从与所述主应用的共享内存中获取所述主应用的场景恢复数据；并将获取的所述场景恢复数据保存到磁盘中；以及记录表征所述主应用运行崩溃的崩溃标记；

所述主应用，用于在运行的过程中，实时将表征所述主应用运行的最新场景的数据作为所述场景恢复数据，缓存到与所述辅助应用的共享内存中；并在启动后，当确定记录有表征所述主应用在上一次运行时崩溃的所述崩溃标记时，从磁盘中获取保存的所述场景恢复数据；以及使用所述场景恢复数据，将所述主应用运行的场景恢复到所述主应用崩溃之前的场景。

18.一种场景恢复数据保存方法，其特征在于，包括：

辅助应用接收主应用在运行过程中实时发送的表征所述主应用运行的最新场景的数据；

将接收的所述数据作为场景恢复数据缓存到内存中；

当所述主应用运行崩溃时，从所述内存中获取所述场景恢复数据并保存到磁盘中；

记录表征所述主应用运行崩溃的崩溃标记。

19.如权利要求18所述的方法，其特征在于，当所述主应用运行崩溃时，从所述内存中获取所述场景恢复数据并保存到磁盘中，具体包括：

根据与主应用之间的心跳机制，在监测到所述主应用运行崩溃时，从所述内存中获取所述场景恢复数据并保存到磁盘中。

20.如权利要求18所述的方法，其特征在于，在从所述内存中获取所述场景恢复数据并保存到磁盘中之前，还包括：

确定当前系统程序表中不存在所述主应用的应用标识。

21.如权利要求18-20任一所述的方法，其特征在于，所述辅助应用与所述主应用运行在不同的设备上。

22.一种应用运行方法，其特征在于，包括：

主应用在运行的过程中，实时向辅助应用发送表征所述主应用运行的最新场景的数据，由所述辅助应用将接收的所述数据作为场景恢复数据缓存到内存中，并由所述辅助应用当所述主应用运行崩溃时，从所述内存中获取所述场景恢复数据并保存到磁盘中；

所述主应用在启动后，当确定记录有表征所述主应用在上一次运行时崩溃的崩溃标记时，从磁盘中获取保存的所述场景恢复数据；

使用所述场景恢复数据，将所述主应用运行的场景恢复到所述主应用崩溃之前的场景。

23.如权利要求22所述的方法，其特征在于，还包括：

所述主应用与所述辅助应用之间执行心跳机制，并由所述辅助应用根据心跳机制在监测到所述主应用运行崩溃时保存所述场景恢复数据到磁盘中。

24.如权利要求22所述的方法，其特征在于，在使用所述场景恢复数据，将所述主应用运行的场景恢复到所述主应用崩溃之前的场景之后，还包括：

删除所述崩溃标记。

25.一种场景恢复数据保存装置，集成于辅助应用，其特征在于，包括：

数据接收单元，用于接收主应用在运行过程中实时发送的表征所述主应用运行的最新场景的数据；

缓存单元，用于将接收的所述数据作为场景恢复数据缓存到内存中；

数据保存单元，用于当所述主应用运行崩溃时，从所述内存中获取所述场景恢复数据并保存到磁盘中；

标记记录单元，用于记录表征所述主应用运行崩溃的崩溃标记。

26.如权利要求25所述的装置，其特征在于，所述数据保存单元，具体用于根据与主应用之间的心跳机制，在监测到所述主应用运行崩溃时，从所述内存中获取所述场景恢复数据并保存到磁盘中。

27.如权利要求25所述的装置，其特征在于，所述数据保存单元，还用于在从所述内存中获取所述场景恢复数据并保存到磁盘中之前，确定当前系统程序表中不存在所述主应用的应用标识。

28.一种应用运行装置，集成于主应用，其特征在于，包括：

数据发送单元，用于在运行的过程中，实时向辅助应用发送表征所述主应用运行的最新场景的数据，由所述辅助应用将接收的所述数据作为场景恢复数据缓存到内存中，并由所述辅助应用当所述主应用运行崩溃时，从所述内存中获取所述场景恢复数据并保存到磁盘中；

数据获取单元，用于所述主应用在启动后，当确定记录有表征所述主应用在上一次运行时崩溃的崩溃标记时，从磁盘中获取保存的所述场景恢复数据；

场景恢复单元，用于使用所述场景恢复数据，将所述主应用运行的场景恢复到所述主应用崩溃之前的场景。

29.如权利要求28所述的装置，其特征在于，还包括：

心跳执行单元，用于与所述辅助应用之间执行心跳机制，并由所述辅助应用根据心跳机制在监测到所述主应用运行崩溃时保存所述场景恢复数据到磁盘中。

30.如权利要求28所述的装置，其特征在于，所述场景恢复单元，还用于在使用所述场景恢复数据，将所述主应用运行的场景恢复到所述主应用崩溃之前的场景之后，删除所述崩溃标记。

31.一种应用场景恢复系统，其特征在于，包括：主应用和辅助应用，其中：

所述辅助应用，用于接收所述主应用在运行过程中实时发送的表征所述主应用运行的最新场景的数据；并将接收的所述数据作为场景恢复数据缓存到内存中；并当所述主应用运行崩溃时，从所述内存中获取所述场景恢复数据并保存到磁盘中；以及记录表征所述主应用运行崩溃的崩溃标记；

所述主应用，用于在运行的过程中，实时向所述辅助应用发送表征所述主应用运行的最新场景的数据；并在启动后，当确定记录有表征所述主应用在上一次运行时崩溃的崩溃标记时，从磁盘中获取保存的所述场景恢复数据；以及使用所述场景恢复数据，将所述主应用运行的场景恢复到所述主应用崩溃之前的场景。