为了更好地分类阅读 52im.net 总计1000多篇精编文章，我将在每周三推送新的一期技术文集，本次是第 43 期。

[-1-] 直播系统聊天技术(一)：百万在线的美拍直播弹幕系统的实时推送技术实践之路

[链接] http://www.52im.net/thread-1236-1-1.html

[摘要] 直播弹幕指直播间的用户，礼物，评论，点赞等消息，是直播间交互的重要手段。美拍直播弹幕系统从 2015 年 11 月到现在，经过了三个阶段的演进，目前能支撑百万用户同时在线。比较好地诠释了根据项目的发展阶段进行平衡演进的过程。这三个阶段分别是快速上线、高可用保障体系建设、长连接演进。具体我将在正文中展开，请继续往下阅读。

[-2-] 直播系统聊天技术(二)：阿里电商IM消息平台，在群聊、直播场景下的技术实践

[链接] http://www.52im.net/thread-3252-1-1.html

[摘要] 本文来自淘宝消息业务团队的技术实践分享，分析了电商IM消息平台在非传统IM应用场景下的高发并、强互动群聊和直播业务中的技术特点，总结并分享了在这些场景下实现大量多对多实时消息分发投递的一些架构方面的设计实践。

[-3-] 直播系统聊天技术(三)：微信直播聊天室单房间1500万在线的消息架构演进之路

[链接] http://www.52im.net/thread-3376-1-1.html

[摘要] 本文将回顾微信直播聊天室单房间海量用户同时在线的消息组件技术设计和架构演进，希望能为你的直播聊天互动中的实时聊天消息架构设计带来启发。

[-4-] 直播系统聊天技术(四)：百度直播的海量用户实时消息系统架构演进实践

[链接] http://www.52im.net/thread-3515-1-1.html

[摘要] 本文主要分享的是百度直播的消息系统的架构设计实践和演进过程。

[-5-] 直播系统聊天技术(五)：微信小游戏直播在Android端的跨进程渲染推流实践

[链接] http://www.52im.net/thread-3594-1-1.html

[摘要] 微信小游戏出于性能和安全等一系列考虑，运行在一个独立的进程中，在该环境中不会初始化视频号直播相关的模块。这就意味着小游戏的音视频数据必须跨进程传输到主进程进行推流，给我们实现小游戏直播带来了一系列挑战。

[-6-] 直播系统聊天技术(六)：百万人在线的直播间实时聊天消息分发技术实践

[链接] http://www.52im.net/thread-3799-1-1.html

[摘要] 本文将基于融云在直播技术实践的背景，分享了单直播间百万用户在线量的实时消息分发的技术经验总结，希望带给你启发。

[-7-] 直播系统聊天技术(七)：直播间海量聊天消息的架构设计难点实践

[链接] http://www.52im.net/thread-3835-1-1.html

[摘要] 本文将主要从高可用、弹性扩缩容、用户管理、消息分发、客户端优化等角度，分享直播间海量聊天消息的架构设计技术难点的实践经验。

[-8-] 视频直播技术干货(十一)：超低延时视频直播技术的演进之路

[链接] http://www.52im.net/thread-4587-1-1.html

[摘要] 本文将带您了解超低延时视频直播技术的优化和演进历程。

[-9 -]  视频直播技术干货(十二)：从入门到放弃，快速学习Android端直播技术

[链接] http://www.52im.net/thread-4714-1-1.html

[摘要] 本文详细介绍了Android端直播技术的全貌，涵盖了从实时音视频采集、编码、传输到解码与播放的各个环节。文章还探讨了直播中音视频同步、编解码器选择、传输协议以及直播延迟优化等关键问题。希望本文能为你提供有关Andriod端直播技术的深入理解和实践指导。

[-10-] 海量实时消息的视频直播系统架构演进之路(视频+PPT)[附件下载]

[链接] http://www.52im.net/thread-1562-1-1.html

[摘要] 本次主要分享的是融云视频直播互动平台的实时消息可靠性的设计方案,支撑无上限消息并发的架构演进,单机吞吐性能的优化历程。

[-11 -] YY直播在移动弱网环境下的深度优化实践分享(视频+PPT)[附件下载]

[链接] http://www.52im.net/thread-1379-1-1.html

[摘要] 本次分享介绍了 YY 直播针对质量较差网络（简称弱网）的环境，基于数据分析，在客户端和云端所采取的一系列技术手段。 同时，就如何改善上下行网络环境，也给出自己的一些解决方案。

[-12 -] 从0到1：万人在线的实时音视频直播技术实践分享(视频+PPT) [附件下载]

[链接] http://www.52im.net/thread-213-1-1.html

[摘要] 本次分享由“跟谁学”CTO带来，介绍跟谁学的团队是怎样在很短的时间内，构建了一个支持万人实时音视频直播的在线教室。

[-13 -] 在线音视频直播室服务端架构最佳实践(视频+PPT) [附件下载]

[链接] http://www.52im.net/thread-196-1-1.html

[摘要] 本期演讲嘉宾将为大家带来金山视频云在社交直播场景的支撑技术架构和优化方案。

👉52im社区本周新文：《Wasm在即时通讯IM场景下的Web端应用性能提升初探》，欢迎阅读！👈

我是Jack Jiang，我为自已带盐！https://github.com/JackJiang2011/MobileIMSDK/

为了更好地分类阅读 52im.net 总计1000多篇精编文章，我将在每周三推送新的一期技术文集，本次是第42 期。

[-1-] 实时音频的混音在视频直播中的技术原理和实践总结

[链接] http://www.52im.net/thread-1904-1-1.html

[摘要] 今天，我们就来聊一聊混音技术在视频直播应用中的实现原理、方案等，及其在创新玩法中的实践应用。

[-2-] 七牛云技术分享：使用QUIC协议实现实时视频直播0卡顿！

[链接] http://www.52im.net/thread-1406-1-1.html

[摘要] 不做任何开发，就能实现弱网环境下实现实时视频直播零卡顿，听上去是不是天方夜谭？看完这篇文章你就知道，我们是如何做到的。

[-3-] 近期大热的实时直播答题系统的实现思路与技术难点分享

[链接] http://www.52im.net/thread-1369-1-1.html

[摘要] 我们首先分析一下直播答题和传统直播在技术上的不同，然后深度解释一下直播答题解决方案的海量并发派题和收题。

[-4-] P2P技术如何将实时视频直播带宽降低75%？

[链接] http://www.52im.net/thread-1289-1-1.html

[摘要] 那整个系统是怎么设计的？使用了哪些技术来达成目标？接下来我来重点分享一下架构设计和技术细节。

[-5-] 网易云信实时视频直播在TCP数据传输层的一些优化思路

[链接] http://www.52im.net/thread-1254-1-1.html

[摘要] 网易云信的实时视频直播目前使用了TCP进行传输，且基于此，从编码动态适配、发送队列调整、协议优化、socket等做了全流程的优化，确保在限带宽、丢包、时延、抖动，无论单项还是复杂网络，都有非常不错的实际体验。

[-6 -] 首次披露：快手是如何做到百万观众同场看直播仍能秒开且不卡顿的？

[链接] http://www.52im.net/thread-1033-1-1.html

[摘要] 快手拥有5亿注册用户，单个直播间人数峰值已经超过180万，他们针对海量用户，基于大数据技术，在首屏和流畅度优化上做了大量的探索与实践。快手直播是如何设计全链路质量监控方案、如何搭建大数据处理Pipeline 、如何解决开播跳帧、首屏卡顿优化等问题的？本文干货满满，全面解密快手直播大数据技术架构与优化实践。

[-7-] 浅谈实时音视频直播中直接影响用户体验的几项关键技术指标

[链接] http://www.52im.net/thread-953-1-1.html

[摘要] 这两年互联网领域的一个热门关键词就是实时音视频直播，从刚开始的游戏直播和秀场娱乐开始，实时音视频直播带来了远超传统互动的用户体验，现在实时音视频直播已逐渐深入当今主流的互联网应用形态里。我们将逐一分析和总结实时音视频直播中的这几个重要技术指标。

[-8-] 技术揭秘：支持百万级粉丝互动的Facebook实时视频直播

[链接] http://www.52im.net/thread-541-1-1.html

[摘要] 在这篇文章中，我们将粗略地看一下我们在每次发布时解决的问题，我还将向你解释我们为负载均衡和 RTMP 实现问题所选择的解决方案。

[-9 -]  移动端实时视频直播技术实践：如何做到实时秒开、流畅不卡

[链接] http://www.52im.net/thread-530-1-1.html

[摘要] 本次分享将为大家揭开移动端实时音视频直播核心技术的神秘面纱。

[-10-] 实现延迟低于500毫秒的1080P实时音视频直播的实践分享

[链接] http://www.52im.net/thread-528-1-1.html

[摘要] 实时视频直播是很多技术团队及架构师关注的问题，在实时性方面，大部分直播是准实时的——存在 1-3 秒延迟。本文由袁荣喜分享其将1080P高清实时视屏直播延迟控制在 500ms 的背后的技术挑战以及实践结论等，期待与各同行共同讨论、学习和进步。

[-11 -] 浅谈开发实时视频直播平台的技术要点

[链接] http://www.52im.net/thread-475-1-1.html

[摘要] 现在大大小小的公司，甚至个人开发者，都想开发自己的直播网站或App，本文会帮你理清，开发视频直播平台，你需要注意哪些技术要点。

[-12 -] 海量用户IM聊天室的架构设计与实践

[链接] http://www.52im.net/thread-4404-1-1.html

[摘要] 本文将分享网易云信针对海量用户IM聊天室的架构设计与应用实践，希望能带给你启发。

[-13 -] 微信团队分享：详解iOS版微信视频号直播中因帧率异常导致的功耗问题

[链接] http://www.52im.net/thread-4507-1-1.html

[摘要] 功耗优化一直是 app 性能优化中让人头疼的问题，尤其是在直播这种用户观看时长特别久的场景。怎样能在不影响主体验的前提下，进一步优化微信iOS端视频号直播的功耗占用，本文给出了一个不太一样的答案。

👉52im社区本周新文：《移动端弱网优化专题(十四)：携程APP移动网络优化实践（弱网识别篇）》，欢迎阅读！👈

我是Jack Jiang，我为自已带盐！https://github.com/JackJiang2011/MobileIMSDK/

关于MobileIMSDK

MobileIMSDK 是一套专门为移动端开发的开源IM即时通讯框架，超轻量级、高度提炼，一套API优雅支持 UDP 、TCP 、WebSocket 三种协议，支持 iOS、Android、H5、标准Java、小程序、Uniapp，服务端基于Netty编写。

工程开源地址是：

• 1）Gitee码云地址：https://gitee.com/jackjiang/MobileIMSDK
• 2）Github托管地址：https://github.com/JackJiang2011/MobileIMSDK

关于RainbowChat

► 详细产品介绍：http://www.52im.net/thread-19-1-1.html
► iOS端更新记录：http://www.52im.net/thread-2735-1-1.html
► 全部运行截图：iOS端全部运行截图 （另：Android端运行截图 点此查看）
► 在线体验下载：App Store安装地址 （另：Android端下载体验 点此查看）

RainbowChat是一套基于开源IM聊天框架 MobileIMSDK 的产品级移动端IM系统。RainbowChat源于真实运营的产品，解决了大量的屏幕适配、细节优化、机器兼容问题（可自行下载体验：专业版下载安装）。

* RainbowChat可能是市面上提供im即时通讯聊天源码的，唯一一款同时支持TCP、UDP两种通信协议的IM产品（通信层基于开源IM聊天框架 MobileIMSDK 实现）。

v9.1 版更新内容

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

