CN117122913A - 一种基于帧同步的追帧加速方法、装置、设备及介质 - Google Patents

Abstract

本申请公开了一种基于帧同步的追帧加速方法、装置、设备及介质，本申请属于游戏技术领域。该方法包括：若发生断线重连事件，向服务器发出重连请求；接收所述服务器基于所述重连请求确定的实时数据包和历史数据包；根据所述实时数据包，对所述客户端的操作对象以及其他客户端的操作对象进行数据解析，得到实时游戏画面；以及，根据历史数据包以及断线时刻所述客户端以及其他客户端的操作对象的历史状态，解析得到回放画面，并进行回放画面的展示。本方案中，实时数据包和历史数据包的组合可以使客户端自行处理断线期间的状态恢复，使用户短时间恢复到游戏当前状态，减少等待时间，提高用户体验，并且可以减轻服务器负担。

Description

一种基于帧同步的追帧加速方法、装置、设备及介质

技术领域

本申请属于游戏技术领域，具体涉及一种基于帧同步的追帧加速方法、装置、设备及介质。

背景技术

在多人游戏中，用户之间的行为和事件需要保持一致，以避免不同用户看到不同的游戏结果，而帧同步是一种多人在线游戏开发中的技术，确保所有用户在游戏中看到的事件和状态都是一致的。它通过将用户的输入在每个游戏帧中进行同步，使得所有用户在同一时刻执行相同的操作，从而保持游戏的一致性和公平性。

在用户发生断线重连后时，如今的帧同步***首先会发送当前游戏状态给用户，然后通过传输压缩的历史帧数据让用户了解之前的游戏情况。接着，服务器发送缺失的帧同步数据，以让用户的游戏状态与其他用户同步。为了追赶游戏进度，服务器进行快进计算，模拟用户加入到当前状态之间的帧。一旦用户追赶上当前状态，服务器继续发送正常的帧同步数据，使用户与其他用户同步继续游戏。

然而，当用户发生断线重连并需要获取之前的游戏状态和帧同步数据包时，服务器可能会因为数据包积累太多而出现延迟。这会导致新用户等待较长时间，因为服务器需要处理和发送大量的数据包，以及计算快进，使新用户追上当前游戏状态。因此，如何在用户发生断线重连时减少用户的等待时间，从而提高用户的体验是本领域亟待解决的问题。

发明内容

本申请实施例提供一种基于帧同步的追帧加速方法、装置、设备及介质，目的是解决在用户发送断线重连时现有的帧同步***由于需要处理大量数据包从而导致用户等待较长时间，降低了用户体验的问题。通过基于帧同步的追帧加速方法，实时数据包和历史数据包的组合可以使客户端自行处理断线期间的状态恢复，使用户短时间恢复到游戏当前状态，减少等待时间，提高用户体验，并且可以减轻服务器负担。

第一方面，本申请实施例提供了一种基于帧同步的追帧加速方法，所述方法包括：

若发生断线重连事件，向服务器发出重连请求；其中，所述重连请求包括断线时刻和重连时刻；

接收所述服务器基于所述重连请求确定的实时数据包和历史数据包；其中，所述实时数据包包括所述客户端以及与所述客户端连接于同一游戏的其他客户端的当前时刻操作指令；所述历史数据包包括与所述客户端连接于同一游戏的其他客户端从断线时刻到重连时刻之间的历史操作指令；

根据所述实时数据包，对所述客户端的操作对象以及其他客户端的操作对象进行数据解析，得到实时游戏画面；以及，根据历史数据包以及断线时刻所述客户端以及其他客户端的操作对象的历史状态，解析得到回放画面，并进行回放画面的展示。

进一步的，在根据历史数据包以及断线时刻所述客户端以及其他客户端的操作对象的历史状态，解析得到回放画面之后，所述方法还包括：

根据所述断线时刻到重连时刻之间的断线时长以及对于所述历史数据包的解析速度，得到加速倍数；

相应的，进行回放画面的展示，包括：

按照所述加速倍数对所述回放画面进行回放画面的加速展示。

进一步的，在接收所述服务器基于所述重连请求确定的实时数据包和历史数据包之前，所述方法还包括：

向服务器发送未经处理的实时数据包和历史数据包，供服务器根据所述实时数据包、所述历史数据包以及预设的关键帧设定条件确定实时关键帧以及历史关键帧，并将所述实时关键帧以及所述历史关键帧存储在实时数据包以及历史数据包中；

相应的，接收所述服务器基于所述重连请求确定的实时数据包和历史数据包，包括：

接收并解析服务器基于所述重连请求确定的实时数据包和历史数据包，得到实时关键帧以及历史关键帧。

进一步的，在接收所述服务器基于所述重连请求确定的实时数据包和历史数据包之前，所述方法还包括：

向服务器发送未经处理的实时数据包和历史数据包，供服务器根据所述实时数据包、所述历史数据包以及预设的定时帧设定条件确定实时定时帧以及历史定时帧，并将所述实时定时帧以及所述历史定时帧存储在实时数据包以及历史数据包中；

相应的，接收所述服务器基于所述重连请求确定的实时数据包和历史数据包，包括：

接收并解析服务器基于所述重连请求确定的实时数据包和历史数据包，得到实时定时帧以及历史定时帧。

进一步的，在得到所述关键帧或得到所述定时帧之后，所述方法还包括：

向服务器发送帧数量检测指令，供服务器根据帧数量检测指令确定所述关键帧或所述定时帧的数量，并将所述关键帧或所述定时帧的数量与预设的关键帧阈值或定时帧阈值作对比，若所述关键帧或所述定时帧超过预设的关键帧阈值或定时帧阈值，则获取当前时间戳，并根据所述当前时间戳、所述关键帧阈值或定时帧阈值删除关键帧或定时帧。

进一步的，在按照所述加速倍数对所述回放画面进行回放画面的加速展示之后，所述方法还包括：

响应于用户选择的跳转时间戳，根据所述跳转时间戳以及断线时刻确定跳转时间范围；

根据所述跳转时间范围确定跳转数据包数量，并根据所述跳转数据包数量确定回放画面，以及进行回放画面的展示。

第二方面，本申请实施例提供了一种基于帧同步的追帧加速装置，所述装置包括：

重连请求发送模块，用于若发生断线重连事件，向服务器发出重连请求；其中，所述重连请求包括断线时刻和重连时刻；

