CN110311754B - 一种数据的接收方法、装置、存储介质及电子设备 - Google Patents

Abstract

本公开实施例公开了一种数据的接收方法、装置、存储介质及电子设备，方法包括：在当前预定界面渲染周期内接收更新数据包，其中，更新数据包的数据仅包括在预定界面渲染周期内发生变化的更新键值项以及与更新键值项对应的数据；确定每个更新键值项在当前预定界面渲染周期的待渲染的第一数据；将更新键值项以及第一数据合并，构建当前预定界面渲染周期的待渲染数据集合。本公开实施例虽然接收的不是全量数据包，但一样能够基于更新数据包完成与全量数据包完全相同的效果，接收数据大大减少，极大的节省了客户端每个界面渲染周期接收到的数据量，提升数据传输的实时性，且客户端刷新数据耗费流量较少，用户体验较好。

Description

一种数据的接收方法、装置、存储介质及电子设备

技术领域

本公开涉及互联网领域，特别涉及一种数据的接收方法、装置、存储介质及电子设备。

背景技术

大批量数据的传输和处理对于互联网技术的发展非常重要，针对密集型时效性数据传输的要求越来越高，这类数据通常具有密集、快速、数据量大的特点，这就要求客户端的接收***能实时、高效、省流的展现和处理数据。

现有技术中，密集型时效性数据均是采用全量数据推送、全局场景刷新的方式，此种刷新方式客户端流量消耗大，实时性较差。

发明内容

有鉴于此，本公开实施例提出了一种数据的接收方法、装置、存储介质及电子设备，用以解决现有技术的如下问题：现有技术中对于密集型时效性数据均是采用全量推送、全局场景刷新的方式，此种刷新方式客户端流量消耗大，实时性较差。

一方面，本公开实施例提出了一种数据的接收方法，包括：在当前预定界面渲染周期内接收更新数据包，其中，所述更新数据包的数据仅包括在所述预定界面渲染周期内发生变化的更新键值项以及与所述更新键值项对应的数据；确定每个所述更新键值项在所述当前预定界面渲染周期的待渲染的第一数据；将所述更新键值项以及所述第一数据合并，构建所述当前预定界面渲染周期的待渲染数据集合。

在一些实施例中，在所述当前预定界面渲染周期内接收到多个所述更新数据包的情况下，所述确定每个所述更新键值项在所述当前预定界面渲染周期的待渲染的第一数据，包括：获取每个所述更新数据包中的更新数据；确定每项所述更新数据对应的所述更新键值项；确定每个所述更新键值项按照时间顺序最后一次发生变化的数据为所述第一数据。

在一些实施例中，所述将所述更新键值项以及所述第一数据合并，构建所述当前预定界面渲染周期的待渲染数据集合还包括：确定数据没有发生变化的未更新键值项；获取在上一个预定界面渲染周期内的待渲染数据集合中与所述未更新键值项对应的第二数据。

在一些实施例中，所述将所述更新键值项以及所述第一数据合并，构建所述当前预定界面渲染周期的待渲染数据集合还包括：将所有所述更新键值项和所述未更新键值项按照预定顺序排列；按照所述预定顺序，将所有所述第一数据和所述第二数据进行存储。

在一些实施例中，所述构建所述当前预定界面渲染周期的待渲染数据集合之后，还包括：加载所述当前预定界面渲染周期的待渲染数据集合的数据；建立内部数据结构；构建渲染树，对页面上各个元素进行位置计算和样式计算；根据渲染树对所述页面进行渲染。

在一些实施例中，所述当前预定界面渲染周期内接收更新数据包之后，还包括：按照预定解压缩方式对所述更新数据包进行解压缩，以得到解压缩后的更新数据。

在一些实施例中，所述确定每个所述更新键值项在所述当前预定界面渲染周期的待渲染的第一数据之前，还包括：在所述更新键值项的键值名为缩略键值名的情况下，将所述更新键值项的所述缩略键值名转换为完整键值名。

另一方面，本公开实施例提出了一种数据的接收装置，包括：接收模块，其配置为在当前预定界面渲染周期内接收更新数据包，其中，所述更新数据包的数据仅包括在所述预定界面渲染周期内发生变化的更新键值项以及与所述更新键值项对应的数据；确定模块，其配置为确定每个所述更新键值项在所述当前预定界面渲染周期的待渲染的第一数据；构建模块，其配置为将所述更新键值项以及所述第一数据合并，构建所述当前预定界面渲染周期的待渲染数据集合。

在一些实施例中，所述确定模块还包括：第一获取单元，其配置为获取每个所述更新数据包中的更新数据；第一确定单元，其配置为确定每项所述更新数据对应的所述更新键值项；第二确定单元，其配置为确定每个所述更新键值项按照时间顺序最后一次发生变化的数据为所述第一数据。

在一些实施例中，所述构建模块还包括：第三确定单元，其配置为确定数据没有发生变化的未更新键值项；第二获取单元，其配置为获取在上一个预定界面渲染周期内的待渲染数据集合中与所述未更新键值项对应的第二数据。

在一些实施例中，所述构建模块还包括：排序单元，其配置为将所有所述更新键值项和所述未更新键值项按照预定顺序排列；存储单元，其配置为按照所述预定顺序，将所有所述第一数据和所述第二数据进行存储。

在一些实施例中，所述装置还包括：渲染模块，其配置为：加载所述当前预定界面渲染周期的待渲染数据集合的数据；建立内部数据结构；构建渲染树，对页面上各个元素进行位置计算和样式计算；根据渲染树对所述页面进行渲染。

在一些实施例中，还包括：解压缩模块，其配置为按照预定解压缩方式对所述更新数据包进行解压缩，以得到解压缩后的更新数据。

在一些实施例中，还包括：转换模块，其配置为在所述更新键值项的键值名为缩略键值名的情况下，将所述更新键值项的所述缩略键值名转换为完整键值名。