• 1）[bug] 解决了与Web产品互通时，收到撤回被引用消息的指令时会崩溃的问题；
• 2）[bug] 解决了“查换用户”界面中精确查找时，输入内容时会导致底部按钮等控件显示高度被错误改变的问题；
• 3）[bug] 解决了聊天输入框中自定义表情和数字、英文混输时，表情图标会消失的问题；
• 4）[优化] 更换了位置消息中的高德地图AppKey，解决每日调用量限制问题；
• 5）[优化] 优化了首页“消息”列表中单聊类型未正确同步时的收发消息和点击后的处理逻辑；
• 6）[优化] 聊天消息自动识别电话、网址、邮箱等内容，点击自动跳转到系统功能；
• 7）[优化] 优化了首页“消息”列表中同一好友和陌生人会话不能自动合并的问题。

部分功能运行截图（更多截图点此查看）：

一、关于RainbowChat-Web

RainbowChat-Web是一套Web网页端IM系统，是RainbowChat的姊妹系统（RainbowChat是一套基于开源IM聊天框架 MobileIMSDK (Github地址)  的产品级移动端IM系统）。

关于RainbowChat

RainbowChat是一套基于开源IM聊天框架 MobileIMSDK 的产品级移动端IM系统。RainbowChat源于真实运营的产品，解决了大量的屏幕适配、细节优化、机器兼容问题（可自行下载体验：专业版下载安装）。

* RainbowChat可能是市面上提供im即时通讯聊天源码的，唯一一款同时支持TCP、UDP两种通信协议的IM产品（通信层基于开源IM聊天框架  MobileIMSDK 实现）。

► 详细产品介绍：http://www.52im.net/thread-19-1-1.html
► 版本更新记录：http://www.52im.net/thread-1217-1-1.html
► 全部运行截图：Android端、iOS端
► 在线体验下载：专业版(TCP协议)、专业版(UDP协议)      （关于 iOS 端，请：点此查看）

关于MobileIMSDK

MobileIMSDK 是一套专门为移动端开发的开源IM即时通讯框架，超轻量级、高度提炼，一套API优雅支持UDP 、TCP 、WebSocket 三种协议，支持iOS、Android、H5、小程序、Uniapp、标准Java平台，服务端基于Netty编写。

工程开源地址：

• 1）Gitee码云地址：https://gitee.com/jackjiang/MobileIMSDK
• 2）Github托管地址：https://github.com/JackJiang2011/MobileIMSDK

v11.7 版更新内容

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

（1）Android端主要更新内容：

• 1）[优化] 优化了首页“消息”列表中单聊类型未正确同步时的收发消息和点击后的处理逻辑；
• 2）[优化] 优化了首页“消息”列表中同一好友和陌生人会话不能自动合并的问题；

（2）服务端主要更新内容：

• 1）[优化] 大幅提升群聊性能（改进离线消息存储方式等：异步提交、批量处理）；
• 2）[优化] 升级了mysql驱动至最新版8.4.0；
• 3）[优化] 优化了离线消息处理性能（异步化、无锁队列、批量处理、事务合并）；
• 4）[优化] 优化了聊天记录处理性能（异步化、无锁队列、批量处理、事务合并）；
• 5）[优化] 优化了“接口1008-26-8”，使得与Web产品联合部署明web前端按时间戳加载的消息不与客户端发生重复；
• 6）[优化] 修改了离线消息、聊天记录异步定时器实现，使之运行更健壮；
• 7）[优化] 加好友成功后将成功通知保存至离线消息和消息记录。

部分功能运行截图（更多截图点此查看）：

► 相关链接：

• ① MobileIMSDK-H5端的详细介绍
• ② MobileIMSDK-H5端的开发手册new（* 精编PDF版）

一、技术准备

您是否已对Web端即时通讯技术有所了解？

• 1）新手入门贴：史上最全Web端即时通讯技术原理详解
• 2）Web端即时通讯技术盘点：短轮询、Comet、Websocket、SSE

您需要对WebSocket技术有所了解：

• 1）新手快速入门：WebSocket简明教程
• 2）WebSocket详解（一）：初步认识WebSocket技术
• 3）WebSocket从入门到精通，半小时就够！
• 4）从零理解WebSocket的通信原理、协议格式、安全性

WebSocket标准文档、API手册：

• 1）WebSocket的API手册
• 2）WebSocket的标准文档

二、开发工具准备

1）WebStorm：

（JackJiang 使用的版本号如上图所示，建议你也使用此版或较新版本）

2）一站式下载地址：WebStorm官方下载地址点此进入。

三、工程文件用途说明

3.1文件概览

纯原生JS实现，无任何重框架依赖：

MobileIMSDK-H5端SDK本身只是JS文件源码的集合，本工程中自带的前端Demo的目的只是为了方便随时测试MobileIMSDK-H5端的SDK代码而已，在此工程中的使用也仅仅只涉及了一个主Demo页面而已。

工程目录说明：

3.2详细说明

SDK 各模块/文件作用说明：

四、主要 API 接口

4.1主要 API 接口概览

如下图所示：所有 SDK 接口均由/mobileimsdk/mobileimsdk-client-sdk.js 提供。，接口设计跟MobileIMSDK 的APP版一样，均为高内聚和低侵入的回调方式传入SDK处理逻辑，无需（也不建议）开发者直接修改sdk级代码。

▲ 图上为浏览器端SDK的对外接口文件位置

▲ 图上为浏览器SDK为开发者提供的回调接口

▲ 图上浏览器端SDK的对外接口文件全图

4.2主要 API 接口用途说明

1）IMSDK.isLogined()：

• 用途：是否已经完成过首次登陆。
• 说明 ：用户一旦从自已的应用中完成登陆IM服务器后，本方法就会一直返回true（直到退出登陆IM）。
• 返回值：{boolean}，true表示已完成首次成功登陆（即已经成功登陆过IM服务端了，后面掉线时不影响此标识），否则表示尚未连接IM服务器。

2）IMSDK.isOnline()：

• 用途：是否在线。
• 说明 ：表示网络连接是否正常。
• 返回值：{boolean}，true表示网络连接正常，否则表示已掉线，本字段只在this._logined=true时有意义（如果都没有登陆到IM服务器，怎么存在在线或掉线的概念呢）。

3）IMSDK.getLoginInfo()：

• 用途：返回登陆时提交的登陆信息（用户名、密码/token等）。
• 说明 ：格式形如：{loginUserId:'',loginToken:''}，此返回值的内容由调用登陆函数 loginImpl()时传入的内容决定。字段定义详见：PLoginInfo
• 返回值：{boolean}，true表示网络连接正常，否则表示已掉线，本字段只在this._logined=true时有意义（如果都没有登陆到IM服务器，怎么存在在线或掉线的概念呢）。

4）IMSDK.sendData(p, fnSucess, fnFail, fnComplete)：

• 用途：向某人发送一条消息。
• 参数p：{Protocal} 要发送的消息协议包对象，Protocal详情请见“/module/mb_constants.js”下的createCommonData函数说明。
• 返回值：{int} 0表示成功，否则表示错误码，错码详见“/module/mb_constants.js”下的MBErrorCode对象属性说明。

5）IMSDK.disconnectSocket()：

• 用途：客户端主动断开客户端socket连接。
• 说明 ：当开发者登陆IM后，需要退出登陆时，调用本函数就对了，本函数相当于登陆函数 loginImpl()的逆操作。

6）IMSDK.setDebugCoreEnable(enable)：

• 用途：是否开启MobileIMSDK-H5端核心算法层的log输入，方便开发者调试。
• 参数enable ：{boolean} true表示开启log输出，否则不输出，开发者不调用本函数的话系统默认是false（即不输出log）。

7）IMSDK.setDebugSDKEnable(enable)：

• 用途：是否开启MobileIMSDK-H5端框架层的log输入，方便开发者调试。
• 参数enable ：{boolean} true表示开启log输出，否则不输出，开发者不调用本函数的话系统默认是false（即不输出log）。

8）IMSDK.setDebugPingPongEnable(enable)：

• 用途：是否开启MobileIMSDK-H5端框架层的底层网络WebSocket心跳包的log输出，方便开发者调试。
• 参数enable ：{boolean} true表示开启log输出，否则不输出，开发者不调用本函数的话系统默认是false（即不输出log）。
• 注意：必须 setDebugEnable(true) 且 setDebugPingPongEnable(true) 时，心跳log才会真正输出，方便控制。
• 返回值：true表示开启log输出，否则不输出，开发者不调用本函数的话系统默认是false（即不输出log）。

9）IMSDK.loginImpl(varloginInfo, wsUrl)：

• 用途：登陆/连接MobileIMSDK服务器时调用的方法。
• 说明 ：登陆/连接MobileIMSDK服务器由本函数发起
• 参数varloginInfo：{PLoginInfo} 必填项，登陆要提交给Websocket服务器的认证信息，不可为空，对象字段定义见：PLoginInfo
• 参数wsUrl：{string} 必填项：要连接的Websocket服务器地址，不可为空，形如：wss://yousite.net:3000/websocket。

10）IMSDK.callback_onIMLog(message, toConsole)：

• 用途：由开发者设置的回调方法：用于debug的log输出。
• 推荐用法 ：开发者可在此回调中按照自已的意图打印MobileIMSDK微信小程序端框架中的log，方便调试时使用。
• 参数1： {String}：必填项，字符串类型，表示log内容。
• 参数2： {boolean}：选填项，true表示输出到console，否则默认方式(由开发者设置的回调决定)。

11）IMSDK.callback_onIMData(p, options)：

• 用途：由开发者设置的回调方法：用于收到聊天消息时在UI上展现出来（事件通知于收到IM消息时）。
• 推荐用法：开发者可在此回调中处理收到的各种IM消息。
• 参数1： {Protocal}：详情请见“/module/mb_constants.js”下的Protocal类定义)。

12）IMSDK.callback_onIMAfterLoginSucess()：

• 用途：由开发者设置的回调方法：客户端的登陆请求被服务端成功认证完成后的回调（事件通知于 登陆/认证 成功后）。
• 推荐用法 ：开发者可在此回调中进行登陆IM服务器成功后的处理。

13）IMSDK.callback_onIMAfterLoginFailed(isReconnect)：

• 用途：由开发者设置的回调方法：客户端的登陆请求被服务端认证失败后的回调（事件通知于 登陆/认证 失败后）。
• 说明 ：登陆/认证失败的原因可能是用户名、密码等不正确等，但具体逻辑由服务端的 callBack_checkAuthToken回调函数去处理。
• 推荐用法：开发者可在此回调中提示用户登陆IM服务器失败。。
• 参数1： {boolean}：true表示是掉线重连后的认证失败（在登陆其间可能用户的密码信息等发生了变更），否则表示首次登陆时的认证失败。

14）IMSDK.callback_onIMReconnectSucess()：

• 用途：由开发者设置的回调方法：掉线重连成功后的回调（事件通知于掉线重连成功后）。
• 推荐用法 ：开发者可在此回调中处理掉线重连成功后的界面状态更新等，比如设置将界面上的“离线”文字更新成“在线”。

15）IMSDK.callback_onIMDisconnected()：

• 用途：由开发者设置的回调方法：网络连接已断开时的回调（事件通知于与服务器的网络断开后）。
• 推荐用法 ：开发者可在此回调中处理掉线时的界面状态更新等，比如设置将界面上的“在线”文字更新成“离线”。

16）IMSDK.callback_onIMPing()：

• 用途：由开发者设置的回调方法：本地发出心跳包后的回调通知（本回调并非MobileIMSDK-H5端核心逻辑，开发者可以不需要实现！）。
• 推荐用法 ：开发者可在此回调中处理底层网络的活动情况。

17）IMSDK.callback_onIMPong()：

• 用途：由开发者设置的回调方法：收到服务端的心跳包反馈的回调通知（本回调并非MobileIMSDK-H5端核心逻辑，开发者可以不需要实现！）。
• 推荐用法 ：开发者可在此回调中处理底层网络的活动情况。

18）IMSDK.callback_onIMShowAlert(alertContent)：

