CN118075224A - 用于消息的压缩处理和解压处理方法及其系统 - Google Patents

Abstract

本申请涉及用于消息的压缩处理和解压处理方法及其系统，所述压缩处理方法包括：在接收到第一消息的情况下，执行第一元数据存储操作，以将所述第一消息的第一元数据存储在元数据存储模块中；以及对所述第一消息的内容执行第一压缩操作，以获取所述第一消息的第一压缩内容并将所述第一压缩内容存储在消息压缩块中；其中所述第一元数据能够定位所述第一压缩内容在所述消息压缩块中的位置。本申请可以通过将消息元数据与压缩的消息内容分离存储，降低消息在压缩处理和解压处理过程中的存取延迟和双端负载。

Description

用于消息的压缩处理和解压处理方法及其系统

技术领域

本申请涉及通信领域，具体而言，涉及用于消息的压缩处理和解压处理方法及其系统。

背景技术

互联网业务中，即时消息、通知是任何平台必不可少的功能。用户之间有群友或者好友是可以互发消息的前提。会话和消息是消息领域中最核心的元素。记录消息发送和接受方联系信息的模型称为会话。对于会话的参与者，都有独立的会话视图。聊天双方发送接受的信息即消息。对于消息的接收方和发送方，也有独立的消息视图。考虑到消息的及时性，以及用户多设备数据的同步需求，同步服务必不可少。

XMPP(可扩展通讯和表示协议)是一种基于XML的开放式通信协议。它最初是为即时通信(IM)设计的，但现在已经扩展到邮件、音视频通话、文件传输、物联网通讯等领域。在针对现有的基于XMPP协议的通讯系统的开发和维护过程中，申请人发现存在如下的一些影响XMPP同步和历史消息收取性能的情况：当用户因长时间未登录某设备而导致消息大量积压时，或者当某些特殊业务消息的内容占用空间较大时，经典的XMPP通信架构都会在服务端和客户端都产生很高的负载。

发明内容

本申请的实施例提供了一种用于消息的压缩处理和解压处理方法及其系统，其通过将消息元数据与压缩的消息内容分离存储，从而能够在通信过程中，降低消息的存取延迟以及服务器(也称为服务端)和客户端双端的负载。

根据本申请的一方面，提供一种用于消息的压缩处理方法，所述压缩处理方法包括：在接收到第一消息的情况下，执行第一元数据存储操作，以将所述第一消息的第一元数据存储在元数据存储模块中；以及对所述第一消息的内容执行第一压缩操作，以获取所述第一消息的第一压缩内容并将所述第一压缩内容存储在消息压缩块中；其中所述第一元数据能够定位所述第一压缩内容在所述消息压缩块中的位置。

在本申请的一些实施例中，可选地，所述元数据存储模块包括跳跃表，其中所述跳跃表具有多级索引的数据结构。

在本申请的一些实施例中，可选地，所述第一元数据包括：与所述第一消息相关联的第一会话id、第一消息id、第一索引位置、第一消息大小以及第一时间戳。

在本申请的一些实施例中，可选地，所述压缩处理方法还包括：在接收到第二消息的情况下，执行第二元数据存储操作，以将所述第二消息的第二元数据存储在所述跳跃表中；其中所述第二元数据包括：与所述第二消息相关联的第二消息id和第二时间戳；并且其中所述第二消息id的排序在所述第一消息id的排序之后，所述第二时间戳晚于所述第一时间戳。

在本申请的一些实施例中，可选地，所述第二元数据还包括：与所述第二消息相关联的第二会话id、第二索引位置和第二消息大小。

在本申请的一些实施例中，可选地，所述压缩处理方法还包括：对所述第二消息的内容执行第二压缩操作，以获取所述第二消息的第二压缩内容并在所述消息压缩块中将所述第二压缩内容首位相接地存储所述第一压缩内容的后面，其中所述第二元数据能够定位所述第二压缩内容在所述消息压缩块中的位置。

在本申请的一些实施例中，可选地，所述第一压缩操作利用滑动窗口来执行，并且在所述第一压缩操作执行完毕后，当前滑动窗口的字典区的内容被保留；并且当要执行所述第二压缩操作时，利用所保留的当前滑动窗口的字典区对所述第二消息的内容进行压缩。

在本申请的一些实施例中，可选地，所述第一压缩操作包括：在当前滑动窗口的内容为空的情况下，用预定义字典的内容来填充所述当前滑动窗口的字典区，并且利用所述预定义字典的内容对所述第一消息的内容进行压缩。

在本申请的一些实施例中，可选地，所述利用所述预定义字典的内容对所述第一消息的内容进行压缩包括：将所述第一消息依序填充到所述当前滑动窗口的待编码区，查找所述待编码区与所述预定义字典的内容之间的最长匹配，并且基于所述最长匹配输出压缩内容。

在本申请的一些实施例中，可选地，所述利用所保留的当前滑动窗口的字典区对所述第二消息的内容进行压缩包括：将所述第二消息依序填充到所述当前滑动窗口的待编码区，查找所述待编码区与所保留的当前滑动窗口的字典区的内容之间的最长匹配，并且基于所述最长匹配输出压缩内容。

在本申请的一些实施例中，可选地，所述压缩处理方法基于XMPP协议。

在本申请的一些实施例中，可选地，所述预定义字典的内容包括XMPP格式中的标签和元素属性数据。

在本申请的一些实施例中，可选地，所述压缩处理方法还包括：响应于客户端的请求(例如，当用户登录相关应用app时，客户端请求将登录前未查看的消息全部发送到客户端)而将所述跳跃表和所述消息压缩块发送到客户端。

在本申请的一些实施例中，可选地，当接收到所述第一消息时，并行地执行所述第一元数据存储操作与所述第一压缩操作。

在本申请的一些实施例中，可选地，当接收到所述第二消息时，并行地执行所述第二元数据存储操作与所述第二压缩操作。

在本申请的一些实施例中，可选地，所述第一元数据和所述第二元数据基于Protocol Buffer进行编码。

根据本申请的另一方面，提供一种用于消息的解压处理方法，所述解压处理方法包括：从元数据存储模块中获取消息元数据，其中所述消息元数据包括至少一个消息的元数据；至少根据所述消息元数据来执行展示信息获取操作，以获取用于向用户显示的展示信息；从消息压缩块中获取消息压缩内容，其中所述消息压缩内容包括所述至少一个消息的压缩内容，其中所述消息元数据能够定位所述至少一个消息中的每个消息的压缩内容在所述消息压缩块中的位置；以及对所述消息压缩内容执行解压操作，以获取消息解压内容，其中所述消息解压内容包括所述至少一个消息的解压内容。

在本申请的一些实施例中，可选地，所述元数据存储模块包括跳跃表，其中所述跳跃表具有多级索引的数据结构。

