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

⭐️ 一款社交产品的诞生，离不开即时通讯（IM）场景。这些IM场景，在消息流的展示形式上是极为相似的，同时每个业务又有着自己特殊的交互需求。基于此，我们对IM消息流能力做了标准化的构建，来减少IM功能的业务接入成本；同时也是为了统一各个业务的技术方案，减少跨业务开发的理解和维护成本。 1️⃣ 业界的实现方案 目前业界有各种即时通讯服务商提供的配套交互层解决方案，其大多以牺牲灵活性来满足快速集成需要，在定制能力上远不能胜任我们业务需要。 2️⃣ 我们的想法 对于一个IM消息流交互层方案，主要考虑这几个方面：规范的消息流结构、标准的消息交互能力、业务拓展性、业务接入成本。 3️⃣ 整体设计 我们期望一套通用的IM消息流能力，能够在方案上标准化。这里的标准化，主要包含消息流结构构建的标准化，以及消息交互能力的标准化。同时，方案需要在交互能力上适应不同业务场景，因此采用依赖注入的方式，提供业务定制能力。按照职能划分，将框架整体分为了两层：消息流结构层和消息交互层。 4️⃣ 聊天消息流的显示结构 不同的业务场景，消息流样式表现必然有所差异。如何设计一套通用的消息流视图结构，满足不同业务需要？经过对各个业务以及一些主流IM工具的观察，将消息视图结构设计成如下结构，是能够满足我们各个IM场景需要的. 5️⃣ 聊天消息交互层 对于业务方而言，在消息交互上通常关心这么几点： 1）提供了哪些标准化的交互能力； 2）如何拓展自定义的交互实现； 3）如何对交互流程进行干预。 结合团队现状，我们在方案内部内置了基于某信的IM交互能力，同时定义了相关交互接口，供业务方按需注入实现。在实际业务中，一个APP内可能存在多个IM场景，因此交互能力支持按会话维度进行注入，各个会话之间的交互是相互隔离的。 6️⃣ 业务接入能力 业务只需要在上层提供针对消息以及会话两个维度的配置，就能基于内置的交互能力，构建出一套基础的IM消息流能力。在具体的消息样式呈现上，则通常需要业务层维护一组关于「消息类型-消息组件类型-消息结构」的映射关系。 （👉️ 全文阅读：http://52im.net/thread-4905-1-1.html） 8️⃣ 延伸阅读 什么是IM聊天系统？👉️ 52im.net/thread-3065-1-1.html 新手入门一篇就够：从零开发移动端IM👉️ 52im.net/thread-464-1-1.html 全面揭秘亿级IM消息的可靠投递机制👉️ 52im.net/thread-3638-1-1.html 一套分布式IM即时通讯系统的技术选型和架构设计👉️ 52im.net/thread-4564-1-1.html B站IM消息系统的新架构升级实践👉️ 52im.net/thread-4886-1-1.html 通俗易懂，理解移动网络的“弱”和“慢”👉️ 52im.net/thread-1587-1-1.html 马蜂窝旅游网的IM系统架构演进之路👉️ 52im.net/thread-2675-1-1.html