另一方面，本公开实施例提出了一种存储介质，存储有计算机程序，计算机程序被处理器执行时实现本公开任意实施例提供的方法。

另一方面，本公开实施例提出了一种电子设备，至少包括存储器、处理器，存储器上存储有计算机程序，处理器在执行存储器上的计算机程序时实现本公开任意实施例提供的方法。

本公开实施例接收到的是更新数据包，更新数据包的数据仅包括在预定界面渲染周期内发生变化的更新键值项以及与更新键值项对应的数据，虽然接收的不是全量数据包，但一样能够基于更新数据包完成与全量数据包完全相同的效果，客户端接收到的更新数据包中的数据相比与原来的全量数据包而言，接收数据大大减少，极大的节省了客户端每个界面渲染周期接收到的数据量，提升数据传输的实时性，且客户端刷新数据耗费流量较少，用户体验较好。

附图说明

图1为本公开第一实施例提供的数据的接收方法的流程图；

图2为本公开第二实施例提供的数据的接收方法的流程图；

图3为本公开第三实施例提供的数据的接收装置的结构示意图；

图4为本公开第五实施例提供的客户端与服务器交互示意图；

图5为本公开第五实施例提供的电子设备的结构示意图。

具体实施方式

为了使得本公开实施例的目的、技术方案和优点更加清楚，下面将结合本公开实施例的附图，对本公开实施例的技术方案进行清楚、完整地描述。显然，所描述的实施例是本公开的一部分实施例，而不是全部的实施例。基于所描述的本公开的实施例，本领域普通技术人员在无需创造性劳动的前提下所获得的所有其他实施例，都属于本公开保护的范围。

除非另外定义，本公开使用的技术术语或者科学术语应当为本公开所属领域内具有一般技能的人士所理解的通常意义。本公开中使用的“第一”、“第二”以及类似的词语并不表示任何顺序、数量或者重要性，而只是用来区分不同的组成部分。“包括”或者“包含”等类似的词语意指出现该词前面的元件或者物件涵盖出现在该词后面列举的元件或者物件及其等同，而不排除其他元件或者物件。“连接”或者“相连”等类似的词语并非限定于物理的或者机械的连接，而是可以包括电性的连接，不管是直接的还是间接的。“上”、“下”、“左”、“右”等仅用于表示相对位置关系，当被描述对象的绝对位置改变后，则该相对位置关系也可能相应地改变。

为了保持本公开实施例的以下说明清楚且简明，本公开省略了已知功能和已知部件的详细说明。

本公开第一实施例提供了一种数据的接收方法，该方法的流程如图1所示，包括步骤S101至S103：

S101，在当前预定界面渲染周期内接收更新数据包，其中，更新数据包的数据仅包括在预定界面渲染周期内发生变化的更新键值项以及与更新键值项对应的数据。

关于界面的渲染，其都是具备一个界面渲染周期的，例如一个界面渲染周期为20ms，当界面渲染周期到达时，就需要基于该界面渲染周期内接收到的数据进行渲染，进而才可以呈现给用户，随后，基于界面渲染周期持续接收数据，以在下一个界面渲染周期到达时再次渲染。

但现有技术中，每个界面渲染周期接收到的数据都是全量数据包，即无论界面上的元素对应的某个键值项是否发生变化，都需要发送其对应的数据，对于用户而言流量消耗太大。

在本实施例中，更新数据包中仅包括在预定界面渲染周期内发生变化的更新键值项以及与更新键值项对应的数据，服务器不会发送没发生变化的键值项所对应的数据，因此，客户端接收到的更新数据包中的数据相比于原来的全量数据包而言，接收数据大大减少，极大的节省了客户端每个界面渲染周期接收到的数据量。

S102，确定每个更新键值项在当前预定界面渲染周期的待渲染的第一数据。

本方法可以针对密集型时效性数据，这种数据体量比较庞大，数据变化频率也很快，一般在极短的时间内(例如毫秒级的时间)变化的数据量达到另一个数量级，所以，更新数据包的发送间隔可以远小于预定界面渲染周期，即一个界面渲染周期内可能会接收到多个更新数据包。

对于每个更新数据包而言，其中既可能出现较多不同的更新键值项产生对应的变化数据，还可能一个界面渲染周期内接收到同一个更新键值项的多个变化数据，为此，本实施例需要确定同一个更新键值项在当前界面渲染周期内接收到的多个变化数据中确定哪一个是后续可以进行渲染的更新数据，可以进行渲染的更新数据即为第一数据。

在一个界面渲染周期内如果接收到同一个更新键值项的多个变化数据，也就意味着当前预定界面渲染周期内接收到更新数据包的次数也至少是多个。在当前预定界面渲染周期内接收到多个更新数据包的情况下，确定每个更新键值项在当前预定界面渲染周期的待渲染的第一数据时，可以包括如下过程：获取每个更新数据包中的更新数据；确定每项更新数据对应的更新键值项；确定每个更新键值项按照时间顺序最后一次发生变化的数据为第一数据。

下面以一个简单的示例对上述过程进行说明。

例如，全量数据包一共包括5个键值项，键值名分别为alpha、bravo、charlie、delta、echo，一个预定界面渲染周期内接收到4个更新数据包，分别是该界面渲染周期内的第3ms、8ms、13ms、18ms，第3ms接收到的更新数据包中包括键值名alpha和charlie对应的数据，第8ms接收到的更新数据包中包括键值名alpha、charlie和echo对应的数据，第13ms接收到的更新数据包中包括键值名echo对应的数据，第18ms接收到的更新数据包中包括键值名bravo和delta对应的数据。

由于键值名alpha、charlie和echo对应的数据都接收到了2次，确定键值名alpha、charlie和echo按照时间顺序最后一次发生变化的数据为第一数据，即键值名alpha的第一数据为第8ms接收到的更新数据包中的数据，键值名charlie的第一数据为第8ms接收到的更新数据包中的数据，键值名echo的第一数据为第13ms接收到的更新数据包中的数据；键值名bravo和delta的第一数据为第18ms接收到的更新数据包中的数据。