在本申请的一些实施例中，可选地，所述消息元数据包括：所述至少一个消息中的每个消息的会话id、消息id、索引位置、消息大小以及时间戳。

在本申请的一些实施例中，可选地，所述展示信息包括：在所述至少一个消息中的所有消息的会话id中，与每一个会话id相关联的会话展示数据。

在本申请的一些实施例中，可选地，所述会话展示数据包括：在所述至少一个消息中，与相应会话id相关联的消息的数量以及最新消息的时间戳。

在本申请的一些实施例中，可选地，所述展示信息获取操作包括：针对每一个会话id，从所述消息元数据直接获取所述消息的数量以及所述最新消息的时间戳。

在本申请的一些实施例中，可选地，所述会话展示数据还包括：与相应会话id相关联的最新消息的消息摘要，其中所述最新消息的消息摘要包括所述最新消息的至少开头部分的内容。

在本申请的一些实施例中，可选地，所述展示信息获取操作还包括：根据所述消息元数据，定位所述最新消息的压缩内容在所述消息压缩块中的位置；以及针对所述最新消息的压缩内容，解压其中的至少部分，以获取所述最新消息的至少开头部分的内容。

在本申请的一些实施例中，可选地，在同步获取到所述消息元数据和所述消息压缩内容的情况下，并行地执行所述展示信息获取操作和所述解压操作。

在本申请的一些实施例中，可选地，所述解压处理方法还包括：在所述解压操作执行完毕后，将所述消息解压内容存储到数据库中，以供用户查看。

在本申请的一些实施例中，可选地，所述解压操作包括：根据所述消息压缩内容在所述消息压缩块中的排序依次解压所述消息压缩内容。

在本申请的一些实施例中，可选地，所述解压操作还包括：针对被查看的会话的会话id，若与所述会话id相关联的消息中存在未被解压的消息，则根据所述消息元数据定位所述未被解压的消息，并优先解压所述未被解压的消息。

在本申请的一些实施例中，可选地，所述解压操作还包括：每当与一个会话id相关联的所有消息解压并在数据库中存储完成时，就对相应的会话id设置完成标识。

在本申请的一些实施例中，可选地，所述消息压缩内容包括至少两个消息的压缩内容，并且所述至少两个消息的压缩内容首尾相接地存储在所述消息压缩块中。

在本申请的一些实施例中，可选地，所述解压处理方法基于XMPP协议。

在本申请的一些实施例中，可选地，所述消息元数据基于Protocol Buffer进行编码。

根据本申请的又一方面，提供一种用于消息的压缩处理系统，所述压缩处理系统包括：存储器，其配置成存储指令；和处理器，其配置成执行所述指令使得所述压缩处理系统执行如上文所述的任意一种压缩处理方法。

根据本申请的又一另外的方面，提供一种用于消息的解压处理系统，所述解压处理系统包括：存储器，其配置成存储指令；和处理器，其配置成执行所述指令使得所述解压处理系统执行如上文所述的任意一种解压处理方法。

根据本申请的又一另外的方面，提供一种用户设备，所述用户设备包括如上文所述的任意一种解压处理系统。

根据本申请的又一另外的方面，提供一种计算机可读存储介质，所述计算机可读存储介质中存储有指令，当所述指令由处理器执行时，使得所述处理器执行如上文所述的任意一种压缩处理方法。

根据本申请的又一另外的方面，提供一种计算机可读存储介质，所述计算机可读存储介质中存储有指令，当所述指令由处理器执行时，使得所述处理器执行如上文所述的任意一种解压处理方法。

本申请提出的用于消息的压缩处理和解压处理方法及其系统能够优化消息的存储、处理和展示，通过将消息元数据与压缩的消息内容分离存储，降低存取延迟和双端负载。在一些实施例中，本申请可以通过在压缩时采用优化的串联压缩方案，减少服务端存储压力、降低网络带宽消耗。在一些实施例中，本申请可以通过在客户端处理消息时采用异步解压和预展示机制，提升客户端对消息的处理速度。

附图说明

从结合附图的以下详细说明中，将会使本申请的上述和其他目的及优点更加完整清楚，其中，相同或相似的要素采用相同的标号表示。

图1示出了根据本申请的一个实施例的用于消息的压缩处理方法的流程图；

图2示出了根据本申请的一个实施例的消息元数据的存储结构示意图；

图3A至图3C示出了根据本申请的一个实施例的压缩操作的流程示意图；

图4示出了根据本申请的一个实施例的用于消息的解压处理方法的流程图；

图5示出了根据本申请的一个实施例的基于XMPP协议的消息内容的示意图；

图6示出了根据本申请的一个实施例的消息压缩内容的数据示意图；

图7示出了根据本申请的一个实施例的在客户端界面上展示消息的示意图；

图8示出了根据本申请的一个实施例的用于消息的压缩处理系统的结构示意图；并且

图9示出了根据本申请的一个实施例的用于消息的解压处理系统的结构示意图。

具体实施方式

出于简洁和说明性目的，本文主要参考其示范实施例来描述本申请的原理。但是，本领域技术人员将容易地认识到相同的原理可等效地应用于所有类型的用于消息的压缩处理和解压处理方法及其系统，并且可以在其中实施这些相同或相似的原理，任何此类变化不背离本申请的真实精神和范围。

在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本申请实施例的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不必针对的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任一个或多个实施例或示例中以合适的方式结合。此外，术语“第一”、“第二”、“第三”仅用于描述目的，而不能理解为指示或暗示相对重要性。此外，在不相互矛盾的情况下，本领域的技术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结合和组合。

下面将结合图1至图3C来描述本申请的一个实施例的用于消息的压缩处理方法100。本申请实施例的压缩处理方法100可以基于XMPP协议进行。

图1示出了根据本申请的一个实施例的用于消息的压缩处理方法100的流程图。如图1所示，压缩处理方法100可以包括步骤S110至S140。在一些实施例中，压缩处理方法100可以由服务器来执行，其中服务器可以以用户为维度，每个用户维护一个消息收件箱，以写扩散机制进行数据写入。

作为示例，假定有两个用户，分别为用户userA和用户userB，用户userA发送三条消息给用户userB，内容分别为："Hello","How are you？","Good to see you！"。在服务器端，用户userB的消息收件箱就可以收到这三条信息。此时，服务端就可以通过执行压缩处理方法100来对用户userB接收到的消息进行压缩存储。在一些实施例中，压缩处理方法100可以由服务端中的压缩处理系统800(参见图8)来执行。

压缩处理方法100自步骤S110开始执行。在一些实施例中，压缩处理方法100可以响应于服务器的启动而开始执行。在步骤S110之后，可以执行步骤S120。