• 用途：由开发者设置的回调方法：框架层的一些提示信息显示回调（本回调并非MobileIMSDK-H5端核心逻辑，开发者可以不需要实现！）。
• 说明 ：开发者不设置的情况下，框架默认将调用wx.showModal()显示提示信息，否则将使用开发者设置的回调——目的主要是给开发者自定义这种信息的UI显示，提升UI体验，别无它用】。
• 参数1：{String}：必填项，文本类型，表示提示内容。

19）IMSDK.callback_onIMKickout(kickoutInfo)：

• 用途：由开发者设置的回调方法：收到服务端的“踢出”指令（本回调并非MobileIMSDK-H5端核心逻辑，开发者可以不需要实现！）。
• 参数1 ：{PKickoutInfo}：非空，详见：PKickoutInfo

20）IMSDK.callback_onMessagesLost(lostMessages)：

• 用途：由开发者设置的回调方法：消息未送达的回调事件通知。
• 发生场景 ：比如用户刚发完消息但网络已经断掉了的情况下，表现形式如：就像手机qq或微信一样消息气泡边上会出现红色图标以示没有发送成功）。
• 建议用途：应用层可通过回调中的指纹特征码找到原消息并可以UI上将其标记为“发送失败”以便即时告之用户。
• 参数1：{Array}：由框架的QoS算法判定出来的未送达消息列表。

21）IMSDK.callback_onMessagesBeReceived(theFingerPrint)：

• 用途：由开发者设置的回调方法：消息已被对方收到的回调事件通知。
• 说明 ：目前，判定消息被对方收到是有两种可能：1) 对方确实是在线并且实时收到了；2) 对方不在线或者服务端转发过程中出错了，由服务端进行离线存储成功后的反馈（此种情况严格来讲不能算是“已被收到”，但对于应用层来说，离线存储了的消息原则上就是已送达了的消息：因为用户下次登陆时肯定能通过HTTP协议取到）。
• 建议用途：应用层可通过回调中的指纹特征码找到原消息并可以UI上将其标记为“发送成功”以便即时告之用户。
• 参数1：{String}：已被收到的消息的指纹特征码（唯一ID），应用层可据此ID找到原先已发的消息并可在UI是将其标记为”已送达“或”已读“以便提升用户体验。

五、前端开发指南

5.1如何引入SDK文件到您的前端工程中？

很简单：只需要将第2节中提到的SDK所有JS文件复制到您的Uniapp工程下即可。

SDK内容见下图：

5.2如何在代码中调用SDK？

第一步：在你的网页中引用SDK的js文件（具体例子详见Demo中的index.html文件）

第二步：直接在你的JS文件中编写回调配置代码（具体例子详见Demo中的index.js文件）

第三步：在你的JS文件中调用IM的登陆方法即可（具体例子详见Demo中的index.js文件）

注意：上图中登录连接的IP地址请设置为您的MobileIMSDK服务器地址哦。

六、Demo运行方法（在WebStorm中直接预览）

6.1重要说明

特别说明：MobileIMSDK的H5端（包括Demo在内），全部是静态的HTML+JS资源，可以通过WebStorm自带的HTML页面预览功能，直接自动加载到电脑的浏览器中运行和预览。

6.2预览方法

1）在Demo中的index.html文件中，移动鼠标，会在右上角出现如下图所示的浮出菜单：

2）点击右上角浮出菜单上相应的浏览器就可以自动预览了（这里以我电脑上已安装的Edge浏览器为例）：

七、Demo运行方法（在Web服务器中部署并访问）

7.1重要说明

特别说明：MobileIMSDK的H5端（包括Demo在内），全部是静态的HTML+JS资源，对于服务端是没有任何依赖的，只需要保证浏览器端能加载到即可，可以把它们放置在Tomcat、Apache、IIS、Nginx等等传统Web服务器中即可，无需任何动态运行环境。

7.2安装Tomcat

提示：以下Demo的部署，以Java程序员最常用和Tomcat为例（Apache、IIS、Nginx等依此类推）。

Tomcat的安装就没什么好说的，直接官网下载对应的版本即可：https://tomcat.apache.org/download-90.cgi。

7.3配置要连接的MobileIMSDK服务器IP

注意：下图中登陆连接的IP地址请设置为您的MobileIMSDK服务器地址哦。

友情提示： MobileIMSDK的服务端该怎么部署就不是本手册要讨论的内容了，你可以参见《即时通讯框架MobileIMSDK的Demo使用帮助：Server端》。

▲ 配置要连接的服务器IP（以上代码详见demo/index.js 文件）

7.4部署Demo

说“部署”有点扯蛋，因为Demo（包括SDK）在内，全是HTML静态内容，只需要直接复制到任何一种Web服务器即可。

以下是复制到Tomcat服务器网页目录后的截图：

7.5启动Tomcat

提示：本手册中仅以启Tomcat为例，Apache、IIS、Nginx等Web服务器的启动请自动百度。

运行startup.bat启动Tomcat：

7.6Demo的运行效果预览

八、Demo功能预览和说明

九、Demo运行效果实拍图

1）Demo在手机端浏览器中的真机实拍图：

2）Demo在电脑端浏览器中的真机实拍图：

十、更多Demo运行效果截图

1）Demo在PC端浏览器运行效果：

2）Demo在手机端浏览器运行效果：

3）Demo在PC端各主流浏览器的运行效果：

十一、常见问题（FAQ）

11.1为什么浏览控制台下有些log不显示？

原因是浏览器控制台下的日志级别默认进行了过滤，勾选所有日志级别，就能看到SDK的详细日志输出了。

勾选所有的日志输出级别：

然后就能看到SDK中详细的日志输出了（就像下图这样），方便调试和研究：

十二、引用资料

[1] WebSocket 标准API手册

[2] MobileIMSDK开源框架的API文档

[3] MobileIMSDK开源IM框架源码（Github地址点此）

[4] MobileIMSDK-H5端基本介绍

[5] MobileIMSDK-H5端的开发手册（* 精编PDF版）

[6] MobileIMSDK的Demo使用帮助：Server端

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

一、基本介绍

• 1）超轻量级、极少依赖；
• 2）纯JS编写、高度提炼，简单易用；
• 3）基于标准WebSocket协议，客户端兼容性好；
• 4）支持运行于iOS、Android等移动端浏览器和各种PC端浏览器；
• 5）能与 MobileIMSDK（Github托管链接）的各种APP原生代码客户端完美互通；
• 6）可应用于手机端/PC端的网页聊天应用、企业OA、Web端等即时通讯场景。

二、与MobileIMSDK的关系

MobileIMSDK-H5端 是基于标准HTML5的WebSocket协议的 MobileIMSDK配套客户端库。

以下是MobileIMSDK的通信架构图：

MobileIMSDK是一套专为移动端开发的原创开源IM通信层框架：

• 1）历经8年、久经考验；
• 2）超轻量级、高度提炼，lib包50KB以内；
• 3）精心封装，一套API同时支持UDP、TCP、WebSocket三种协议（可能是全网唯一开源的）；
• 4）客户端支持iOS、Android、标准Java、H5(暂未开源)、微信小程序(暂未开源)、Uniapp(暂未开源)；
• 5）服务端基于Netty，性能卓越、易于扩展；
• 6）可与姊妹工程 MobileIMSDK-Web 无缝互通实现网页端聊天或推送等；
• 7）可应用于跨设备、跨网络的聊天APP、企业OA、消息推送等各种场景。

PS： MobileIMSDK一直在持续开发和升级中，新Uniapp端是MobileIMSDK工程的最新成果。

三、与MobileIMSDK-Web的关系

• 1）都是Web端即时通讯框架；
• 2）都是纯JS编写；
• 3）都可以运行在手机、pc端的浏览器或web容器内。

• 1）MobileIMSDK-Web可以兼容不支持HTML5的旧版浏览器或容器，而MobileIMSDK-H5端必须运行在当前主流的HTML5浏览器或容器；
• 2）MobileIMSDK-Web需依赖于socket.io这种第3方通信层库，而MobileIMSDK-H5端无任何额外依赖。

• 选择一：如果您的应用必须兼容旧版浏览器（包括旧版IE等）：
  那唯一的选择就是MobileIMSDK-Web，因为它存在的主要价值就是为了兼容旧版浏览器；
• 选择二：如果您的应用只需运行在现今主流的HTML5浏览器或容器：
  那么建议您优先使用MobileIMSDK的H5端，必竟直接调用标准HTML5的WebSocket API，要简洁、轻量多了，也没有第3方依赖。

四、设计目标

• 1）功能有限：没有提供心跳保活、断线重连、送达保证（重传和去重）等即时通讯关键算法和逻辑；
• 2）API 简陋：在如此有限的标准API下，能逻辑清晰和健壮地实现并组合心跳保活、断线重连、送达保证等算法，需要相当高的技术掌控力；
• 3）逻辑耦合：经验欠缺的开发人员，会将WebSocket通信代码与前端UI界面代码混在一起，使得UI界面的编写、维护、改版都非常困难。

• 1）前端与通信解偶：前端UI与网络通信代码解耦，UI界面的重构、维护、改版都非常容易和优雅；
• 2）轻量级和兼容性：受益于标准WebSocket，可很好地运行于现今主流的H5浏览器上，且无需额外依赖；
• 3）核心内聚和收敛：得益于长期的提炼和经验积累，SDK核心层高度封装，开发者无需理解复杂算法即可简单上手。
• 4）纯JS轻量级实现：纯JS编写，无Angular、EmberJS、VUE等各种重量级前端框架依赖，方便对接各种既有系统；

五、技术亮点

• 1）轻量易使用：超轻量级——纯JS编写且极少依赖，高度提炼——简单易用；
• 2）兼容性很好：基于标准WebSocket，可很好地运行于现今主流的H5浏览器上，且无需额外依赖；
• 3）断网恢复能力：拥有网络状况自动检测、断网自动治愈的能力；
• 4）送达保证机制：完善的QoS消息送达保证机制（自动重传、消息去重、状态反馈等），不漏过每一条消息；
• 5）支持多种设备：支持运行于iOS、Android等移动端浏览器和各种PC端浏览器；
• 6）通信协议封装：实现了一个对上层透明的即时通讯通信协议模型；
• 7）身份认证机制：实现了简单合理的身份认证机制；
• 8）完善的log信息：在开发调试阶段，确保每一个算法关键步骤都有日志输出，让您的运行调试更为便利；
• 9）前端代码解耦：实现了UI前端代码与sdk网络通信代码解偶，防止前端代码跟IM核心代码混在一起，不利于持续升级、重用和维护；
• 10）多端协议兼容：实现了与MobileIMSDK各APP端完全兼容的协议模型；

六、文件组成

SDK代码文件概览：

SDK代码文件用途说明：

七、Demo功能预览和说明

八、Demo运行效果实拍图

1）Demo在手机端浏览器中的真机实拍图：

2）Demo在电脑端浏览器中的真机实拍图：

八、更多Demo运行效果截图

3）Demo在PC端主流浏览器的运行效果（点击可看大图 ▼）：

十、详尽开发者手册

十一、相关资料

本文由携程技术Jim分享，原题“日访问过亿，办公IM及开放式平台在携程的实践”，下文进行了排版和内容优化。

1、引言

携程内部的办公IM项目最早在2016年立项，经历了初期简单办公场景下的纯IM服务，到支持简单办公组件的IM应用，又演变为一体化办公集成平台，进而演变为目前集成IM功能的开放式企业效率平台。

本文总结了携程办公IM这些年的发展历程及未来的演进方向，并着重从高可用、高性能和可扩展的角度，探讨开放式平台的技术实现及发展方向。

2、关于作者

Jim：携程高级研发经理，关注Java & Go技术栈后端研发。目前致力于TripPal开放平台的高可用、开放化进程及核心衍生服务。

3、什么是IM

IM（Instant Message）即时消息，是一种通过网络提供实时消息传输的在线沟通技术。