S103，将更新键值项以及第一数据合并，构建当前预定界面渲染周期的待渲染数据集合。

每个预定界面渲染周期到达时都需要基于接收到的数据进行渲染，本实施例由于接收的是更新数据包，则没有变化的键值项不会被接收到，但是没有变化的未更新键值项对应的元素也是需要渲染的，因此，在将更新键值项以及第一数据合并，构建当前预定界面渲染周期的待渲染数据集合的过程中，还需要确定数据没有发生变化的未更新键值项，并获取在上一个预定界面渲染周期内的待渲染数据集合中与未更新键值项对应的第二数据。

例如，全量数据包一共包括5个键值项，键值名分别为alpha、bravo、charlie、delta、echo，一个预定界面渲染周期内接收到4个更新数据包，分别是该界面渲染周期内的第3ms、8ms、13ms、18ms，第3ms接收到的更新数据包中包括键值名alpha和charlie对应的数据，第8ms接收到的更新数据包中包括键值名alpha、charlie和echo对应的数据，第13ms接收到的更新数据包中包括键值名echo对应的数据，第18ms接收到的更新数据包中包括键值名bravo和echo对应的数据。

由于当前预定界面渲染周期内接收到的更新数据包中没有键值名delta对应的数据，因此，可以在上一个预定界面渲染周期内的待渲染数据集合中获取键值名delta对应的数据，以将该数据作为第二数据，放入到当前预定界面渲染周期的待渲染数据集合中以用于本预定界面渲染周期后的渲染操作。

获取到的上一个预定界面渲染周期内键值名delta的待渲染数据集合中的第二数据可能是上一个预定界面渲染周期接收到的更新数据包中的数据，也可能是键值名delta在上一个预定界面渲染周期也未更新，该数据是上一个的上一个预定界面渲染周期获取到的。相对应的，如果当前预定界面渲染周期的下一个预定界面渲染周期内键值名delta对应的数据也未更新，则下一个预定界面渲染周期在构建待渲染数据集合时，可以获取当前预定界面渲染周期内待渲染数据集合中的数据来作为第二数据。

在获取到全部键值项对应的数据后，将所有更新键值项和未更新键值项按照预定顺序排列，并按照预定顺序将所有第一数据和第二数据进行存储。至此，当前预定界面渲染周期的待渲染数据集合已经完全构建好。

在构建当前预定界面渲染周期的待渲染数据集合之后，就可以对待渲染数据集合进行如下渲染过程：加载当前预定界面渲染周期的待渲染数据集合的数据；建立内部数据结构；构建渲染树，对页面上各个元素进行位置计算和样式计算；根据渲染树对页面进行渲染。由于待渲染数据集合中包括所有键值项对应的数据，所以，上述渲染过程与现有技术中对全量数据包的渲染过程完全相同，此处不再赘述。

本公开实施例接收到的是更新数据包，更新数据包的数据仅包括在预定界面渲染周期内发生变化的更新键值项以及与更新键值项对应的数据，虽然接收的不是全量数据包，但一样能够基于更新数据包完成与全量数据包完全相同的效果，客户端接收到的更新数据包中的数据相比与原来的全量数据包而言，接收数据大大减少，极大的节省了客户端每个界面渲染周期接收到的数据量，提升数据传输的实时性，且客户端刷新数据耗费流量较少，用户体验较好。

本公开第二实施例提供了一种数据的接收方法，该方法的流程如图2所示，包括步骤S201至S205：

S201，在当前预定界面渲染周期内接收更新数据包，其中，更新数据包的数据仅包括在预定界面渲染周期内发生变化的更新键值项以及与更新键值项对应的数据。

关于界面的渲染，其都是具备一个界面渲染周期的，例如一个界面渲染周期为20ms，当界面渲染周期到达时，就需要基于该界面渲染周期内接收到的数据进行渲染，进而才可以呈现给用户，随后，基于界面渲染周期持续接收数据，以在下一个界面渲染周期到达时再次渲染。

但现有技术中都是每个界面渲染周期接收到的数据都是全量数据包，即无论某个键值项是否发生变化，都需要发送其对应的数据，对于用户而言流量消耗太大。

在本实施例中，更新数据包中仅包括在预定界面渲染周期内发生变化的更新键值项以及与更新键值项对应的数据，服务器不会发送没发生变化的键值项所对应的数据，因此，客户端接收到的更新数据包中的数据相比与原来的全量数据包而言，接收数据大大减少，极大的节省了客户端每个界面渲染周期接收到的数据量。

S202，按照预定解压缩方式对更新数据包进行解压缩，以得到解压缩后的更新数据包。

在服务器对全量数据包进行推送时，由于其数据量较大，大多数情况是无法对数据进行压缩的，即使进行压缩，也会因为数据量较大，而导致压缩耗时会较长；当服务器发送的数据由全量数据变为发生变化的数据时，数据量明显降低，所以服务器可以对更新数据包进行压缩，由于更新数据包的数据量少，压缩时间较短，压缩后还可以减少一部分字节，例如，没有压缩前更新数据包为100字节，压缩后变成了60字节。上述的预定压缩方式通常可以采用gzip压缩，当然，也可以采用其它的压缩方式，此处不进行限定。

基于上述考虑，本公开实施例客户端接收到的更新数据包正是服务器压缩后的更新数据包，所以在接收到更新数据包后，需要按照预定解压缩方式对更新数据包进行解压缩，预定解压缩方式与服务器的预定压缩方式相对应即可，此处不进行限定。客户端接收压缩后的更新数据包能够再次减少使用的流量。

S203，在更新键值项的键值名为缩略键值名的情况下，将更新键值项的缩略键值名转换为完整键值名。