在步骤S120中，可以判断当前是否接收到消息。在未接收到消息的情况下，可以返回到步骤S120以持续地监测当前是否接收到消息。在经由步骤S120确定当前接收到消息的情况下，可以进一步执行步骤S130和S140。

在步骤S130中，针对步骤S120所接收到的消息执行元数据存储操作，以存储与所接收到的消息相关联的元数据。作为示例，元数据可以包括：与消息相关联的会话id、消息id、索引位置、消息大小以及时间戳。例如，元数据可以根据以下格式来定义：

本申请实施例可以支持使用任意的方式对消息元数据进行编码。在一些实施例中，可以以Protocol Buffer作为二进制序列化库为例进行编码。例如，可以使用以下Protocol Buffers定义：

在一些实施例中，可以在对接收到的消息提取元数据之后，将所提取的元数据存储在元数据存储模块中。作为示例，元数据存储模块可以包括跳跃表。也就是说，本申请的一些实施例可以以跳跃表的方式存储所接收到的消息的会话id、消息id、索引位置、大小、时间等元数据。

在步骤S140中，针对步骤S120所接收到的消息执行压缩操作，以获取该消息的压缩内容并将所述压缩内容存储在消息压缩块中。

本申请实施例可以通过执行步骤S130来存储各个消息的元数据，并通过执行步骤S140来存储消息内容。在一些实施例中，可以在提取出消息的元数据(例如，经由步骤S130)之后，将剩下的消息内容进行压缩(例如，经由步骤S140)。在一些实施例中，如图1所示，步骤S130与S140可以并行地执行。本申请实施例通过并行地执行步骤S130与S140，可以分别分开地存储消息内容和消息元数据，从而能够提升服务端对消息的存取性能，减轻服务端压力。

一方面，在步骤S130和S140执行完毕之后，可以返回到步骤S120以持续地监测当前是否接收到消息。也就是说，随着消息流持续抵达服务端，可以不断地执行压缩处理方法100。另一方面，服务端可以将通过压缩处理方法100所获得的消息元数据和消息压缩数据分别传送到客户端，以供客户端解压和读取。例如，在用户userA发送三条消息给用户userB的示例中，当用户userB登录其用户设备中的客户端时，客户端向服务端发出请求，以请求服务端将登录前未查看的消息全部发送到客户端。此时，服务端可以响应于客户端的请求而将这三条消息的消息元数据和消息压缩数据分别传送到用户userB的客户端。

为了方便描述，本文将连续接收到的两个消息分别记为第一消息和第二消息，并且分别将第一消息的元数据称为第一元数据，第二消息的元数据称为第二元数据。其中第一元数据可以包括：与第一消息相关联的第一会话id、第一消息id、第一索引位置、第一消息大小以及第一时间戳，而第二元数据可以包括：与第二消息相关联的第二会话id、第二消息id、第二索引位置、第二消息大小以及第二时间戳。其中第二消息id的排序在第一消息id的排序之后，第二时间戳晚于所述第一时间戳。此外，本文将针对第一消息执行的元数据存储操作称为第一元数据存储操作，将针对第一消息执行的压缩操作称为第一压缩操作。以此类推，本文还定义了对应于第二消息的第二元数据存储操作和第二压缩操作。另外，为了方便描述，本文将包括第一元数据和第二元数据在内的所有消息的元数据统称为“消息元数据”。

本申请的一些实施例可以采用基于内存的存储方式，并使用收件箱机制，将属于一个用户待收取的全部消息缓存于内存数据库的一个哈希键中。在此基础上，各个用户能够直接从自己的收件箱中收取消息，而无需在每次收取消息时先查询全量的消息表，再从中筛选出属于相应用户的消息。在本申请的实施例中，一个用户待收取的全部消息可以包括与该用户相关联的元数据存储模块和消息压缩块中的消息数据。也就是说，本申请实施例可以通过采用收件箱机制存取消息来实现消息的高速存取。

图2示出了根据本申请的一个实施例的消息元数据的存储结构示意图。在压缩处理方法100的执行过程中，随着消息流的抵达，尽管即时通讯的消息在整体上是有序的，但在局部可能因为处理时间和网络延时等原因而出现乱序的现象。

跳跃表是一种在有序链表上增加多级索引的数据结构，通过索引可以实现消息的快速查找。考虑到消息元数据本身占用的空间是很小的，因而采用跳跃表存储消息元数据，能够保证针对各个消息元数据的插入和读取的高效性。跳跃表不仅能提高搜索性能，同时也可以提高插入和删除操作的性能。另外，跳跃表结构能以较低的成本维持消息的有序性，从而保证了提取消息后，在服务端和客户端都不需要对消息做额外的排序处理，也降低了计算的复杂度。

如图2所示，各个消息元数据以跳跃表的形式存储，其中每个消息元数据具有相关联的全局id。根据全局id的数值大小，可以设置有关于全局id的索引。作为示例，设跳跃表有n个节点，在第k级则有n/(2k)个索引节点，其中整个跳跃表的高度为log2n。作为示例，全局id可以是消息id。通过索引标签，可以迅速地获取或者插入相应的消息。

在发生消息乱序接收的情况下，需要保证消息在跳跃表中的排序并在跳跃表中插入消息。例如，在第一消息与第二消息出现乱序接收的情况下，由于消息元数据中的消息id具有表征消息排序的作用，因此可以根据第一消息id将第一消息插入到跳跃表，以使得即使第一消息晚于第二消息被接收，第一消息在跳跃表中的排序也位于第二消息之前。

在一些实施例中，可以通过执行如下步骤来查找第一消息的插入位置：为了查找某个乱序消息的插入位置，从第k级索引中遍历到第一个大于此消息id的索引时，就通过该索引的向下指针找到其引用的k-1级索引，并将消息id与此k-1级索引的相邻节点相比较，以决定从哪个相邻的索引节点继续向下查找。本申请的实施例从跳跃表的最大级开始遍历(即，首次遍历索引时，k＝log2n)，因此向跳跃表插入消息的时间复杂度为O(logn)。

上文描述了根据消息id的大小来确定乱序消息的插入位置的实施例，由于消息元数据中的时间戳也具有表征消息排序的作用，因此，在另一些实施例中，可以根据时间戳的大小来确定乱序消息的插入位置。

本申请采用跳跃表存储消息元数据的存储方法，利用跳跃表能够保证消息的有序性，大大优化消息存取性能。传统上，在基于XMPP协议的消息同步中，要么由客户端排序，要么由服务端使用数据库表，以消息时间戳或消息id等为主键排序。但在客户端排序会导致客户端处理压力增加，而由服务端使用数据库表的方案在高并发情况下，消息插入和查询的性能会受到影响。本申请的实施例使用跳跃表存储，具有插入的高效性。同时，因为只存储了占用空间很小的消息元数据，所以本申请实施例在操作跳跃表时不会存在因存储的值过大而导致慢操作的情况，从而也不会因为慢操作而阻塞后续命令以致发生一系列慢查询的情况。