在移动互联网时代，IM的使用变得越来越广泛，通过各种技术手段使得用户之间的交流成本变的极低，沟通效率和用户体验有极大的提升。而且IM的出现极大地改变了目前互联网应用的形态，多数互联网应用只要做到了一定规模，一定会有自身IM的需求，而不是单纯地仅仅依托第三方（例如微信、云信等）。

PS：关于什么是IM，您也可详读专题文章《零基础IM开发入门(一)：什么是IM系统？》。

4、 携程办公IM的发展历程

早期携程使用微软的IM软件lync和自研的纯IM软件CtripTeam来支持企业内的沟通需求，这些软件在维护性、拓展性和可用性上都或多或少存在一些缺陷。同时随着互联网的发展，也逐渐不适合日益增长的办公需求和用户体验。

2017年左右，使用基于ejabberd+erlang的自研IM服务的Cchat项目应运而生，该项目的主要目标是在采用自研IM的基础上，实现IM与办公的结合。在完善IM服务的基础上，支持了一些常规的办公场景，如电话、假单、考勤、OA等，通常采用嵌入外部页面、跳转外部地址等方式提供服务。这个改造项目奠定了携程办公IM继续发展的基础。

随着项目的深入，最初的系统交互模式及服务管理模式逐渐不适用越来越复杂的办公场景及服务治理需求。于是在2019年上马了TripPal的改造项目，在结合公司国际化战略的基础上，倾力打造小程序平台，服务号等基础服务。在梳理、优化原有服务的同时，打造了诸多衍生服务。

2020年中开始，在继续推进企业内办公一站式平台的基础上，我们需要支持更多的外部场景，实际需求促使我们向开放式平台转型，这在服务整体架构、安全性、扩展性等方面都提出了新的要求及挑战。

5、携程TripPal开放平台总体架构

5.1Gateway网关层

这一层是所有请求调用流量的入口，主要功能如下：

• 1）服务路由；
• 2）集中式限流、风控、日志监控等功能；
• 3）调用IDS (Identity Service) 验证请求的合法性。

第 3）步中验证通过后，可以将用户ID、Token等基本信息，通过 HttpHeader 的方式向后端服务透传，后端服务可以直接使用UserID，也可以再次对Token进行认证

5.2IDS (Identity Service) 服务

IDS同时支持多种不同类型的访问令牌的鉴权，同时还负责令牌的颁发，以及RBAC+模块级别的接口控权。

另外，针对开放小程序，TripPal提供两种认证方式：

1）常规的Oauth第三方模式接入：

2）另一种是基于Oauth+开放平台签名的第三方认证，对于接入方相对简单：

5.3微服务层

这一层是整个系统的业务层，具体包含三种类型的微服务：

• 1）TripPal开放平台内部系统微服务：只有在特定用户认证和权限验证通过之后，外部才能访问；
• 2）开放平台对外提供的OpenAPI：采用Oauth+RBAC的方式控制权限；
• 3）自研小程序后端服务：根据安全需要，所有使用Oauth+模块权限的第一方小程序服务端。

目前TripPal自身的核心微服务应用达到28个，提供全集团的多端（C端、B端）基础服务能力，服务全公司超过500个业务应用，在线C端用户均值超过2万，日访问量超过亿。

6、 TripPal的IM服务

目前TripPal使用完全自研的基于Java实现的类ejabberd架构，底层采用的XMPP协议进行通讯。

Tips：

XMPP全称是ExtensibleMessageing and Presence Protocol，可扩展消息与存在协议。是目前网络上开源，最灵活，应用最广泛的一种即时消息通信协议。

1999年Jeremie Miller，首先提出了Jabber，一种为实现即时消息和存在的开放技术，后续基于这个协议，开发了一个开源的服务实现jabberd。后续，IETF国际标准组织介入，成立Extensible Messageing and Presence Protocol（XMPP）工作组，并开始标准化工作。

2000年，jabberd服务器1.0版本发布，那时Jabber协议的基本特点（基于XML的流，消息，存在，联系人列表等）都被固定下来。

2004年，IETF出版了RFC 3902和RFC3921，定义了XMPP的核心功能，成为推荐标准。

后续在2011年，IETF出版了RFC6120和RFC 6121，更新了XMPP的核心定义，替代了之前的RFC 3920和3921。

目前XMPP协议被XMPP Standards Foundation负责管理运作，集中于在IETF定义的基础XMPP规范之上，如何开发开放的协议扩展。

IM服务端做了大量的系统性的优化，从底层的数据库调优、底层通讯服务升级，到上层消息、群、群成员等核心功能的大幅改造。

底层通讯服务由之前的erlang完整迁移至java技术栈，服务可靠性、弹性伸缩、安全性和性能获得了提升。同时对上层偏业务的服务进行了改造，极大地提升了接口响应，服务稳定性也得到了提升，为整个产品的研发提供了重要支撑。

目前这套自研的IM 3.0服务在生产环境稳定运行，整体资源消耗比2.0时期有较大下降。

7、 TripPal办公衍生服务

7.1概述

在实际的企业办公场景下，尤其是大型企业复杂组织架构和管理模式的场景下，TripPal逐渐摸索出了自己的一套行之有效且契合携程场景的办公智能应用，如搜索中台，消息卡片，智能审批中台，角色服务，工作流引擎等。

本文简单介绍其中3个服务。

7.2智能审批中台

智能审批中台在集成携程自有的审批系统的同时也集成了自研的智能审批配置服务，该服务支持用户自定义整个审批单及审批流的全部细节。

7.3角色服务

角色服务在灵活定义角色范围及基础角色的基础上，支持用户灵活调整，动态管理，且自动接入审批中台，同时打通应用对接渠道。

整个角色服务在产品定义上分为如下表4个主要概念：

7.4在线文档

在线文档服务主要提供文档的在线协作能力，支持用户同时/实时的查看、编辑、保存和分享的能力。同时结合IM实现通知和反馈等功能。

技术实现上，在线文档是采用CRDT算法实现的无冲突merge（LastWrite Wins）、多端最终一致的分布式方案，同时兼具高可用、可容错的特性，在服务器发生故障时，允许Shift至另一台机器上继续执行，即使服务端完全宕机，客户端依然能够离线工作。

8、 TripPal高可用的实践

目前TripPal部署在3个机房，分为公有云1个机房及私有云2个机房。

总体架构在应用多机房部署、数据层跨机房DRC的基础上，采用就近访问的原则进行服务访问，其中一旦发生任意2个机房全挂的情况，都能保证系统内的核心应用仍能提供服务。

其中公有云机房的一期部署方案已经完成，二期部署方案和测试计划预计于7月完成，届时可以和大家分享一下混合云方案的一些细节和历程。

9、 开放平台的未来架构及演进方向

9.1概述

开放平台主要面向两类群体，开发者和用户。

所以主要有两个方向：

1）一是便捷开发，主要围绕降低开发者门槛、较低研发成本，打通不同开发者、应用之间的壁垒，实现生态共享。

2）另一方面，针对实际用户，在提高用户体验、数据安全的同时，实现用户服务能力整合和主动发现。

9.2开发者

在这方面，目前主流开放平台已经对开发者提供了强大的支持。

主要形式分为以下3种。

1）前端信任：

前端信任的目的是通过减少或杜绝开发者后端跟开放平台OpenAPI交互的方式，来降低开发者接入门槛，减少工作量。主要的做法是通过权限控制、签名、加密等手段使得小程序能够在前端拿到可信数据。

2）低代码(Low-Code)：

由于大量的互联网业务属于简单交互或模型化交互，以此为出发点，基于构建合理模型、简单业务函数等形式，可以允许开发者通过拖拽组件、简单伪业务代码等形式提供编程入口，可以大幅度降低开发者的研发门槛和成本，打破用户和开发者界线，提高开放平台整体生态的活力。

3）ServerLess：

基于云原生的ServerLess结合低代码，开放开发者的云端编程入口，同时提供云端基础组件，允许开发者无需部署实际的后端应用服务，极大降低的开发者的运营维护门槛。

9.3用户层面

目前业界主流开放平台在对用户本身的服务能力整合和挖掘上，投入的都比较少，也没有比较成熟的实践，我们认为在这方面可以围绕两个点展开。

一方面：第三方应用治理模式向商城化的转型。常规开放平台的应用治理和推广，基本是应用方独立管理和推广，但是随着应用数量的大幅度增加，以及应用方单方面推广难度较大等原因，亟需开放平台从生态整体角度进行支持和治理。这样可以在安全性、可维护性、便捷性等维度上对应用进行正向反馈，实现开放平台应用生态的可持续性和能力共享。同时，在特定场景下，结合用户分析、大数据及AI，提高用户主动或被动的应用发现能力。

另一方面：构建符合应用间开放协议的软件联盟，打破应用壁垒，围绕服务集成、开放应用的核心原则，使得不同的互联网业务或行为在一定程度上实现数据/能力共享。一般情况下，一个复杂互联网业务通常由多个异构子业务/子应用构成，这样，通过应用拆分、开放共享等形式，在一定程度上使复杂的互联网业务更加精细化、轻量化、可扩展。

9.4开放平台标准化、互通

目前国内外各大互联网公司、机构和组织都搭建了多种开放平台，用于提供各种各样的信息服务，在可以预见的未来，各个平台之间会有一个整合、标准化、互通的可能性。

那么构建标准开放协议，使得开放平台向底层沉淀的过程则至关重要。

10、 本文小结

通过实现基本IM开放平台架构，以及各种衍生服务，我们总结出了IM开放平台的一些核心能力。

主要是：

• 1）服务集成：根据不同的业务场景集成并提供相应场景下的基础服务能力；
• 2）开放应用：提供第三方接入能力；
• 3）高性能、高可用。

11、参考资料

[1] 零基础IM开发入门(一)：什么是IM系统？

[2] 从零到卓越：京东客服即时通讯系统的技术架构演进历程

[3] 瓜子IM智能客服系统的数据架构设计（整理自现场演讲，有配套PPT）

[4] 从游击队到正规军(一)：马蜂窝旅游网的IM系统架构演进之路

[5] 一套高可用、易伸缩、高并发的IM群聊、单聊架构方案设计实践

[6] 浅谈IM系统的架构设计

[7] 简述移动端IM开发的那些坑：架构设计、通信协议和客户端

[8] 一套海量在线用户的移动端IM架构设计实践分享(含详细图文)

[9] 一套原创分布式即时通讯(IM)系统理论架构方案

[10] 一套亿级用户的IM架构技术干货(上篇)：整体架构、服务拆分等

[11] 从新手到专家：如何设计一套亿级消息量的分布式IM系统

[12] 企业微信的IM架构设计揭秘：消息模型、万人群、已读回执、消息撤回等

[13] 阿里IM技术分享(三)：闲鱼亿级IM消息系统的架构演进之路

[14] 基于实践：一套百万消息量小规模IM系统技术要点总结

[15] 跟着源码学IM(十)：基于Netty，搭建高性能IM集群（含技术思路+源码）

[16] 一套十万级TPS的IM综合消息系统的架构实践与思考

[17] 直播系统聊天技术(八)：vivo直播系统中IM消息模块的架构实践

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

[19] 得物从0到1自研客服IM系统的技术实践之路

[20] 一套分布式IM即时通讯系统的技术选型和架构设计

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

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

关于RainbowChat

RainbowChat是一套基于开源IM聊天框架 MobileIMSDK 的产品级移动端IM系统。RainbowChat源于真实运营的产品，解决了大量的屏幕适配、细节优化、机器兼容问题（可自行下载体验：专业版下载安装）。

* RainbowChat可能是市面上提供im即时通讯聊天源码的，唯一一款同时支持TCP、UDP两种通信协议的IM产品（通信层基于开源IM聊天框架  MobileIMSDK 实现）。

► 详细产品介绍：http://www.52im.net/thread-19-1-1.html
► 版本更新记录：http://www.52im.net/thread-1217-1-1.html
► 全部运行截图：Android端、iOS端
► 在线体验下载：专业版(TCP协议)、专业版(UDP协议)      （关于 iOS 端，请：点此查看）

