对于IM系统来说，如何做到IM聊天消息离线差异拉取（差异拉取是为了节省流量）、消息多端同步、消息顺序保证等，是典型的IM技术难点。总结下来其实就是要解决好一个问题：即如何保证聊天消息的唯一性判定和顺序判定。

很多读者在讨论这个问题的时候，普遍考虑的是使用整型自增序列号作为消息ID（即MsgId）：这样确实能保证消息的唯一性又方便保证顺序性，但问题是在分布式情况下是很难保证消息id的唯一性且顺序递增的，维护id生成的一致性难度太大了（网络延迟、调试出错等等都可能导致不同的机器取到的消息id存在碰撞的可能）。

微信消息序列号实际上是解决消息的唯一性、顺序性问题，可以将一个技术点分解成两个：即将原先每条消息一个自增且唯一的消息ID分拆成两个关键属性——消息ID（msgId）和消息序列号（seqId）。消息ID只要保证唯一性而不需要兼顾顺序性（比如直接用UUID）、消息序列号只要保证顺序性而不需要兼顾唯一性，这样的技术分解就能很好的解决原本一个消息ID既要保证唯一性又要保证顺序性的难题。

那么，如何优雅地解决“消息序列号只要保证顺序性而不需要兼顾唯一性”的问题呢？这就是本文所要分享的内容，强烈建议深入理解和阅读。

2、本文分篇

• 上篇：《微信技术分享：微信的海量IM聊天消息序列号生成实践（算法原理篇）》（☜  本文）
• 下篇：《微信技术分享：微信的海量IM聊天消息序列号生成实践（容灾方案篇）》

本文是“IM消息ID技术专题”系列文章的第1篇，总目录如下：

1. 《IM消息ID技术专题(一)：微信的海量IM聊天消息序列号生成实践（算法原理篇）》（☜  本文）
2. 《IM消息ID技术专题(二)：微信的海量IM聊天消息序列号生成实践（容灾方案篇）》
3. 《IM消息ID技术专题(三)：解密融云IM产品的聊天消息ID生成策略》
4. 《IM消息ID技术专题(四)：深度解密美团的分布式ID生成算法》
5. 《IM消息ID技术专题(五)：开源分布式ID生成器UidGenerator的技术实现》
6. 《IM消息ID技术专题(六)：深度解密滴滴的高性能ID生成器(Tinyid)》
7. 《IM消息ID技术专题(七)：深度解密vivo的自研分布式ID服务(鲁班)》

3、技术背景

微信在立项之初，就已确立了利用数据版本号（注：具体的实现也就是本文要分享的消息序列号）实现终端与后台的数据增量同步机制，确保发消息时消息可靠送达对方手机，避免了大量潜在的家庭纠纷。时至今日，这套同步机制仍然在消息收发、朋友圈通知、好友数据更新等需要数据同步的地方发挥着核心的作用。

而在这同步机制的背后，需要一个高可用、高可靠的消息序列号生成器来产生同步数据用的版本号（注：因为序列号天生的递增特性，完全可以当版本号来使用，但又不仅限于版本号的用途）。这个消息序列号生成器我们微信内部称之为 seqsvr ，目前已经发展为一个每天万亿级调用的重量级系统，其中每次申请序列号平时调用耗时1ms，99.9%的调用耗时小于3ms，服务部署于数百台4核 CPU 服务器上。

本篇将重点介绍微信的消息序列号生成器 seqsvr 的算法原理、架构核心思想，以及 seqsvr 随着业务量快速上涨所做的架构演变（下篇《微信技术分享：微信的海量IM聊天消息序列号生成实践（容灾方案篇）》会着重讨论分布式容灾方案）。

4、关于作者

曾钦松：微信高级工程师，负责过微信基础架构、微信翻译引擎、微信围棋PhoenixGo，致力于高可用高性能后台系统的设计与研发。2011年毕业于西安电子科技大学，早先曾在腾讯搜搜从事检索架构、分布式数据库方面的工作。

5、技术思路

微信服务器端为每一份需要与客户端同步的数据（例如聊天消息）都会赋予一个唯一的、递增的序列号（后文称为 sequence ），作为这份数据的版本号（这是利用了序列号递增的特性）。在客户端与服务器端同步的时候，客户端会带上已经同步下去数据的最大版本号，后台会根据客户端最大版本号与服务器端的最大版本号，计算出需要同步的增量数据，返回给客户端。这样不仅保证了客户端与服务器端的数据同步的可靠性，同时也大幅减少了同步时的冗余数据（就像这篇文章中讨论的一样：《如何保证IM实时消息的“时序性”与“一致性”？》）。