图3A至图3C示出了根据本申请的一个实施例的压缩操作的流程示意图。作为实施例，图3A至图3C示出了执行步骤S140的实施方式。

图3A示出了利用滑动窗口301进行压缩操作的流程。如图3A所示，滑动窗口301可以包括字典区302和待编码区303。在图3A所示的实施例中，字典区302可以设置为5个字符的大小，待编码区303可以设置为3个字符的大小。相应地，当开始利用滑动窗口301进行编码时，可以在待编码区303中填充待压缩的消息内容的头3个字符的内容。在其他实施例中，也可以设置其他字符大小的字典区302和待编码区303。

在利用滑动窗口301进行压缩操作的过程中，根据字典区302与待编码区303的内容的匹配情况来输出压缩结果。随着压缩操作的进行，后续待压缩的消息内容不断向左移动，以不断地更新字典区302与待编码区303，从而可以利用更新的字典区302对接下来的待编码区303的内容进行压缩。如图3A所示，在刚开始要利用滑动窗口301进行编码时，可能会出现滑动窗口301的字典区302的内容为空的情形。由于在压缩初期字典区302的内容为空，因此待压缩的消息内容往往需要等待其开头部分累计向左移动以通过字典区302之后，其后续的消息内容才能得到压缩。

本申请实施例的压缩操作可以在字典区302的内容为空的情况下利用预定义字典的内容来填充字典区302，从而一方面无需等待待压缩的消息内容通过字典区302后再进行实质上的压缩，另一方面有效提高消息内容的压缩程度。图3A示出了当字典区302的内容为空时，利用预定义字典的内容来填充字典区302，并基于所填充的字典区302进行压缩的过程。

在一些实施例中，还可以在一个阶段的消息内容完成压缩之后，保留该阶段下的滑动窗口301的字典区302，从而在要压缩下一个阶段的消息内容时，可以直接利用上一阶段中保留的字典区302进行压缩。保留上一个压缩阶段的字典区302以供下一个压缩阶段使用，能够在压缩下一个阶段的消息内容的过程中避免等待下一个阶段的消息内容累计通过字典区302。

如图3B所示，执行压缩操作的步骤S140可以包括步骤S310至S360。通过执行步骤S310至S360，可以对经由步骤S120所接收到的消息内容进行压缩。本申请所采用的压缩方法可以是任意的，作为示例，步骤S310至S360可以是基于对LZ77压缩算法的一种改进实现。

在步骤S310中，可以获取滑动窗口(本文中还称为“滑动压缩窗口”)301。在滑动窗口301包括字典区302和待编码区303的实施例中，可以利用字典区302来查找待编码区中消息内容的最长匹配来执行压缩编码。

一方面，结合图3A和图3C可以看到，在当前滑动窗口301的内容为空的情况下，可以用预定义字典的内容来填充当前滑动窗口的字典区302，并且根据消息内容的待压缩的顺序将待压缩的内容填充到滑动窗口301的待编码区303。预定义字典的内容可以包括：预定义的一部分XMPP格式中频繁出现的标签610(参见图5)和元素属性数据620(参见图5)。在压缩开始时将滑动窗口的字典区填充为预定义字典的内容，可以在开始压缩时就找到这些预定义值的匹配，而无需等待数据通过窗口累计。

另一方面，在存在已保留的滑动窗口301的情况下，可以直接利用当前保留的滑动窗口301的字典区302，并且根据消息内容的待压缩的顺序将待压缩的内容填充到滑动窗口301的待编码区303。在步骤S310之后，可以进一步执行步骤S320。

在步骤S320中，在滑动窗口301中查找字典区302与待编码区303的最长匹配。结合图3A可以看到，在一些实施例中，可以通过以下方式来查找字典区302与待编码区303的最长匹配：首先读取待编码区303的第一个字符(例如，字符“A”)，再基于所读取的第一个字符，在字典区302中查找是否存在与第一个字符相匹配的字符；若字典区302中存在相匹配的字符(例如，字典区302中存在字符“A”)，则依次读取待编码区303的第二个字符(例如，字符“A”)以便与第一个字符组成字符串(例如，字符串“AA”)，并且基于所组成的字符串，在字典区302中查找是否存在相匹配的字符串；若字典区302中存在相匹配的字符串(例如，字典区302中存在字符串“AA”)，则依次读取待编码区303的下一个字符(例如，字符“B”)以形成更新的字符串(例如，字符串“AAB”)，直到字典区302中不存在与更新的字符串相匹配的内容。在步骤S320之后，可以进一步执行步骤S330。

在步骤S330中，基于字典区302与待编码区303的匹配情况，输出并存储与消息内容相关联的压缩内容。根据步骤S320的匹配情况，压缩内容可以是基于最长匹配的长度和距离，也可以是原始字符。例如，当在字典区302中未查找到与待编码区303的字符相匹配的内容的情况下，压缩内容可以是原始字符；而当在字典区302中查找到与待编码区303的字符相匹配的内容的情况下，压缩内容可以是待编码区303与字典区302之间最长匹配的长度和距离。在步骤S330之后，可以进一步执行步骤S340。

在步骤S340中，判断当前消息内容是否读取完毕。若已读取完毕，则可以进一步执行步骤S360。若未读取完毕，则可以进一步执行步骤S350。

在步骤S350中，将滑动窗口301向后滑动以读取消息内容中剩余的新字符，以形成更新的滑动窗口301。结合图3A可以看到，在对待编码区303中的字符内容编码完成后，可以将待编码的消息内容向左移动以形成更新的字典区302和待编码区303。随着解压操作的不断执行，滑动压缩窗口301不断向后滑动，因而滑动压缩窗口301的内容是动态更新的，其中的字典区302也是动态的。基于此，本文中可以将滑动压缩窗口301中字典区302动态更新的内容称为“动态字典”。在步骤S350之后，可以返回到步骤S320以在更新的滑动窗口301中查找字典区302与待编码区303的最长匹配。

在一些实施例中，当消息内容的输入流不断抵达时，通过步骤S320至S350可以基于读取到的输入流的数据不断执行LZ77的标准压缩操作并更新滑动窗口301。

在步骤S360中，保持当前滑动窗口301的内容。也就是说，通过步骤S360，可以维护滑动窗口301当前的状态。结合图3A可以看到，在对当前消息内容的压缩执行完毕时，滑动窗口301的字典区302中仍然填充有字符内容。在一些实施例中，可以在一个阶段的压缩过程结束后，仍然保留滑动窗口301的字典区302的内容。在步骤S360之后，可以转到图1中所示的步骤S120，以持续监测当前是否接收到新的消息。

