语源科技BlogJava-首页技术区

socket长连接在手游场景下的技术实践

Jack Jiang — Wed, 06 May 2026 14:27:00 GMT

本文由37手游黄子键分享，有排版和内容优化等。

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）

Jack Jiang 2026-05-06 22:27 发表评论

基于开源MobileIMSDK框架，即时通讯IM产品RainbowChat v12.0已发布

Jack Jiang — Mon, 27 Apr 2026 09:22:00 GMT

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开源工程

MobileIMSDK 是一套全平台开源IM即时通讯聊天框架，超轻量级、高度提炼，一套API优雅支持UDP 、TCP 、WebSocket 三种协议，客户端支持iOS、Android、H5、小程序、Uniapp、标准Java、纯血鸿蒙等，服务端基于Netty编写，性能卓越、易于扩展。

工程同步开源地址：

❶ 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、真机实拍截图

Jack Jiang 2026-04-27 17:22 发表评论

社交场景下的统一即时通讯im消息流交互层模块化技术实践

Jack Jiang — Mon, 20 Apr 2026 10:43:00 GMT

网易技术团队旭风分享，有排版优化和修订。

1、引言

一款社交产品的诞生，离不开即时通讯（IM）场景。随着团队业务版图在社交领域的布局，诞生了多个社交场景APP，涉及的IM场景，包含私聊、群聊、聊天室等。

这些IM场景，在消息流的展示形式上是极为相似的，同时每个业务又有着自己特殊的交互需求。基于此，我们对IM消息流能力做了标准化的构建，来减少IM功能的业务接入成本；同时也是为了统一各个业务的技术方案，减少跨业务开发的理解和维护成本。本文主要针对iOS端在IM消息流交互层的设计上，提供一些实践思路。

2、业界的实现方案

目前业界有各种即时通讯服务商提供的配套交互层解决方案，其大多以牺牲灵活性来满足快速集成需要，在定制能力上远不能胜任我们业务需要。

再诸如 MessageKit之类的社区IM框架，其在视觉交互表现上功能完备，能帮助我们快速、灵活搭建IM消息流结构，但业务需要的是一套完整的携带消息交互能力的方案，因此对此类框架，仍需要做不小的改造才能适应我们的业务（另一参考方案：MobileIMSDK（Gitee源码托管地址））。

3、我们的想法

对于一个IM消息流交互层方案，主要考虑几个方面：

1）规范的消息流结构：提供消息流视图结构规范化的构建方式；
2）标准的消息交互能力：统一消息交互能力，业务方按需使用，快速集成；
3）业务拓展性：针对数据源、消息交互能力提供业务灵活拓展点；
4）业务接入成本：内置通用交互方案，降低业务接入成本。

目前，我们存量业务中的IM场景，底层IM能力主要由云信引擎提供。同时又存在基于业务服务端，通过HTTP去交互的场景。

另外，还需要预留后期切换IM引擎的可能性，因此需要将交互层IM能力抽象出来。

此外，为了适应团队现状，减小业务接入成本，考虑将云信提供的交互能力内置在方案中。

4、整体设计

设计愿景：提供标准化的能力，同时对拓展开放。

我们期望一套通用的IM消息流能力，能够在方案上标准化。这里的标准化，主要包含消息流结构构建的标准化，以及消息交互能力的标准化。同时，方案需要在交互能力上适应不同业务场景，因此采用依赖注入的方式，提供业务定制能力。

按照职能划分，将框架整体分为了两层：

1）消息流结构层：负责消息流结构的构建，定义消息视图、布局、数据上的规范，提供业务层分别在「消息」、「会话」两个维度的配置能力。

2）消息交互层：提供消息能力、消息流、消息数据方面的交互能力，向下依赖交互接口，内置标准交互能力的同时，也支持业务按需注入交互实现。

5、聊天消息流的显示结构

5.1 消息组件

不同的业务场景，消息流样式表现必然有所差异。

下面列出了我们几个业务中的消息流界面：

如何设计一套通用的消息流视图结构，满足不同业务需要？经过对各个业务以及一些主流IM工具的观察，将消息视图结构设计成如下结构，是能够满足我们各个IM场景需要的（见下图）。

我将消息结构拆分成了5部分，对应5个消息组件 MessageView ，每个消息组件都支持业务对其「样式」、「显隐」、「布局」进行配置，从而满足不同场景定制需要。

MessageView作为基础消息组件，提供了一些标准能力，例如是否响应菜单动作 canPerformMenuAction 、视图重用回调时机 prepareForReuse 、尺寸策略等。
open class MessageView: MessageAbstractView {
  public var canPerformMenuAction = false
    open func refresh(with message: Message) {}
    open func prepareForReuse() {}
    open class func createSizeStrategy(message: Message, fittingSize: CGSize) -> MessageLayoutSizeStrategy? {
    // ...
    }
}

5.2 尺寸策略

消息组件尺寸作为消息流布局上不可或缺的要素，方案提供了多种尺寸计算策略 MessageLayoutSizeStrategy 。

具体是：

1）自动布局计算策略：业务方对消息组件使用 AutoLayout 布局时使用，内部会依据约束自动计算好组件尺寸；
2）SizeThatFit 策略：依据组件 SizeThatFit 方法返回的尺寸进行布局；
3）自定义策略：提供自定义尺寸计算方式。

public protocol MessageLayoutSizeStrategy {
    func caclulateSize(_ sizeViewType: MessageView.Type,
                       message: Message,
                       fittingSize: CGSize) -> CGSize
}