数据包接收模块，用于接收所述服务器基于所述重连请求确定的实时数据包和历史数据包；其中，所述实时数据包包括所述客户端以及与所述客户端连接于同一游戏的其他客户端的当前时刻操作指令；所述历史数据包包括与所述客户端连接于同一游戏的其他客户端从断线时刻到重连时刻之间的历史操作指令；

回放画面展示模块，用于根据所述实时数据包，对所述客户端的操作对象以及其他客户端的操作对象进行数据解析，得到实时游戏画面；以及，根据历史数据包以及断线时刻所述客户端以及其他客户端的操作对象的历史状态，解析得到回放画面，并进行回放画面的展示。

进一步的，所述装置还包括加速倍数确定模块，所述加速倍数确定模块用于：

根据所述断线时刻到重连时刻之间的断线时长以及对于所述历史数据包的解析速度，得到加速倍数；

相应的，所述回放画面展示模块用于：

按照所述加速倍数对所述回放画面进行回放画面的加速展示。

进一步的，所述装置还包括帧确定模块，所述帧确定模块用于：

向服务器发送未经处理的实时数据包和历史数据包，供服务器根据所述实时数据包、所述历史数据包以及预设的关键帧设定条件确定实时关键帧以及历史关键帧，并将所述实时关键帧以及所述历史关键帧存储在实时数据包以及历史数据包中；

相应的，所述数据包接收模块用于：

接收并解析服务器基于所述重连请求确定的实时数据包和历史数据包，得到实时关键帧以及历史关键帧。

进一步的，所述装置还包括数据包发送模块，所述数据包发送模块用于：

向服务器发送未经处理的实时数据包和历史数据包，供服务器根据所述实时数据包、所述历史数据包以及预设的定时帧设定条件确定实时定时帧以及历史定时帧，并将所述实时定时帧以及所述历史定时帧存储在实时数据包以及历史数据包中；

相应的，所述数据包接收模块用于：

接收并解析服务器基于所述重连请求确定的实时数据包和历史数据包，得到实时定时帧以及历史定时帧。

进一步的，所述装置还包括指令发送模块，所述指令发送模块用于：

向服务器发送帧数量检测指令，供服务器根据帧数量检测指令确定所述关键帧或所述定时帧的数量，并将所述关键帧或所述定时帧的数量与预设的关键帧阈值或定时帧阈值作对比，若所述关键帧或所述定时帧超过预设的关键帧阈值或定时帧阈值，则获取当前时间戳，并根据所述当前时间戳、所述关键帧阈值或定时帧阈值删除关键帧或定时帧。

进一步的，所述装置还包括跳转时间范围确定模块，所述跳转时间范围确定模块用于：

响应于用户选择的跳转时间戳，根据所述跳转时间戳以及断线时刻确定跳转时间范围；

根据所述跳转时间范围确定跳转数据包数量，并根据所述跳转数据包数量确定回放画面，以及进行回放画面的展示。

第三方面，本申请实施例提供了一种电子设备，该电子设备包括处理器、存储器及存储在所述存储器上并可在所述处理器上运行的程序或指令，所述程序或指令被所述处理器执行时实现如第一方面所述的方法的步骤。

第四方面，本申请实施例提供了一种可读存储介质，所述可读存储介质上存储程序或指令，所述程序或指令被处理器执行时实现如第一方面所述的方法的步骤。

第五方面，本申请实施例提供了一种芯片，所述芯片包括处理器和通信接口，所述通信接口和所述处理器耦合，所述处理器用于运行程序或指令，实现如第一方面所述的方法。

在本申请实施例中，若发生断线重连事件，向服务器发出重连请求；其中，所述重连请求包括断线时刻和重连时刻；接收所述服务器基于所述重连请求确定的实时数据包和历史数据包；其中，所述实时数据包包括所述客户端以及与所述客户端连接于同一游戏的其他客户端的当前时刻操作指令；所述历史数据包包括与所述客户端连接于同一游戏的其他客户端从断线时刻到重连时刻之间的历史操作指令；根据所述实时数据包，对所述客户端的操作对象以及其他客户端的操作对象进行数据解析，得到实时游戏画面；以及，根据历史数据包以及断线时刻所述客户端以及其他客户端的操作对象的历史状态，解析得到回放画面，并进行回放画面的展示。通过上述基于帧同步的追帧加速方法，实时数据包和历史数据包的组合可以使客户端自行处理断线期间的状态恢复，使用户短时间恢复到游戏当前状态，减少等待时间，提高用户体验，并且可以减轻服务器负担。

附图说明

图1是本申请实施例一提供的基于帧同步的追帧加速方法的流程示意图；

图2是本申请实施例二提供的基于帧同步的追帧加速方法的流程示意图；

图3是本申请实施例三提供的基于帧同步的追帧加速方法的流程示意图；

图4是本申请实施例四提供的基于帧同步的追帧加速方法的流程示意图；

图5是本申请实施例五提供的基于帧同步的追帧加速装置的结构示意图；

图6是本申请实施例六提供的电子设备的结构示意图。

具体实施方式

为了使本申请的目的、技术方案和优点更加清楚，下面结合附图对本申请具体实施例作进一步的详细描述。可以理解的是，此处所描述的具体实施例仅仅用于解释本申请，而非对本申请的限定。另外还需要说明的是，为了便于描述，附图中仅示出了与本申请相关的部分而非全部内容。在更加详细地讨论示例性实施例之前应当提到的是，一些示例性实施例被描述成作为流程图描绘的处理或方法。虽然流程图将各项操作(或步骤)描述成顺序的处理，但是其中的许多操作可以被并行地、并发地或者同时实施。此外，各项操作的顺序可以被重新安排。当其操作完成时所述处理可以被终止，但是还可以具有未包括在附图中的附加步骤。所述处理可以对应于方法、函数、规程、子例程、子程序等等。

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员获得的所有其他实施例，都属于本申请保护的范围。

本申请的说明书和权利要求书中的术语“第一”、“第二”等是用于区别类似的对象，而不用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便本申请的实施例能够以除了在这里图示或描述的那些以外的顺序实施，且“第一”、“第二”等所区分的对象通常为一类，并不限定对象的个数，例如第一对象可以是一个，也可以是多个。此外，说明书以及权利要求中“和/或”表示所连接对象的至少其中之一，字符“/”，一般表示前后关联对象是一种“或”的关系。

下面结合附图，通过具体的实施例及其应用场景对本申请实施例提供的基于帧同步的追帧加速方法、装置、设备及介质进行详细地说明。

实施例一

图1是本申请实施例一提供的基于帧同步的追帧加速方法的流程示意图。

如图1所示，具体包括如下步骤：