为了进一步减少传输的数据量，服务器还可以在将发生变化的数据按照预定压缩方式进行压缩之前，为每个更新键值项都配置缩略键值名，进一步减少传输的数据；相对应的，客户端接收的更新数据包中更新键值项就是具有缩略键值名的键值项。例如，键值名是999的键值项在现有推送至客户端的全量数据包中会写成“alpha:999”，本公开将alpha进行了缩写，直接写成a，则原来的“alpha:999”在发生变化时，更新数据包中就会是“a:999”，这样会减少数据的处理量,当然,在与服务器初次建立连接接收全量数据包时就可以按照缩略的键值名发送,该方法只需要客户端能够解析并知晓该缩略的键值名对应的含义即可。

S204，确定每个更新键值项在当前预定界面渲染周期的待渲染的第一数据。

本方法可以针对密集型时效性数据，这种数据体量比较庞大，数据变化频率也很快，一般在极短的时间内(例如毫秒级的时间)变化的数据量达到另一个数量级，所以，更新数据包的发送间隔可以远小于预定界面渲染周期，即一个界面渲染周期内可能会接收到多个更新数据包。

对于每个更新数据包，既可能出现较多不同的更新键值项产生对应的变化数据，还可能一个界面渲染周期内接收到同一个更新键值项的多个变化数据，为此，本实施例需要确定同一个更新键值项在当前界面渲染周期内接收到的多个变化数据中确定哪一个是后续可以进行渲染的更新数据，可以进行渲染的更新数据即为第一数据。

一个界面渲染周期内如果接收到同一个更新键值项的多个变化数据，也就意味着当前预定界面渲染周期内接收到更新数据包的次数也至少是多个。在当前预定界面渲染周期内接收到多个更新数据包的情况下，确定每个更新键值项在当前预定界面渲染周期的待渲染的第一数据时，可以包括如下过程：获取每个更新数据包中的更新数据；确定每项更新数据对应的更新键值项；确定每个更新键值项按照时间顺序最后一次发生变化的数据为第一数据。

下面以一个简单的示例对上述过程进行说明。

例如，全量数据包一共包括5个键值项，键值名分别为alpha、bravo、charlie、delta、echo，一个预定界面渲染周期内接收到4个更新数据包，分别是该界面渲染周期内的第3ms、8ms、13ms、18ms，第3ms接收到的更新数据包中包括键值名alpha和charlie对应的数据，第8ms接收到的更新数据包中包括键值名alpha、charlie和echo对应的数据，第13ms接收到的更新数据包中包括键值名echo对应的数据，第18ms接收到的更新数据包中包括键值名bravo和delta对应的数据。

由于键值名alpha、charlie和echo对应的数据都接收到了2次，确定键值名alpha、charlie和echo按照时间顺序最后一次发生变化的数据为第一数据，即键值名alpha的第一数据为第8ms接收到的更新数据包中的数据，键值名charlie的第一数据为第8ms接收到的更新数据包中的数据，键值名echo的第一数据为第13ms接收到的更新数据包中的数据；键值名bravo和delta的第一数据为第18ms接收到的更新数据包中的数据。

S205，将更新键值项以及第一数据合并，构建当前预定界面渲染周期的待渲染数据集合。

每个预定界面渲染周期到达时都需要对接收到的数据进行渲染，本实施例由于接收的是更新数据包，则没有变化的键值项不会被接收到，但是没有变化的键值项也是需要渲染的，因此，在将更新键值项以及第一数据合并，构建当前预定界面渲染周期的待渲染数据集合的过程中，还需要确定数据没有发生变化的未更新键值项，并获取在上一个预定界面渲染周期内的待渲染数据集合中与未更新键值项对应的第二数据。

例如，全量数据包一共包括5个键值项，键值名分别为alpha、bravo、charlie、delta、echo，一个预定界面渲染周期内接收到4个更新数据包，分别是该界面渲染周期内的第3ms、8ms、13ms、18ms，第3ms接收到的更新数据包中包括键值名alpha和charlie对应的数据，第8ms接收到的更新数据包中包括键值名alpha、charlie和echo对应的数据，第13ms接收到的更新数据包中包括键值名echo对应的数据，第18ms接收到的更新数据包中包括键值名bravo和echo对应的数据。

由于当前预定界面渲染周期内接收到的更新数据包中没有键值名delta对应的数据，因此，去上一个预定界面渲染周期内的待渲染数据集合中获取键值名delta对应的数据，以将该数据作为第二数据，放入到当前预定界面渲染周期的待渲染数据集合中。

获取到的上一个预定界面渲染周期内键值名delta的待渲染数据集合中的第二数据可能是上一个预定界面渲染周期接收到的更新数据包中的数据，也可能是键值名delta在上一个预定界面渲染周期也未更新，该数据是上一个的上一个预定界面渲染周期获取到的。相对应的，如果当前预定界面渲染周期的下一个预定界面渲染周期内键值名delta对应的数据也未更新，则下一个预定界面渲染周期在构建待渲染数据集合时，可以获取当前预定界面渲染周期内待渲染数据集合中的数据来作为第二数据。

在获取到全部键值项对应的数据后，将所有更新键值项和未更新键值项按照预定顺序排列，并按照预定顺序将所有第一数据和第二数据进行存储。至此，当前预定界面渲染周期的待渲染数据集合已经完全构建好。

在构建当前预定界面渲染周期的待渲染数据集合之后，就可以对待渲染数据集合进行如下渲染过程：加载当前预定界面渲染周期的待渲染数据集合的数据；建立内部数据结构；构建渲染树，对页面上各个元素进行位置计算和样式计算；根据渲染树对页面进行渲染。由于待渲染数据集合中包括所有键值项对应的数据，所以，上述渲染过程与现有技术中对全量数据包的渲染过程完全相同，此处不再赘述。

本公开实施例接收到的是更新数据包，更新数据包的数据仅包括在预定界面渲染周期内发生变化的更新键值项以及与更新键值项对应的数据，虽然接收的不是全量数据包，但一样能够基于更新数据包完成与全量数据包完全相同的效果，客户端接收到的更新数据包中的数据相比与原来的全量数据包而言，接收数据大大减少，极大的节省了客户端每个界面渲染周期接收到的数据量，提升数据传输的实时性，且客户端刷新数据耗费流量较少，用户体验较好。