关于MobileIMSDK

MobileIMSDK 是一套专门为移动端开发的开源IM即时通讯框架，超轻量级、高度提炼，一套API优雅支持UDP 、TCP 、WebSocket 三种协议，支持iOS、Android、H5、小程序、Uniapp、标准Java平台，服务端基于Netty编写。

工程开源地址是：

• 1）Gitee码云地址：https://gitee.com/jackjiang/MobileIMSDK
• 2）Github托管地址：https://github.com/JackJiang2011/MobileIMSDK

v11.6 版更新内容

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

（1）Android端主要更新内容：

• 1）[bug] 解决了APP从后台恢复时，有一定几率因后台多线程操作好友数据导致的线程安全崩溃问题；
• 2）[优化] 加固了一处好友列表中根据昵称取拼音首字母的非空检查逻辑；

（2）服务端主要更新内容：

• 1）[bug] 升级了MobileIMSDK至v6.5，尝试解决极小几率下Android端会误把“自已”踢掉的问题
• 2）[bug] 解决了因Netty库版本升级导致iOS消息推送失败报错的问题：
• 3）[bug] 解决了消息撤回时，被引用消息的历史记录没有正确处理撤回逻辑；
• 4）[优化] 为“接口1008-26-7”增加了“at_me”字段的返回；
• 5）[优化] 优化了“接口1008-26-8”，使得在跟Web互通时支持按时间戳的聊天记录分页加载方案；
• 6）[优化] 为“接口1008-26-8”增加了“消息发送者昵称”内容的返回；

部分功能运行截图（更多截图点此查看）：

一、关于RainbowChat-Web

RainbowChat-Web是一套Web网页端IM系统，是RainbowChat的姊妹系统（RainbowChat是一套基于开源IM聊天框架 MobileIMSDK (Github地址)  的产品级移动端IM系统）。

为了更好地分类阅读 52im.net 总计1000多篇精编文章，我将在每周三推送新的一期技术文集，本次是第41 期。

[- 1 -] 移动端实时音视频直播技术详解（一）：开篇

[链接] http://www.52im.net/thread-853-1-1.html

[摘要] 本文是《移动端实时音视频直播技术详解》系列文章之第一篇，我们将从整体介绍直播中的各个环节。

[- 2 -] 移动端实时音视频直播技术详解（二）：采集

[链接] http://www.52im.net/thread-955-1-1.html

[摘要] 本文是《移动端实时音视频直播技术详解》系列文章之第二篇：我们将从整体介绍直播中的采集环节。

[- 3 -] 移动端实时音视频直播技术详解（三）：处理

[链接] http://www.52im.net/thread-960-1-1.html

[摘要] 本篇是《移动端实时音视频直播技术详解》系列文章之第三篇：我们将从整体讲解常见视频处理功能：如美颜、视频水印、滤镜、连麦等。

[- 4 -] 移动端实时音视频直播技术详解（四）：编码和封装

[链接] http://www.52im.net/thread-965-1-1.html

[摘要] 本篇是是《移动端实时音视频直播技术详解》系列文章之第四篇：我们将从整体讲解编码和封装。

[- 5 -] 移动端实时音视频直播技术详解（五）：推流和传输

[链接] http://www.52im.net/thread-967-1-1.html

[摘要] 本篇是《移动端实时音视频直播技术详解》系列文章之第五篇：我们将从整体讲解推流和传输。

[- 6 -] 移动端实时音视频直播技术详解（六）：延迟优化

[链接] http://www.52im.net/thread-972-1-1.html

[摘要] 本篇是《移动端实时音视频直播技术详解》系列文章之第六篇：我们将从整体讲解延迟优化技术。

[- 7 -] 理论联系实际：实现一个简单地基于HTML5的实时视频直播

[链接] http://www.52im.net/thread-875-1-1.html

[摘要] 本次分享就向大家介绍一下分享一下直播的整个流程和一些技术点，并动手实现一个简单的Demo。

[- 8 -] 实时视频直播客户端技术盘点：Native、HTML5、WebRTC、微信小程序

[链接] http://www.52im.net/thread-1564-1-1.html

[摘要] 连麦视频直播的客户端主要包括：原生 APP、浏览器 H5、浏览器 WebRTC、微信小程序。浏览器上的应用包括 H5 和 WebRTC，前者可以拉流观看，后者可以实现推流和拉流。

[- 9 -]  Android直播入门实践：动手搭建一套简单的直播系统

[链接] http://www.52im.net/thread-1154-1-1.html

[摘要] 实时视频直播是这两年非常火的技术形态，已经渗透到教育、在线互娱等各种业务场景中。但要搭建一套实时视频直播系统，并非易事，当然相关的直播技术理论在论坛的其它文章里已经写的非常详细，本文不再展开。

[- 10 -] 淘宝直播技术干货：高清、低延时的实时视频直播技术解密

[链接] http://www.52im.net/thread-3220-1-1.html

[摘要] 本文由淘宝直播音视频算法团队分享，对实现高清、低延时实时视频直播技术进行了较深入的总结，希望分享给大家。

[- 11 -] 技术干货：实时视频直播首屏耗时400ms内的优化实践

[链接] http://www.52im.net/thread-2087-1-1.html

[摘要] 直播行业的竞争越来越激烈，进过2018年这波洗牌后，已经度过了蛮荒暴力期，剩下的都是在不断追求体验。最近正好在做直播首开优化工作，实践中通过多种方案并行，已经能把首开降到500ms以下，借此机会分享出来，希望能对大家有所启发。

[- 12 -] 新浪微博技术分享：微博实时直播答题的百万高并发架构实践

[链接] http://www.52im.net/thread-2022-1-1.html

[摘要] 本文将分享新浪微博系统开发工程师陈浩在 RTC 2018 实时互联网大会上的演讲。他分享了新浪微博直播互动答题架构设计的实战经验。其背后的百万高并发实时架构，值得借鉴并用于未来更多场景中

👉52im社区本周新文：《IM跨平台技术学习(十二)：万字长文详解QQ Linux端实时音视频背后的跨平台实践》，欢迎阅读！👈

我是Jack Jiang，我为自已带盐！https://github.com/JackJiang2011/MobileIMSDK/

本文由爱奇艺技术团队分享，作者isno，原题“爱奇艺海外App的网络优化实践”，下文进行了排版和内容优化等。

1、引言

做海外市场，特别目标是面向全球的用户，网络的重要性不言而喻。试想一个移动端应用，比如即时通讯IM，聊天消息的本质就是人跟人在说话，一条消息从发送到接受需要10秒的时间，这恐怕会让用户崩溃，随之就是被无情地卸载，开拓海外市场那就是做梦了。

本次分享的文章内容，基于爱奇艺面向全球用户推出的国际版，在海外跨国网络环境复杂的前提下，针对性地做了一系列弱网优化实践，取得了不错的效果，在此总结分享我们的一些做法和优化思路，希望对你有所帮助。

总结下来，跨国弱网优化实践的几个核心就是：

• 1）能不请求网络就不请求；
• 2）请求的链接目标 0-RTT；
• 3）请求的内容越小越好。

正文内容我们将逐个技术点展开了分享。

2、系列文章

本文是系列文章中的第 3 篇，本系列文章的大纲如下：

1. 《移动端IM开发者必读(一)：通俗易懂，理解移动网络的“弱”和“慢”》
2. 《移动端IM开发者必读(二)：史上最全移动弱网络优化方法总结》
3. 《移动端IM开发者必读(三)：爱奇艺移动端跨国弱网通信的优化实践》（* 本文）

如果您是IM开发初学者，强烈建议首先阅读《新手入门一篇就够：从零开发移动端IM》。

3、 跨国弱网样本摸底

在 App 初期版本内增加请求链路的采样。样本数足够的情况下，可以清楚你要推广的市场是怎样的环境。样本数据让我们清楚发现了各个国家、地区网络的问题，在大规模宣传和投入前，做好 App 的基础工作非常重要。

海外用户至海外数据中心的网络延迟（这是监测节点数据，用户端延迟更高）：

海外主要国家、地区移动网络情况：

在调研阶段，我们发现了以下问题比较明显，切实影响我们的运营及 App 体验。

这些问题主要是：

• 1）运营商劫持严重，DNS 劫持、HTTP 劫持；
• 2）移动端网络复杂 ，东南亚的网络基础建设还待改善；
• 3）低端 Android 机有一定的占比，数量级别影响决策；
• 4）国际网络用户端到服务器的延迟高。

在初期阶段，技术工作的核心是解决以上问题，为后续的运营做好基础建设。因为业务接口大部分为 HTTP 形式，就开始围绕 HTTPS 进行针对性改进。

一个HTTPS请求阶段分析：

一个 HTTPS 在第一请求会有 5 个 RTT：

1RTT(DNS)+ 1RTT(TCP 握手)+ 2RTT(TLS1.2)+ 1RTT(HTTP 链接)

如果以端到服务 50ms 延迟为例：

一个 HTTPS 的接口延迟 =  350ms =  50*5+ 100ms（服务端）

如果目标是一个非国内用户，打开首页需要 1.1s, 这个时间显然有点长。

下面开始进行技术改进的正文，以下是概括技术性优化的关键点：

4、基础链路的改进优化

4.1DNS 优化调整

DNS 的解析改为 HTTPDNS，DNS 的改进上线后观察初始连接请求提升 17% 的效率。

目的主要是：

• 1）解决域名劫持问题 （东南亚地区回传的数据显示有不少劫持）；
• 2）解决 LocalDNS 非就近分配问题；
• 3）结合业务可以做解析预热。

4.2传输层的优化调整

MTU 的问题 ：

• 1）Client 端和 Server 端不同的 MTU 值会导致丢包率过高。AWS 某些场景实例默认巨型帧：MTU 是 9001，但接收端默认 1500，这时候就会出现一些丢包的现象；
• 2）如果你用了多个云商服务，用 VPN 组网，IP隧道封装的数据临界 1500，又会造成丢包、包重传问题；
• 3）最严重的情况：部分网络封杀 ICMP 协议，导致 MTU 无法自动协商。

TCP 拥塞控制优化：

拥塞窗口 CongWin 是未接收到接收端确认情况下连续发送的字节数; 。CongWin 是动态调整，取决于带宽和延迟的积，比如 100MB 的带宽 100ms 的延迟环境。

时延带宽积 = 100Mbps*100ms = (100/8)*(100/1000) = 1.25MB

理论上 CongWin 窗口可以最大化到 1.25MB。CentOS 默认CongWin = 20*MSS，在 29KB 左右，离上限 1.26MB 差太多了，默认值上调TCP的启动会更快。

TCP 快速打开 (TCP Fast Open：TFO)：

TCP 的 keepalive 下依然会有链接断掉重建的情况，TFO 是针对这种情况的优化。

TFO 的原理机制：

在我们观察中开启 TFO 机制，海外业务一个 RTT 通常时间在 100ms 以上，HTTP 请求效率提升了 12% 左右。

5、应用层的改进优化

5.1HTTP 的优化

HTTP1.1 有个 keep-alive 作用是复用 TCP 链接，减少新建的消耗，对于浏览器的业务比较适用，但对于移动端这种时间分散的请求，大部分请求还是新建连接。

HTTP1.1 的串行机制有头部阻塞的问题。

5.2SSL 层优化

尽量升级到 TLS1.3（微信的TLS1.3实践：《微信新一代通信安全解决方案：基于TLS1.3的MMTLS详解》），利用 Pre-shared Key 机制，开启 ssl_early_data 可以进一步优化 “0-RTT ”，如果无法升级 TLS 版本，优化密钥算法为 ECDHE，运算速度快，握手的消息往返由 2-RTT 减少到 1-RTT，能达到与 TLS1.3 类似的效果。

TLS 版本的区别：

TLS1.3 经过优化后，一个 HTTP 请求由之前的 4 个 RTT 减少为 3 个 RTT。

5.3升级 HTTP2.0

几个重要的改进点：