S101，若发生断线重连事件，向服务器发出重连请求；其中，所述重连请求包括断线时刻和重连时刻。

首先，本方案的使用场景可以是多人游戏中当用户断线后重新连接向服务器发送重连请求后，接收服务器根据用户的重连请求发送的实时数据包以及历史数据包，并根据实时数据包以及历史数据包解析出回放画面，并重连到游戏中的场景。

基于上述使用场景，可以理解的，本申请的执行主体可以是客户端，此处不做过多的限定。

本方案中，断线重连事件可以是在用户在进行在线游戏时，由于网络故障、连接问题或其他原因，与游戏服务器的连接中断，并在网络稳定后尝试重新连接到服务器的事件。

服务器可以是游戏的中央控制节点，负责处理用户的操作指令、维护游戏状态、以及同步多人游戏状态等任务。在断线重连场景中，服务器负责处理用户的重连请求，发送实时数据和历史数据，以及协调各个客户端的状态。

重连请求可以是指用户的客户端向服务器发送的一种请求，要求重新连接到游戏服务器，这个请求包括了断线时刻和重连时刻。

断线时刻可以是用户与服务器连接中断的***时间戳，即用户最后一次与服务器成功通信的时间。例如，若断线时的***时间是2023年8月21日10点整，则断线时刻可以表示为2023-08-21-10-00-00。

重连时刻可以是用户重新连接服务器的***时间戳，即用户尝试重新建立与服务器的通信连接的时间。例如，若重连时的***时间是2023年8月21日10点01分，则断线时刻可以表示为2023-08-21-10-01-00。

客户端可以首先检测自己是否处于断线状态，具体的，可以是通过与服务器的连接状态以及网络延迟等信息来判断是否断线。如果客户端确认自己已经断线，而且需要重新连接到游戏服务器以继续游戏，就会触发断线重连的逻辑。然后客户端会构建一个重连请求，具体的，这个请求可以包含断线时刻的时间戳、重连时刻的时间戳，以及一些身份验证信息或游戏标识等。最后客户端将构建好的重连请求通过网络发送给游戏服务器，具体的，可以通过客户端与服务器之间的通信协议和网络连接来进行发送。

S102，接收所述服务器基于所述重连请求确定的实时数据包和历史数据包；其中，所述实时数据包包括所述客户端以及与所述客户端连接于同一游戏的其他客户端的当前时刻操作指令；所述历史数据包包括与所述客户端连接于同一游戏的其他客户端从断线时刻到重连时刻之间的历史操作指令。

实时数据包可以是服务器根据断线重连请求，确定的包含当前游戏状态的数据，具体的，可以包括与用户所在游戏房间内的其他用户的当前操作指令。

历史数据包可以是服务器根据断线重连请求，确定的包含从断线时刻到重连时刻间其他用户的操作历史的数据，具体的，可以包括其他用户从断线时刻到重连时刻之间的操作指令。

当前时刻操作指令可以是其他与用户在同一游戏房间内的用户在重连时刻发送的操作指令，用于描述其他用户在此刻的游戏行为。

历史操作指令可以是其他与用户在同一游戏房间内的用户在断线时刻到重连时刻之间发送的操作指令，用于描述其他用户在这段时间内的游戏行为。

客户端收到服务器发送的实时数据包和历史数据包后，可以解析实时数据包，提取其他用户的当前时刻操作指令，并解析历史数据包，提取其他用户从断线时刻到重连时刻之间的历史操作指令。

S103，根据所述实时数据包，对所述客户端的操作对象以及其他客户端的操作对象进行数据解析，得到实时游戏画面；以及，根据历史数据包以及断线时刻所述客户端以及其他客户端的操作对象的历史状态，解析得到回放画面，并进行回放画面的展示。

操作对象可以是用户、角色以及游戏物体等在游戏中可以进行操作的实体，每个操作对象都有自己的状态和行为。

实时游戏画面可以是指客户端根据实时数据包中的操作指令解析得到的游戏状态，具体的，可以包括当前时刻用户和其他操作对象的位置、状态以及动作等信息，以呈现出当前游戏的情况。

操作对象的历史状态可以是指根据历史数据包和断线时刻的操作对象状态，即在客户端解析得到的一段时间内操作对象的状态记录。

回放画面可以是指客户端根据历史数据包和断线时刻的操作对象历史状态，解析得到的一段时间内的操作回放，可以用来展示用户在断线期间的游戏行为。

客户端可以根据实时数据包中的操作指令，解析用户和其他操作对象在当前时刻的状态，例如位置、状态以及动作等。根据解析得到的操作对象状态，客户端可以生成实时游戏画面，反映当前游戏状态，并根据历史数据包和断线时刻的操作对象历史状态，解析用户和其他操作对象在断线期间的历史状态，记录一段时间内的操作。根据解析得到的历史操作对象状态，客户端可以生成回放画面，用来展示用户在断线期间的游戏行为。最后客户端可以同时展示实时游戏画面和回放画面，让用户看到当前游戏状态，以及在断线期间发生的情况。

在本申请实施例中，若发生断线重连事件，向服务器发出重连请求；其中，所述重连请求包括断线时刻和重连时刻；接收所述服务器基于所述重连请求确定的实时数据包和历史数据包；其中，所述实时数据包包括所述客户端以及与所述客户端连接于同一游戏的其他客户端的当前时刻操作指令；所述历史数据包包括与所述客户端连接于同一游戏的其他客户端从断线时刻到重连时刻之间的历史操作指令；根据所述实时数据包，对所述客户端的操作对象以及其他客户端的操作对象进行数据解析，得到实时游戏画面；以及，根据历史数据包以及断线时刻所述客户端以及其他客户端的操作对象的历史状态，解析得到回放画面，并进行回放画面的展示。通过上述基于帧同步的追帧加速方法，实时数据包和历史数据包的组合可以使客户端自行处理断线期间的状态恢复，使用户短时间恢复到游戏当前状态，减少等待时间，提高用户体验，并且可以减轻服务器负担。

实施例二

图2是本申请实施例二提供的基于帧同步的追帧加速方法的流程示意图。

如图2所示，具体包括如下步骤：

S201，若发生断线重连事件，向服务器发出重连请求；其中，所述重连请求包括断线时刻和重连时刻。

S202，接收所述服务器基于所述重连请求确定的实时数据包和历史数据包；其中，所述实时数据包包括所述客户端以及与所述客户端连接于同一游戏的其他客户端的当前时刻操作指令；所述历史数据包包括与所述客户端连接于同一游戏的其他客户端从断线时刻到重连时刻之间的历史操作指令。