这里不用乐观锁机制来生成版本号，而是使用了一个独立的 seqsvr 来处理序列号操作：

• 1）一方面因为业务有大量的 sequence 查询需求——查询已经分配出去的最后一个 sequence ，而基于 seqsvr 的查询操作可以做到非常轻量级，避免对存储层的大量 IO 查询操作；
• 2）另一方面微信用户的不同种类的数据存在不同的 Key-Value 系统中，使用统一的序列号有助于避免重复开发，同时业务逻辑可以很方便地判断一个用户的各类数据是否有更新。

从 seqsvr 申请的、用作数据版本号的 sequence ，具有两种基本的性质：

• 1）递增的64位整型变量；
• 2）每个用户都有自己独立的64位 sequence 空间。

举个例子，小明当前申请的 sequence 为100，那么他下一次申请的 sequence ，可能为101，也可能是110，总之一定大于之前申请的100。而小红呢，她的 sequence 与小明的 sequence 是独立开的，假如她当前申请到的 sequence 为50，然后期间不管小明申请多少次 sequence 怎么折腾，都不会影响到她下一次申请到的值（很可能是51）。

这里用了每个用户独立的64位 sequence 的体系，而不是用一个全局的64位（或更高位） sequence ，很大原因是全局唯一的 sequence 会有非常严重的申请互斥问题，不容易去实现一个高性能高可靠的架构。对微信业务来说，每个用户独立的64位 sequence 空间已经满足业务要求。

目前 sequence 用在终端与后台的数据同步外，同时也广泛用于微信后台逻辑层的基础数据一致性cache中，大幅减少逻辑层对存储层的访问。虽然一个用于终端——后台数据同步，一个用于后台cache的一致性保证，场景大不相同。

但我们仔细分析就会发现，两个场景都是利用 sequence 可靠递增的性质来实现数据的一致性保证，这就要求我们的 seqsvr 保证分配出去的 sequence 是稳定递增的，一旦出现回退必然导致各种数据错乱、消息消失；另外，这两个场景都非常普遍，我们在使用微信的时候会不知不觉地对应到这两个场景：小明给小红发消息、小红拉黑小明、小明发一条失恋状态的朋友圈，一次简单的分手背后可能申请了无数次 sequence。

微信目前拥有数亿的活跃用户，每时每刻都会有海量 sequence 申请，这对 seqsvr 的设计也是个极大的挑战。那么，既要 sequence 可靠递增，又要能顶住海量的访问，要如何设计 seqsvr 的架构？我们先从 seqsvr 的架构原型说起。

6、具体的技术架构原型

不考虑 seqsvr 的具体架构的话，它应该是一个巨大的64位数组，而我们每一个微信用户，都在这个大数组里独占一格8 bytes 的空间，这个格子就放着用户已经分配出去的最后一个 sequence：cur_seq。每个用户来申请sequence的时候，只需要将用户的cur_seq+=1，保存回数组，并返回给用户。

▲ 图1：小明申请了一个sequence，返回101

6.1 预分配中间层

任何一件看起来很简单的事，在海量的访问量下都会变得不简单。前文提到，seqsvr 需要保证分配出去的sequence 递增（数据可靠），还需要满足海量的访问量（每天接近万亿级别的访问）。满足数据可靠的话，我们很容易想到把数据持久化到硬盘，但是按照目前每秒千万级的访问量（~10^7 QPS），基本没有任何硬盘系统能扛住。

后台架构设计很多时候是一门关于权衡的哲学，针对不同的场景去考虑能不能降低某方面的要求，以换取其它方面的提升。仔细考虑我们的需求，我们只要求递增，并没有要求连续，也就是说出现一大段跳跃是允许的（例如分配出的sequence序列：1,2,3,10,100,101）。

于是我们实现了一个简单优雅的策略：

• 1）内存中储存最近一个分配出去的sequence：cur_seq，以及分配上限：max_seq；
• 2）分配sequence时，将cur_seq++，同时与分配上限max_seq比较：如果cur_seq > max_seq，将分配上限提升一个步长max_seq += step，并持久化max_seq；
• 3）重启时，读出持久化的max_seq，赋值给cur_seq。