public struct MessageAutoLayoutSizeStrategy: MessageLayoutSizeStrategy {
    public func caclulateSize(_ sizeViewType: MessageView.Type,
                              message: Message,
                              fittingSize: CGSize) -> CGSize {
    // ...省略其他代码
        return sizeView.systemLayoutSizeFitting(UIView.layoutFittingCompressedSize)
    }

}

public struct MessageSizeThatFitsStrategy: MessageLayoutSizeStrategy {
    public func caclulateSize(_ sizeViewType: MessageView.Type,
                              message: Message,
                              fittingSize: CGSize) -> CGSize {
        // ...省略其他代码
        return sizeView.sizeThatFits(fittingSize)
    }
}

5.3 布局快照

我们还针对消息组件维度支持了布局快照。通常当一个消息组件尺寸固定，在交互过程中尺寸不会发生的情况下，打开布局快照，以减少布局计算消耗。同时也提供了快照清除的能力。

我们对多个消息流在快速滚动过程中的CPU峰值做了统计，在使用自动布局尺寸策略的情况下，开启布局快照，峰值降低了10%~20%。

5.4 交互事件

另外在手势交互上，对外暴露了各个消息组件的一系列交互事件。常见的场景例如单击浏览消息内容，长按展示消息菜单等。

方案内部提供了基于系统样式的长按菜单，并提供上层菜单配置能力，同时也可以基于暴露的长按手势事件来自定义菜单。

5.5 消息流

一个会话对应一个流，方案也提供了消息流在会话维度上的一些标准化配置。例如消息分页数量、是否自动拉取历史消息、是否开启增量刷新，以及在时间展示上的样式配置等。

此外为了减少列表重绘，消息流也支持增量刷新。通常情况下业务层不需要主动刷新列表，只需对消息数据进行增删改操作，内部会触发对数据源的「diff-update」计算，从而驱动列表的增量更新。

6、聊天消息交互层

6.1 概述

对于业务方而言，在消息交互上通常关心这么几点：

1）提供了哪些标准化的交互能力；
2）如何拓展自定义的交互实现；
3）如何对交互流程进行干预。

结合团队现状，我们在方案内部内置了基于某信的IM交互能力，同时定义了相关交互接口，供业务方按需注入实现。

在实际业务中，一个APP内可能存在多个IM场景，因此交互能力支持按会话维度进行注入，各个会话之间的交互是相互隔离的。

6.2 消息源

不同的IM场景，消息数据来源可能存在差异。例如我们私聊、群聊的数据源来自云信数据同步服务，聊天室数据需要通过云信提供的历史消息接口拉取，另外也存在诸如通过业务服务端接口来拉取消息数据的场景。

因此方案上设置了数据源接口 SessionMessageProvider ，提供不同场景消息源的定制能力。

public protocol SessionMessageProvider {
    func messages(in session: Session,
                  anchorMessage: Message?,
                  limit: Int,
                  completion: @escaping ([Message]) -> Void)
}

方案设置了一个负责管理消息数据源的 DataManager 实例，其依赖 SessionMessageProvider 提供的数据源。同时内置了基于云信的数据源获取实现，能够根据当前会话类型，获取私聊、群聊、聊天室的数据源。

如果当前场景是通过HTTP拉取消息的，则需要业务上层手动注入一个从接口获取数据源的 SessionMessageProvider 实例。

6.3 交互源

方案提供了IM标准交互能力，例如消息收发、消息撤回、保存等，以统一各业务交互姿势。

具体的交互源除了要考虑目前包含的云信及业务服务端，也要适应其他交互源，因此将交互实现部分也抽象出了接口 MessageServiceInterface 。业务根据当前实际场景，注入具体的交互实现即可。

下面列出了一些交互申明：

public protocol MessageServiceInterface {
    func send(message: Message, in session: Session, completion: @escaping MessageServiceInterfaceCompletion)
    func resend(message: Message, completion: @escaping MessageServiceInterfaceCompletion)
    func forward(message: Message, to session: Session, completion: @escaping MessageServiceInterfaceCompletion)
    func revoke(message: Message, completion: @escaping MessageServiceInterfaceCompletion)
    func save(message: Message, in session: Session, completion: @escaping MessageServiceInterfaceCompletion)
    func delete(message: Message, completion: @escaping MessageServiceInterfaceCompletion)
}

同样，我们也内置了一些通用交互方案，例如支持云信提供的私聊群聊交互能力，以及由中台提供的通用聊天室服务交互能力，以支持相关场景下快速接入。

6.4 交互钩子

在实际IM业务开发过程中，往往需要对交互流程做一些干预，或是在交互过程中做一些定制化的动作。因此方案也提供了一些交互钩子，支持「交互前置校验」、「交互前准备」。

以消息发送流程为例，提供了「发送前校验」、「发送准备」两个消息发送过程的回调钩子：

public protocol MessageServicePrechecker {
   // 消息发送前置校验
    func shouldSend(message: Message, in session: Session) -> Bool

    // ...省略其他代码
}

public protocol MessageServicePreparation {
    /// 准备发送准备
    func prepareSend(message: Message, in session: Session, callback: @escaping MessageServicePreparationCallback)

    // ...省略其他代码
}

整体的发送流程如图所示：

前置校验阶段，用来作消息发送前的校验工作，根据实际状态决定消息是否可以发送。发送准备阶段，则可以在消息投递前做最后的准备工作，例如海外业务可以在这里处理消息资源附件上传Amazon，或是在此处对消息塞入一些客户端信息、反作弊Token等，支持异步操作。