消息处理方法、装置、电子设备及可读存储介质与流程

1.本发明实施例涉及消息处理技术领域，特别是涉及一种消息处理方法、装置、电子设备及可读存储介质。


背景技术：

2.在实时聊天场景中，信息收发双方及服务端所处的网络环境可能较为复杂，当收发双方所处的网络环境或服务器所处的网络环境存在波动时，可能出现聊天消息的乱序问题。此外，服务端应用存在不稳定性，当连接到服务端的聊天用户数量暴增，或者服务端存在软硬件故障时，也可能导致消息的乱序问题。


技术实现要素：

3.本发明实施例的目的在于提供一种消息处理方法、装置、电子设备及可读存储介质，以避免实时聊天过程中出现消息乱序的问题。具体技术方案如下：
4.在本发明实施的第一方面，首先提供了一种消息处理方法，应用于包括第一客户端、第二客户端和服务端的系统，所述第一客户端和所述第二客户端通过所述服务端进行消息交互，所述方法执行于所述第一客户端，所述方法包括：
5.按照消息id对在当前时间段内接收到的各个消息进行排序，生成新消息列表；
6.从已展示消息列表中截取部分消息列表，以作为待处理消息列表，所述已展示消息列表中的消息是按照所述消息id顺序排列的，所述已展示消息列表中消息的排列顺序与所述新消息列表中消息的排列顺序相同，所述待处理消息列表中的第一个消息id小于所述新消息列表中的第一个消息id，所述待处理消息列表中的最后一个消息id为所述已展示消息列表中的最后一个消息id；
7.比较所述新消息列表中的消息id与所述待处理消息列表中的消息id，从所述新消息列表中识别出不存在于所述待处理消息列表中的消息id，以及，识别出所述待处理消息列表中的插入位置；
8.将识别出的消息id所对应的消息插入所述待处理消息列表中的所述插入位置，生成待展示消息列表；
9.在下一时间段对所述待展示消息列表中的各个消息进行展示。
10.在本发明实施的第二方面，还提供了一种消息处理装置，应用于包括第一客户端、第二客户端和服务端的系统，所述第一客户端和所述第二客户端通过所述服务端进行消息交互，所述装置设置于所述第一客户端，所述装置包括：
11.生成模块，用于按照消息id对在当前时间段内接收到的各个消息进行排序，生成新消息列表；
12.截取模块，用于从已展示消息列表中截取部分消息列表，以作为待处理消息列表，所述已展示消息列表中的消息是按照所述消息id顺序排列的，所述已展示消息列表中消息的排列顺序与所述新消息列表中消息的排列顺序相同，所述待处理消息列表中的第一个消
息id小于所述新消息列表中的第一个消息id，所述待处理消息列表中的最后一个消息id为所述已展示消息列表中的最后一个消息id；
13.比较模块，用于比较所述新消息列表中的消息id与所述待处理消息列表中的消息id，从所述新消息列表中识别出不存在于所述待处理消息列表中的消息id，以及，识别出所述待处理消息列表中的插入位置；
14.插入模块，用于将识别出的消息id所对应的消息插入所述待处理消息列表中的所述插入位置，生成待展示消息列表；
15.展示模块，用于在下一时间段对所述待展示消息列表中的各个消息进行展示。
16.在本发明实施的第三方面，还提供了一种电子设备，包括存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述计算机程序被所述处理器执行时实现如本发明实施例第一方面所述的消息处理方法的步骤。
17.在本发明实施的第四方面，还提供了一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现如实现本发明实施例第一方面所述的消息处理方法的步骤。
18.采用本发明实施例提供的消息处理方法，按照消息id对当前时间段内接收到的各个消息进行排序后生成新消息列表，由于已展示消息列表中的消息是按照消息id顺序排列的，且已展示消息列表中的消息排列顺序与新消息列表中的消息排列顺序相同，因此从已展示消息列表中截取的待处理消息列表中的消息也是按照消息id的顺序排列的，待处理消息列表与新消息列表中消息的排列规则相同。将新消息列表中的消息id与待处理消息列表中的消息id进行比较，识别出新消息列表中不存在于待处理消息列表中的消息id，以及，识别出待处理消息列表中的插入位置，将识别出不存在于待处理消息列表中的消息id所对应的消息插入待处理消息列表中的正确插入位置，使得新消息列表中的消息能够以正确的插入位置插入待处理消息列表中，从而实现两个消息列表的正确合并，生成待展示消息列表，以实现待展示消息列表中的消息也是按照消息id顺序排列展示的，从而避免了实时聊天过程中的消息乱序问题。
附图说明
19.为了更清楚地说明本发明实施例的技术方案，下面将对本发明实施例的描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。
20.图1是本发明一实施例示出的一种应用场景示意图；
21.图2是本发明一实施例示出的一种消息处理方法的流程图；
22.图3是本发明一实施例示出的一种消息队列示意图；
23.图4是本发明一实施例示出的一种消息确定方法的流程图；
24.图5是本发明一实施例示出的一种消息比较方法的流程图；
25.图6是本发明一实施例示出的一种消息补偿方法的流程图；
26.图7是本发明一实施例示出的一种消息送达确认方法的流程图；
27.图8是本发明一实施例示出的一种消息交互示意图；
28.图9是本发明一实施例提供的消息处理装置的结构框图；
29.图10是本发明一实施例示出的一种电子设备的示意图。
具体实施方式
30.下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
31.由于网络波动或服务端不稳定，在实时聊天场景中，可能出现聊天双方接收到的聊天消息出现消息乱序问题。例如，因网络波动原因或服务端不稳定等各种原因造成客户端接收到的消息顺序并不是服务端(或对应客户端)实际发出的消息顺序，而客户端也依旧按照其接收到的消息顺序进行展示，从而导致客户端已展示的消息产生乱序，如已展示消息的顺序为3
→5→
1；当客户端在下一时间段依次接收到的消息的顺序为：7
→2→
6，而客户端依旧按照将接收到的消息按接收顺序进行展示的逻辑进行消息展示，则此时已展示消息的顺序会变为3
→5→1→7→2→
6，从而进一步导致了客户端已展示消息的乱序问题。
32.为了至少部分地解决上述问题以及其他潜在问题中的一个或者多个，本发明实施例提出了一种消息处理方法，该方法将接收到的各个消息按消息id顺序排列生成新消息列表，并根据新消息列表中的消息id从按照消息id顺序排列的已展示消息中确定出待处理消息列表，比较新消息列表与待处理消息列表
33.之间的消息id，识别出新消息列表中不存在于待处理消息列表中的消息id及
34.该消息id所对应的消息在待处理消息列表中的正确插入位置，按照该正确插
35.入位置将不存在于待处理消息列表中的消息id所对应的消息插入待处理消息列表中，以生成待展示消息列表进行消息展示，从而保证了在实时聊天过程中消息能够从始至终按顺序展示。
36.图1是本发明一实施例示出的一种应用场景示意图。如图1所示，本实施例的应用场景为包括服务端100、第一客户端110和第二客户端120的系统130，其中，服务端100分别与第一客户端110和第二客户端120通信连接，第一客户端110和第二客户端120通过服务段100进行消息交互。在聊天过程中，第一客户端110和第二客户端120分别通过消息传输通道连接到服务端100，第一客户端110(或第二客户端120)发出的消息通过消息传输通道到达服务端110后，服务端110作为中转站将接收到消息通过消息传输通道分发给对应的第二客户端120(或第一客户端110)，从而实现消息的发送与接收。
37.在本实施例中，客户端可以是指为用户提供本地服务的程序，客户端可以以不同的程序形态来实现同一软件功能；例如，客户端可以是应用软件app、小程序、网页web浏览器等。本实施例中的客户端具有聊天功能，第一客户端与第二客户端分别为进行消息聊天的交互对端，第一客户端可以为任意客户端，第二客户端可以为与第一客户端进行聊天的除第一客户端外的任意客户端等。服务端可以为客户端的后台服务器，如服务端可以为与客户端通信连接的计算机等。需要说明的是，图1只是本实施例提供的一个示例，本实施例中的服务端可以同时连接多个客户端进行消息分发，本实施例对连接至服务端的客户端数量不做任何具体限制。
38.参考图2，图2是本发明一实施例示出的一种消息处理方法的流程图，该方法应用于上述包括第一客户端、第二客户端和服务器的系统，第一客户端和第二客户端通过服务器进行消息交互，该方法执行于第一客户端。如图2所示，本实施例的消息处理方法可以包括以下步骤：
39.步骤s11：按照消息id对在当前时间段内接收到的各个消息进行排序，生成新消息列表。
40.本实施例中，第一客户端接收服务端转发的消息，并根据预设时长对接收到的消息进行分批处理，分成当前需要处理的消息(当前时间段内接收到的各个消息)和接下来需要处理的消息(下一时间段内接收到的各个消息)，例如预设时长为5s，将接收时间为18:00-18:05的消息确定当前时间段内接收到的各个消息，将接收时间为18:05-18:10的消息确定为下一时间段内接收到的各个消息，而当处理下一时间段内的消息时，接收时间为18:05-18:10的消息即为当前时间段内接收到的各个消息，接收时间为18:10-18:15的消息为下一时间段内接收到的各个消息，
……
以此类推。
41.其中，本实施例中的预设时长为事先设置的一个经验时长，该经验时长既不会太短，以避免第一客户端的频繁计算，降低了第一客户端的计算压力，节约了计算资源，尤其当第一客户端已展示消息列表(即历史消息)中有大量消息时，在较差的客户端设备上进行频繁计算可能会产生性能问题；该经验时长也不会太长，以避免聊天实时性不好，导致用户的体验变差，本实施例对预设时长的具体数值不作任何限制。
42.本实施例中，第一客户端根据消息id对当前时间段内接收到的各个消息从小到大进行排序，生成新消息列表。其中，消息id指的是服务端为其接收到的消息进行分配的连续递增的id。可以理解，第一客户端接收到的消息均为其他客户端(即第二客户端)发送至服务端，并由服务端进行转发的消息，客户端发送的消息通过消息传输通道传输到服务端时，服务端会对消息进行处理，如根据消息的接收双发为消息分配连续递增的消息id、为消息标记上消息所处状态、消息发送时间(如消息时间戳)等等，并将处理后的消息存入服务端的消息队列中(如图3所示，图3是本发明一实施例示出的一种消息队列示意图)，从而将消息队列中的消息按照先入先出的方式发送给相应的客户端。
43.步骤s12：从已展示消息列表中截取部分消息列表，以作为待处理消息列表，所述已展示消息列表中的消息是按照所述消息id顺序排列的，所述已展示消息列表中消息的排列顺序与所述新消息列表中消息的排列顺序相同，所述待处理消息列表中的第一个消息id小于所述新消息列表中的第一个消息id，所述待处理消息列表中的最后一个消息id为所述已展示消息列表中的最后一个消息id。
44.本实施例中，第一客户端本地存储有已展示消息列表，已展示消息列表为第一客户端已经展示的各个消息所组成的消息列表，且已展示消息列表中的消息是按照消息id从小到大顺序排列的。第一客户端根据新消息列表中的消息id从已展示消息列表中截取出部分消息列表，以作为待处理消息列表，待处理消息列表即为本次需要与新消息列表进行合并的消息列表，第一客户端截取的待处理消息列表中的第一个消息id小于所述新消息列表中的第一个消息id，所述待处理消息列表中的最后一个消息id为所述已展示消息列表中的最后一个消息id。其中，由于已展示消息列表中的消息是按照消息id顺序排列的，且已展示消息列表中消息的排列顺序与新消息列表中消息的排列顺序相同，均为按照消息id从小到
大进行顺序排列，因此，从已展示消息列表中截取的待处理消息列表中的消息也是按照消息id从小到大顺序排列的。需要说明的是，由于已展示消息列表中的消息和待处理消息列表中的消息均按照消息id顺序排列的，因此，两个消息列表中的第一个消息id均代表消息列表中第一条消息所对应的消息id，最后一个消息id均代表消息列表中最后一条消息所对应的消息id，
45.新消息列表中可能包含实时的新消息和重发消息，其中，重发消息为服务端因各种原因而重新发送的消息，第一客户端接收到的重发消息包括：重新发送的重复消息，和/或重新发送的缺失补偿消息。由于实时的新消息为服务端正常转发的后续消息，为服务端之前已转发的消息之后的消息，也即实时的新消息为已展示消息列表中最后一条消息之后的消息，因此，如果要将实时的新消息与待处理消息列表合并，则待处理消息列表中必须包含已展示消息列表中的最后一条消息，因此，待处理消息列表中的最后一个消息id为已展示消息列表中的最后一个消息id；而由于新消息列表中的第一条消息可能为重发消息，而重发消息为服务端之前已经向第一客户端发送过、又重新发送的消息，重发消息应该排在已展示消息列表中、消息id比重发消息的消息id小的消息之后，因此，将重发消息(可能为新消息列表中的第一条消息)插入待处理消息列表需要考虑待处理消息中的第一个消息id与新消息列表中的第一条消息id的大小关系，待处理消息列表中的第一个消息id小于新消息列表中的第一个消息id才能将重发消息插入待处理消息列表中。而当截取出的待处理消息列表中第一个消息id小于新消息列表中的第一个消息id，且待处理消息列表中的第一个消息id与新消息列表中的第一个消息id的差值最小时，能够使得截取出的待处理消息列表最合理，该最合理的待处理消息列表在后续进行消息id比较时进行的无效判断最少，减少计算资源。
46.在一种可选的方式中，第一客户端从已展示消息列表中截取待处理消息列表时，可以从已展示消息列表中的最后一条消息往前依次选取一定数量的消息，直至在已展示消息列表中选取到第一个、消息id小于新消息列表中的第一个消息id的消息。其中，如果第一客户端从已展示消息列表的最后一条消息往前选取消息，直至选取到已展示消息列表的第一条消息所对应的消息id依旧不小于(即大于或等于)新消息列表中的第一条消息id时，则直接将已展示消息列表作为待处理消息列表。
47.步骤s13：比较所述新消息列表中的消息id与所述待处理消息列表中的消息id，从所述新消息列表中识别出不存在于所述待处理消息列表中的消息id，以及，识别出所述待处理消息列表中的插入位置。
48.本实施例中，第一客户端在确定出新消息列表和待处理消息列表后，需将新消息列表中的消息id与待处理消息列表中的消息id进行比较，从而识别出存在于新消息列表中却不存在于待处理消息列表中的消息id，以及，识别出该消息id对应的消息在待处理消息列表中的正确插入位置，其中，按正确插入位置插入待处理消息列表表征了插入消息后的待处理消息列表不会出现消息乱序问题。
49.步骤s14：将识别出的消息id所对应的消息插入所述待处理消息列表中的所述插入位置，生成待展示消息列表。
50.本实施例中，第一客户端识别出存在于新消息列表中却不存在于待处理消息列表中的消息id以及识别出该消息id对应的消息在待处理消息列表中的正确插入位置后，第一
客户端按照识别出的插入位置将与该插入位置对应的消息id所对应的消息插入待处理消息列表中，使得新消息列表中的消息能够根据消息id以正确的插入位置插入待处理消息列表中，在避免消息乱序的前提下实现两个消息列表的合并，生成待展示消息列表。
51.步骤s15：在下一时间段对所述待展示消息列表中的各个消息进行展示。
52.本实施例中，第一客户端接收当前时间段内的新消息生成待展示消息列表后，在下一时间段对待展示消息列表中的各个消息进行顺序排列展示，使得用户通过客户端看到的聊天消息是以正确的顺序展示，不会出现消息乱序的情况。例如，待处理消息列表中的消息id顺序为2
→4→
5，新消息列表中消息id的顺序为3
→6→
7，那么根据本实施例的消息处理方法，识别出新消息列表中不存在与待处理消息列表中的消息为：消息3、消息6和消息7；识别出各消息相对应的插入位置为：消息3的正确插入位置为待处理消息列表的消息2与消息4之间，消息6和消息7的正确插入位置为待处理消息列表的消息5之后，那么将识别出的消息id所对应的消息按照正确的插入位置插入至待处理消息列表，得到的待展示消息列表中消息id的顺序即为2
→3→4→5→6→
7，从而实现了在实时的聊天过程中从始至终都不会产生消息乱序问题。
53.其中，生成的待展示消息列表在下一时间段进行顺序展示时，还会同时存入客户端本地，并作为下一时间段的已展示消息列表。也就是说，将下一时间段内接收到的各个消息进行排序，生成新消息列表后进行消息处理，此时的待插入新消息的已展示消息列表即为上一时间段生成的待展示消息列表。
54.此外，在本实施例中，当第一客户端接收到服务端发送的第一批消息时(即客户端在初始时间段内接收到各个消息)，如第一批消息为服务端打包一次性发送给第一客户端的，则第一客户端接收到的第一批消息为服务端已经根据消息id排好序的消息，第一客户端接收到该第一批消息并直接展示该第一批消息，并将该第一批消息存入客户端本地作为下一时间段的已展示消息列表；如第一批消息为服务端逐条发送给第一客户端的，则第一客户端按照消息id将接收到的第一批消息进行排序后再展示，并将排序后的第一批消息存入本地作为下一时间段的已展示消息列表。
55.在本实施例中，新消息列表中的消息和已展示消息列表中的消息均为按照消息id的顺序排列，从已展示消息截取出待处理消息列表，比较新消息列表
56.与待处理消息列表之间的消息id，确定出新消息列表中不存在于待处理消息
57.列表中的消息id及该消息id所对应的消息在待处理消息列表中的正确插入位
58.置，按照该正确插入位置将不存在于待处理消息列表中的消息id所对应的消息插入待处理消息列表中，以生成待展示消息列表进行消息展示，从而保证了在实时聊天过程中消息能够从始至终按顺序展示。
59.结合以上实施例，在一实施方式中，本发明实施例还提供了一种消息处理方法。在该方法中，步骤s13中“比较所述新消息列表中的消息id与所述待处理消息列表中的消息id，从所述新消息列表中识别出不存在于所述待处理消息列表中的消息id”具体包括步骤s21至步骤s23，步骤s21至步骤s23之间的关系如图4所示，图4是本发明一实施例示出的一种消息确定方法的流程图：
60.步骤s21：以所述待处理消息列表中进行比较的消息id为第一id，以所述新消息列表中进行比较的消息id为第二id，比较所述第一id与所述第二id。
61.本实施例中，第一客户端生成新消息列表和待处理消息列表后，需要进行新消息列表中的消息id与待处理消息列表中的消息id之间的比较，此时以待处理消息列表中进行比较的消息id为第一id，以新消息列表中进行比较的消息id为第二id，进行第一id与第二id之间的比较。
62.步骤s22：在所述第一id与所述第二id之间的比较结果表征所述第二id对应的消息为重新发送的缺失补偿消息时，确定所述第二id为所述不存在于所述待处理消息列表中的消息id。
63.本实施例中，第一客户端将第一id与第二id进行比较之后，当第一id与第二id之间的比较结果表征：该第二id所对应的消息为服务端重新发送的缺失补偿消息时，那么第一客户端则确定该第二id为不存在于待处理消息列表中的消息id，需要将该第二id对应的消息插入至待处理消息列表中。
64.步骤s23：在所述第一id与所述第二id之间的比较结果表征所述第二id对应的消息为实时发送的新消息时，确定所述第二id为所述不存在于所述待处理消息列表中的消息id。
65.本实施例中，第一客户端将第一id与第二id进行比较之后，当第一id与第二id之间的比较结果表征：该第二id所对应的消息为服务端实时发送的新消息时，那么，第一客户端确定该第二id为不存在于待处理消息列表中的消息id，需要将该第二id对应的消息插入至待处理消息列表中。
66.此外，第一客户端将第一id与第二id进行比较之后，当第一id与第二id之间的比较结果表征：该第二id所对应的消息为服务端重新发送的重新消息时，那么，第一客户端确定该第二id为存在于待处理消息列表中的消息id，第一客户端无需处理该第二id对应的消息。
67.在本实施例中，第一客户端可以根据第一id与第二id之间的比较结果识别出第二id对应的消息是否为重新发送的缺失补偿消息或实时发送的新消息，当识别出第二id对应的消息为重新发送的缺失补偿消息或实时发送的新消息时，将此时的第二id确定为不存在于待处理消息列表中的消息id，从而在后续进行消息插入时可以只对被确定为不存在于待处理消息列表中第二id所对应的消息进行处理，从而避免了待处理消息列表中重复消息的插入，进一步保证了实时聊天过程中消息顺序展示且不重复的聊天效果。
68.结合以上实施例，在另一实施方式中，本发明实施例还提供了一种消息处理方法。在该方法中，还提供了一种消息id比较方法，具体包括步骤s31至步骤s33。步骤s31至步骤s33之间的关系如图5所示，图5是本发明一实施例示出的一种消息比较方法的流程图。
69.步骤s31：第一次比较时，将所述待处理消息列表中的第一个消息id确定为所述第一id，且将所述新消息列表中的第一个消息id确定为所述第二id。
70.本实施例中，在进行第一次消息id比较时，将待处理消息列表中的第一个消息id作为第一id(即第一id为待处理消息列表中第一个消息所对应的消息id)，将新消息列表中的第一个消息id作为第二id(即第二id为新消息列表中第一个消息所对应的消息id)，以进行第一id与第二id之间的消息id大小比较。
71.其中，在一种可选的实施方式中，为了明确每次消息比较时两个消息在各自列表中的具体位置，可以通过设置指针的方式进行消息id之间的比较：例如，可以为待处理消息
列表设置第一指针，为新消息列表设置第二指针，且第一指针和第二指针的初始位置均指向消息列表中的第一条消息，即进行第一次消息id比较时，第一指针指向待处理消息列表中的第一条消息，第二指针指向新消息列表中的第一条消息，以此进行第一指针指向的消息id与第二指针指向的消息id之间的比较。
72.步骤s32：当所述第一id与所述第二id之间的比较结果为：所述第一id小于所述第二id时，将所述第二id作为下一次比较中的第二id，对所述待处理消息列表自所述第一id往下进行遍历，直至找到所述待处理消息列表中大于或等于所述第二id的消息id，并将所述消息id作为下一次比较中的第一id。
73.本实施例中，当第一客户端进行第一id与第二id之间的比较，且第一id与第二id之间的比较结果为：第一id小于第二id时，，此时则可确定第二id应该在第一id的后面，但并不能确定第二id相较于第一id的具体位置(如不能确定当前第二id是在当前第一id的后一位、后两位还是后三位等等)，因此，此时将该第二id作为下一次比较中的第二id进行继续比较。而对于第一id来说，此时需对待处理消息列表从当前第一id往下遍历，直至找到待处理消息列表中大于或等于当前第二id的消息id，并将找到的该消息id作为下一次比较时的第一id，以进行后续的消息比较。
74.举例来说，如第一id为2，第二id为5，待处理消息列表中的消息id依次为2
→3→4→
6，比较第一id与第二id，确定第一id2小于第二id5，则确定第二id5为下一次比较中的第二id，即下一次比较时第二id不变，依旧为5；而对于第一id来说，则从2往下遍历，直至从待处理消息列表中找到大于或等于第二id5的消息id，则此时确定6为下一次比较时的第一id。
75.其中，在一种可选的实施方式中，可以通过设置指针的方式进行消息id之间的比较，继续以上述第一指针、第二指针为例：比较第一指针指向的消息id与第二指针指向的消息id的大小关系，当第一指针指向的消息id小于第二指针指向的消息id时，第二指针的位置不变，第一指针向下移动直至第一指针移动到其指向的消息id大于或等于第二指针指向的消息id，从而完成本次比较。
76.步骤s33：当所述第一id与所述第二id之间的比较结果为：所述第一id大于或等于所述第二id时，将所述第二id的下一个消息id作为下一次比较中的第二id，将所述第一id作为下一次比较中的第一id。
77.本实施例中，当第一客户端进行第一id与第二id之间的比较，且第一id与第二id之间的比较结果为：第一id等于第二id时，此时则可确定第二id已经存在于待处理消息列表中，所述第二id所对应的消息已经在待处理消息列表中展示，第二id所对应的消息为服务端重新发送的重复消息。因此，对新消息列表
78.中的重复消息(即第二id所对应的消息)不作处理，将该第二id的下一个消息
79.id作为下一次比较中的第二id进行后续比较，而对于第一id来说，第一id不变，将该第一id作为下一次比较中的第一id进行继续比较。
80.举例来说，如第一id为5，第二id为5，新消息列表中的消息id依次为5
→6→
7，比较第一id与第二id，确定第一id5等于第二id5，则确定第一id5为下一次比较中的第一id，即下一次比较时第一id不变，依旧为5；而对于第二id来说，则找到第二id的下一个消息id，即找到消息id5后面的下一个消息id6，则此时确定消息id6为下一次比较时的第二id，从而完
成此次消息id的比较。
81.其中，在一种可选的实施方式中，可以通过设置指针的方式进行消息id之间的比较，继续以上述第一指针、第二指针为例：比较第一指针指向的消息id与第二指针指向的消息id的大小关系，当第一指针指向的消息id等于第二指针指向的消息id时，第一指针的位置不变，第二指针往下移一位，从而完成本次比较。
82.本实施例中，当第一客户端进行第一id与第二id之间的比较，且第一id与第二id之间的比较结果为：第一id大于第二id时，此时则可确定第二id不存在于待处理消息列表中，且第二id应在第一id的前面，第二id所对应的消息为待处理消息列表中服务端重新发送的缺失补偿消息。因此，此时将该第二id的下一个消息id作为下一次比较中的第二id以进行后续比较；而对于第一id来说，第一id不变，即将该第一id作为下一次比较中的第一id继续进行比较，从而完成本次的消息id比较。
83.举例来说，如第一id为6，第二id为5，待处理消息列表中的消息id依次为6
→7→
8，新消息列表中的消息id依次为5
→
7，比较第一id与第二id，确定第一id6大于第二id5，则确定第一id6为下一次比较中的第一id，即下一次比较时第一id不变，依旧为6；而对于第二id来说，则找到第二id的下一个消息id，即找到消息id5后面的下一个消息id7，则此时确定消息id7为为下一次比较时的第二id，从而完成此次消息id的比较。
84.其中，在一种可选的实施方式中，可以通过设置指针的方式进行消息id之间的比较，继续以上述第一指针、第二指针为例：比较第一指针指向的消息id与第二指针指向的消息id的大小关系，当第一指针指向的消息id大于第二指针指向的消息id时，第一指针的位置不变，将第二指针往下移一位，从而完成本次比较。
85.本实施例在进行新消息列表与待处理消息列表之间的消息id比较时，通过本实施例提出的比较方法逐步进行第一id与第二id之间的比较，能够依次确定新消息列表中各个消息的情况，并根据情况确定下一次比较时待处理消息列表中的第一id和下一次比较时新消息列表中的第二id以进行后续比较从而在比较过程中能够对新消息列表中的各个消息做出准确的消息处理，从而确保消息的顺序展示。
86.结合以上实施例，在一种实施方式中，待处理消息列表中的插入位置包括第一插入位置和第二插入位置，第一插入位置和第二插入位置的确定需要依据第一id与第二id之间的比较情况而定：其中，
87.针对第一插入位置：在所述第一id与所述第二id之间的比较结果表征所述第二id对应的消息为重新发送的缺失补偿消息时，确定第一插入位置为：所述第一id所对应的消息的前一位。
88.本实施例中，当第一客户端进行第一id与第二id之间的比较，且第一id与第二id之间的比较结果表征该第二id对应的消息为重新发送的缺失补偿消息时，此时表明该第二id小于该第一id，第二id应在第一id的前面，因此，第一客户端确定待处理消息列表中的第一插入位置为：该第一id所对应的消息的前一位。
89.针对第二插入位置：在所述待处理消息列表中的各个消息均已参与比较使得比较结束时，或，在所述第一id与所述第二id之间的比较结果表征所述第二id对应的消息为实时发送的新消息时，确定第二插入位置为：所述待处理消息列表的末尾。
90.本实施例中，待处理消息列表中的各个消息均已参与比较可以使得消息id结束比
较，此时第一id为待处理消息列表中的最后一个消息id，且第一id已经与第二id完成了比较，而待处理消息列表中已经没有剩余的消息能与新消息列表中的消息进行后续比较了，则结束消息id的比较。
91.例如：待处理消息中的消息id依次为5
→7→
9，新消息列表中的消息id依次为6
→
10
→
11
→
12，此时第一id为9，前面的消息id5、消息id7已经进行了比较，而当第一id9与第二id10进行比较时，第一id9小于第二id10，此时因为第一id9后面无法找到大于或等于第二id10的消息进行后续比较了，因此结束消息id的比较。
92.此时，如果新消息列表中还有剩余的未插入待处理消息列表中的消息，其理应插入待处理消息列表的末尾，因此，此时第一客户端确定待处理消息列表中的第二插入位置为：待处理消息列表的末尾。
93.本实施例中，若当第一客户端进行第一id与第二id之间的比较，且第一id与第二id之间的比较结果表征该第二id对应的消息为实时发送的新消息时，此时表明该第二id对应的消息为第一客户端待处理消息列表中消息的后续消息，因此，此时第一客户端确定待处理消息列表中的第二插入位置为：待处理消息列表的末尾。
94.在本实施例中，根据两个消息列表间消息id的比较情况，可以确定出各第二id所对应的消息相对于待处理消息列表中的合理插入位置，进一步为后续实现补偿更新待处理消息列表中消息的同时进行消息顺序展示提供保障。
95.结合以上实施例，在一种实施方式中，第一客户端还需要依据第一id与第二id之间的比较情况来进行识别出的消息id所对应消息的插入，本实施例中的消息插入分以下两种情况：
96.第一种情况：在比较的过程中，将识别出的所述缺失补偿消息插入所述待处理消息列表中的所述第一插入位置。
97.本实施例中，第一客户端在进行待处理消息列表中第一id与新消息列表中第二id比较的过程中，确定出第二id所对应的消息为缺失补偿消息，该第二id所对应的插入位置为第一插入位置后，第一客户端可按照确定出的第一插入位置(即当前进行比较的第一id所对应的消息的前一位)将第二id所对应的消息(即识别出的缺失补偿消息)插入至待处理消息列表中。
98.此外，需要说明的是：新消息列表中的各个消息均已参与比较也可以使得消息id结束比较，此时则为：当前进行比较的第二id为新消息列表中最后一条消息的消息id，且新消息列表中最后一条消息已经完成了消息处理(即第二id所对应的消息已经插入待处理列表或第二id所对应的消息被确定为重复消息，无需处理该消息)，新消息列表中没有消息需要进行处理了，则结束消息id的比较。
99.例如：新消息列表中的消息id依次为3
→6→
8，此时第二id为8，前面的消息id3、消息id6已经进行了比较，而第二id8已经与第一id完成了比较，且第二id8所对应的消息已经插入待处理消息列表中或第二id8所对应的消息被确定为重复消息无需处理，而第二id8所对应的消息后面没有消息，代表已经完成了新消息列表中的消息处理，则结束消息id的比较。
100.可见，此种情况下结束消息id的比较，新消息列表中的消息在比较过程中已完成了消息处理(消息均已按照第一插入位置进行了消息的插入或消息为重复消息无需进行处
理)，此时也属于上述第一种情况，是在比较过程中，将识别出的缺失补偿消息插入待处理消息列表中的第一插入位置。
101.第二种情况：在所述待处理消息列表中的各个消息均已参与比较使得比较结束，且所述第二id所对应的消息之后的消息还未参与比较的情况下，将所述第二id所对应的消息及所述第二id所对应的消息之后的消息插入所述待处理消息列表中的所述第二插入位置。
102.本实施例中，第一客户端确定出第一id为待处理消息列表中的最后一个消息id，且第一id已经与第二id完成比较，第二id所对应的消息及其之后的消息还未插入待处理列表的情况下，此时表征第二id所对应的消息及其之后的消息为第一客户端接收到的实时新消息，第一客户端将新消息列表中第二id所对应的消息及第二id所对应的消息之后的消息插入至待处理消息列表中的第二插入位置(即待处理消息列表的末尾)，以完成待处理消息列表的消息更新。
103.其中，第一客户端可以按照消息id的顺序将第二id所对应的消息及第二id所对应的消息之后的消息依次插入待处理消息列表的末尾，也可以将第二id所对应的消息及第二id所对应的消息之后的消息一起插入待处理消息列表的末尾，本实施例对此不作任何限制。
104.此外，本实施例具体在进行消息插入时，可以是第一客户端从新消息列表中拷贝第二id所对应的消息，并将拷贝的第二id所对应的消息按照确定出的插入位置(第一插入位置或第二插入位置)插入至待处理消息列表中，这样新消息列表中的第二id所对应的消息未被移除或删减，能够保证新消息列表不会因移除消息而产生消息乱序问题；或者，也可以是第一客户端直接将新消息列表
105.中的第二id所对应的消息移动至待处理消息列表中的插入位置，新消息列表中
106.的第二id所对应的消息被移除，本实施例对上述两种插入消息的方法不作任何具体限制。
107.在本实施例中，第一客户端根据消息id的比较情况以及确定出的插入位置将新消息列表中的消息插入至待处理消息列表中，从而能够使得新消息列表中包含的实时消息和/或缺失补偿消息均能以正确的位置与待处理消息列表进行合并展示，从而实现了补偿更新待处理消息列表中消息的同时保证了消息的顺序展示。该方法不仅能快速完成消息插入合并，而且还在合并过程中只影响有限的本地聊天消息(即仅影响待处理消息列表)，不会出现整个消息列表(所有已展示消息)重新渲染，提高了用户体验。
108.结合以上实施例，在一种实施方式中，本发明还提供了一种消息处理方法，在该方法中，步骤s15之后还包括步骤s41至步骤s43。步骤s41至步骤s43之间的关系如图6所示，图6是本发明一实施例示出的一种消息补偿方法的流程图。
109.步骤s41：遍历所述待展示消息列表，判断所述待展示消息列表中的消息id是否连续。
110.本实施例中，第一客户端生成待展示消息列表后，还会遍历待展示消息列表，判断待展示消息列表中的消息id是否连续。
111.步骤s42：当所述待展示消息列表中的消息id不连续时，或，当响应于聊天界面发生前后台切换时，向离线数据库拉取第一时间段的补偿消息；其中，所述离线数据库中备份
有所有需要发送给所示第一客户端的消息。
112.本实施例中，当第一客户端确定待展示消息列表中的消息id不连续时，即表征待展示消息列表中依旧存在缺失消息，第一客户端会主动向离线数据库中请求第一时间段的补偿消息。其中，服务端在进行客户端之间的消息转发过程中，当消息由客户端发送给服务端时，服务端对接收到的消息进行消息处理(如前所述的为消息分配连续递增的消息id、为消息标记消息所处状态、消息发送时间等等)后，服务端还会将处理后的消息存入离线数据库中进行备份，在服务端可用资源充足的情况下，服务端可将自身作为离线数据库进行消息的备份。也就是说，离线数据库中备份有所有需要发送给客户端的消息。
113.而在本实施例中，第一客户端向离线数据库拉取第一时间段的补偿消息，可以是第一客户端向离线数据库发送补偿消息请求，该请求中携带了第一时间段信息以及消息接收双方的身份标识，离线数据库接收到补偿消息请求后响应该补偿消息请求，根据该补偿消息请求向第一客户端返回第一时间段的备份消息，也就是说，补偿消息为第一客户端向离线数据库主动拉取的，按消息id顺序排列的指定备份消息。
114.在本实施例中，由于在客户端由聊天界面切回后台或客户端由后台切进聊天界面的时候，可能出现代码无法执行，无法正常接收消息的情况，因此当第一客户端响应于聊天界面发生前后台切换时，即当第一客户端检测到客户端从聊天界面切出到其他界面，或从其他界面切入到聊天界面时，第一客户端也会主动向离线数据库拉取第一时间段的补偿消息，以进行展示消息的补偿。
115.步骤s43：根据所述补偿消息对所述待展示消息列表进行消息离线补偿。
116.本实施例中，第一客户端接收到离线数据库返回的补偿消息后，可以根据该补偿消息对待展示消息列表进行消息离线补偿。其中，在进行消息离线补偿时，是将补偿消息当作上述的新消息列表，待展示消息列表当作上述的待处理消息列表，通过前述各实施例的消息合并方法进行补偿消息和待展示消息列表的合并，以生成新的待展示消息列表。
117.其中，消息离线补偿与前述新消息列表与待处理消息列表的消息合并处理方法的区别仅在于：补偿消息是第一客户端主动向离线数据库主动拉取的消息，而新消息列表中的消息是第一客户端被动接收的服务端转发的消息。
118.在本实施例中，通过设置合理的离线补偿机制，当第一客户端检测到消息合并处理后的消息依旧不连续时或检测到聊天界面发生前后台切换时触发离线补偿，拉取离线数据库中的消息列表与展示消息进行进一步合并，从而实现了第一客户端展示消息的离线补偿，确保了用户在聊天过程中切出应用或者短时间内网络故障的场景下依然能可靠接收到丢失的消息。
119.结合以上实施例，在一种实施方式中，在进行消息离线补偿时，可以分以下三种方式来确定第一时间段：
120.第一种方式为：当所述消息离线补偿为第一次消息离线补偿，且所述消息离线补偿是在所述待展示消息列表中的消息id不连续时进行的消息离线补偿的情况下，所述第一时间段为以第二消息的接收时间作为起始时间，以当前时间作为结束时间的时间区间；其中，所述第二消息为所述待展示消息列表中缺失消息的前一条消息。
121.本实施例中，当消息离线补偿为第一次消息离线补偿，且该消息离线补偿是在第一客户端判断出待展示消息列表中的消息id不连续时进行的消息离线补偿的情况下，第一
客户端主动向离线数据库拉取第一时间段的补偿消息，该第一时间段为：以第二消息的接收时间作为起始时间，以当前时间作为结束时间的时间区间。本实施例中的第二消息为待展示消息列表中缺失消息的前一条消息，例如，当第一客户端遍历待展示消息列表后确定待展示列表中的消息id不连续，不连续消息id为6
→
8，此时确定消息id6对应的消息与消息id8对应的消息之间存在缺失消息，则该缺失消息的前一条消息(即消息id6对应的消息)即为第二消息。
122.本实施例在确定待展示消息列表消息id不连续时触发的第一次离线补偿时，可以确定消息列表的中间有消息丢失，但无法确定最后的消息是否丢失，因此为了保险起见，第一客户端向离线数据库拉取的补偿消息是从待展示消息列表中缺失消息的前一条消息的接收时间为起始时间，持续向后拉取至当前时间的接收消息，从而能够保证对缺失消息进行足够的补偿。
123.第二种方式为：当所述消息离线补偿为第一次消息离线补偿，且所述消息离线补偿是在响应于聊天界面发生前后台切换时进行的消息离线补偿的情况下，所述第一时间段为以所述待展示消息列表中最后一条消息的接收时间作为起始时间，以当前时间作为结束时间的时间区间。
124.本实施例中，当消息离线补偿为第一次消息离线补偿，且该消息离线补偿是在第一客户端响应于聊天界面发生前后台切换时进行的消息离线补偿的情况下，第一客户端主动向离线数据库拉取第一时间段的补偿消息，该第一时间段为：以待展示消息列表中最后一条消息的接收时间作为起始时间，以当前时间作为结束时间的时间区间。
125.本实施例在响应于聊天界面发生前后台切换时触发的第一次离线补偿时，可能丢失的是新消息，因此拉取补偿消息的结束时间需为当前时间，即此时第一客户端向离线数据库拉取的补偿消息是从待展示消息列表中最后一条消息的接收时间为起始时间，持续向后拉取至当前时间的接收消息，从而能够实现对当前的聊天界面进行刷新，并自动补偿是否存在上次展示消息后的更新消息。
126.第三种方式为：当所述消息离线补偿为后续消息离线补偿时，所述第一时间段为以前次消息离线补偿时，所述补偿消息中最后一条消息的接收时间作为起始时间，以当前时间作为结束时间的时间区间。
127.本实施例中，当消息离线补偿为后续消息离线补偿时，不管该离线补偿是因为第一客户端检测到待展示消息列表中的消息id不连续时所触发的离线补偿，还是该离线补偿是第一客户端响应于聊天界面发生前后台切换时所触发的离线补偿，第一客户端主动向离线数据库拉取第一时间段的补偿消息，该第一时间段均为：以前次消息离线补偿的补偿消息中最后一条消息的接收时间作为起始时间，以当前时间作为结束时间的时间区间。
128.本实施例在第一客户端触发的第一次离线补偿后的后续离线补偿时，第一客户端向离线数据库拉取的补偿消息是从前次消息离线补偿时拉取的补偿消息中最后一条消息的接收时间作为起始时间，持续向后拉取至当前时间的接收消息，从而能够实现以前次补偿消息的后续消息对展示消息进行补偿。
129.在本实施例中，根据离线补偿分情况拉取不同时间区间的补偿消息，从而实现补偿消息的精准拉取，以此保证对第一客户端展示消息的精准离线补偿，进一步提升了用户接收聊天消息的体验。
130.结合以上实施例，在一种实施方式中，本发明还提供了一种消息处理方法，具体地，该方法还包括：在所述消息通过客户端与服务端之间的传输通道进行传输的过程中，通过第一检测方法和第二检测方法并行的方式对所述传输通道进行检测，以检测所述传输通道是否失活或断开，并在所述传输通道失活或断开时，进行重连。
131.本实施例中，消息是通过客户端(如第一客户端或第二客户端)与服务端之间的传输通道进行传输的，而如果该传输通道可能因各种原因(如网络原因、设备原因等等)断开或失活，因此，为了保障消息的可靠传输，本实施例在进行消息处理的过程中还会进行传输通道的检测：在消息通过客户端与服务端之间的传输通道进行传输的过程中，可通过两种方法(第一检测方法和第二检测方法)并行的方式对传输通道进行检测，以检测客户端与服务端之间的传输通道是否失活或断开，并在传输通道失活或断开时，进行传输通道的重连。
132.其中，第一检测方法为：所述第一客户端中用于打开网页的插件对所述传输通道进行监听，以监听所述传输通道是否失活或断开。
133.本实施例的第一客户端中用于打开网页的插件可以为webview等，第一客户端中用于打开网页的插件具有监听功能，当第一客户端或服务端所处网络环境存在极大不确定性，波动较大时可能导致第一客户端网络断开，如果网络断开时间较长，该插件能够监听到该传输通道断开，则该插件通知第一客户端进行重连尝试；如果网络断开时间较短，或服务端消息分发出现阻塞时，该插件通常无法感知到该通道是否断开，因此需要其他检查方法同时进行通道检测。在一种可选方式中，该插件在监听到该传输通道断开时，还会直接进行公网访问以判断是否为第一客户端侧的网络故障，如为第一客户端侧的网络故障，则提示用户重连网络以重连传输通道。
134.所述第二检测方法为：当所述第一客户端在第一时长内无法收到所述服务端以固定时间间隔向所述第一客户端重复发送的检测消息时，确定所述传输通道失活或断开。
135.本实施例还可由服务端以固定时间间隔向第一客户端重复发送ping消息(心跳检测)，如果第一客户端收到ping消息，则会向服务端回复pong消息；当第一客户端在第一时长内没有收到ping消息时，则确定该传输通道失活或断开，从而进行传输通道的重连。其中，第一时长为心跳检测过程中预先设定的时间段，在时间段内收到ping消息则视为通道正常，在时间段内未收到ping消息则视为通道失活或断开，本实施例对第一时长的具体数值不作任何具体限制。
136.本实施例中，在消息的传输过程中通过两种方法并行的方式检测传输通道的状态，从而实现了网络情况及传输通道稳定性的实时检测和及时连接重试，进一步提升了消息收发时的用户体验。
137.结合以上实施例，在一种实施方式中，本发明还提供了一种消息处理方法，在该方法中传输通道为ws通道，该方法还包括：当所述ws通道超出第二时长依旧未连接成功时，通过http协议建立所述第一客户端与所述服务端之间的传输通道。
138.本实施例中，用户之间的聊天场景为web聊天场景，客户端通过网页端进行消息的收发和展示，客户端与服务端之间的消息传输通道为ws通道，即为websocket通道，websocket(缩写为ws)通道存在延时低，通道可永久复用的特点，被广泛用户实时聊天场景中。
139.而当第一客户端检测到websocket通道长时间依旧未连接成功时，即第一客户端
检测到websocket通道超过第二时长(其中，第二时长为事先设定的允许通道未连接的最大时长，本实施例对第二时长的具体数值不作任何具体限制)依旧未连接成功时，通过http协议建立第一客户端与服务端之间的通道连接，从而实现消息传输通道的降级，以能够有效确保消息的可靠性传输。
140.需要说明的是，消息传输通道的降级并不会影响本技术所提出的消息处理方法，因为消息传输由websocket协议变为http协议，区别仅在于是否客户端主动请求是否有新消息，当消息传输到客户端后(即客户端接收到消息后)，客户端进行消息处理的方法不变。
141.在本实施例中，当websocket通道出现长时间故障时，依旧能够通过传输协议的降级处理来有效确保消息可靠性传输，以此为实时聊天场景中的消息收发提供基础保障。
142.结合以上实施例，在一种实施方式中，本发明还提供了一种消息处理方法，具体地，该方法还包括步骤s51和步骤s52，步骤s51与步骤s52之间的关系如图7所示，图7是本发明一实施例示出的一种消息送达确认方法的流程图。
143.步骤s51：在通过第一客户端与服务端之间的传输通道进行消息传输的过程中，通过ack机制进行消息的送达确认。
144.在本实施例中，由于消息传输会先达到服务端，再由服务端转发，在每个传输环节中都有可能出现消息丢失，因此，本实施例在消息通过客户端与服务端之间的传输通道进行传输的过程中，通过ack机制进行消息的送达确认：消息在传输的过程中均会携带一个ack消息，当接收方接收到消息时则会向发送方返回一个ack响应消息以表征消息的成功送达。
145.步骤s52：当在第三时长内未收到服务端的ack响应时，进行消息重发。
146.本实施例中，当第一客户端在第三时长内未收到服务端返回的ack响应时，第一客户端确定服务端未收到第一客户端发送的消息，该消息发送失败，则第一客户端可在合适的时机向服务端重新发送该消息，以此实现消息的重新发送。其中，合适的时间可以为：传输通道重连成功后或当前消息发完后(即不干涉当前消息的前提下)。而如当服务端在第三时长内未收到第一客户端返回的ack响应时，服务端确定第一客户端未收到服务端发送的消息，该消息发送失败，则服务端向第一客户端重新发送该消息，以此实现消息的重新发送。其中，第三时长为本实施例事先设定的认为消息发送成功的最大时长，超过第三时长接收到的ack响应也视为消息发送失败，本实施例对第三时长的具体数值不作任何具体限制。
147.在本实施例中，在消息的传输过程中通过ack机制进行消息的送达确认，以实时确定进行消息重发的时机，从而能够对消息发送失败场景做及时处理，此为实时聊天场景中消息的实时收发提供基础保障。
148.结合以上实施例，在一种实施方式中，两个客户端进行实时聊天的过程中，消息收发过程如图8所示，图8是本发明一实施例示出的一种消息交互示意图。第一客户端与第二客户端之间通过服务端进行消息交互，服务端会对接收到的消息进行消息处理，并将处理后的消息存进消息队列中。其中，消息在传输的过程中均会携带一个ack消息，接收方需要回应ack，当一段时间(如上述第三时长)内，发送方未收到ack响应，则由发送方进行消息重发。并且，服务端会以固定时间间隔向客户端(第一客户端和第二客户端)重复发送ping消息，如果第一客户端或第二客户端收到ping消息，则会向服务端回复pong消息；当第一客户端或第二客户端在第一时长内没有收到ping消息时，则确定客户端与服务端之间的传输通
道失活或断开，从而进行传输通道的重连。
149.需要说明的是，对于方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本发明实施例并不受所描述的动作顺序的限制，因为依据本发明实施例，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作并不一定是本发明实施例所必须的。
150.基于同一发明构思，本发明一实施例提供了一种消息处理装置900，该装置900应用于包括第一客户端、第二客户端和服务端的系统，所述第一客户端和所述第二客户端通过所述服务端进行消息交互，所述装置设置于所述第一客户端。参考图9，图9是本发明一实施例提供的消息处理装置的结构框图。如图9所示，该装置900包括：
151.生成模块901，用于按照消息id对在当前时间段内接收到的各个消息进行排序，生成新消息列表；
152.截取模块902，用于从已展示消息列表中截取部分消息列表，以作为待处理消息列表，所述已展示消息列表中的消息是按照所述消息id顺序排列的，所述已展示消息列表中消息的排列顺序与所述新消息列表中消息的排列顺序相同，所述待处理消息列表中的第一个消息id小于所述新消息列表中的第一个消息id，所述待处理消息列表中的最后一个消息id为所述已展示消息列表中的最后一个消息id；
153.比较模块903，用于比较所述新消息列表中的消息id与所述待处理消息列表中的消息id，从所述新消息列表中识别出不存在于所述待处理消息列表中的消息id，以及，识别出所述待处理消息列表中的插入位置；
154.插入模块904，用于将识别出的消息id所对应的消息插入所述待处理消息列表中的所述插入位置，生成待展示消息列表；
155.展示模块905，用于在下一时间段对所述待展示消息列表中的各个消息进行展示。
156.可选的，所述比较模块903包括：
157.比较子模块，用于以所述待处理消息列表中进行比较的消息id为第一id，以所述新消息列表中进行比较的消息id为第二id，比较所述第一id与所述第二id；
158.第一消息确定模块，用于在所述第一id与所述第二id之间的比较结果表征所述第二id对应的消息为重新发送的缺失补偿消息时，确定所述第二id为所述不存在于所述待处理消息列表中的消息id；
159.第二消息确定模块，用于在所述第一id与所述第二id之间的比较结果表征所述第二id对应的消息为实时发送的新消息时，确定所述第二id为所述不存在于所述待处理消息列表中的消息id。
160.可选的，所述比较模块903还包括：
161.第一插入位置确定模块，用于在所述第一id与所述第二id之间的比较结果表征所述第二id对应的消息为重新发送的缺失补偿消息时，确定第一插入位置为：所述第一id所对应的消息的前一位；
162.第二插入位置确定模块，用于在所述待处理消息列表中的各个消息均已参与比较使得比较结束时，或，在所述第一id与所述第二id之间的比较结果表征所述第二id对应的消息为实时发送的新消息时，确定第二插入位置为：所述待处理消息列表的末尾。
163.可选的，所述插入模块904，包括：
164.第一插入子模块，用于在比较的过程中，将识别出的所述缺失补偿消息插入所述待处理消息列表中的所述第一插入位置；
165.第二插入子模块，用于在所述待处理消息列表中的各个消息均已参与比较使得比较结束，且所述第二id所对应的消息之后的消息还未参与比较的情况下，将所述第二id所对应的消息及所述第二id所对应的消息之后的消息插入所述待处理消息列表中的所述第二插入位置。
166.可选的，所述装置900还包括：
167.第一次比较子模块，用于第一次比较时，将所述待处理消息列表中的第一个消息id确定为所述第一id，且将所述新消息列表中的第一个消息id确定为所述第二id；
168.第一消息id确定模块，用于当所述第一id与所述第二id之间的比较结果为：所述第一id小于所述第二id时，将所述第二id作为下一次比较中的第二id，对所述待处理消息列表自所述第一id往下进行遍历，直至找到所述待处理消息列表中大于或等于所述第二id的消息id，并将所述消息id作为下一次比较中的第一id；
169.第二消息id确定模块，用于当所述第一id与所述第二id之间的比较结果为：所述第一id大于或等于所述第二id时，将所述第二id的下一个消息id作为下一次比较中的第二id，将所述第一id作为下一次比较中的第一id。
170.可选的，所述装置900还包括：
171.遍历模块，用于遍历所述待展示消息列表，判断所述待展示消息列表中的消息id是否连续；
172.消息拉取模块，用于当所述待展示消息列表中的消息id不连续时，或，当响应于聊天界面发生前后台切换时，向离线数据库拉取第一时间段的补偿消息；其中，所述离线数据库中备份有所有需要发送给所述第一客户端的消息；
173.离线补偿模块，用于根据所述补偿消息对所述待展示消息列表进行消息离线补偿。
174.可选的，所述第一时间段为：
175.当所述消息离线补偿为第一次消息离线补偿，且所述消息离线补偿是在所述待展示消息列表中的消息id不连续时进行的消息离线补偿的情况下，所述第一时间段为以第二消息的接收时间作为起始时间，以当前时间作为结束时间的时间区间；其中，所述第二消息为所述待展示消息列表中缺失消息的前一条消息；或者，
176.当所述消息离线补偿为第一次消息离线补偿，且所述消息离线补偿是在响应于聊天界面发生前后台切换时进行的消息离线补偿的情况下，所述第一时间段为以所述待展示消息列表中最后一条消息的接收时间作为起始时间，以当前时间作为结束时间的时间区间；或者，
177.当所述消息离线补偿为后续消息离线补偿时，所述第一时间段为以前次消息离线补偿时，所述补偿消息中最后一条消息的接收时间作为起始时间，以当前时间作为结束时间的时间区间。
178.可选的，所述装置900还包括：
179.检测模块，用于在所述消息通过第一客户端与服务端之间的传输通道进行传输的
过程中，通过第一检测方法和第二检测方法并行的方式对所述传输通道进行检测，以检测所述传输通道是否失活或断开，并在所述传输通道失活或断开时，进行重连；
180.其中，所述第一检测方法为：所述第一客户端中用于打开网页的插件对所述传输通道进行监听，以监听所述传输通道是否失活或断开；
181.所述第二检测方法为：当所述第一客户端在第一时长内无法收到所述服务端以固定时间间隔向所述第一客户端重复发送的检测消息时，确定所述传输通道失活或断开。
182.可选的，所述传输通道为ws通道，所述装置900还包括：
183.降级模块，用于当所述ws通道超出第二时长依旧未连接成功时，通过http协议建立所述第一客户端与所述服务端之间的传输通道。
184.可选的，所述装置900还包括：
185.ack机制模块，用于在通过第一客户端与服务端之间的传输通道进行消息传输的过程中，通过ack机制进行消息的送达确认；
186.重发模块，用于当在第三时长内未收到服务端的ack响应时，进行消息重发。
187.基于同一发明构思，本发明另一实施例提供一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，该计算机程序被处理器执行时实现如本发明上述任一实施例所述的消息处理方法中的步骤。
188.基于同一发明构思，本发明另一实施例提供一种电子设备1000，如图10所示。图10是本发明一实施例示出的一种电子设备的示意图。该电子设备包括存储器1002、处理器1001及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行时实现本发明上述任一实施例所述的消息处理方法中的步骤。
189.对于装置实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。
190.本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。
191.本领域内的技术人员应明白，本发明的实施例可提供为方法、装置、或计算机程序产品。因此，本发明实施例可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明实施例可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。
192.本发明实施例是参照根据本发明实施例的方法、终端设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理终端设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理终端设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
193.这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理终端设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方
框或多个方框中指定的功能。
194.这些计算机程序指令也可装载到计算机或其他可编程数据处理终端设备上，使得在计算机或其他可编程终端设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程终端设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
195.尽管已描述了本发明实施例的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例做出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本发明实施例范围的所有变更和修改。
196.最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者终端设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者终端设备所固有的要素。在没有更多限制的情况下，由语句“包括一个
……”
限定的要素，并不排除在包括所述要素的过程、方法、物品或者终端设备中还存在另外的相同要素。
197.以上对本发明所提供的一种消息处理方法、装置、电子设备及可读存储介质，进行了详细介绍，本文中应用了具体个例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心思想；同时，对于本领域的一般技术人员，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本发明的限制。