▲ 图2：小明、小红、小白都各自申请了一个sequence，但只有小白的max_seq增加了步长100

这样通过增加一个预分配 sequence 的中间层，在保证 sequence 不回退的前提下，大幅地提升了分配 sequence 的性能。实际应用中每次提升的步长为10000，那么持久化的硬盘IO次数从之前~10^7 QPS降低到~10^3 QPS，处于可接受范围。在正常运作时分配出去的sequence是顺序递增的，只有在机器重启后，第一次分配的 sequence 会产生一个比较大的跳跃，跳跃大小取决于步长大小。

6.2 分号段共享存储

请求带来的硬盘IO问题解决了，可以支持服务平稳运行，但该模型还是存在一个问题：重启时要读取大量的max_seq数据加载到内存中。

我们可以简单计算下，以目前 uid（用户唯一ID）上限2^32个、一个 max_seq 8bytes 的空间，数据大小一共为32GB，从硬盘加载需要不少时间。另一方面，出于数据可靠性的考虑，必然需要一个可靠存储系统来保存max_seq数据，重启时通过网络从该可靠存储系统加载数据。如果max_seq数据过大的话，会导致重启时在数据传输花费大量时间，造成一段时间不可服务。

为了解决这个问题，我们引入号段 Section 的概念，uid 相邻的一段用户属于一个号段，而同个号段内的用户共享一个 max_seq，这样大幅减少了max_seq 数据的大小，同时也降低了IO次数。

▲ 图3：小明、小红、小白属于同个Section，他们共用一个max_seq。在每个人都申请一个sequence

的时候，只有小白突破了max_seq上限，需要更新max_seq并持久化

目前 seqsvr 一个 Section 包含10万个 uid，max_seq 数据只有300+KB，为我们实现从可靠存储系统读取max_seq 数据重启打下基础。

6.3 工程实现

工程实现在上面两个策略上做了一些调整，主要是出于数据可靠性及灾难隔离考虑：

1）把存储层和缓存中间层分成两个模块 StoreSvr 及 AllocSvr 。StoreSvr 为存储层，利用了多机 NRW 策略来保证数据持久化后不丢失； AllocSvr 则是缓存中间层，部署于多台机器，每台 AllocSvr 负责若干号段的 sequence 分配，分摊海量的 sequence 申请请求。

2）整个系统又按 uid 范围进行分 Set，每个 Set 都是一个完整的、独立的 StoreSvr+AllocSvr 子系统。分 Set 设计目的是为了做灾难隔离，一个 Set 出现故障只会影响该 Set 内的用户，而不会影响到其它用户。

▲ 图4：原型架构图

7、本篇小结

写到这里把 seqsvr 基本原型讲完了，正是如此简单优雅的模型，可靠、稳定地支撑着微信五年来的高速发展。五年里访问量一倍又一倍地上涨，seqsvr 本身也做过大大小小的重构，但 seqsvr 的分层架构一直没有改变过，并且在可预见的未来里也会一直保持不变。

原型跟生产环境的版本存在一定差距，最主要的差距在于容灾上。像微信的 IM 类应用，对系统可用性非常敏感，而 seqsvr 又处于收发消息、朋友圈等功能的关键路径上，对可用性要求非常高，出现长时间不可服务是分分钟写故障报告的节奏。

本文的下篇《微信技术分享：微信的海量IM聊天消息序列号生成实践（容灾方案篇）》会讲讲 seqsvr 的容灾方案演变。另：《微信团队分享：来看看微信十年前的IM消息收发架构，你做到了吗》一文中提到的利用sequence序列号实现消息防丢机制的原理，也可以一并阅读之。

8、相关资料

[1] 零基础IM开发入门(四)：什么是IM聊天系统的消息时序一致性？

[2] IM消息送达保证机制实现(一)：保证在线实时消息的可靠投递

[3] IM消息送达保证机制实现(二)：保证离线消息的可靠投递

[4] 如何保证IM实时消息的“时序性”与“一致性”？

[5] IM单聊和群聊中的在线状态同步应该用“推”还是“拉”？

[6] IM群聊消息如此复杂，如何保证不丢不重？