本公开第三实施例提供了一种数据的接收装置，该装置的结构示意如图3所示，包括：

接收模块10，其配置为在当前预定界面渲染周期内接收更新数据包，其中，更新数据包的数据仅包括在预定界面渲染周期内发生变化的更新键值项以及与更新键值项对应的数据；确定模块20，与接收模块10耦合，其配置为确定每个更新键值项在当前预定界面渲染周期的待渲染的第一数据；构建模块30，与确定模块20耦合，其配置为将更新键值项以及第一数据合并，构建当前预定界面渲染周期的待渲染数据集合。

关于界面的渲染，其都是具备一个界面渲染周期的，例如一个界面渲染周期为20ms，当界面渲染周期到达时，就需要对该界面渲染周期内接收到的数据进行渲染，进而才可以呈现给用户，随后，持续接收数据，以在下一个界面渲染周期到达时再次渲染。

但现有技术中，每个界面渲染周期接收到的数据都是全量数据包，即无论某个键值项是否发生变化，都需要发送其对应的数据，对于用户而言流量消耗太大。

在本实施例中，更新数据包中仅包括在预定界面渲染周期内发生变化的更新键值项以及与更新键值项对应的数据，服务器不会发送没发生变化的键值项所对应的数据，因此，客户端接收到的更新数据包中的数据相比于原来的全量数据包而言，接收数据大大减少，极大的节省了客户端每个界面渲染周期接收到的数据量。

本方法可以针对密集型时效性数据，这种数据体量比较庞大，数据变化频率也很快，一般在极短的时间内(例如毫秒级的时间)变化的数据量达到另一个数量级，所以，更新数据包的发送间隔可以远小于预定界面渲染周期，即一个界面渲染周期内可能会接收到多个更新数据包。

对于每个更新数据包而言，其中既可能出现较多不同的更新键值项产生对应的变化数据，还可能一个界面渲染周期内接收到同一个更新键值项的多个变化数据，为此，本实施例需要确定同一个更新键值项在当前界面渲染周期内接收到的多个变化数据中确定哪一个是后续可以进行渲染的更新数据，可以进行渲染的更新数据即为第一数据。

一个界面渲染周期内如果接收到同一个更新键值项的多个变化数据，也就意味着当前预定界面渲染周期内接收到更新数据包的次数也至少是多个。在当前预定界面渲染周期内接收到多个更新数据包的情况下，确定模块还包括：第一获取单元，其配置为获取每个更新数据包中的更新数据；第一确定单元，其配置为确定每项更新数据对应的更新键值项；第二确定单元，其配置为确定每个更新键值项按照时间顺序最后一次发生变化的数据为第一数据。

下面以一个简单的示例对上述过程进行说明。

例如，全量数据包一共包括5个键值项，键值名分别为alpha、bravo、charlie、delta、echo，一个预定界面渲染周期内接收到4个更新数据包，分别是该界面渲染周期内的第3ms、8ms、13ms、18ms，第3ms接收到的更新数据包中包括键值名alpha和charlie对应的数据，第8ms接收到的更新数据包中包括键值名alpha、charlie和echo对应的数据，第13ms接收到的更新数据包中包括键值名echo对应的数据，第18ms接收到的更新数据包中包括键值名bravo和delta对应的数据。

由于键值名alpha、charlie和echo对应的数据都接收到了2次，确定键值名alpha、charlie和echo按照时间顺序最后一次发生变化的数据为第一数据，即键值名alpha的第一数据为第8ms接收到的更新数据包中的数据，键值名charlie的第一数据为第8ms接收到的更新数据包中的数据，键值名echo的第一数据为第13ms接收到的更新数据包中的数据；键值名bravo和delta的第一数据为第18ms接收到的更新数据包中的数据。

每个预定界面渲染周期到达时都需要对接收到的数据进行渲染，本实施例由于接收的是更新数据包，则没有变化的键值项不会被接收到，但是没有变化的键值项也是需要渲染的，因此，构建模块还包括：第三确定单元，其配置为确定数据没有发生变化的未更新键值项；第二获取单元，其配置为获取在上一个预定界面渲染周期内的待渲染数据集合中与未更新键值项对应的第二数据。

例如，全量数据包一共包括5个键值项，键值名分别为alpha、bravo、charlie、delta、echo，一个预定界面渲染周期内接收到4个更新数据包，分别是该界面渲染周期内的第3ms、8ms、13ms、18ms，第3ms接收到的更新数据包中包括键值名alpha和charlie对应的数据，第8ms接收到的更新数据包中包括键值名alpha、charlie和echo对应的数据，第13ms接收到的更新数据包中包括键值名echo对应的数据，第18ms接收到的更新数据包中包括键值名bravo和echo对应的数据。

由于当前预定界面渲染周期内接收到的更新数据包中没有键值名delta对应的数据，因此，去上一个预定界面渲染周期内的待渲染数据集合中获取键值名delta对应的数据，以将该数据作为第二数据，放入到当前预定界面渲染周期的待渲染数据集合中。

获取到的上一个预定界面渲染周期内键值名delta的待渲染数据集合中的第二数据可能是上一个预定界面渲染周期接收到的更新数据包中的数据，也可能是键值名delta在上一个预定界面渲染周期也未更新，该数据是上一个的上一个预定界面渲染周期获取到的。相对应的，如果当前预定界面渲染周期的下一个预定界面渲染周期内键值名delta对应的数据也未更新，则下一个预定界面渲染周期在构建待渲染数据集合时，可以获取当前预定界面渲染周期内待渲染数据集合中的数据来作为第二数据。

构建模块还包括：排序单元，其配置为在获取到全部键值项对应的数据后，将所有更新键值项和未更新键值项按照预定顺序排列；存储单元，其配置为按照预定顺序，将所有第一数据和第二数据进行存储。至此，当前预定界面渲染周期的待渲染数据集合已经完全构建好。