本申请的实施例在经由步骤S320至S350执行LZ77的标准压缩操作的过程中增加了步骤S360，即使在当前所有消息压缩完成后仍然保留了滑动窗口的内容不丢弃，使得原有的LZ77的标准压缩操作得到了优化。

本申请实施例的压缩操作对滑动窗口301的获取步骤(例如，步骤S310)进行了优化。例如，在压缩开始时，可以将滑动窗口302的内容填充为预定义字典的内容，这样就能够在开始压缩时就找到这些预定义值的匹配，而无需等待数据通过窗口累计。作为示例，当针对第一消息进行压缩操作时，由于当前的滑动窗口301的内容为空，此时可以利用预定义字典的内容填充滑动窗口的字典区，以执行对第一消息的压缩编码，直至第一消息编码完成。

另外，本申请实施例在第一消息编码完成后仍可以保留当前滑动窗口301的内容，以用于直接对即将到来的第二消息进行压缩编码。基于此，在先前已针对第一消息执行步骤S320至S350的压缩操作的情况下，在消息内容的新数据第二消息到达后，可以立刻获取到已保留的滑动窗口302的状态并用于对第二消息执行压缩操作。通过这样的处理，在频繁需要追加少量新数据到已串联好的压缩数据时，就不需要重新解压最后一个窗口大小的数据并重新构建滑动窗口字典，而是可以直接在上次压缩结束的位置继续压缩。本申请通过对压缩算法进行自定义的优化，可以在不解压缩前序的数据的情况下，实现对后续消息数据的压缩。本文将上述通过保留滑动窗口301以实现连续压缩的方式称为串联的压缩方式。

如图3C所示，在一些实施例中，在通过串联的方式压缩多个消息内容的基础上，还可以将多个消息整体压缩后合并为一个记录。例如，在执行压缩操作的步骤S140的过程中，在串联地压缩第一消息和第二消息的消息内容的基础上，可以将第一消息的第一压缩内容与第二消息的第二压缩内容首尾相接地拼接在同一块内存空间中。为了方便描述，本文将用于整体地合并存储所有消息的压缩内容的空间称为消息压缩块370。如图3C所示，消息压缩块370可以包括对应于第一压缩内容的压缩二进制块1和对应于第二压缩内容的压缩二进制块2。在第二消息后，若基于第三消息进一步压缩获得第三压缩内容，则可以将第三压缩内容直接存储在压缩二进制块2之后的压缩二进制块3(图3C中未示出)。也就是说，新压缩的数据能直接添加到之前的压缩数据后面，并以此类推。

本申请实施例在针对压缩内容的写入时，可以直接追加写入新获得的压缩数据，而在读取时，可以直接取得某会话的全部消息块。上述针对压缩内容的写入和读取方式能够避免因为消息数量过多而导致数据库性能下降，以及Zset(有序集合)中存放数据过大的key、哈希表频繁重分配等问题，从而提高了消息存取的效率。在一些实施例中，消息的元数据能够定位该消息的压缩内容在消息压缩块中的位置。

针对消息内容数据，本申请实施例在压缩时使用了基于滑动窗口301的动态字典，采用了串联压缩的方式进行存储。在执行压缩操作时，本申请实施例首先将预定义字典的内容初始化到滑动窗口301中，之后将新到达的消息数据加入窗口并进行压缩，将新产生的压缩块追加到已有压缩块的最后。

相比于在数据库或内存中对消息以条为单位分别存储(即，每条消息作为一个记录)的分散存储方式，串联压缩存储的方式一方面进一步减小了数据所占用的空间，另一方面避免了分散存储可能导致的频繁扩容问题。

接下来将结合图4来描述本申请的一个实施例的用于消息的解压处理方法400。例如，在用户userA发送三条消息给用户userB的示例中，用户userB的客户端在上线后，可以向服务端发出请求，以请求服务端将上线前未查看的消息全部发送到客户端。相应地，用户userB的客户端可以接收到上线前未查看的所有消息的消息元数据和消息压缩数据。在接收到消息元数据和消息压缩数据的基础上，用户userB的客户端可以执行解压处理方法400以对这三条消息的消息元数据和消息压缩数据进行提取、解压和展示。在压缩处理方法100基于XMPP协议进行的情况下，解压处理方法400也可以基于XMPP协议进行。

图4示出了根据本申请的一个实施例的用于消息的解压处理方法400的流程图。如图4所示，解压处理方法400可以包括步骤S410至S450。在一些实施例中，解压处理方法400可以由客户端来执行。作为示例，解压处理方法400可以由客户端中的解压处理系统900(参见图9)来执行。

在步骤S410中，获取消息元数据，其中消息元数据可以包含每条消息的会话id、消息id、索引位置、大小、时间数据。在一些实施例中，消息元数据以跳跃表的形式存储，因而可以从跳跃表中获取消息元数据。

在步骤S420中，获取消息压缩数据，其中消息压缩数据可以包括各个消息的消息压缩内容。在一些实施例中，消息压缩数据中所有消息的消息压缩内容整体地存储在消息压缩块中，因而可以从消息压缩块中获取消息压缩数据。

如图4所示，步骤S410和步骤S420可以并行地执行，因而客户端可以同时接收来自服务端的消息元数据和消息压缩数据。在一些实施例中，在同步接收到消息元数据和消息压缩数据之后，客户端可以首先处理消息元数据。

在步骤S410之后，可以进一步执行步骤S430以执行展示信息获取操作。通过执行展示信息获取操作，可以获取到用于在客户端界面上显示的展示消息，以供客户端界面的预展示。由于客户端界面是面向用户的界面，因此本文还将客户端界面称作“用户界面(UI)”。本文中的展示信息指的是在UI界面上用作预展示的消息。

作为示例，展示信息可以包括：在所有消息的会话id中，与每一个会话id相关联的会话展示数据。也就是说，展示信息可以按会话id进行分类，其中每个会话id具有一个相关联的会话展示数据。其中，会话展示数据可以包括以下中的任何一项或多项：与相应会话id相关联的消息的数量、最新消息的时间戳、以及最新消息的消息摘要。其中，最新消息的消息摘要包括最新消息的至少开头部分的内容。例如，在最新消息是文本的情况下，若最新消息的总字符个数不超过阈值个数(例如，20个)，则最新消息的消息摘要可以是最新消息的所有内容；若最新消息的总字符个数超过阈值个数时，则最新消息的消息摘要可以是最新消息开头的阈值个数的字符(例如，最新消息开头的20个字符)。

在一些实施例中，步骤S430可以包括：直接基于步骤S410所获取的消息元数据来获取展示信息。例如，可以从消息元数据直接获取消息的数量以及最新消息的时间戳。