• 1）分帧传输；
• 2）多路复用；
• 3）头部压缩。

多路复用：

在 HTTP/2 中，两个非常重要的概念：帧（frame）和流（stream）。帧代表着最小的数据单位，每个帧会标识出该帧属于哪个流，流也就是多个帧组成的数据流。多路复用，就是在一个 TCP 连接中可以存在多条流。这些改进可以避免 HTTP 队头阻塞问题，提高传输性能。

头部压缩：

开发人员如果不注意对 header 内容的控制，会造成 header 内容失控的现象，客户端极容易存储一个非常大的 Cookie。

HTTP2 的分帧传输机制：

5.4边缘节点动态加速

这个是非常有效的方式。

尽可能离用户最近，利用边缘节点对路由、链路进行优化，提高动态服务的效率。相较于直连模式，使用动态加速后，P90 的接口延迟效率提升了 60%。

爱奇艺海外动态加速的效果提升（请求时间为秒）：

5.5启用兜底机制

对于失败的请求，启用兜底的协议 QUIC 或者 kcp。

客户端的失败率在 3% 左右，对这部分请求使用 UDP 协议兜底尝试，在我们的观察成功率提升了 45%。

6、传输内容的优化

6.1应用 Brotli

因为预置了字典，在同等级别的压缩率下，对比 gzip 至少提升了 17% 的压缩比，接口平均的 Content-Size 由 30KB，降至 18KB。

6.2接口由 JSON 改为 Google Protobuf

应用 Protobuf 的重要原因是解析效率比 JSON 至少高四五倍，在节点深度和数据量大的情况下更明显。

但注意 Protobuf 内部的 varint 压缩，只对小于 128 的数字进行可变长压缩。实际效果不大，生产环境如果数据量大，外层的压缩如 gzip 不可少。

PS：关于Protobuf的资料，可以进一步阅读《IM通讯协议专题学习》。

6.3图片格式升级为 WebP

在应用 WebP 的同时，降低海报图片的质量，实践看海报的 quality 设置为 85% 肉眼难以分辨，相对同质量的 JPEG 或者 PNG ，可以最大减小 45% 的体积。

应用效果明显。App 打开首页图片的加载提升肉眼可见。

7、业务层面的优化改进

7.1减少不必要请求：

一些通用内容，如导航、频道，通常由运营人员主动更新。

如下图：增加一个启动阶段请求的接口，里面放入内容更新的时间戳，与本地 cache 的时间戳有差异，则异步请求更新。

 

7.2区别用户网络，适应不同的策略

具体作法是：

• 1）对于视频，非 WiFi 默认启播码率为 360P；
• 2）对于海报，后端接口提供两种质量的 Url，WiFi 高质，4G 低质。

7.3更多的业务优化

增加请求重试、调整 HTTP 的超时时间，请求缓存等等  这些可以根据业务的需求进行调整。

8、本文小结

爱奇艺海外版APP经过一系列细节优化，用户体验持续上升。用户接口延迟、客户端失败率、视频播放成功率一系列的关键指标得到很大的改善。这也助力爱奇艺在东南亚多个国家的应用市场排名升至 TOP 1。

另外 App 优化、Server 延迟优化、产品体验的改进，这一系列只有相辅相成才可以最大化提升用户体验。

9、参考资料

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

[2] 网络编程懒人入门(三)：快速理解TCP协议一篇就够

[3] 新手入门一篇就够：从零开发移动端IM

[4] 现代移动端网络短连接的优化手段总结：请求速度、弱网适应、安全保障

[5] 全面了解移动端DNS域名劫持等杂症：技术原理、问题根源、解决方案等

[6] 美图App的移动端DNS优化实践：HTTPS请求耗时减小近半

[7] 百度APP移动端网络深度优化实践分享(一)：DNS优化篇

[8] 百度APP移动端网络深度优化实践分享(二)：网络连接优化篇

[9] 百度APP移动端网络深度优化实践分享(三)：移动端弱网优化篇

[10] 爱奇艺移动端网络优化实践分享：网络请求成功率优化篇

[11] 美团点评的移动端网络优化实践：大幅提升连接成功率、速度等

[12] 淘宝移动端统一网络库的架构演进和弱网优化技术实践

[13] 谈谈移动端 IM 开发中登录请求的优化

[14] 移动端IM开发需要面对的技术问题（含通信协议选择）

[15] 简述移动端IM开发的那些坑：架构设计、通信协议和客户端

[16] 微信对网络影响的技术试验及分析（论文全文）

[17] 腾讯原创分享(二)：如何大幅压缩移动网络下APP的流量消耗（上篇）

[18] IM开发者的零基础通信技术入门(十二)：上网卡顿？网络掉线？一文即懂！

[19] 微信新一代通信安全解决方案：基于TLS1.3的MMTLS详解

[20] IM通讯协议专题学习(一)：Protobuf从入门到精通，一篇就够！

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

一、关于RainbowChat-Web

RainbowChat-Web是一套Web网页端IM系统，是RainbowChat的姊妹系统（RainbowChat是一套基于开源IM聊天框架 MobileIMSDK (Github地址)  的产品级移动端IM系统）。

为了更好地分类阅读 52im.net 总计1000多篇精编文章，我将在每周三推送新的一期技术文集，本次是第 40 期。

[- 1 -] 一个基于长连接的安全可扩展的订阅/推送服务实现思路

[链接] http://www.52im.net/thread-776-1-1.html

[摘要] 本文将从如何保证连接的业务安全（禁止非业务认证的连接订阅消息）和如何扩展能够支持更多的消息和连接两点展开分析。

[- 2 -] 实践分享：如何构建一套高可用的移动端消息推送系统？

[链接] http://www.52im.net/thread-800-1-1.html

[摘要] 本文追溯了推送技术的发展历史，剖析了其核心原理，并对推送服务的关键技术进行深入剖析，围绕消息推送时产生的服务不稳定性，消息丢失、延迟，接入复杂性，统计缺失等问题，提供了一整套平台级的高可用消息推送解决方案。实践中，借助于该平台，不仅能提能显著提高消息到达率，还能提高研发效率，并道出了移动开发基础设施的平台化架构思路。

[- 3 -] Go语言构建千万级在线的高并发消息推送系统实践(来自360公司)

[链接] http://www.52im.net/thread-848-1-1.html

[摘要] 本文内容整理自奇虎360公司的周洋在 Gopher China 2015 大会上的分享（演讲PPT下载：《Go语言构建高并发消息推送系统实践PPT(来自奇虎360)[附件下载] 》），该次分享以360海量在线的消息推送系统为例，来探讨使用Go语言构建高并发消息推送系统时所遇到的问题以及总结出的各种实践技巧。

[- 4 -]腾讯信鸽技术分享：百亿级实时消息推送的实战经验

[链接] http://www.52im.net/thread-999-1-1.html

[摘要] 本文整理了此次甘恒演讲的内容并以文字的方式分享给大家，希望能给技术同行带来一些技术上的启发。

[- 5 -] 百万在线的美拍直播弹幕系统的实时推送技术实践之路

[链接] http://www.52im.net/thread-1236-1-1.html

[摘要] 本文作者是美拍的架构师，经历了直播弹幕从无到有，从小到大的过程，借此文为大家分享构建弹幕系统的经验，希望能为正在开发或正打算开发弹幕、消息推送、IM聊天等系统的技术同行带来一些启发。

[- 6 -] 京东京麦商家开放平台的消息推送架构演进之路

[链接] http://www.52im.net/thread-1321-1-1.html

[摘要] 我会详细的介绍下京麦实时消息推送是如何在演变中不断完善的。

[- 7 -] 了解iOS消息推送一文就够：史上最全iOS Push技术详解

[链接] http://www.52im.net/thread-1762-1-1.html

[摘要] 本文将对iOS Push的在线push、本地push及离线（远程）push进行了详细梳理，介绍相关逻辑、测试时要注意的要点以及相关工具的使用。

[- 8 -] 基于APNs最新HTTP/2接口实现iOS的高性能消息推送(服务端篇)

[链接] http://www.52im.net/thread-1820-1-1.html

[摘要] 本文要分享的消息推送指的是当iOS端APP被关闭或者处于后台时，还能收到消息/信息/指令的能力。

[- 9 -]  解密“达达-京东到家”的订单即时派发技术原理和实践

[链接] http://www.52im.net/thread-1928-1-1.html

[摘要] 本文将描述“达达-京东到家”的订单即时派发系统从无到有的系统演进过程，以及方案设计的关键要点，希望能为大家在解决相关业务场景上提供一个案例参考。

[- 10 -] 技术干货：从零开始，教你设计一个百万级的消息推送系统

[链接] http://www.52im.net/thread-2096-1-1.html

[摘要] 本文主要分享的是如何从零设计开发一个中大型推送系统，因限于篇幅，文中有些键技术只能一笔带过，建议有这方面兴趣的读者可以深入研究相关知识点，从而形成横向知识体系。

[- 11 -] 长连接网关技术专题(四)：爱奇艺WebSocket实时推送网关技术实践

[链接] http://www.52im.net/thread-3539-1-1.html

[摘要] 本文分享了爱奇艺基于Netty实现WebSocket长连接实时推送网关时的实践经验总结。

[- 12 -] 喜马拉雅亿级用户量的离线消息推送系统架构设计实践

[链接] http://www.52im.net/thread-3621-1-1.html

[摘要] 本文分享的离线消息推送系统设计并非专门针对IM产品，但无论业务层的差别有多少，大致的技术思路上都是相通的，希望借喜马拉雅的这篇分享能给正在设计大用户量的离线消息推送的你带来些许启发。

[- 13 -] 直播系统聊天技术(三)：微信直播聊天室单房间1500万在线的消息架构演进之路

[链接] http://www.52im.net/thread-3376-1-1.html

[摘要] 本文将回顾微信直播聊天室单房间海量用户同时在线的消息组件技术设计和架构演进，希望能为你的直播聊天互动中的实时聊天消息架构设计带来启发。

[- 14 -] 直播系统聊天技术(四)：百度直播的海量用户实时消息系统架构演进实践

[链接] http://www.52im.net/thread-3515-1-1.html

[摘要] 本文主要分享的是百度直播的消息系统的架构设计实践和演进过程。

[- 15 -] 消息推送技术干货：美团实时消息推送服务的技术演进之路

[链接] http://www.52im.net/thread-3662-1-1.html

[摘要] 本文将首先从Pike的系统架构升级、工作模式升级、长稳保活机制升级等方面介绍2.0版本的技术演进，随后介绍其在直播、游戏等新业务场景下的技术特性支持，并对整个系统升级过程中的技术实践进行了总结。

[- 16 -] 揭秘vivo百亿级厂商消息推送平台的高可用技术实践

[链接] http://www.52im.net/thread-4416-1-1.html

[摘要] 本文将要分享的是vivo技术团队针对消息推送系统的高并发、高时效、突发流量等特点，从长连接层容灾、逻辑层容灾、流量容灾、存储容灾等方面入手，如何保证百亿级厂商消息推送平台的高可用性的。

[- 17 -] 得物从零构建亿级消息推送系统的送达稳定性监控体系技术实践

[链接] http://www.52im.net/thread-4614-1-1.html

[摘要] 本文分享的是得物针对现有的消息推送系统的消息送达耗时、实时性、稳定性等方面问题，从零到一构建完整的消息推送质量监控体系和机制的技术实践。

[- 18 -] B站千万级长连接实时消息系统的架构设计与实践

[链接] http://www.52im.net/thread-4647-1-1.html

[摘要] 本文将介绍B站基于golang实现的千万级长连接实时消息系统的架构设计与实践，包括长连接服务的框架设计，以及针对稳定性与高吞吐做的相关优化。

👉52im社区本周新文：《IM跨平台技术学习(十一)：环信基于Electron打包Web IM桌面端的技术实践》，欢迎阅读！👈

我是Jack Jiang，我为自已带盐！https://github.com/JackJiang2011/MobileIMSDK/