在构建当前预定界面渲染周期的待渲染数据集合之后，就可以对待渲染数据集合进渲染。上述装置还包括渲染模块，其配置为：加载当前预定界面渲染周期的待渲染数据集合的数据；建立内部数据结构；构建渲染树，对页面上各个元素进行位置计算和样式计算；根据渲染树对页面进行渲染。由于待渲染数据集合中包括所有键值项对应的数据，所以，上述渲染过程与现有技术中对全量数据包的渲染过程完全相同，此处不再赘述。

在服务器对全量数据包进行推送时，由于其数据量较大，大多数情况是无法对数据进行压缩的，即使进行压缩，也会因为数据量较大，而导致压缩耗时会较长；当服务器发送的数据由全量数据变为发生变化的数据时，数据量明显降低，所以服务器可以对更新数据包进行压缩，由于更新数据包的数据量少，压缩时间较短，压缩后还可以减少一部分字节，例如，没有压缩前更新数据包为100字节，压缩后变成了60字节。上述的预定压缩方式通常可以采用gzip压缩，当然，也可以采用其它的压缩方式，此处不进行限定。

基于上述考虑，本公开实施例还包括解压缩模块，其配置为按照预定解压缩方式对更新数据包进行解压缩，以得到解压缩后的更新数据包。本公开实施例客户端接收到的更新数据包正是服务器压缩后的更新数据包，所以在接收到更新数据包后，需要按照预定解压缩方式对更新数据包进行解压缩，预定解压缩方式与服务器的预定压缩方式相对应即可，此处不进行限定。客户端接收压缩后的更新数据包能够再次减少使用的流量。

为了进一步减少传输的数据量，服务器还可以在将发生变化的数据按照预定压缩方式进行压缩之前，为每个更新键值项都配置缩略键值名，进一步减少传输的数据；相对应的，客户端接收的更新数据包中更新键值项就是具有缩略键值名的键值项。所以，上述装置还可以包括转换模块，其配置为在更新键值项的键值名为缩略键值名的情况下，将更新键值项的缩略键值名转换为完整键值名。例如，键值名是999的更新键值项在现有推送至客户端的全量数据包中会写成“alpha:999”，本公开将alpha进行了缩写，直接写成a，则原来的“alpha:999”在发生变化时，更新数据包中就会是“a:999”，这样会减少数据的处理量,当然,在与服务器初次建立连接接收全量数据包时就可以按照缩略的键值名发送,该方法只需要客户端能够解析并知晓该缩略的键值名对应的含义即可。当客户端接收到缩略的键值名时，通过转换模块对其进行转换即可。

本公开实施例接收到的是更新数据包，更新数据包的数据仅包括在预定界面渲染周期内发生变化的更新键值项以及与更新键值项对应的数据，虽然接收的不是全量数据包，但一样能够基于更新数据包完成与全量数据包完全相同的效果，客户端接收到的更新数据包中的数据相比与原来的全量数据包而言，接收数据大大减少，极大的节省了客户端每个界面渲染周期接收到的数据量，提升数据传输的实时性，且客户端刷新数据耗费流量较少，用户体验较好。

本公开第四实施例提供了一种存储介质，存储有计算机程序，该计算机程序被处理器执行时实现本公开任意实施例提供的方法，包括如下步骤S11至S13：

S11，在当前预定界面渲染周期内接收更新数据包，其中，更新数据包的数据仅包括在预定界面渲染周期内发生变化的更新键值项以及与更新键值项对应的数据；

S12，确定每个更新键值项在当前预定界面渲染周期的待渲染的第一数据；

S13，将更新键值项以及第一数据合并，构建当前预定界面渲染周期的待渲染数据集合。

计算机程序被处理器执行确定每个更新键值项在当前预定界面渲染周期的待渲染的第一数据的步骤时，具体被处理器执行如下步骤：在当前预定界面渲染周期内接收到多个更新数据包的情况下，获取每个更新数据包中的更新数据；确定每项更新数据对应的更新键值项；确定每个更新键值项按照时间顺序最后一次发生变化的数据为第一数据。

计算机程序被处理器执行将更新键值项以及第一数据合并，构建当前预定界面渲染周期的待渲染数据集合的步骤时，具体被处理器执行如下步骤：确定数据没有发生变化的未更新键值项；获取在上一个预定界面渲染周期内的待渲染数据集合中与未更新键值项对应的第二数据。

计算机程序被处理器执行将更新键值项以及第一数据合并，构建当前预定界面渲染周期的待渲染数据集合的步骤时，具体被处理器执行如下步骤：将所有更新键值项和未更新键值项按照预定顺序排列；按照预定顺序，将所有第一数据和第二数据进行存储。

计算机程序被处理器执行构建当前预定界面渲染周期的待渲染数据集合的步骤之后，还被处理器执行如下步骤：加载当前预定界面渲染周期的待渲染数据集合的数据；建立内部数据结构；构建渲染树，对页面上各个元素进行位置计算和样式计算；根据渲染树对页面进行渲染。

计算机程序被处理器执行当前预定界面渲染周期内接收更新数据包的步骤之后，还被处理器执行如下步骤：按照预定解压缩方式对更新数据包进行解压缩，以得到解压缩后的更新数据。

计算机程序被处理器执行确定每个更新键值项在当前预定界面渲染周期的待渲染的第一数据的步骤之前，还被处理器执行如下步骤：更新键值项的键值名为缩略键值名的情况下，将更新键值项的缩略键值名转换为完整键值名。

本公开实施例接收到的是更新数据包，更新数据包的数据仅包括在预定界面渲染周期内发生变化的更新键值项以及与更新键值项对应的数据，虽然接收的不是全量数据包，但一样能够基于更新数据包完成与全量数据包完全相同的效果，客户端接收到的更新数据包中的数据相比与原来的全量数据包而言，接收数据大大减少，极大的节省了客户端每个界面渲染周期接收到的数据量，提升数据传输的实时性，且客户端刷新数据耗费流量较少，用户体验较好。