在一些实施例中，步骤S430可以包括：基于步骤S410所获取的消息元数据和步骤S420所获取的消息压缩内容来获取展示信息。例如，当要获取消息摘要时，可以通过以下方式来获取：从消息元数据中所提供的索引快速定位到每个会话的最新一条消息在消息压缩内容中的位置，并优先解压所述最新一条消息的压缩内容的至少部分，以获取所述最新消息的至少开头部分的内容。

在用户userA发送三条消息给用户userB的示例中，用户userB的客户端可以根据消息元数据中提供的`sessionid`部分对用户userA到用户userB的会话列表在UI上作预展示，并根据消息元数据的`msgid`部分，定位到该会话最后一条消息的消息id，以获得该最后一条消息的`index`和`size`信息。通过执行步骤430的展示信息获取操作，客户端可以对该最后一条消息所对应的部分优先进行解压，由此即可得到明文消息"Goodto seeyou！"(其总字符个数不超过阈值个数)。此时，客户端即可以在UI上展示该会话最后一条消息的消息摘要，从而完成对相应会话列表页的预展示。

在步骤S420之后，可以进一步执行步骤S440。在步骤S440中，可以执行解压操作以获取消息解压内容，并且将所获取的消息解压内容存储到客户端本地的数据库中(本文中也称为“入库”)以供用户查看。

在一些实施例中，在同步获取到所述消息元数据和所述消息压缩内容的情况下，可以并行地执行步骤S430的展示信息获取操作和步骤S440的解压操作。也就是说，客户端在对展示信息进行预展示的同时，可以在后台异步地进行其它消息的解压操作。

如图4所示，在步骤S430和S440之后，可以进一步执行步骤S450。在步骤S450中，在客户端中向用户展示已存储的消息。虽然图4中示出步骤S450在步骤S440之后执行，但是在本申请的实施例中，步骤S440与S450可以同步进行。一方面，在解压操作的步骤S440未执行完毕的情况下，步骤S450可以向用户做“预展示”以显示展示信息；另一方面，在解压操作的步骤S440执行完毕地情况下，步骤S450可以向用户显示所有消息的消息内容。

本申请的实施例通过将消息元数据和消息内容分开存储，同时对占空间较大的消息内容压缩处理，而占空间很小的对消息元数据不压缩，从而客户端在接收到消息后，能够根据消息元数据中描述的索引、消息大小、会话id、时间等，在UI做“预展示”，从而可以提升客户端同步消息的响应速度，避免卡顿、假死的情况发生。如果服务端不将消息元数据和消息内容分开存储，则客户端必须在将所有消息压缩内容解压完成后才能向用户做展示，而无法在UI做“预展示”，此时若数据流量较大则将阻塞客户端的消息展示。

本文中所述的“预展示”指的是在对全部的消息解压和解析之前，客户端就能通过提前提取或者优先解压来获取展示信息，以供用户提前查看。通过上述方式，客户端能够在解压消息的同时先对UI做出适应性的变化，以展示当前所能获取(例如，经由步骤S430所获取)的展示信息。本申请实施例在保证客户端展示(例如，通过步骤S450)正常进行的同时，异步进行解压和入库(例如，通过步骤S440)，避免阻塞客户端的其它功能，从而使解压和处理数据的过程对用户无感，保证流畅的使用体验。

下面将结合图5来描述本申请实施例中对于预定义字典的内容的配置。图5示出了根据本申请的一个实施例的基于XMPP协议的消息(本文中也称作“XMPP消息”)内容的示意图。如图5所示，XMPP消息包括XMPP格式中的标签610和元素属性数据620。其中，标签610是XMPP消息中的XML组织结构，可以在XMPP格式中频繁出现。本文将XMPP消息中的标签610部分用方框示出，并且将元素属性数据620用椭圆形的圈来示出。如图5所示的示例，标签610和元素属性数据620可以占整个XMPP消息约40％的字节数。

本申请实施例利用标签610和元素属性数据620在XMPP消息中所占的比例较高且频繁出现的特性，将预定义字典的内容配置成包括标签610和元素属性数据620。由于预定义字典与XMPP消息的内容之间有较高的匹配度，因此，在步骤S140中的压缩操作开始执行时直接利用预定义字典的内容来对XMPP消息进行压缩匹配，能够实现较高的压缩度。

图6示出了根据本申请的一个实施例的消息压缩内容的数据示意图。对应于上文所述的用户userA给用户userB发送三条内容分别为："Hello","How are you？","Good tosee you！"的消息的示例，图6示出了对这三条消息的内容进行压缩编码以获得的消息压缩内容的数据。如图6所示，消息压缩内容可以通过串联压缩的二进制数据来表示。由于XML的组织结构松散且冗余，且XML采用基于文本而非二进制格式，本申请实施例通过串联压缩的二进制数据进行数据存储和传输，而非利用XML的组织结构，因而解决了数据存储和传输时的数据冗余和空间浪费问题。另外，由于针对XML的组织结构进行解析和处理也需要更多的计算和内存资源，本申请采用串联压缩的二进制数据也大大降低了解析和处理所消耗的计算和内存资源。

图7示出了根据本申请的一个实施例的在客户端界面上显示展示信息的示意图。在客户端，本申请实施例通过异步及响应式解压和入库，可以优化展示性能。图7示出了客户端界面的预展示的内容(即，展示信息)。如图7所示，展示信息包括：消息数量、最新消息的时间戳、以及消息摘要。对应于UI的消息列表界面的预展示，只需要从消息压缩内容中提取用于UI展示的数据(例如，消息摘要)，而其它数据(例如，消息数量、最新消息的时间戳)都可以直接从消息元数据中取得。另外，本申请实施例在展示消息列表的同时，可以在后台异步地解压消息，从而保证客户端消息同步的流畅体验，避免收到大量消息后，在解析、处理过程中出现卡死。

本申请的实施例在消息元数据中存储了收件箱中各个会话的会话id以及各条消息的索引位置和大小。当用户查看会话列表界面时，客户端能够先使用缓存中的信息展示会话列表，并通过消息元数据提供的索引快速定位到每个会话的最新一条消息，在列表页面优先解压并展示消息摘要，使用户即使在消息整体的解压没有完成时，也能够先查看到每个会话的最新消息，保证了使用体验。

在一些实施例中，在执行步骤S440的解压操作的过程中，可以根据消息压缩内容在消息压缩块中的排序依次解压消息压缩内容。在此情况下，只有当消息压缩内容全部被解压时，用户才可以自由地查看所接收到的任何会话的消息，尤其当某一会话中存在解压排序较后的消息时，需要等待较长的时间才能完整地查看该会话。为了实现自由地查看用户希望查看的会话，本申请的一些实施例可以在监测到某个会话被用户查看时，针对被查看的会话判断相应会话id中是否存在未被解压的消息，若存在未被解压的消息，则可以根据消息元数据定位未被解压的消息在消息压缩内容中的位置，并优先解压该会话id中未被解压的消息。