S203，根据所述实时数据包，对所述客户端的操作对象以及其他客户端的操作对象进行数据解析，得到实时游戏画面；以及，根据历史数据包以及断线时刻所述客户端以及其他客户端的操作对象的历史状态，解析得到回放画面。

S204，根据所述断线时刻到重连时刻之间的断线时长以及对于所述历史数据包的解析速度，得到加速倍数。

断线时长可以是用户从网络中断到重新连接的时间间隔，即断线的持续时长。

历史数据包的解析速度可以是客户端解析历史数据包以及操作对象历史状态的速度，具体的，可以用操作对象的历史帧数或操作指令的数量来衡量。

加速倍数可以是一个相对值，表示断线期间的操作恢复和回放展示的速度相对于实际时间的倍数。例如，加速倍数为2表示操作恢复和回放展示的速度是实际时间的两倍。

客户端可以首先计算用户从断线到重连的时间间隔，即断线时长。然后根据历史数据包和断线时刻的操作对象历史状态，解析操作指令的数量或历史帧数，并记录历史数据包的解析速度。最后将断线时长除以历史数据包的解析速度，得到加速倍数，来表示断线期间的操作恢复和回放展示在客户端上的速度相对于实际时间的倍数。

S205，按照所述加速倍数对所述回放画面进行回放画面的加速展示。

客户端可以获取历史数据包以及断线时刻操作对象的历史状态，以生成回放画面。然后将断线时长除以历史数据包的帧数或操作指令数量，得到每帧的时间间隔，即实际时间与回放画面之间的对应关系。再创建一个回放画面的渲染器，用于显示加速后的回放画面。并根据所计算的加速倍数，将每帧间隔乘以加速倍数，得到加速后的帧间隔，即加速后回放画面的时间间隔。最后开始逐帧播放回放画面。使用加速后的帧间隔，让每帧的展示时间缩短，从而实现回放画面的加速展示。

本实施例中，根据加速倍速进行回放画面的展示，可以使用户在较短时间内回看断线期间的游戏情况，以了解断线期间的游戏进程。并且使用加速倍速进行回放画面的展示还可以减轻处理历史数据包的负担，提高效率。

在上述各技术方案的基础上，可选的，在按照所述加速倍数对所述回放画面进行回放画面的加速展示之后，所述方法还包括：

响应于用户选择的跳转时间戳，根据所述跳转时间戳以及断线时刻确定跳转时间范围；

根据所述跳转时间范围确定跳转数据包数量，并根据所述跳转数据包数量确定回放画面，以及进行回放画面的展示。

本方案中，跳转时间戳可以是用户在游戏中选择的一个时间点，示用户希望从这个时间点开始进行回放，标志着用户感兴趣的游戏时刻。

跳转时间范围可以是根据用户选择的跳转时间戳和已知的断线时刻确定的一个时间段，可以包括从用户选择的时间戳到断线时刻之间的游戏时间段，这个时间范围定义了用户希望回放的游戏片段。

跳转数据包数量可以是在跳转时间范围内需要加载的网络数据包的数量，这些数据包包含了跳转时间范围内的游戏状态信息，例如用户的位置、动作以及事件等。加载足够的数据包可以确保在回放时能够还原游戏的状态。

回放画面可以是根据跳转时间范围内的游戏数据所生成的游戏画面，可以是实际游戏中的还原，让用户能够观看游戏在指定时间段内的内容。回放画面可以允许用户重新体验游戏中的特定时刻。

用户可以在游戏界面中选择一个时间戳，标志着他们希望从这个时间点开始进行回放。

客户端可以基于用户选择的时间戳和已知的断线时刻，确定跳转时间范围，具体的，跳转时间范围可以包括用户选择的时间戳到断线时刻之间的游戏时间段。然后客户端可以根据跳转时间范围内的游戏状态信息，计算需要加载的网络数据包的数量，这些数据包包含了跳转时间范围内的关键信息。然后游戏客户端加载跳转时间范围内的数据包，并根据这些数据包还原游戏状态，还原的游戏状态可以包括用户位置、状态以及物***置等。基于还原的游戏状态，客户端可以生成回放画面，即游戏在跳转时间范围内的还原，并将生成的回放画面展示给用户，允许他们观看游戏在指定时间段内的内容。

本方案中，通过设置游戏回放和跳转功能可以使用户跳转到感兴趣的片段，无需从头开始进行回放，节省了用户时间，从而提高了用户的体验。

实施例三

图3是本申请实施例三提供的基于帧同步的追帧加速方法的流程示意图。

如图3所示，具体包括如下步骤：

S301，若发生断线重连事件，向服务器发出重连请求；其中，所述重连请求包括断线时刻和重连时刻。

S302，向服务器发送未经处理的实时数据包和历史数据包，供服务器根据所述实时数据包、所述历史数据包以及预设的关键帧设定条件确定实时关键帧以及历史关键帧，并将所述实时关键帧以及所述历史关键帧存储在实时数据包以及历史数据包中。

未经处理的实时数据包和历史数据包可以包含用户在游戏中的操作指令，但未经过服务器的处理和解析。

预设的关键帧设定条件可以是一些预先设定的条件，用于判定哪些时刻的数据被认为是关键帧。例如，可以当游戏中出现重要时间时生成一个关键帧，例如用户完成了一次击杀以及BOSS出现等事件发生时生成一个关键帧。还可以是用户完成了连续击杀事件时生成一个关键帧。

实时关键帧可以是根据实时数据包和预设的关键帧设定条件，由服务器确定并存储的重要数据帧。

历史关键帧可以是根据历史数据包和预设的关键帧设定条件，由服务器确定并存储的断线时刻到重连时刻之间的重要数据帧。

客户端可以将未经处理的实时数据包和历史数据包发送给服务器。服务器接收并解析客户端发送的实时数据包和历史数据包，以获取操作指令和时间戳等信息。然后服务器可以根据预设的关键帧设定条件，判断哪些数据帧应该被设定为关键帧，具体的，这些条件可以包括游戏状态的变化以及关键动作的发生等。然后服务器可以根据设定的条件，从实时数据包和历史数据包中选择关键帧，并将这些关键帧存储在相应的数据包中。

S303，接收并解析服务器基于所述重连请求确定的实时数据包和历史数据包，得到实时关键帧以及历史关键帧。其中，所述实时数据包包括所述客户端以及与所述客户端连接于同一游戏的其他客户端的当前时刻操作指令；所述历史数据包包括与所述客户端连接于同一游戏的其他客户端从断线时刻到重连时刻之间的历史操作指令。