[7] 浅谈移动端IM的多点登陆和消息漫游原理

[8] IM群聊消息究竟是存1份(即扩散读)还是存多份(即扩散写)？

[9] 一套亿级用户的IM架构技术干货(下篇)：可靠性、有序性、弱网优化等

[10] 融云技术分享：全面揭秘亿级IM消息的可靠投递机制

[11] 阿里IM技术分享(七)：闲鱼IM的在线、离线聊天数据同步机制优化实践

[12] 转转平台IM系统架构设计与实践(一)：整体架构设计

[13] 如何保障分布式IM聊天系统的消息有序性（即消息不乱）

[14] 微信团队分享：来看看微信十年前的IM消息收发架构，你做到了吗

即时通讯技术学习：

- 移动端IM开发入门文章：《新手入门一篇就够：从零开发移动端IM》

- 开源IM框架源码：https://github.com/JackJiang2011/MobileIMSDK（备用地址点此）

（本文同步发布于：http://www.52im.net/thread-1998-1-1.html）

1、引言

本文介绍了37手游基于B站goim框架自研长连接系统的实践。系统采用分层设计，支持多协议和发布/订阅机制，用于直播弹幕、实时推送等场景，实现了高性能与业务适配。

2、长连接对于大部分公司的意义

实时的响应总是让人兴奋的，就如你在微信里看到对方正在输入，如你在王者峡谷里一呼百应，如你们在直播弹幕里不约而同的 666，它们的背后都离不开长连接技术的加持。

每个互联网公司里几乎都有一套长连接系统，它们被应用在消息提醒、即时通讯、推送、直播弹幕、游戏、共享定位、股票行情等等场景。而当公司发展到一定规模，业务场景变得更复杂后，更有可能是多个业务都需要同时使用长连接系统。

3、长连接是什么?

长连接，在百科上的定义：指在一个连接上可以连续发送多个数据包，在连接保持期间，如果没有数据包发送，需要双方发链路检测包。

严格上来说：长连接是一种概念，它指的是在网络发送，接收双方保持一个持续连接的状态，双方都可以发送或接收消息（全双工）。

当然，长连接系统听起来好像高深莫测，但实际不可能说完全脱离于我们实际公司的业务去出发设计，这就引出来我们今天的主题—— 长连接技术在37手游内是如何设计以及实践的？

4、技术痛点

从服务端而言：缺乏在SDK内实时推送通知用户的能力，如防沉迷的弹窗通过http定时轮询来实现，给服务造成很大的压力

从客户端而言：也缺乏低成本告知服务端自身在线的能力，如维持用户在线状态靠客户端定时上报心跳到防沉迷服务实现。

5、搭建背景

业务背景：手游的SDK需要提供内嵌直播弹幕的功能，供玩家在看直播的时候进行沟通发言，业界一般会用到长连接来进行实时的推送，以降低服务的轮训和请求。

从业务上而言：直播弹幕需求由于初始量级很少，不用通过长连接的形式也能实现具体业务逻辑；但出于平台的拓展和能力考虑，长连接的能力是必须具备的。

长连接系统的这次搭建，本质是通过SDK内嵌直播弹幕为切入点，从0到1，为平台提供了完整的一套实时推送触达用户的能力。

从以上角度出发：我们便着手想要设计一个高可用且高性能的长连接系统提供给我们使用。

6、方案选型

 

从实际上而言，我们考虑三个方向。

1）云服务：

市面上可购买的服务如环信等，大多数都以即时聊天通讯为主，长连接往往只是附带产品，过于偏向于社交业务，在花钱的同时也很难适应到自身游戏业务。

2）开源框架：

b站的goim框架、NettyChat框架、MobileIMSDK框架等，好处是免费且能快速接入，但业务还是不相适应，且语言栈和技术栈不一定相契合。

 

3）自研：

弊：开发成本高，且容易踩坑。利：基础组件完善，统一框架好进行监控和问题查询。且能充分契合自身业务进行拓展，并将数据源掌控在自己手中。

4）结论：

出于扩展性的考虑，肯定是自研的方式更加合适，但完全自研相应的成本和不确定性会非常高，因此最终的选型方案为借鉴b站的goim框架设计和部分代码，并做了符合自身技术栈和业务架构的改善。

可认为是基于开源框架的自研方案的形式完成了长连接这个系统的落地。