可选地，在本实施例中，上述存储介质可以包括但不限于：U盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，RandomAccessMemory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。可选地，在本实施例中，处理器根据存储介质中已存储的程序代码执行上述实施例记载的方法步骤。可选地，本实施例中的具体示例可以参考上述实施例及可选实施方式中所描述的示例，本实施例在此不再赘述。显然，本领域的技术人员应该明白，上述的本公开的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，并且在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本公开不限制于任何特定的硬件和软件结合。

本公开第五实施例提供了一种电子设备，该电子设备可以与服务器交互，其交互示意如图4所示，每个该电子设备的结构示意图均可以如图5所示，至少包括存储器901和处理器902，存储器901上存储有计算机程序，处理器902在执行存储器901上的计算机程序时实现本公开任意实施例提供的方法。示例性的，电子设备计算机程序步骤如下S21至S23：

S21，在当前预定界面渲染周期内接收更新数据包，其中，更新数据包的数据仅包括在预定界面渲染周期内发生变化的更新键值项以及与更新键值项对应的数据；

S22，确定每个更新键值项在当前预定界面渲染周期的待渲染的第一数据；

S23，将更新键值项以及第一数据合并，构建当前预定界面渲染周期的待渲染数据集合。

处理器在执行存储器上存储的确定每个更新键值项在当前预定界面渲染周期的待渲染的第一数据的计算机程序时，具体执行如下计算机程序：在当前预定界面渲染周期内接收到多个更新数据包的情况下，获取每个更新数据包中的更新数据；确定每项更新数据对应的更新键值项；确定每个更新键值项按照时间顺序最后一次发生变化的数据为第一数据。

处理器在执行存储器上存储的将更新键值项以及第一数据合并，构建当前预定界面渲染周期的待渲染数据集合的计算机程序时，具体执行如下计算机程序：确定数据没有发生变化的未更新键值项；获取在上一个预定界面渲染周期内的待渲染数据集合中与未更新键值项对应的第二数据。

处理器在执行存储器上存储的将更新键值项以及第一数据合并，构建当前预定界面渲染周期的待渲染数据集合的计算机程序时，具体执行如下计算机程序：将所有更新键值项和未更新键值项按照预定顺序排列；按照预定顺序，将所有第一数据和第二数据进行存储。

处理器在执行存储器上存储的构建当前预定界面渲染周期的待渲染数据集合的计算机程序之后，还执行如下计算机程序：加载当前预定界面渲染周期的待渲染数据集合的数据；建立内部数据结构；构建渲染树，对页面上各个元素进行位置计算和样式计算；根据渲染树对页面进行渲染。

处理器在执行存储器上存储的当前预定界面渲染周期内接收更新数据包的计算机程序之后，还执行如下计算机程序：按照预定解压缩方式对更新数据包进行解压缩，以得到解压缩后的更新数据。

处理器在执行存储器上存储的确定每个更新键值项在当前预定界面渲染周期的待渲染的第一数据的计算机程序之前，还执行如下计算机程序：更新键值项的键值名为缩略键值名的情况下，将更新键值项的缩略键值名转换为完整键值名。

本公开实施例接收到的是更新数据包，更新数据包的数据仅包括在预定界面渲染周期内发生变化的更新键值项以及与更新键值项对应的数据，虽然接收的不是全量数据包，但一样能够基于更新数据包完成与全量数据包完全相同的效果，客户端接收到的更新数据包中的数据相比与原来的全量数据包而言，接收数据大大减少，极大的节省了客户端每个界面渲染周期接收到的数据量，提升数据传输的实时性，且客户端刷新数据耗费流量较少，用户体验较好。

下面以路况数据为例，对上述交互过程进一步说明。

(1)客户端与服务器建立路况数据连接。

(2)连接成功后，服务器首先向客户端推送当前的全量数据包，之后当路况更新，将此更新数据包做长短键值映射、gzip压缩，推送给客户端。

(3)客户端收到该增量数据，分发到与界面渲染线程并行的数据处理线程，进行gzip解压缩、长短键值反映射，并与本地已有数据做合并，最后将处理后数据转发给界面渲染线程；界面渲染线程使用数据对界面进行增量局部刷新。

实现时，客户端设备屏幕刷新率一般为60fps，即最短每隔16ms会有一次界面渲染，数据推送是毫秒级的，所以两次界面渲染间隔内可能会收到多次数据推送。出于用户体验考虑，客户端的操作***一般均要求界面渲染过程必须发生在主线程上，网络操作发生在异步线程，当网络得到数据后，将其转发到主线程。针对路况存在的数据推送频率大于刷新频率的场景，在网络数据获取线程和渲染主线程中桥接数据处理线程，进行gzip解压缩、长短键值反映射和数据合并工作，处理完毕后再转发给主线程，确保数据处理没有阻塞渲染主线程。

长短键值映射和gzip压缩方式能够使数据量约减少50％，数据包大小减小，基本能保证绝大部分数据包在一个1mtu(1500字节)内，分发送达时间变短，实时性提高。客户端线程并行处理和渲染数据，并执行局部刷新，降低客户端处理延时，减少网络分包数，从而提高实时性和节省流量。

上述数据的接收方法或者装置同样可运用在其他涉及到密集型时效性数据传输的运用环境中，例如天气信息传输领域、实况比赛信息传输领域等，本公开对此不做限定。

此外，尽管已经在本文中描述了示例性实施例，其范围包括任何和所有基于本公开的具有等同元件、修改、省略、组合(例如，各种实施例交叉的方案)、改编或改变的实施例。权利要求书中的元件将被基于权利要求中采用的语言宽泛地解释，并不限于在本说明书中或本申请的实施期间所描述的示例，其示例将被解释为非排他性的。因此，本说明书和示例旨在仅被认为是示例，真正的范围和精神由以下权利要求以及其等同物的全部范围所指示。