客户端可以首先接收服务器发送的实时数据包和历史数据包，这些数据包中包含了用户的操作指令和游戏状态信息。然后客户端可以解析实时数据包，提取其中的操作指令、时间戳和其他游戏状态信息。并解析历史数据包，提取其中断线时刻到重连时刻之间的操作指令、时间戳和游戏状态信息。根据实时数据包中的操作指令和预设的关键帧设定条件，客户端可以从实时数据包中筛选出实时关键帧。根据历史数据包中的操作指令、时间戳和预设的关键帧设定条件，客户端可以从历史数据包中筛选出断线时刻到重连时刻之间的历史关键帧。最后客户端还可以将获取到的实时关键帧和历史关键帧存储起来，以便后续使用。

S304，根据所述实时数据包，对所述客户端的操作对象以及其他客户端的操作对象进行数据解析，得到实时游戏画面；以及，根据历史数据包以及断线时刻所述客户端以及其他客户端的操作对象的历史状态，解析得到回放画面，并进行回放画面的展示。

本实施例中，通过根据预设条件确定关键帧并存储在对应的数据包中，可以使游戏的重要状态得以保存，以帮助客户端顺利实现断线重连，减少用户的等待时间，提高用户的体验。

实施例四

图4是本申请实施例四提供的基于帧同步的追帧加速方法的流程示意图。

如图4所示，具体包括如下步骤：

S401，若发生断线重连事件，向服务器发出重连请求；其中，所述重连请求包括断线时刻和重连时刻。

S402，向服务器发送未经处理的实时数据包和历史数据包，供服务器根据所述实时数据包、所述历史数据包以及预设的定时帧设定条件确定实时定时帧以及历史定时帧，并将所述实时定时帧以及所述历史定时帧存储在实时数据包以及历史数据包中。

预设的定时帧设定条件可以是一些预先设定的条件，用于判定哪些时刻的数据被认为是定时帧。例如，可以是根据固定的时间间隔生成定时帧来同步游戏状态，可以设置每隔2s设定一个定时帧。

实时定时帧可以是根据实时数据包和预设的定时帧设定条件，在断线重连时，由服务器确定并存储的重要数据帧。这些帧代表了断线恢复后的游戏状态的关键时刻，有助于将断线时的游戏状态与当前游戏状态同步。

历史定时帧可以是根据历史数据包和预设的定时帧设定条件，在断线重连时，由服务器确定并存储的重要数据帧。这些帧代表了断线时刻到重连时刻之间的游戏状态的关键时刻，用于恢复断线期间的游戏状态。

客户端可以将未经处理的实时数据包和历史数据包发送给服务器。服务器可以接收并解析客户端发送的实时数据包和历史数据包，以获取操作指令和时间戳等信息。然后服务器根据预设的关键帧设定条件，判断哪些数据帧应该被设定为定时帧。这些条件可以包括游戏状态的变化以及关键动作的发生等。然后服务器可以根据设定的条件，从实时数据包和历史数据包中选择定时帧，并将这些定时帧存储在相应的数据包中。

在上述各技术方案的基础上，可选的，在得到所述关键帧或得到所述定时帧之后，所述方法还包括：

向服务器发送帧数量检测指令，供服务器根据帧数量检测指令确定所述关键帧或所述定时帧的数量，并将所述关键帧或所述定时帧的数量与预设的关键帧阈值或定时帧阈值作对比，若所述关键帧或所述定时帧超过预设的关键帧阈值或定时帧阈值，则获取当前时间戳，并根据所述当前时间戳、所述关键帧阈值或定时帧阈值删除关键帧或定时帧。

本方案中，帧数量检测指令可以是一种由客户端向服务器发送的特定指令。目的是请求服务器检测在一段特定时间内收集到的关键帧或定时帧的数量，并作出相应的处理。

关键帧或定时帧的数量可以是指在一段特定时间内收集到的关键帧或定时帧的总数量。关键帧通常是游戏状态发生重要变化的帧，而定时帧是根据预设的时间间隔生成的帧。

关键帧阈值可以是预设的关键帧数量的上限。当服务器检测到在一段时间内收集到的关键帧数量超过预设的阈值时，可能会删除部分关键帧，以避免影响游戏性能或流畅性。

定时帧阈值可以是预设的定时帧数量的上限。如果服务器检测到在一段时间内生成的定时帧数量超过预设的阈值，可能会删除部分定时帧，以避免影响游戏性能或流畅性。

当前时间戳可以是一个记录客户端发送帧数量检测指令时的时间，用于计算一段特定时间内的关键帧或定时帧的数量，服务器可以使用当前时间戳来判断哪些帧在特定时间段内生成。

客户端在与服务器建立的通信中，可以发送一个特定的帧数量检测指令。当服务器接收到客户端发送的帧数量检测指令后，可以解析此指令，并根据此指令查询一共收集到的关键帧或定时帧的总数量。然后服务器可以将查询得到的关键帧或定时帧的数量与预设的关键帧阈值或定时帧阈值进行比较。如果帧数量超过了预设的阈值，服务器则获取当前的时间戳，根据当前时间戳和预设的阈值，删除一些关键帧或定时帧，以确保帧的数量保持在可接受范围内，具体的，删除的帧可以根据一定的策略，例如可以删除最旧的帧。服务器还可以将处理结果响应给客户端，通知客户端关键帧或定时帧的数量是否已经被调整。

本方案中，通过检测关键帧以及定时帧数量是否超过阈值，并在超过阈值后删除相应的关键帧或定时帧，可以降低网络传输的数据量，减少网络延迟，从而提升游戏的响应速度。并且删除相应的关键帧或定时帧还能节省存储空间，降低存储成本。

S403，接收并解析服务器基于所述重连请求确定的实时数据包和历史数据包，得到实时定时帧以及历史定时帧。其中，所述实时数据包包括所述客户端以及与所述客户端连接于同一游戏的其他客户端的当前时刻操作指令；所述历史数据包包括与所述客户端连接于同一游戏的其他客户端从断线时刻到重连时刻之间的历史操作指令。

客户端可以接收服务器发送的实时数据包和历史数据包，这些数据包中包含了用户的操作指令和游戏状态信息。然后客户端可以解析实时数据包，提取其中的操作指令、时间戳和其他游戏状态信息。然后可以解析历史数据包，提取其中断线时刻到重连时刻之间的操作指令、时间戳和游戏状态信息。根据实时数据包中的操作指令、时间戳和预设的关键帧设定条件，客户端可以从实时数据包中筛选出实时定时帧，具体的，这些定时帧可能是游戏状态的关键时刻，用于同步断线重连后的游戏状态。根据历史数据包中的操作指令、时间戳和预设的关键帧设定条件，客户端可以从历史数据包中筛选出断线时刻到重连时刻之间的历史定时帧，具体的，这些定时帧用于恢复断线期间的游戏状态。最后客户端还可以将获取到的实时定时帧和历史定时帧存储起来，以便后续使用。