7、goim技术概况

7.1 goim是什么？为什么借鉴它？

goim是b站开源研发的一个支持集群的im及实时推送服务。业务上为直播间的弹幕发送场景。

主要考虑到：

• 1）技术栈契合：语言栈为Golang ，消息队列为kafka，缓存设计为redis；
• 2）高性能：有压测报告，性能设计有保障；
• 3）多协议支持：websocket、tcp。

7.2 goim的模块？

如上图所示：

• 1）comet：用于跟端上保连，在内存中存储订阅信息；
• 2）logic：用于处理鉴权，在线房间等业务逻辑；
• 3）business：业务服务；
• 4）balancer：负载均衡模块；
• 5）discovery：服务发现模块；
• 6）job：kafka用于削峰。redis用于缓存房间信息；
• 7）logic和comet的通讯：采用rpc，优化性能。

从上面的goim的设计而言，我们可以总结出长连接的设计原则。

长连接架构的设计总是大同小异的，通用的有这几点：

• 1）业务层次分明：分接入层，逻辑层，存储层，服务发现层；通过这几层，实现业务解耦
• 2）协议通用：传输的数据协议必须在所有服务内进行通讯，并支持扩展
• 3）上行和下行收敛：上行和下行都会有一个对应的网关来进行收敛消息的收敛
• 4）消息削峰：通过队列来将发送信息削峰。并使接入层和逻辑层解藕

8、手游长连接系统的设计实践

根据以上的通用设计原则，我们不难得出，需要针对goim的架构如何做适配才能实际满足我们的业务需求，下面我们将会一一介绍。

8.1 架构改动

从架构而言，我们改动的点不多：

• 1）cient获取连接节点：手游内无统一的服务发现模块，但有外层LB，因此通过LB来实现comet节点负载均衡
• 2）推送消息：同上，消费者获取节点时需要到logic服务中查询，而不是discovery
• 3）服务通讯协议：由于手游内架构通讯协议的统一，接入层和逻辑层的通讯由RPC转为http

8.2 逻辑改动

1）鉴权机制：客户端第一次连接上comet的时候，会发送鉴权上行。comet会解析客户端传输的数据，若包体协议或对应的签名错误，comet会将会直接主动断连

2）心跳机制：comet会有心跳计时器，若客户端无定时上报心跳，则认为该连接已经超时，直接断开。这种业务的心跳主要是为了防止僵尸连接的存在。

3）回包机制：客户端每发送一次上行操作，comet都会有对应的消息回包给端上。端上可根据回包，来知道自己鉴权，心跳，或者订阅，退订的操作是否成功，从而决定是否进行重试。

4）发布/订阅机制：

我们在观看goim的源码时，发现goim适用于直播，群体推送以房间为维度，带有强业务属性，因此我们针对该部分抽象出发布/订阅机制。将房间抽象为topic，修改进房/出房动作为  订阅/退订。

将所有的通知抽象为业务事件，客户端想要接受到哪个事件过来的消息时，可发送对应的订阅上行。单个连接订阅的事件不做限制，对某个用户或某个事件范围内的用户推送消息时，comet会根据事件去取到推送的用户，只有用户订阅了才会收到消息。

5）内存设计：

• a. bucket维护消息通道和事件的信息；
• b. 一个session对应一个用户连接；
• c. 根据sessionid做一致性哈希来选择落到那个bucket上；
• d. bucket有两个map，一个是session map，一个是topic map；
• e. 所有bucket都会开启一个chan做监听，广播的时候，会通知到所有bucket，所有bucket再取出某个事件的所有连接进行下发。

8.3 总体交互

8.4 总体特点

因此，我们可以总结出来，我们手游长连接系统的总体特点：

• 1）纯golang实现；
• 2）多协议支持：websocket和tcp；
• 3）可拓扑结构：主要模块均无状态，可横向扩展；
• 4）消息支持单推/群推，消息协议业务可自定义；
• 5）发布/订阅机制，事件可业务自定义。

9、性能评估

在说性能之前，我们先抛出一个疑问：协程数过多实际占用的是什么？连接数过多是否影响CPU？

从实际上来说：长连接的性能瓶颈一般卡在接入层，因此以接入层为评估维度，通过全链路压测得出来结果。

如下：