基于上述方式，本申请实施例能够优先展示用户需要查看的消息，而无需等待所有消息解压完成。也就是说，本申请实施例可以在用户希望详细查看某个会话时，若发现客户端本地存在尚未完成对该会话内消息的解压，则通过消息元数据定位到该会话的剩余消息，并将这些未解压的剩余消息的解压和处理操作的优先级提前。

为了方便客户端迅速地识别与各个会话id相关联的所有消息是否都被解压完成，在一些实施例中，步骤S440在执行解压操作的过程中可以在每当一个会话的全部消息解压并入客户端本地库完成时，在客户端本地为此会话记录一个入库完成标识。基于此，当用户点击查看某一个会话的详细消息记录时，客户端可以首先判断该会话是否被设置了完成标识。若被设置了完成标识，则表示已经入库完成，此时可以直接从本地库加载全部消息；若未设置完成标识，则表示未解压完成，此时可以将消息压缩内容队列中与该会话相关消息的解压优先级提前，并按照逆序解压后，待一个屏幕上的消息解压完成后，即时地展示于会话页面。

接下来将结合图8来描述本申请的一个实施例的用于消息的压缩处理系统800。

图8示出了根据本申请的一个实施例的用于消息的压缩处理系统800的结构示意图。如图8所示，压缩处理系统800可以包括存储器810和处理器820。存储器810与处理器820之间可以互相通信。在一些实施例中，存储器810可以是诸如闪存、ROM、硬盘驱动器、磁盘、光盘之类的非易失存储器。在其它实施例中，存储器810也可以是其它类型的存储器。存储器810可以配置成存储指令。处理器820可以配置成执行所述指令使得压缩处理系统800执行根据本申请的一个或多个实施例的压缩处理方法100。

接下来将结合图9来描述本申请的一个实施例的用于消息的解压处理系统900。

图9示出了根据本申请的一个实施例的用于消息的解压处理系统900的结构示意图。如图9所示，解压处理系统900可以包括存储器910和处理器920。存储器910与处理器920之间可以互相通信。在一些实施例中，存储器910可以是诸如闪存、ROM、硬盘驱动器、磁盘、光盘之类的非易失存储器。在其它实施例中，存储器910也可以是其它类型的存储器。存储器910可以配置成存储指令。处理器920可以配置成执行所述指令使得解压处理系统900执行根据本申请的一个或多个实施例的解压处理方法400。

根据本申请的又一方面，提供一种用户设备，所述用户设备可以包括上文中所描述的任意一种解压处理系统900。本文中所指的用户设备可以是任何能够接收消息的电子设备，例如，计算机、平板电脑、手机、可穿戴设备等。其中，可穿戴设备可以包括智能手表(手环)、智能眼镜等。

根据本申请的另一方面，提供一种计算机可读存储介质，其中存储有指令，当所述指令由处理器执行时，使得所述处理器执行如上文所述的任意一种用于消息的压缩处理方法100和解压处理方法400。本申请中所称的计算机可读介质包括各种类型的计算机存储介质，可以是通用或专用计算机能够存取的任何可用介质。举例而言，计算机可读介质可以包括RAM、ROM、EPROM、E²PROM、寄存器、硬盘、可移动盘、CD-ROM或其他光盘存储器、磁盘存储器或其他磁存储设备、或者能够用于携带或存储具有指令或数据结构形式的期望的程序代码单元并能够由通用或专用计算机、或者通用或专用处理器进行存取的任何其他临时性或者非临时性介质。如本文所使用的盘通常磁性地复制数据，而碟则用激光来光学地复制数据。上述的组合也应当包括在计算机可读介质的保护范围之内。示例性存储介质耦合到处理器以使得该处理器能从/向该存储介质读写信息。在替换方案中，存储介质可以被整合到处理器。处理器和存储介质可驻留在ASIC中。ASIC可驻留在用户终端中。在替换方案中，处理器和存储介质可作为分立组件驻留在用户终端中。

本申请通过实施例描述了基于XMPP协议的通讯系统，并提出一种基于XMPP协议的消息压缩存储、处理及展示方法，需要说明的是，本申请所提出的用于消息的压缩处理和解压处理方法及其系统也可以应用于其他适应的通讯协议。

以上仅为本申请的具体实施方式，但本申请的保护范围并不局限于此。本领域的技术人员可以根据本申请所披露的技术范围想到其他可行的变化或替换，此等变化或替换皆涵盖于本申请的保护范围之中。在不冲突的情况下，本申请的实施方式及实施方式中的特征还可以相互组合。本申请的保护范围以权利要求的记载为准。

Claims (37)

1.一种用于消息的压缩处理方法，其特征在于，所述压缩处理方法包括：

在接收到第一消息的情况下，执行第一元数据存储操作，以将所述第一消息的第一元数据存储在元数据存储模块中；以及

对所述第一消息的内容执行第一压缩操作，以获取所述第一消息的第一压缩内容并将所述第一压缩内容存储在消息压缩块中；

其中所述第一元数据能够定位所述第一压缩内容在所述消息压缩块中的位置。

2.根据权利要求1所述的压缩处理方法，其特征在于，所述元数据存储模块包括跳跃表，其中所述跳跃表具有多级索引的数据结构。

3.根据权利要求2所述的压缩处理方法，其特征在于，所述第一元数据包括：与所述第一消息相关联的第一会话id、第一消息id、第一索引位置、第一消息大小以及第一时间戳。

4.根据权利要求3所述的压缩处理方法，其特征在于，所述压缩处理方法还包括：在接收到第二消息的情况下，执行第二元数据存储操作，以将所述第二消息的第二元数据存储在所述跳跃表中；

其中所述第二元数据包括：与所述第二消息相关联的第二消息id和第二时间戳；并且

其中所述第二消息id的排序在所述第一消息id的排序之后，所述第二时间戳晚于所述第一时间戳。

5.根据权利要求4所述的压缩处理方法，其特征在于，所述第二元数据还包括：与所述第二消息相关联的第二会话id、第二索引位置和第二消息大小。

6.根据权利要求5所述的压缩处理方法，其特征在于，所述压缩处理方法还包括：

对所述第二消息的内容执行第二压缩操作，以获取所述第二消息的第二压缩内容并在所述消息压缩块中将所述第二压缩内容首位相接地存储所述第一压缩内容的后面，其中所述第二元数据能够定位所述第二压缩内容在所述消息压缩块中的位置。

7.根据权利要求6所述的压缩处理方法，其特征在于，所述第一压缩操作利用滑动窗口来执行，并且在所述第一压缩操作执行完毕后，当前滑动窗口的字典区的内容被保留；并且

