共计 4765 个字符，预计需要花费 12 分钟才能阅读完成。
IM 即时通讯技术的倒退
即时通讯（Instant Messaging）是一种基于互联网的即时交换音讯的业务。
实时聊天交互性能是市面上支流 APP 的重要性能之一，人们所相熟的就是微信，QQ 的聊天音讯零碎，IM 看似简略，技术开发绝非易事，海量并发，超低延时，音讯必达等高实时性需要须要泛滥技术的利用合体；
近几年，随着挪动互联网的深刻浸透和社交 + 的迅速倒退，IM 衍生出了很多新的玩法，不仅仅利用于社交聊天场景，还呈现在电商、直播、客服等各种场景，正在被人们宽泛的利用。
调研数据显示：市面上 60% 以上的 APP 领有即时通讯能力，用户能够间接在 app 内跟其余用户实时聊天，有助于晋升 app 沉闷和用户体验。IM 性能的实现已成为利用开发者们必修课程。
笔者从事 IM 开发工作十年无余，本文次要分享 IM 开发的 3 种实现形式，心愿对 IM 开发者有所帮忙。
IM 即时通讯 3 种实现形式
IM 开发的 3 种实现形式别离为：1、开源代码 2、自研 3、集成 IM SDK。开发者可依据我的项目状况进行抉择。
一个 IM 产品的落地，大体上能够分成三个重要局部：客户端开发，服务端开发，服务运维。
- 客户端开发：包含各平台的手机 app、桌面软件，网页端，小程序端等。
- 服务端开发：负责 IM 各种性能的实现，比方用户接入、关系链保护、收发音讯、文件图片存储、平安审核等。
- 服务运维：一个长期经营的产品，必然须要一个持续性的运维过程，以保障 IM 服务端稳固牢靠，比方业务量上涨的扩容解决。以上三局部，任何一部分从零到一的实现，都会有不小的难度，齐全自研对我的项目成员能力，以及资源投入的要求都比拟高。除了大型公司会齐全自研以外，个别都会采取援用开源代码，或者集成商业 IM SDK 的形式。上面总结一下这 3 种实现形式的区别。
表：IM3 种实现形式
| \ 实现形式 比照维度 | 开源代码 | 自研 | 集成商业 IM SDK |
|---|---|---|---|
| 实现难度 | 低 | 高 | 中 |
| 性能扩展性 | 依赖开源我的项目打算，绝对艰难 | 不依赖内部条件，绝对简略 | 依赖其它厂商，难度中等 |
| 运维老本 | 本人运维，老本高 | 本人运维，老本高 | 不须要本人运维 |
| 上线周期 | 中 | 慢 | 快 |
| 适用人群 | 集体体验 | 研发能力较强的大公司 | 中小型公司，集体工作室 |
第一种实现形式：应用开源我的项目实现 IM 聊天
实现 IM 性能最快的形式就是抉择开源我的项目，不仅是站在伟人的肩膀上，还可会集全社区的智慧进行疾速开发；
如何抉择 IM 的开源我的项目？我的项目性能的欠缺度和活跃度是次要参考的维度，依据过往教训我选取了两个还算不错的开源我的项目供大家参考。
1.MobileIMSDK
我的项目地址：https://github.com/JackJiang2…
MobileIMSDK 是一个原创挪动端 IM 通信层框架，轻量级、高度提炼，历经 8 年、久经考验。是市面上惟一同时反对 UDP+TCP+WebSocket 三种协定的同类开源框架，反对 iOS、Android、Java、H5，服务端基于 Netty。
PS: 须要留神的是该项目标 H5 端暂未开源，小程序与 Uniapp 也还在开发之中。
2.OpenIM
我的项目地址：https://github.com/OpenIMSDK/…
OpenIM 的开创团队来自 IM 高级架构师，由 IM/WebRTC 专家团队开发，致力于用开源技术发明服务价值，打造轻量级、高可用的 IM 架构，不便开发者构建多种即时通讯及实时音视频互动场景。
借鉴开源我的项目适宜开发周期紧，无需太多定制化开发者，可帮忙开发者疾速实现 IM 性能。但性能个别绝对简略根底，且后续的性能扩大重大依赖开源我的项目的开发进度。如果对定制化性能需要比拟高，或者将来业务体量比拟大，倡议不要偷懒去应用这种形式。
对 IM 定制化要求高有研发能力的团队个别采取自研的形式，接下来会跟大家分享下自研过程中的技术难点和坑点。
第二种实现形式：自研实现 IM 聊天
IM 技术波及范畴很广，齐全自研对研发团队能力、资金投入要求都比拟高，研发周期也会拉的比拟长。为了避免错失商机，须要做好长期的布局。
如图：自研技术概览
咱们在自研 IM 过程中，也遇到了一些比拟辣手的技术难题，这里列出来给大家做个参考，比方
- 音讯的可靠性、有序性。
- 高并发场景下的音讯实时推送，以及音讯拉取。
- 音讯存储计划选型：应用读扩散还是写扩散。
- 音讯未读数的精确计算。
- 群回执音讯。
- 异地多活。
对这些问题感兴趣，也能够参考优良 IM 学习网站（即时通讯网：http://www.52im.net/）。
自研过程中，有些性能也能够间接应用市面上的成熟产品，比方 文件存储，平安审核，音讯离线推送。以放慢研发步调。将来如果决定自研这部分性能，也能够很不便的替换掉，达到事倍功半的成果。
对于有经济和开发实力的企业，且业务预期客户体量大，倡议走自研的实现形式，合乎前期能力拓展、疾速迭代和稳固运维的布局。
但自研须要投入较大的人力、财力，倡议想要走自研的开发者，做好明确的开发布局，缩小不必要的损耗。
引入开源我的项目，无奈很好的扩大新性能，且运维简单，难以撑持将来的长期倒退；自研路线周期长，老本较高。
那有没有折中一点的计划呢？既能够疾速上线，又不必投入那么大的老本，还能够定制化需要。集成商业 sdk 则是最便捷的形式，这也是目前较支流的开发模式。当初 sdk 厂商都很成熟，很多公司会抉择此形式。
第三种实现形式：集成商业 IM SDK 实现 IM 即时通讯
集成商业 sdk 具备以下劣势：
- 疾速落地 IM 产品，疾速上线，抢占市场。
- 服务稳固，防止烦杂的运维工作。
- 性能可扩大：减少新性能时，能够被动向 sdk 厂商提需要实现。
- 相比自研，大幅降低成本。##
IM 即时通讯产品落地流程
抉择集成商业 sdk 时，产品落地流程如下：
- 申请 sdk 厂商服务账号，获取账号秘钥，用于用户登录。
- 开发业务服务后盾，用于计算登录鉴权信息。
- 集成厂商 sdk，开发应用程序（比方 iOS 利用、Android 利用、小程序等）。以收发音讯为例，各模块之间的交互流程如下：
由此可见，集成商业 sdk 的计划，只须要开发一个简略的业务后盾，而后集成 sdk，开发本人的应用程序，即可疾速上线服务。
IM SDK 厂商举荐 - 即构 IM SDK
以后市面上曾经有不少成熟的 IM SDK 厂商，在这里举荐一家不错的厂商 – 即构科技（https://doc-zh.zego.im/article/11598）。之前开发的直播产品接了即构的 RTC SDK，整个接入过程很顺畅，近期因我的项目需实现即时通讯性能，同一厂商图不便抱着尝试态度接入 ZEGO IM SDK，没想到很快就实现开发实现了。
ZIM 反对所有支流平台，包含 flutter 和 uniapp 两大跨平台框架，减速产品上线。在音讯平安审核方面，他们采纳支流第三方平安厂商的服务，须要的审核性能根本都可能反对。
实时通信的我的项目随着业务一直倒退，对通信服务的高可用 / 高并发 / 低延时有更高的要求。之前应用他们的 RTC 产品，低提早业内当先体现很优良。IM 产品我拿集成的 Demo 测试了下，端到端延只有几十毫秒。
即构的 IM 产品不仅反对根底的单聊 / 群聊性能，还反对音讯高并发量的房间聊天，官网数据显示：单房间人数反对到百万以上，适宜对房间人数要求高的场景应用。另外还有很新鲜的呼叫邀请性能，满足即时通讯的需要。
教训分享：基于即构 ZIM 实现即时通讯性能
应我的项目需要笔者选用 ZIM 实现单聊场景音讯收发，仅有简略 2 步整个过程半天搞定。以下以自己的教训分享如何疾速实现单聊场景音讯收发。集成 sdk 过程感兴趣的小伙伴到即构官网查看（https://doc-zh.zego.im/article/11598），在此不赘述。
IM 的应用场景中比拟常见的是点对点音讯，这里咱们以安卓端收发文本音讯为例。
3 步轻松实现即时通讯音讯收发
1、初始化 IM SDK
取得一个 ZIM 实例
zim = ZIM.create(appID, application);2、登录 ZIM
类比微信账号登录的操作，用来作为收发音讯的载体
void login(ZIMUserInfo userInfo,String token,ZIMLoggedInCallback callback)对应 UI 示例：
3、发送端调用发送单聊文本音讯
登录后便可调用该接口，在 message 填上想要发送的音讯，在 toUserID 填上接收端的 userID，想要发送时调用即可
接口展现：
void sendPeerMessage(ZIMMessage message,String toUserID,ZIMMessageSendConfigconfig,ZIMMessageSentCallback callback)对应 UI 示例：
4、IM 接收端收音讯
(1) 通过 setEventHandler 注册事件回调的接管对象
IM 运行过程中会有各式各样的事件产生：收到了一条音讯、网络连接中断等，通过该接口便能够接管 ZIM 抛出的事件，以便 App 做出相应的反馈。
void setEventHandler(ZIMEventHandler handler)(2) 在注册事件回调的接管对象中重写接管单聊音讯的办法
zim.setEventHandler(new ZIMEventHandler() {
@Override
public void onReceivePeerMessage(ZIM zim, ArrayList<ZIMMessage> messageList, String fromUserID) {}});对应 UI 示例
由此咱们实现了点对点文本音讯的收发。
By the way，ZIM SDK 也反对富媒体音讯的收发，包含图片、视频、音频和文件。发送富媒体音讯时只须要将文件的 path 传入接口，上传进度可从 progress 回调中取得。
5、多样化音讯收发：发送富媒体音讯
void sendMediaMessage(ZIMMediaMessage message,String toConversationID,ZIMConversationType conversationType,ZIMMessageSendConfigconfig,ZIMMessageSentCallback callback)UI 示例，以发送图片为例，从相册读取图片并压缩保留到 APP 目录下，将本地图片的 path 传入 ZIMImageMessage, 并调用 sendMediaMessage,UI 上做对应展现即可。
一旦点对点音讯和群聊音讯首次被发送，对应的会话随即产生。
咱们晓得 UI 的更新都是由数据驱动的。驱动此处 UI 变动的，是 ZIMEventHandler 抛出的会话更新事件回调，应用层只须要保护一份会话列表, 在此事件抛出时及时更新列表，并驱动 UI 刷新即可。
会话更新接口
void onConversationChanged(ZIM zim,ArrayList<ZIMConversationChangeInfo> conversationChangeInfoList)结语：即构 IM SDK 联合 RTC SDK 实现音视频 / 直播实时聊天
此外 ZIM SDK 还反对房间、群组的用法，无需去二次封装，绘制相干 UI 并应用 SDK 接口提供的数据驱动即可实现对应性能。此处不再开展叙述，感兴趣的笔者之后会更新相干的文章，或者去 ZEGO 官网去查看相干文档：https://doc-zh.zego.im/article/14314?
同时 ZIM SDK 联合即构自家的 RTC SDK 实现各类音视频场景的用户互动，适宜 Avatar , 直播，语聊房等场景的开发者和有需要企业。
近期有开发布局的开发者可上即构官网查看，恰逢即构七周年全线音视频 / 直播产品 1 折的优惠，适宜有估算要求的中小型企业和集体开发工作室。
笔者为大家争取到小福利：提交表单有业余销售分割您，可取得即构 IM SDK 1 个月收费试用。
填写支付：https://www.zego.im/cluesColl…