• 1）压测参数：3000连接+ 3000 qps的实时推送；
• 2）推送内容：{msg:test}  ；
• 3）推送类型：群推；
• 4）推送持续时长：5分钟 ；
• 5）资源使用：1核2G的容器；
• 6）CPU的使用：达到100%。

目前采用的长连接系统，通过压测结果发现，本身的连接数的维持和实时推送实际影响到是机器两个维度的性能，推送量影响到的是CPU，连接数影响到的是内存。分别提高两个参数对相应的内存，CPU的影响并不大。

10、实际应用情况

直播弹幕：

 

悬浮球实时红点：

从实际上来说，接入的业务虽小，但基础能力已经具备。

11、本文小结

长连接系统从根本上来说，对应的设计都是大同小异的，我们应该更加关注的是对于自身业务的适配以及实现。

12、参考资料

[1] 以网游服务端的网络接入层设计为例，理解实时通信的技术挑战

[2] 知乎千万级并发的高性能长连接网关技术实践

[3] 手淘亿级移动端接入层网关的技术演进之路

[4] 喜马拉雅自研亿级API网关技术实践

[5] 石墨文档单机50万WebSocket长连接架构实践

[6] 小米小爱单机120万长连接接入层的架构演进

[7] B站基于微服务的API网关从0到1的演进之路

[8] 去哪儿网酒店高性能业务网关技术实践

[9] 百度基于Go的千万级统一长连接服务架构实践

[10] 揭秘腾讯公网TGW网关系统的技术架构演进

[11] 基于Netty的携程高性能网关异步改造实践

[12] 手把手教你写基于TCP的Socket长连接

[13] 正确理解IM长连接、心跳及重连机制，并动手实现

[14] 万字长文：手把手教你实现一套高效的IM长连接自适应心跳保活机制

[15] 用JWT技术解决IM系统Socket长连接的身份认证痛点

[16] TCP/IP详解 - 第11章·UDP：用户数据报协议

[17] TCP/IP详解 - 第17章·TCP：传输控制协议

[18] WebSocket从入门到精通，半小时就够！

[19] 快速理解TCP协议一篇就够

[20] 快速理解TCP和UDP的差异

[21] 一泡尿的时间，快速搞懂TCP和UDP的区别

[22] 到底什么是Socket？一文即懂！

[23] 我们在读写Socket时，究竟在读写什么？

[24] 假如你来设计TCP协议，会怎么做？

[25] 深入操作系统，一文搞懂Socket到底是什么

即时通讯技术学习：

- 移动端IM开发入门文章：《新手入门一篇就够：从零开发移动端IM》

- 开源IM框架源码：https://github.com/JackJiang2011/MobileIMSDK（备用地址点此）

（本文同步发布于：http://www.52im.net/thread-4907-1-1.html）

1、关于RainbowChat

RainbowChat是一套基于开源IM即时通讯聊天框架 MobileIMSDK 的产品级移动端IM系统。RainbowChat源于真实运营的产品，解决了大量的屏幕适配、细节优化、机器兼容问题。RainbowChat可能是市面上提供im即时通讯聊天源码的，唯一一款同时支持TCP、UDP、WebSocket三种通信协议的IM产品。与姊妹产品 RainbowTalk 和 RainbowChat-Web 技术同源，历经考验。

• ☞ 详细介绍：http://www.52im.net/thread-19-1-1.html
• ☞ 版本日志：http://www.52im.net/thread-2735-1-1.html
• ☞ 运行截图：Android端、iOS端
• ☞ 下载体验：App Store安装地址 （另：Android端下载体验 点此查看）

2、关于MobileIMSDK开源工程

工程同步开源地址：

• ❶ GitHub：https://github.com/JackJiang2011/MobileIMSDK
• ❷ 码云gitee： https://gitee.com/jackjiang/MobileIMSDK
• ❸ Gitcode：https://gitcode.com/hellojackjiang2011/MobileIMSDK

2、v12.0 版更新内容

此版更新内容（更多历史更新日志）：

（1）Android端主要更新内容【全面适配Android 16、适配16KB page size、适配全面屏特性等】：