以上描述旨在是说明性的而不是限制性的。例如，上述示例(或其一个或更多方案)可以彼此组合使用。例如本领域普通技术人员在阅读上述描述时可以使用其它实施例。另外，在上述具体实施方式中，各种特征可以被分组在一起以简单化本公开。这不应解释为一种不要求保护的公开的特征对于任一权利要求是必要的意图。相反，本公开的主题可以少于特定的公开的实施例的全部特征。从而，以下权利要求书作为示例或实施例在此并入具体实施方式中，其中每个权利要求独立地作为单独的实施例，并且考虑这些实施例可以以各种组合或排列彼此组合。本公开的范围应参照所附权利要求以及这些权利要求赋权的等同形式的全部范围来确定。

以上对本公开多个实施例进行了详细说明，但本公开不限于这些具体的实施例，本领域技术人员在本公开构思的基础上，能够做出多种变型和修改实施例，这些变型和修改都应落入本公开所要求保护的范围之内。

Claims (16)

1.一种数据的接收方法，其特征在于，包括：

在当前预定界面渲染周期内接收更新数据包，其中，所述更新数据包的数据仅包括在所述预定界面渲染周期内发生变化的更新键值项以及与所述更新键值项对应的数据，所述更新数据包的发送间隔小于所述预定界面渲染周期；

确定每个所述更新键值项在所述当前预定界面渲染周期的待渲染的第一数据；

将所述更新键值项以及所述第一数据合并，构建所述当前预定界面渲染周期的待渲染数据集合。

2.如权利要求1所述的方法，其特征在于，在所述当前预定界面渲染周期内接收到多个所述更新数据包的情况下，所述确定每个所述更新键值项在所述当前预定界面渲染周期的待渲染的第一数据，包括：

获取每个所述更新数据包中的更新数据；

确定每项所述更新数据对应的所述更新键值项；

确定每个所述更新键值项按照时间顺序最后一次发生变化的数据为所述第一数据。

3.如权利要求1所述的方法，其特征在于，所述将所述更新键值项以及所述第一数据合并，构建所述当前预定界面渲染周期的待渲染数据集合还包括：

确定数据没有发生变化的未更新键值项；

获取在上一个预定界面渲染周期内的待渲染数据集合中与所述未更新键值项对应的第二数据。

4.如权利要求3所述的方法，其特征在于，所述将所述更新键值项以及所述第一数据合并，构建所述当前预定界面渲染周期的待渲染数据集合还包括：

将所有所述更新键值项和所述未更新键值项按照预定顺序排列；

按照所述预定顺序，将所有所述第一数据和所述第二数据进行存储。

5.如权利要求1所述的方法，其特征在于，所述构建所述当前预定界面渲染周期的待渲染数据集合之后，还包括：

加载所述当前预定界面渲染周期的待渲染数据集合的数据；

建立内部数据结构；

构建渲染树，对页面上各个元素进行位置计算和样式计算；

根据渲染树对所述页面进行渲染。

6.如权利要求1至5中任一项所述的方法，其特征在于，所述当前预定界面渲染周期内接收更新数据包之后，还包括：

按照预定解压缩方式对所述更新数据包进行解压缩，以得到解压缩后的更新数据。

7.如权利要求1至5中任一项所述的方法，其特征在于，所述确定每个所述更新键值项在所述当前预定界面渲染周期的待渲染的第一数据之前，还包括：

在所述更新键值项的键值名为缩略键值名的情况下，将所述更新键值项的所述缩略键值名转换为完整键值名。

8.一种数据的接收装置，其特征在于，包括：

接收模块，其配置为在当前预定界面渲染周期内接收更新数据包，其中，所述更新数据包的数据仅包括在所述预定界面渲染周期内发生变化的更新键值项以及与所述更新键值项对应的数据，所述更新数据包的发送间隔小于所述预定界面渲染周期；

确定模块，其配置为确定每个所述更新键值项在所述当前预定界面渲染周期的待渲染的第一数据；

构建模块，其配置为将所述更新键值项以及所述第一数据合并，构建所述当前预定界面渲染周期的待渲染数据集合。

9.如权利要求8所述的装置，其特征在于，所述确定模块还包括：

第一获取单元，其配置为获取每个所述更新数据包中的更新数据；

第一确定单元，其配置为确定每项所述更新数据对应的所述更新键值项；

第二确定单元，其配置为确定每个所述更新键值项按照时间顺序最后一次发生变化的数据为所述第一数据。

10.如权利要求8所述的装置，其特征在于，所述构建模块还包括：

第三确定单元，其配置为确定数据没有发生变化的未更新键值项；

第二获取单元，其配置为获取在上一个预定界面渲染周期内的待渲染数据集合中与所述未更新键值项对应的第二数据。

11.如权利要求10所述的装置，其特征在于，所述构建模块还包括：

排序单元，其配置为将所有所述更新键值项和所述未更新键值项按照预定顺序排列；

存储单元，其配置为按照所述预定顺序，将所有所述第一数据和所述第二数据进行存储。

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

渲染模块，其配置为：加载所述当前预定界面渲染周期的待渲染数据集合的数据；建立内部数据结构；构建渲染树，对页面上各个元素进行位置计算和样式计算；根据渲染树对所述页面进行渲染。

13.如权利要求8至12中任一项所述的装置，其特征在于，还包括：

解压缩模块，其配置为按照预定解压缩方式对所述更新数据包进行解压缩，以得到解压缩后的更新数据。

14.如权利要求8至12中任一项所述的装置，其特征在于，还包括：

转换模块，其配置为在所述更新键值项的键值名为缩略键值名的情况下，将所述更新键值项的所述缩略键值名转换为完整键值名。

15.一种存储介质，存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现权利要求1至8中任一项所述方法的步骤。

16.一种电子设备，至少包括存储器、处理器，所述存储器上存储有计算机程序，其特征在于，所述处理器在执行所述存储器上的计算机程序时实现权利要求1至8中任一项所述方法的步骤。

Images