S404，根据所述实时数据包，对所述客户端的操作对象以及其他客户端的操作对象进行数据解析，得到实时游戏画面；以及，根据历史数据包以及断线时刻所述客户端以及其他客户端的操作对象的历史状态，解析得到回放画面，并进行回放画面的展示。

本实施例中，通过根据预设条件确定关键帧并存储在对应的数据包中，可以使游戏的重要状态得以保存，以帮助客户端顺利实现断线重连，减少用户的等待时间，提高用户的体验。

可以理解的，上述各实施例所提供的技术方案，针对的是尚未开设定时任务的场景。在一些情况下，对于开设任务中存在定时任务的场景，可以通过基于状态同步的离线任务加速的方式实现离线后用户重新在线的加速处理。

具体的，状态同步模式可以是采用如下方式：

状态同步是指同步游戏中的各种状态。它是把大部分的状态和逻辑计算都放在服务器这边，然后服务器把结果下发给客户端，客户端只是根据服务器下发的结果来播放动画。当客户端向服务器发送游戏行为时，服务器接收这些行为，通过计算游戏行为的结果在服务器上运行完整的游戏逻辑，然后在游戏中广播发送给客户端的各种状态数据。客户端接收状态数据，然后显示相关内容。这包括每个角色在游戏地图上的行走和攻击。角色与角色之间的战斗是在服务器端编写和实现的。它可以被理解为在服务器端运行的游戏，没有图像渲染。

这种方法类似于各个客户端都在服务器上远程操作软件。国内大量的网络游戏，特别是回合制游戏，大都采用这种方式。同时，由于是多人在线，服务器端接收每个用户客户端的输入操作，并根据用户的操作进行迭代计算。

一般来说，状态同步MMO(Massive Multiplayer Online Game，大型多人在线游戏)用于在服务器上实现常见的游戏开发功能和模块，如战斗逻辑、寻路导航、地图、技能释放、怪物AI(Artificial Intelligence，人工智能)行为决策以及物理引擎等。

具体的，实现细节如下：

客户端首先将操作上传至服务器，服务器接收并计算游戏操作的结果；其中，游戏操作的结果可以包括技能逻辑以及战斗计算等。然后服务器以广播的形式下发游戏中的各种状态给客户端。客户端接收到服务器下发的游戏状态后更新本地状态；其中，本地状态可以包括行动状态、缓冲状态以及位置等。

为了给游戏用户更好的体验，减少同步的数据量，客户端也会做大量的本地操作，以减少服务器同步的频率以及数据量。

状态同步其实是一种不严谨的同步，它基于这样的想法：只要每次操作的结果相同，在不同用户的屏幕上表现一致就不是一个重要的指标。因此，状态同步不需要很高的网络延时。例如，在RPG(Role-playing game，角色扮演游戏)游戏中，200-300ms的延迟是用户可以接受的，但在RTS(Real-Time Strategy Game，即时战略游戏)游戏中，50ms的延迟就很影响体验。

本方案所提供的状态同步模式，优点在于：

首先，本方案的安全性非常高，外挂基本上没有什么能力从中收益。

其次，状态同步对网络带宽和抖动包有较强的适应性，即使有200ms或300ms的输入延迟再恢复正常，用户其实也感受不到不太舒服的地方。

再次，在开发游戏过程中，它的断线重连比较快，如果我的游戏崩溃了，客户端重启之后只需要服务器把所有重要对象的状态再同步一次过来，重新再创建出来就可以了。

最后，逻辑性能优化有优势，其客户端性能优化的优势也比较明显，比如可以做优化裁剪，用户看不到的角色可以不用创建，不用对它进行运算，节省消耗。

结合上述内容，本方案还提供一种基于状态同步的离线任务加速技术，具体如下：

在状态同步模式下，所有的游戏逻辑和数据都保存在服务器端，而客户端更像是服务器端数据的一个表现层。由于每个对象的状态信息都是实时记录的，当重新连接时，整个场景和角色都是直接重新生成的，而同步信息只是根据服务器端的规定给角色增加各种数值。

例如，在模拟经营类游戏中，由于游戏中有很多不同的建筑，每个建筑的产出/消耗内容和时间间隔都不一样，游戏中存在大量需要定时检测的任务，因此可以把所有的定时任务添加到一个统一的定时器中管理，每隔一段时间检测延时任务是否要执行。

游戏中建筑的产出/消耗是动态的，在计算建筑的产出/消耗时需要从用户那里获得数据，如果用户在线，可以直接从在线用户那里获得，但如果用户是离线的，则需要从数据库中加载用户的数据，或者把所有用户的数据一直放在内存中，每隔一段时间做一些零散的计算。这显然是一个需要解决的问题，游戏中的大部分内存和计算资源都被离线用户的数据和任务占用了，这严重影响了在线用户的体验，当用户数量上升时，会感觉很卡。

对于这些定时计算任务，采用的处理方式是，当用户离线时，中止所有定时任务并保存状态，等到登录和重连时再统一进行合并计算，具体的，可以在计算前获取一次***时间，并使用一个逻辑时钟进行任务跳转，加速执行，以减轻服务器端实时计算的压力。

本方案提供的状态同步模式以及基于状态同步的离线任务加速的方式，可以在客户端开设定时任务且出现离线状态的情况下，实现动态场景的加速同步。此处的动态场景和上述的定时任务的静态场景可以是相对应的。对于同一款游戏中，可以根据实际需求设置为不同的加速同步方式。例如，在一款模拟经营类游戏中，当用户操作的角色在开设一个新的建筑后出现离线状态，可以基于状态同步模式下的离线任务加速进行同步，如果用户操作的角色在跑动过程中出现离线状态，可以基于帧同步模式下的追帧加速进行同步。并且对于以上两种模式，还可以基于离线时长来进行相应的选择。

本方案通过这样的设置，可以应对更多的游戏的使用需求，可以在用户离线状态后切换至在线状态时，采用适合的模式进行同步，提高用户的使用体验。

实施例五

图5是本申请实施例五提供的基于帧同步的追帧加速装置的结构示意图。

如图5所示，具体包括如下：