• 1）[bug] 解决了两个表情占位符重复的问题；
• 2）[bug] 解决了好友列表删除唯一好友后，一直转圈的问题；
• 3）[bug] 优化了搜索聊天记录时，当首页“消息”中不存在该陌生人时，搜出的群聊详细中消息发送者昵称会用uid显示的问题；
• 4）[bug] 解决了不支持分区存储的老手机转发的大文件消息，在新系统上无法下载的问题；
• 5）[bug] 优化了存在多条置顶消息时，不是按置顶时间而是消息时间排序的问题；
• 6）[新增] 二维码生成界面下方增加功能按钮；
• 7）[新增] “用户信息”界面增加了“查看用户资料”按钮；
• 8）[新增] 优化了世界频道的打开入口等；
• 9）[新增] 去掉了“商城”模块，增加了“发现”页面；
• 10）[优化] 将核心层提炼成独立的chatkit模块；
• 11）[优化] 解决了独立chatkit后，好友信息中删除对方时，无法自动跳转到主页的问题；
• 12）[优化] 现在不能删除首页列表中的“确认提醒”这个item了；
• 13）[优化] 升级腾讯Bugly至4.1.9.3，解决上架国内应用市场的隐私合规问题；
• 14）[优化] 登录和退出登录接口中废弃了osType字段；
• 15）[优化] 优化了注册界面中关于服务端返回邮箱格式不正确的错误码的处理；
• 16）[优化] 支持小窗、分屏显示；
• 17）[优化] 只有好友才能查看对方的注册和登录时间；
• 18）[优化] 查找好友时不再显示对方的在线状态；
• 19）[优化] 提升targetSdkVersion至36，全面兼容Android 16；
• 20）[优化] 开发工程升级适配AGP 9.1最新版；
• 21）[优化] 升级权限框架以适配最新Android 16系统；
• 22）[优化] 针对全部界面适配系统强制的Edge to Edge全面屏特性；
• 23）[优化] 解决了Android 16下聊天界面输入法弹出时会挡住消息输入框的问题；
• 24）[优化] 解决基于PopupWindow实现的弹出界面底部在Edge to Edge全面屏特性下的显示问题；
• 25）[优化] 加固一处因多线程安全问题导致的可能崩溃风险；
• 26）[优化] 升级高德地图SDK至最新v11.1等，适配google play强制16KB page size问题；
• 27）[优化] 优化了位置消息搜索界面的搜索组件ui并提升了细节体验；
• 28）[优化] 解决了进入了主页搜索界面在Android 16下不能自动弹出输入法，及优化了点击背景可收起软键盘；
• 29）[优化] 删减了APP首次启动时的权限申请内容；
• 30）[优化] 解决了Android 16下返回按钮事件捕获失败的问题；
• 31）[优化] 聊天界面下方的功能面板图标美化等；
• 32）[优化] 聊天文本框自动换行；
• 33）[优化] 其它更具现代感的UI细节优化和体验等；

（2）服务端主要更新内容【安全加固、新增接口等】：

• 1）[bug] 解决了对接RainbowChat-Web产品时，网页端无法正常登录的问题；
• 2）[优化] 加固了后端SQL防注入逻辑；
• 3）[优化] 开启了WebSocket协议支持；
• 4）[优化] 对离线数据表中的消息指纹字段增加了索引，提升查询性能；
• 5）[优化] 优化了文件下载服务中存在利用文件名进行越权文件操作的安全隐患；
• 6）[优化] 提供了一个校验token与uid一致性的安全性实现示例；
• 7）[优化] 优化了原Android专用的登录接口【接口1009】，使之同时支持验证码、密码登录；
• 8）[优化] 【接口1008-10-22】新增了“preview_count”字段；
• 9）[优化] 将IDEA工程中applicationContextRoot改成了rainbowchat_pro/（方便开发环境跟生产环境一致）;
• 10）[优化] 优化了注册接口【接口1008-1-7】，增加了手机号和短信验证码支持；
• 11）[新增] 数据库新增了注销登录相关字段；
• 12）[新增] 新增注销登录接口；
• 13）[新增] 新增获取验证码接口【接口1008-1-27】；
• 14）[新增] 新增新的登录接口【接口1017】，同时支持ios等客户端的验证码、密码登录；
• 15）[新增] 新增对接鸿蒙NEXT产品时支持华为Push Kit离线推送；

3、升级后的主要UI运行截图

（☞ 更多截图请查看：Android端运行截图、iOS端运行截图）

4、真机运行视频

（☞ 新窗口中查看真机运行视频）

5、真机实拍截图