为了更好地分类阅读 52im.net 总计1000多篇精编文章，我将在每周三推送新的一期技术文集，本次是第 39 期。

[- 1 -] iOS的推送服务APNs详解：设计思路、技术原理及缺陷等

[链接] http://www.52im.net/thread-345-1-1.html

[摘要] 本文重点介绍APNs的设计思路、技术原理以及各种缺陷槽点，也希望能给自已设计推送系统的同行带来启发。

[- 2 -] 信鸽团队原创：一起走过 iOS10 上消息推送(APNS)的坑

[链接] http://www.52im.net/thread-862-1-1.html

[摘要] 集成推送需要注意些什么？集成之后，怎样确认自己是否正确集成了远程消息推送呢？

[- 3 -] Android端消息推送总结：实现原理、心跳保活、遇到的问题等

[链接] http://www.52im.net/thread-341-1-1.html

[摘要] 最近研究Android推送的实现, 研究了两天一夜, 有了一点收获, 写下来既为了分享, 也为了吐槽. 需要说明的是有些东西偏底层硬件和通信行业, 我对这些一窍不通, 只能说说自己的理解.

[- 4 -] 扫盲贴：认识MQTT通信协议

[链接] http://www.52im.net/thread-318-1-1.html

[摘要] MQTT（Message Queuing Telemetry Transport，消息队列遥测传输）是IBM开发的一个即时通讯协议，有可能成为物联网的重要组成部分。

[- 5 -] 一个基于MQTT通信协议的完整Android推送Demo

[链接] http://www.52im.net/thread-315-1-1.html

[摘要] 本文主要介绍的是基于MQTT实现一个简单的Android消息推送系统。更多推送技术资料请见：http://www.52im.net/forum.php?mod=collection&action=view&ctid=11

[- 6 -] 求教android消息推送：GCM、XMPP、MQTT三种方案的优劣

[链接] http://www.52im.net/thread-314-1-1.html

[摘要] 对各个方案的优缺点的研究和对比，推荐使用MQTT协议的方案进行实现，主要原因是在文中。

[- 7 -] IBM技术经理访谈：MQTT协议的制定历程、发展现状等

[链接] http://www.52im.net/thread-525-1-1.html

[摘要] MQTT（Message Queuing Telemetry Transport，消息队列遥测传输）是IBM开发的一个即时通讯协议，有可能成为物联网的重要组成部分。

[- 8 -] 移动端实时消息推送技术浅析

[链接] http://www.52im.net/thread-288-1-1.html

[摘要] 本文将从移动端无线网络的特点来谈谈实时消息推送的技术原理及相关问题，希望能给你带来些许启发。

[- 9 -]  扫盲贴：浅谈iOS和Android后台实时消息推送的原理和区别

[链接] http://www.52im.net/thread-286-1-1.html

[摘要] 本文将从原理上谈谈两个平台上实时消息推送的区别。

[- 10 -] 绝对干货：基于Netty实现海量接入的推送服务技术要点

[链接] http://www.52im.net/thread-166-1-1.html

[摘要] 通过本文的案例分析和对推送服务设计要点的总结，帮助大家在实际工作中少走弯路。

[- 11 -] 移动端IM实践：谷歌消息推送服务(GCM)研究（来自微信）

[链接] http://www.52im.net/thread-122-1-1.html

[摘要] 本文主要内容由微信开发团队人员编写，来自 WeMobileDev

[- 12 -] 为何微信、QQ这样的IM工具不使用GCM服务推送消息？

[链接] http://www.52im.net/thread-117-1-1.html

[摘要] 同样是IM软件，为什么微信不使用GCM的机制而要自己开启一个Service常驻后台轮询，并且还要使用多种方式触发该Service导致无法关闭，这种机制既耗电又浪费网络资源，微信放弃成熟的GCM推送机制而使用自身后台服务的软件是否有其他自身目的性？还是说微信某些功能必须自身常驻呢？

[- 13 -] 极光推送系统大规模高并发架构的技术实践分享

[链接] http://www.52im.net/thread-602-1-1.html

[摘要] 2016年的双十一大促改改过去，作为国内第三方推送服务的领导者，极光（JIGUANG）采取了哪些措施来应对高并发推送服务？同时，极光基于 ICE 打造高可用云推送平台，其背后有哪些技术细节值得探索？

[- 14 -] 从HTTP到MQTT：一个基于位置服务的APP数据通信实践概述

[链接] http://www.52im.net/thread-605-1-1.html

[摘要] 基于以上业务场景，如此频繁的数据交互，要达到数据的实时推送级别，该选用哪种技术？HTTP短轮询还是基于TCP的实时长连接？本文给出的答案是使用MQTT协议，请继续往下阅读。

[- 15 -] 魅族2500万长连接的实时消息推送架构的技术实践分享

[链接] http://www.52im.net/thread-723-1-1.html

[摘要] 此文内容整理自魅族架构师于小波在“魅族技术开放日”的演讲分享，本次演讲中于小波分享了魅族在实现2500万长连接的实时消息推送系统中所遇到的坑和一些心得体会，希望对实时消息推送技术相关的技术同行有所启发和帮助。

[- 16 -] 专访魅族架构师：海量长连接的实时消息推送系统的心得体会

[链接] http://www.52im.net/thread-750-1-1.html

[摘要] 本文内容来自ChinaUnix的IT名人堂对魅族系统架构师于小波的专访，于小波分享了在构建魅族海量长连接的实时消息推送系统过程中所总结出的各种心得和体会，希望对正在或即将开发消息推送系统的开发者同行带来一些启发。请往下看正文。

[- 17 -]  深入的聊聊Android消息推送这件小事

[链接] http://www.52im.net/thread-771-1-1.html

[摘要] 微信由于有国际版，将 GCM 作为辅助公共通道，但仅用于激活微信自己的 Push 通道，并没有通过 GCM 来传递数据，这点也是为了复用心跳的优化策略和数据处理逻辑。

[- 18 -] 基于WebSocket实现Hybrid移动应用的消息推送实践(含代码示例)

[链接] http://www.52im.net/thread-773-1-1.html

[摘要] 本文将围绕 Hybrid App（以Cordova为例）的 WebSocket 消息推送进行一系列的实践性探索。

👉52im社区本周新文：《社交软件红包技术解密(十三)：微信团队首次揭秘微信红包算法，为何你抢到的是0.01元》，欢迎阅读！👈

我是Jack Jiang，我为自已带盐！https://github.com/JackJiang2011/MobileIMSDK/

本文由腾讯技术何金源分享，原题“不畏移山，手机QQ技术架构升级变迁史”，本文进行了排版和内容优化等。

1、引言

接上篇《总是被低估，从未被超越，揭秘QQ极致丝滑背后的硬核IM技术优化》，本文则将重点介绍手机 QQ 客户端技术架构升级背后的故事。

手机 QQ 经过20多年发展，功能不断增加，代码不断累积，架构已经变得越来越臃肿，影响到协作团队开发效率，对用户体验、质量稳定都有较大风险，因此手机 QQ 亟需技术架构的升级。但是对如此庞大的项目进行架构升级，在行业内也是少有的，手机 QQ 架构升级面临的困难和挑战都十分巨大，本文将围绕最新手机 QQ 客户端项目背景、项目历程、项目挑战、项目成果等方面进行深入介绍。

2、手机QQ的历史包袱

在过去20多年里，手机 QQ 从原来纯粹的即时通讯IM工具，成长为承载了空间、频道、短视频、超秀、增值服务等众多业务的平台。

随着业务越来越复杂，最初设计的技术架构变得越来越不适配，业务相互之间耦合越来越严重，时常会遇到改一个问题，牵扯出 N 个问题，问题改不动，代码债越积越多的情况，历史的包袱如同一座大山横在每一位手机 QQ 项目成员面前。

2020年，我们开始着手做架构升级。

鉴于手机 QQ 的业务复杂度、代码量级都非常大，评估下来架构升级的工作量大得惊人，于是我们采用分阶段、逐步演进的策略去进行架构升级。

整体回顾，手机 QQ 的架构升级时间线是这样的：

3、“解耦重构”架构设计

虽然历史包袱如同一座大山，但是手机 QQ 项目成员也有移山的意志和决心。

在2020年，手机 QQ 启动了名为“工业化实践”的技术架构升级项目，这标志着手机 QQ 工程首次系统性地进行业务边界划分、解耦和重构升级。

从上图可看出，旧架构虽然有模块化和插件化，但存在以下不足：

• 1）边界不清晰：主工程承载基础和大部分业务代码，导致基础和业务代码边界不清晰；
• 2）代码耦合紧：基础核心类持续膨胀、业务之间代码依赖不合理；
• 3）开发效率低：代码修改扩散造成 CR、解冲突、定位问题成本高，同时拖慢编译速度。

针对以上不足，对手机 QQ 工程重新设计了架构：

1）新架构按业务划分模块，业务模块之间是相互解耦的，业务模块之间通过接口和路由进行通信；

2）同时按层级设计划分，层级自上而下依赖，上层模块可依赖下层模块，但下层模块不能逆向依赖上层模块。

手 Q 客户端新架构：

新架构的主要收益：

• 1）模块更加内聚：新特性开发影响范围逐步收敛到模块内部，提升研发效率；
• 2）接口更加清晰：依赖数减少，可测性提升，更易于通过单元测试、接口测试保障代码逻辑正确性，提升产品质量。

4、“解耦重构”的实践历程

4.1概述

手机 QQ 工程各个业务之间的依赖非常严重，对它进行解耦重构不是一蹴而就的事情，需要按阶段制定目标，一步一步地优化。

通过整理，手机 QQ 工程解耦重构划分为以下三个阶段。

4.2阶段一（2020.11 - 2021.2）

基本完成约300万行核心代码的解耦，一共约30个基础模块和40个基础组件完成解耦，核心业务模块基本完成解耦。

开发新功能时，因为接口与服务实现是隔离的，通过接口依赖的代码不会再耦合严重。

4.3阶段二（2021.3 - 2021.6）

目标：业务模块继续解耦，建设防劣化机制。

成果：

• 1）API 代码占比与依赖数不增加；
• 2）完成防劣化机制搭建，在合入阶段拦住不合理修改；
• 3）完善动态化能力，优化插件与宿主间通信机制和发布效率。

4.4阶段三（2021.7 以后）

目标：进一步完善基础模块和组件化，实现子工程化。

成果：

• 1）完善基础模块和公共组件重构，建立基础模块发布组件流程；
• 2）对频道、小世界业务实现子工程化，独立编译运行。

5、“解耦重构”的技术收益

在重构基础上，梳理依赖关系，通过三个阶段改善模块化水平，提高编译速度和研发效率，流水线的编译耗时提升50%。

代码冲突方面也得到明显改善，对比重构前后数据，冲突文件数减少60%，冲突次数减少30%，大大提升开发效率。

6、手机QQ下一代架构：NT架构

在成功迈出改革的第一步之后，我们将注意力转向了手机 QQ 面临的版本碎片化问题。

不同端各自发展，形成了所谓的“烟囱式”结构，其中代码的复用率极低。这种结构带来了多端体验不一致、端内业务体验参差不齐以及每次版本更新时高昂的开发和维护成本等问题。

为了解决这些问题，并在提升用户体验、优化性能和提高研发效率方面实现突破，我们不得不深入思考。

正是这些迫切的需求和挑战促使我们启动了改革的第二步——推进手机 QQ NT 架构升级项目。

在 NT 架构设计之初，我们坚定认为不应该继续缝缝补补，而是应该采用最新且合理的技术理念，摒弃了简单的修补式方法。这次升级不仅是技术上的一次大刀阔斧的改造，更是一场深思熟虑的技术转型。

我们重视在不造成架构大规模动荡的前提下，制定了一条清晰、可行的实施路径。目标是以更少的人力投入实现更高的工作效率和成果，确保了升级过程中的高效和稳健。这种方法不仅保证了项目的顺利进行，也为未来的技术发展和迭代奠定了坚实的基础。