重连请求发送模块501，用于若发生断线重连事件，向服务器发出重连请求；其中，所述重连请求包括断线时刻和重连时刻；

数据包接收模块502，用于接收所述服务器基于所述重连请求确定的实时数据包和历史数据包；其中，所述实时数据包包括所述客户端以及与所述客户端连接于同一游戏的其他客户端的当前时刻操作指令；所述历史数据包包括与所述客户端连接于同一游戏的其他客户端从断线时刻到重连时刻之间的历史操作指令；

回放画面展示模块503，用于根据所述实时数据包，对所述客户端的操作对象以及其他客户端的操作对象进行数据解析，得到实时游戏画面；以及，根据历史数据包以及断线时刻所述客户端以及其他客户端的操作对象的历史状态，解析得到回放画面，并进行回放画面的展示。

进一步的，所述装置还包括加速倍数确定模块，所述加速倍数确定模块用于：

根据所述断线时刻到重连时刻之间的断线时长以及对于所述历史数据包的解析速度，得到加速倍数；

相应的，所述回放画面展示模块用于：

按照所述加速倍数对所述回放画面进行回放画面的加速展示。

进一步的，所述装置还包括帧确定模块，所述帧确定模块用于：

向服务器发送未经处理的实时数据包和历史数据包，供服务器根据所述实时数据包、所述历史数据包以及预设的关键帧设定条件确定实时关键帧以及历史关键帧，并将所述实时关键帧以及所述历史关键帧存储在实时数据包以及历史数据包中；

相应的，所述数据包接收模块用于：

接收并解析服务器基于所述重连请求确定的实时数据包和历史数据包，得到实时关键帧以及历史关键帧。

进一步的，所述装置还包括数据包发送模块，所述数据包发送模块用于：

向服务器发送未经处理的实时数据包和历史数据包，供服务器根据所述实时数据包、所述历史数据包以及预设的定时帧设定条件确定实时定时帧以及历史定时帧，并将所述实时定时帧以及所述历史定时帧存储在实时数据包以及历史数据包中；

相应的，所述数据包接收模块用于：

接收并解析服务器基于所述重连请求确定的实时数据包和历史数据包，得到实时定时帧以及历史定时帧。

进一步的，所述装置还包括指令发送模块，所述指令发送模块用于：

向服务器发送帧数量检测指令，供服务器根据帧数量检测指令确定所述关键帧或所述定时帧的数量，并将所述关键帧或所述定时帧的数量与预设的关键帧阈值或定时帧阈值作对比，若所述关键帧或所述定时帧超过预设的关键帧阈值或定时帧阈值，则获取当前时间戳，并根据所述当前时间戳、所述关键帧阈值或定时帧阈值删除关键帧或定时帧。

进一步的，所述装置还包括跳转时间范围确定模块，所述跳转时间范围确定模块用于：

响应于用户选择的跳转时间戳，根据所述跳转时间戳以及断线时刻确定跳转时间范围；

根据所述跳转时间范围确定跳转数据包数量，并根据所述跳转数据包数量确定回放画面，以及进行回放画面的展示。

在本申请实施例中，重连请求发送模块，用于若发生断线重连事件，向服务器发出重连请求；其中，所述重连请求包括断线时刻和重连时刻；数据包接收模块，用于接收所述服务器基于所述重连请求确定的实时数据包和历史数据包；其中，所述实时数据包包括所述客户端以及与所述客户端连接于同一游戏的其他客户端的当前时刻操作指令；所述历史数据包包括与所述客户端连接于同一游戏的其他客户端从断线时刻到重连时刻之间的历史操作指令；回放画面展示模块，用于根据所述实时数据包，对所述客户端的操作对象以及其他客户端的操作对象进行数据解析，得到实时游戏画面；以及，根据历史数据包以及断线时刻所述客户端以及其他客户端的操作对象的历史状态，解析得到回放画面，并进行回放画面的展示。通过上述基于帧同步的追帧加速装置，实时数据包和历史数据包的组合可以使客户端自行处理断线期间的状态恢复，使用户短时间恢复到游戏当前状态，减少等待时间，提高用户体验，并且可以减轻服务器负担。

本申请实施例中的基于帧同步的追帧加速装置可以是装置，也可以是终端中的部件、集成电路、或芯片。该装置可以是移动电子设备，也可以为非移动电子设备。示例性的，移动电子设备可以为手机、平板电脑、笔记本电脑、掌上电脑、车载电子设备、可穿戴设备、超级移动个人计算机(ultra-mobilepersonalcomputer，UMPC)、上网本或者个人数字助理(personaldigitalassistant，PDA)等，非移动电子设备可以为服务器、网络附属存储器(NetworkAttachedStorage，NAS)、个人计算机(personalcomputer，PC)、电视机(television，TV)、柜员机或者自助机等，本申请实施例不作具体限定。

本申请实施例中的基于帧同步的追帧加速装置可以为具有操作***的装置。该操作***可以为安卓(Android)操作***，可以为ios操作***，还可以为其他可能的操作***，本申请实施例不作具体限定。

本申请实施例提供的基于帧同步的追帧加速装置能够实现上述各方法实施例实现的各个过程，为避免重复，这里不再赘述。

实施例六

如图6所示，本申请实施例还提供一种电子设备600，包括处理器601，存储器602，存储在存储器602上并可在所述处理器601上运行的程序或指令，该程序或指令被处理器601执行时实现上述基于帧同步的追帧加速装置实施例的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。

需要说明的是，本申请实施例中的电子设备包括上述所述的移动电子设备和非移动电子设备。

实施例七

本申请实施例还提供一种可读存储介质，所述可读存储介质上存储有程序或指令，该程序或指令被处理器执行时实现上述基于帧同步的追帧加速装置实施例的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。

其中，所述处理器为上述实施例中所述的电子设备中的处理器。所述可读存储介质，包括计算机可读存储介质，如计算机只读存储器(Read-OnlyMemory，ROM)、随机存取存储器(RandomAccessMemory，RAM)、磁碟或者光盘等。

实施例八

本申请实施例另提供了一种芯片，所述芯片包括处理器和通信接口，所述通信接口和所述处理器耦合，所述处理器用于运行程序或指令，实现上述基于帧同步的追帧加速装置实施例的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。

应理解，本申请实施例提到的芯片还可以称为***级芯片、***芯片、芯片***或片上***芯片等。