当要执行所述第二压缩操作时，利用所保留的当前滑动窗口的字典区对所述第二消息的内容进行压缩。

8.根据权利要求7所述的压缩处理方法，其特征在于，所述利用所保留的当前滑动窗口的字典区对所述第二消息的内容进行压缩包括：

将所述第二消息依序填充到所述当前滑动窗口的待编码区，查找所述待编码区与所保留的当前滑动窗口的字典区的内容之间的最长匹配，并且基于所述最长匹配输出压缩内容。

9.根据权利要求1所述的压缩处理方法，其特征在于，所述第一压缩操作包括：

在当前滑动窗口的字典区的内容为空的情况下，用预定义字典的内容来填充所述当前滑动窗口的字典区，并且利用所述预定义字典的内容对所述第一消息的内容进行压缩。

10.根据权利要求9所述的压缩处理方法，其特征在于，所述利用所述预定义字典的内容对所述第一消息的内容进行压缩包括：

将所述第一消息依序填充到所述当前滑动窗口的待编码区，查找所述待编码区与所述预定义字典的内容之间的最长匹配，并且基于所述最长匹配输出压缩内容。

11.根据权利要求9所述的压缩处理方法，其特征在于，所述压缩处理方法基于XMPP协议。

12.根据权利要求11所述的压缩处理方法，其特征在于，所述预定义字典的内容包括XMPP格式中的标签和元素属性数据。

13.根据权利要求1所述的压缩处理方法，其特征在于，所述压缩处理方法还包括：

响应于客户端的请求而将所述跳跃表和所述消息压缩块发送到客户端。

14.根据权利要求1所述的压缩处理方法，其特征在于，当接收到所述第一消息时，并行地执行所述第一元数据存储操作与所述第一压缩操作。

15.根据权利要求6所述的压缩处理方法，其特征在于，当接收到所述第二消息时，并行地执行所述第二元数据存储操作与所述第二压缩操作。

16.根据权利要求4所述的压缩处理方法，其特征在于，所述第一元数据和所述第二元数据基于Protocol Buffer进行编码。

17.一种用于消息的解压处理方法，其特征在于，所述解压处理方法包括：

从元数据存储模块中获取消息元数据，其中所述消息元数据包括至少一个消息的元数据；

至少根据所述消息元数据来执行展示信息获取操作，以获取用于向用户显示的展示信息；

从消息压缩块中获取消息压缩内容，其中所述消息压缩内容包括所述至少一个消息的压缩内容，其中所述消息元数据能够定位所述至少一个消息中的每个消息的压缩内容在所述消息压缩块中的位置；以及

对所述消息压缩内容执行解压操作，以获取消息解压内容，其中所述消息解压内容包括所述至少一个消息的解压内容。

18.根据权利要求17所述的解压处理方法，其特征在于，所述元数据存储模块包括跳跃表，其中所述跳跃表具有多级索引的数据结构。

19.根据权利要求18所述的解压处理方法，其特征在于，所述消息元数据包括：所述至少一个消息中的每个消息的会话id、消息id、索引位置、消息大小以及时间戳。

20.根据权利要求19所述的解压处理方法，其特征在于，所述展示信息包括：在所述至少一个消息中的所有消息的会话id中，与每一个会话id相关联的会话展示数据。

21.根据权利要求20所述的解压处理方法，其特征在于，所述会话展示数据包括：在所述至少一个消息中，与相应会话id相关联的消息的数量以及最新消息的时间戳。

22.根据权利要求21所述的解压处理方法，其特征在于，所述展示信息获取操作包括：针对每一个会话id，从所述消息元数据直接获取所述消息的数量以及所述最新消息的时间戳。

23.根据权利要求22所述的解压处理方法，其特征在于，所述会话展示数据还包括：与相应会话id相关联的最新消息的消息摘要，其中所述最新消息的消息摘要包括所述最新消息的至少开头部分的内容。

24.根据权利要求23所述的解压处理方法，其特征在于，所述展示信息获取操作还包括：

根据所述消息元数据，定位所述最新消息的压缩内容在所述消息压缩块中的位置；以及

针对所述最新消息的压缩内容，解压其中的至少部分，以获取所述最新消息的至少开头部分的内容。

25.根据权利要求24所述的解压处理方法，其特征在于，在同步获取到所述消息元数据和所述消息压缩内容的情况下，并行地执行所述展示信息获取操作和所述解压操作。

26.根据权利要求25所述的解压处理方法，其特征在于，所述解压处理方法还包括：

在所述解压操作执行完毕后，将所述消息解压内容存储到数据库中，以供用户查看。

27.根据权利要求26所述的解压处理方法，其特征在于，所述解压操作包括：根据所述消息压缩内容在所述消息压缩块中的排序依次解压所述消息压缩内容。

28.根据权利要求27所述的解压处理方法，其特征在于，所述解压操作还包括：

针对被查看的会话的会话id，若与所述会话id相关联的消息中存在未被解压的消息，则根据所述消息元数据定位所述未被解压的消息，并优先解压所述未被解压的消息。

29.根据权利要求28所述的解压处理方法，其特征在于，所述解压操作还包括：每当与一个会话id相关联的所有消息解压并在数据库中存储完成时，就对相应的会话id设置完成标识。

30.根据权利要求17所述的解压处理方法，其特征在于，所述消息压缩内容包括至少两个消息的压缩内容，并且所述至少两个消息的压缩内容首尾相接地存储在所述消息压缩块中。

31.根据权利要求30所述的解压处理方法，其特征在于，所述解压处理方法基于XMPP协议。

32.根据权利要求30所述的解压处理方法，其特征在于，所述消息元数据基于ProtocolBuffer进行编码。

33.一种用于消息的压缩处理系统，其特征在于，所述压缩处理系统包括：

存储器，其配置成存储指令；和

处理器，其配置成执行所述指令使得所述压缩处理系统执行如权利要求1-16中任一项所述的压缩处理方法。

34.一种用于消息的解压处理系统，其特征在于，所述解压处理系统包括：

存储器，其配置成存储指令；和

处理器，其配置成执行所述指令使得所述解压处理系统执行如权利要求17-32中任一项所述的解压处理方法。

35.一种用户设备，其特征在于，所述用户设备包括如权利要求34所述的解压处理系统。

36.一种计算机可读存储介质，所述计算机可读存储介质中存储有指令，其特征在于，当所述指令由处理器执行时，使得所述处理器执行如权利要求1-16中任一项所述的压缩处理方法。

37.一种计算机可读存储介质，所述计算机可读存储介质中存储有指令，其特征在于，当所述指令由处理器执行时，使得所述处理器执行如权利要求17-32中任一项所述的解压处理方法。