7、NT架构落地之难

由于手机 QQ 的历史悠久且拥有庞大的用户群，该项目在业务和用户层面都展现了巨大的复杂性。

具体来看，项目层面的挑战包括：

• 1）代码总量庞大：手机端代码近千万行，形成了一个技术上的庞然大物；
• 2）测试复杂性高：测试用例众多，功能繁杂，且存在部分文档缺失的情况；
• 3）依赖组件过时：项目中依赖了一些陈旧且缺乏维护的组件，以及大量无人维护的二进制库；
• 4）研发流程保障：在进行架构升级的同时，必须确保研发工作流程能够平稳过渡，以免影响到研发效率。

用户层面上的挑战则包括：

• 1）在长达一年以上的升级过程中，日常版本需要正常迭代；
• 2）用户本地数据量巨大，如超过 10G 的本地消息数据库；
• 3）项目需在技术优化的同时提升用户体验与活跃度，确保技术优化在用户端实现价值。

面对这些复杂度，项目的核心难点主要集中在以下三个方面。

1）海量功能项目的架构升级和统一：针对全终端、全功能和全项目团队的整体升级，确保架构升级过程中不能有任何缺失。手机 QQ 是在发展了20多年进行彻底重构，难度空前，没有资料可参考。

2）IM 全链路架构重写升级：解决陈年技术债，优化消息架构，平稳迁移用户历史数据，并提升消息性能。QQ 消息架构有陈年技术债，很多 QQ 历史版本里，没有统一的消息 ID 生成规则，没有统一的存储和索引方案，消息类型也是无序扩张。所以，既需要对IM全链路重写优化，同时在过程中，还需要平稳迁移用户历史数据，最终完成升级，保护用户数据、用户体验不受影响。

3）用户体验提升与活跃数据提升：逐步优化核心功能体验，不影响用户习惯，通过提升体验推动产品数据增长。代码的重写不能全盘一次性推倒重来。核心功能体验要保持，逐步优化，不能影响用户使用习惯。

这些挑战不仅说明了手机 QQ NT 架构升级项目的复杂性，也证明了我们在面对前所未有的技术难题时的决心。

8、NT架构设计

为了实现架构升级和统一，项目团队先用 C++ 开发了具备 QQ IM 核心功能的跨平台内核层：把 IM 核心业务逻辑（好友、群、频道等消息逻辑、资料与关系链逻辑、图片语音视频等富媒体收发逻辑、实时音视频逻辑等），QQ 通用组件（数据库、协议编解码、网络传输等），以及线程/网络/IO 等通用资源管理模块和操作系统封装部分，由原来的各平台原生语言实现，统一下沉到 C++ 跨平台层。

为了控制项目质量风险，NT 跨平台内核先接入用户量相对较少，对功能补齐紧迫度高的桌面端，完全用新架构重写桌面端。

在桌面端成功完成功能验证和质量测试之后，我们开始了向移动端的迁移工作，并顺利完成了 iOS 和安卓平台的集成。

当然，移动端的接入远远不像图中描述的这般容易，接下来将介绍其中的解决方案和主要过程。

9、 IM客户端全链路重写升级

在新的 NT 架构基础上，对 QQ 来说，最核心的技术升级，是 IM 全链路的升级。

IM 消息数据源复杂，历史包袱很重，升级过程的遇到的第一个难点就是数据转换及存量数据迁移到新版本问题。

比如：

• 1）老版本的 QQ，好友消息没有唯一标识字段，导入和去重影响大；
• 2）2012年以前的版本，群消息没有支持漫游，消息无唯一字段；
• 3）各平台消息数据格式不同，复杂度高，iOS 和 Android 分别有约200种消息类型；
• 4）富媒体（图片、视频、语音、文件）资源，存储的目录结构、命名都不同；
• 5）特殊消息，如结构化消息、Ark 消息、小灰条消息，需要做转换，完成业务的梳理和下架工作；
• 6）还有因为各种功能的变迁带来的遗留数据问题，如已经退出或者解散的群和讨论组等。

所以，首先需要做 IM 的精简。项目团队基于用户价值考虑，零基思维，完成消息格式统一，对消息和会话类型进行彻底精简，为 QQ 消息长治久安打下基础。

有了全端格式统一和类型精简的基础，开始用大小、性能、安全性综合最优方案设计跨平台统一的全新客户端 DB，然后再考虑旧 DB 的数据，如何平稳升级到新 DB。

移动端和桌面端不同，活跃用户全年在线，有些手机本地纯文本消息的 DB 文件超过10G，加上富媒体、文件等，总数据量超过100G，而且移动端又有存储空间小、功耗敏感、后台杀进程等多方面限制，需要设计出一套周密的升级策略，保护用户核心数据资产不丢失。

方案核心要点：

• 1）断点续导：移动端场景，进程随时可能被杀或退出。确保消息不丢失、不重复；
• 2）用户分级：跟进消息数据大小，用户分为三类，做不同的体验优化，减少对用户的影响；
• 3）优化发烫和耗电：限制导入速度，防止手机发烫。手机切后台后停止导入。对消息数据多的用户，引导用户设置在后台导入；
• 4）监控：做好各种导入异常上报监控，随时跟进用户反馈。

通过设计周密的升级策略，内部多轮推演，外部从百级开始放量，全方位监控，并用兜底策略保障不丢消息。最终结合监控数据和用户反馈数据，完成了全量用户的全量数据平稳迁移新 DB。

10、客户端核心功能优化提升

不仅是消息，在 NT 架构重写升级过程中，对 QQ 核心功能也一起做了更彻底的重构，手机 QQ 原生功能进行了大规模解耦，通用的部分进行优化并下沉为统一的 NT-Runtime 原生组件（NT 组件服务及框架层）。基于重构后的架构，也对性能进行全面优化。

首先是消息相关核心模块的优化。

消息逻辑下沉到 C++ 跨平台，也推动上层进行架构刷新。

以聊天窗口（AIO）为例：基于全新数据流架构 + 数据预加载 + UI 逻辑并行化的设计思路，完成单向数据流驱动与异步加载渲染，系统资源全力供给 AIO 消息列表，最终性能指标提升明显，AIO 内查看、跳转、滑动消息，顺畅丝滑。

核心技术优化方案：

• 1）采用基于单向数据流的 MVI 架构，实现业务解耦；
• 2）预加载和异步渲染，实现消息无缝滑动；
• 3）消息加载并行化，减少首屏和滑动时的加载时间；
• 4）消息动态加载、释放，优化内存占用。
• 5）200+业务组件懒加载，实现数据分层和按需加载。

其它 QQ 主场景，如消息列表页、消息与富媒体收发、图片视频查看等，也采用相同的路径进行优化，最终性能全面提升。

11、本文小结

在手机 QQ 超过20年的发展历程中，应用功能的不断扩展和代码量的持续增长积累了巨大的技术债务，给原有的客户端架构带来了沉重的负担。最新版手机QQ通过一系列的架构演变和技术升级，成功地实现了从臃肿不堪到模块化、高效、稳定的转变。

客户端架构由各端烟囱式架构逐步升级为多端跨平台复用的 NT 架构，降低多端维护人力成本，提升 QQ 全端开发效率，为 QQ 的持续发展和技术迭代打下了坚实的基础。

展望未来，QQ 将基于 NT 架构，在技术创新的道路上继续前行，不断进行架构优化和技术升级，为用户提供更加流畅稳定的产品体验。

12、相关资料

[1] 总是被低估，从未被超越，揭秘QQ极致丝滑背后的硬核IM技术优化

[2] 大型IM工程重构实践：企业微信Android端的重构之路

[3] 企业微信针对百万级组织架构的客户端性能优化实践

[4] 微信团队分享：详解iOS版微信视频号直播中因帧率异常导致的功耗问题

[5] 腾讯技术分享：Android版手机QQ的缓存监控与优化实践

[6] 腾讯技术分享：Android手Q的线程死锁监控系统技术实践

[7] 全面解密新QQ桌面版的Electron内存优化实践

[8] 移动端IM实践：iOS版微信界面卡顿监测方案

[9] 微信团队原创分享：Android版微信的臃肿之困与模块化实践之路

[10] 微信Windows端IM消息数据库的优化实践：查询慢、体积大、文件损坏等

[11] 微信团队分享：微信支付代码重构带来的移动端软件架构上的思考

[12] 微信客户端团队负责人技术访谈：如何着手客户端性能监控和优化

[13] 抖音技术分享：飞鸽IM桌面端基于Rust语言进行重构的技术选型和实践总结

[14] 阿里技术分享：闲鱼IM基于Flutter的移动端跨端改造实践

[15] QQ设计团队分享：新版 QQ 8.0 语音消息改版背后的功能设计思路

13、更多鹅厂技术文章汇总

1. 微信朋友圈千亿访问量背后的技术挑战和实践总结
2. 腾讯技术分享：腾讯是如何大幅降低带宽和网络流量的(图片压缩篇)
3. IM全文检索技术专题(二)：微信移动端的全文检索多音字问题解决方案
4. 微信团队分享：iOS版微信的高性能通用key-value组件技术实践
5. 微信团队分享：iOS版微信是如何防止特殊字符导致的炸群、APP崩溃的？
6. 微信团队分享：微信Android版小视频编码填过的那些坑
7. IM全文检索技术专题(一)：微信移动端的全文检索优化之路
8. 企业微信客户端中组织架构数据的同步更新方案优化实战
9. 微信新一代通信安全解决方案：基于TLS1.3的MMTLS详解
10. 微信“红包照片”背后的技术难题
11. 移动端IM实践：iOS版微信的多设备字体适配方案探讨
12. 腾讯信鸽技术分享：百亿级实时消息推送的实战经验
13. IPv6技术详解：基本概念、应用现状、技术实践（上篇）
14. 腾讯技术分享：GIF动图技术详解及手机QQ动态表情压缩技术实践
15. 微信团队分享：Kotlin渐被认可，Android版微信的技术尝鲜之旅
16. 社交软件红包技术解密(一)：全面解密QQ红包技术方案——架构、技术实现等
17. 社交软件红包技术解密(四)：微信红包系统是如何应对高并发的
18. 社交软件红包技术解密(十)：手Q客户端针对2020年春节红包的技术实践
19. 微信团队分享：极致优化，iOS版微信编译速度3倍提升的实践总结
20. IM“扫一扫”功能很好做？看看微信“扫一扫识物”的完整技术实现
21. 微信团队分享：微信支付代码重构带来的移动端软件架构上的思考
22. IM开发宝典：史上最全，微信各种功能参数和逻辑规则资料汇总
23. 微信团队分享：微信直播聊天室单房间1500万在线的消息架构演进之路
24. 企业微信的IM架构设计揭秘：消息模型、万人群、已读回执、消息撤回等
25. IM全文检索技术专题(四)：微信iOS端的最新全文检索技术优化实践
26. 微信团队分享：微信后台在海量并发请求下是如何做到不崩溃的
27. 微信Windows端IM消息数据库的优化实践：查询慢、体积大、文件损坏等
28. 微信技术分享：揭秘微信后台安全特征数据仓库的架构设计
29. IM跨平台技术学习(九)：全面解密新QQ桌面版的Electron内存优化实践
30. 企业微信针对百万级组织架构的客户端性能优化实践
31. 揭秘企业微信是如何支持超大规模IM组织架构的——技术解读四维关系链
32. 微信团队分享：详解iOS版微信视频号直播中因帧率异常导致的功耗问题
33. 微信团队分享：微信后端海量数据查询从1000ms降到100ms的技术实践
34. 大型IM工程重构实践：企业微信Android端的重构之路
35. IM技术干货：假如你来设计微信的群聊，你该怎么设计？
36. 微信团队分享：来看看微信十年前的IM消息收发架构，你做到了吗
37. 长连接网关技术专题(十一)：揭秘腾讯公网TGW网关系统的技术架构演进

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