需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者装置中还存在另外的相同要素。此外，需要指出的是，本申请实施方式中的方法和装置的范围不限按示出或讨论的顺序来执行功能，还可包括根据所涉及的功能按基本同时的方式或按相反的顺序来执行功能，例如，可以按不同于所描述的次序来执行所描述的方法，并且还可以添加、省去、或组合各种步骤。另外，参照某些示例所描述的特征可在其他示例中被组合。

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

上面结合附图对本申请的实施例进行了描述，但是本申请并不局限于上述的具体实施方式，上述的具体实施方式仅仅是示意性的，而不是限制性的，本领域的普通技术人员在本申请的启示下，在不脱离本申请宗旨和权利要求所保护的范围情况下，还可做出很多形式，均属于本申请的保护之内。

上述仅为本申请的较佳实施例及所运用的技术原理。本申请不限于这里所述的特定实施例，对本领域技术人员来说能够进行的各种明显变化、重新调整及替代均不会脱离本申请的保护范围。因此，虽然通过以上实施例对本申请进行了较为详细的说明，但是本申请不仅仅限于以上实施例，在不脱离本申请构思的情况下，还可以包括更多其他等效实施例，而本申请的范围由权利要求的范围决定。

Claims (10)

1.一种基于帧同步的追帧加速方法，其特征在于，所述方法由客户端执行，所述方法包括：

若发生断线重连事件，向服务器发出重连请求；其中，所述重连请求包括断线时刻和重连时刻；

接收所述服务器基于所述重连请求确定的实时数据包和历史数据包；其中，所述实时数据包包括所述客户端以及与所述客户端连接于同一游戏的其他客户端的当前时刻操作指令；所述历史数据包包括与所述客户端连接于同一游戏的其他客户端从断线时刻到重连时刻之间的历史操作指令；

根据所述实时数据包，对所述客户端的操作对象以及其他客户端的操作对象进行数据解析，得到实时游戏画面；以及，根据历史数据包以及断线时刻所述客户端以及其他客户端的操作对象的历史状态，解析得到回放画面，并进行回放画面的展示。

2.根据权利要求1所述的基于帧同步的追帧加速方法，其特征在于，在根据历史数据包以及断线时刻所述客户端以及其他客户端的操作对象的历史状态，解析得到回放画面之后，所述方法还包括：

根据所述断线时刻到重连时刻之间的断线时长以及对于所述历史数据包的解析速度，得到加速倍数；

相应的，进行回放画面的展示，包括：

按照所述加速倍数对所述回放画面进行回放画面的加速展示。

3.根据权利要求1所述的基于帧同步的追帧加速方法，其特征在于，在接收所述服务器基于所述重连请求确定的实时数据包和历史数据包之前，所述方法还包括：

向服务器发送未经处理的实时数据包和历史数据包，供服务器根据所述实时数据包、所述历史数据包以及预设的关键帧设定条件确定实时关键帧以及历史关键帧，并将所述实时关键帧以及所述历史关键帧存储在实时数据包以及历史数据包中；

相应的，接收所述服务器基于所述重连请求确定的实时数据包和历史数据包，包括：

接收并解析服务器基于所述重连请求确定的实时数据包和历史数据包，得到实时关键帧以及历史关键帧。

4.根据权利要求1所述的基于帧同步的追帧加速方法，其特征在于，在接收所述服务器基于所述重连请求确定的实时数据包和历史数据包之前，所述方法还包括：

向服务器发送未经处理的实时数据包和历史数据包，供服务器根据所述实时数据包、所述历史数据包以及预设的定时帧设定条件确定实时定时帧以及历史定时帧，并将所述实时定时帧以及所述历史定时帧存储在实时数据包以及历史数据包中；

相应的，接收所述服务器基于所述重连请求确定的实时数据包和历史数据包，包括：

接收并解析服务器基于所述重连请求确定的实时数据包和历史数据包，得到实时定时帧以及历史定时帧。

5.根据权利要求3或4所述的基于帧同步的追帧加速方法，其特征在于，在得到所述关键帧或得到所述定时帧之后，所述方法还包括：

向服务器发送帧数量检测指令，供服务器根据帧数量检测指令确定所述关键帧或所述定时帧的数量，并将所述关键帧或所述定时帧的数量与预设的关键帧阈值或定时帧阈值作对比，若所述关键帧或所述定时帧超过预设的关键帧阈值或定时帧阈值，则获取当前时间戳，并根据所述当前时间戳、所述关键帧阈值或定时帧阈值删除关键帧或定时帧。

6.根据权利要求2所述的基于帧同步的追帧加速方法，其特征在于，在按照所述加速倍数对所述回放画面进行回放画面的加速展示之后，所述方法还包括：

响应于用户选择的跳转时间戳，根据所述跳转时间戳以及断线时刻确定跳转时间范围；

根据所述跳转时间范围确定跳转数据包数量，并根据所述跳转数据包数量确定回放画面，以及进行回放画面的展示。

7.一种基于帧同步的追帧加速装置，其特征在于，所述装置配置于客户端，所述装置包括：

重连请求发送模块，用于若发生断线重连事件，向服务器发出重连请求；其中，所述重连请求包括断线时刻和重连时刻；

数据包接收模块，用于接收所述服务器基于所述重连请求确定的实时数据包和历史数据包；其中，所述实时数据包包括所述客户端以及与所述客户端连接于同一游戏的其他客户端的当前时刻操作指令；所述历史数据包包括与所述客户端连接于同一游戏的其他客户端从断线时刻到重连时刻之间的历史操作指令；

回放画面展示模块，用于根据所述实时数据包，对所述客户端的操作对象以及其他客户端的操作对象进行数据解析，得到实时游戏画面；以及，根据历史数据包以及断线时刻所述客户端以及其他客户端的操作对象的历史状态，解析得到回放画面，并进行回放画面的展示。

8.根据权利要求7所述的基于帧同步的追帧加速装置，其特征在于，所述装置还包括加速倍数确定模块，所述加速倍数确定模块用于：

根据所述断线时刻到重连时刻之间的断线时长以及对于所述历史数据包的解析速度，得到加速倍数；

相应的，所述回放画面展示模块用于：

按照所述加速倍数对所述回放画面进行回放画面的加速展示。

9.一种电子设备，其特征在于，包括处理器，存储器及存储在所述存储器上并可在所述处理器上运行的程序或指令，所述程序或指令被所述处理器执行时实现如权利要求1-6中任一项所述的基于帧同步的追帧加速方法的步骤。

10.一种可读存储介质，其特征在于，所述可读存储介质上存储程序或指令，所述程序或指令被处理器执行时实现如权利要求1-6中任一项所述的基于帧同步的追帧加速方法的步骤。