Jack Jiang

我的最新工程MobileIMSDK:http://git.oschina.net/jackjiang/MobileIMSDK
posts - 433, comments - 13, trackbacks - 0, articles - 0

2024年5月9日

     摘要: 本文由环信技术黄飞鹏分享,原题“实战|如何利用 Electron 快速开发一个桌面端应用”,本文进行了排版和内容优化等。1、引言早就听说利用Electron可以非常便捷的将网页端快速打包成桌面应用,并且利用 Electron 提供的 API 调用可以使用原生桌面 API 一些高级功能。于是这次借着论证 Web IM端 SDK 是否可以在 Electron 生成的桌面端正常稳...  阅读全文

posted @ 2024-06-13 11:53 Jack Jiang 阅读(12) | 评论 (0)编辑 收藏

为了更好地分类阅读 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聊天等系统的技术同行带来一些启发。


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

[链接] 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/

posted @ 2024-06-12 14:54 Jack Jiang 阅读(20) | 评论 (0)编辑 收藏

     摘要: 本文由腾讯梁中原分享,原题“红包算法揭秘!哪段代码让你只抢了0.01元?”,下文进行了排版和内容优化等。1、引言在上一篇《来看看微信十年前的IM消息收发架构,你做到了吗》的文章中,有用户提到想了解自己每次微信红包只能抽中 0.01 元的反向手气最佳是怎么在技术上实现的,于是就有了本篇文章的诞生。其实,微信红包最初在产品设计上有过很多思路,最初曾以多档次、按比例分配的方式,但...  阅读全文

posted @ 2024-06-06 12:45 Jack Jiang 阅读(33) | 评论 (0)编辑 收藏

为了更好地分类阅读 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/

posted @ 2024-06-05 11:56 Jack Jiang 阅读(7) | 评论 (0)编辑 收藏

本文由腾讯技术何金源分享,原题“不畏移山,手机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

posted @ 2024-05-30 10:24 Jack Jiang 阅读(40) | 评论 (0)编辑 收藏

     摘要: 本文由腾讯云开发者张曌、毕磊分享,原题“QQ 9“傻快傻快”的?!带你看看背后的技术秘密”,本文进行了排版和内容优化等。1、引言最新发布的 QQ 9 自上线以来,流畅度方面收获了众多用户好评,不少用户戏称 QQ 9 “傻快傻快”的,快到“有点不习惯了都”。作为庞大量级的IM应用,QQ 9 从哪些方面做了...  阅读全文

posted @ 2024-05-23 14:20 Jack Jiang 阅读(68) | 评论 (0)编辑 收藏

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

[- 1 -] 高仿Android版手机QQ首页侧滑菜单源码 [附件下载]

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

[摘要] 本文分享的源码高仿了手机QQ的这个效果,希望可以为有相同需求的IM开发者同行节省点撸码时间。


[- 2 -] 开源libco库:单机千万连接、支撑微信8亿用户的后台框架基石 [源码下载]

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

[摘要] libco在2013年的时候作为腾讯六大开源项目首次开源,ibco支持后台敏捷的同步风格编程模式,同时提供系统的高并发能力。


[- 3 -] 分享java AMR音频文件合并源码,全网最全

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

[摘要] 分享java AMR音频文件合并源码,全网最全。


[- 4 -]微信团队原创Android资源混淆工具:AndResGuard [有源码]

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

[摘要] 本文主要是讲述资源混淆组件的用法以及性能,资源混淆组件不涉及编译过程,只需输入一个apk,可得到一个实现资源混淆后的apk


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

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

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


[- 6 -] Android版高仿微信聊天界面源码 [附件下载]

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

[摘要] 微信的聊天界面是挺漂亮的,每条消息都带一个气泡,给人一种很清新的感觉,其实实现起来也不是那么的难,下面我们就来实现一下。


[- 7 -] 高仿手机QQ的Android版锁屏聊天消息提醒功能 [附件下载]

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

[摘要] 今天为大家带来的是,可以在锁屏下弹窗显示消息来提醒用户,可用于移动端IM或消息推送应用中。


[- 8 -] 高仿iOS版手机QQ录音及振幅动画完整实现 [源码下载]

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

[摘要] 高仿iOS版手机QQ聊天界面中录音及振幅动画。


[- -]  Android端社交应用中的评论和回复功能实战分享[图文+源码]

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

[摘要] 页面整体采用了CoordinatorLayout来实现详情页的顶部视差效。同时,这里我采用ExpandableListView来实现多级列表,然后再解决它们的嵌套滑动问题。


[- 10 -] Android端IM应用中的@人功能实现:仿微博、QQ、微信,零入侵、高可扩展[图文+源码]

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

[摘要] 网上已经有一些文章分享了类似功能实现逻辑,但是几乎都是扩展EditText类,这种实现方式肯定不能进入我的首发阵容。你以为是因为它不符合面向对象六大原则?错,只因为它不够优雅!不够优雅!不够优雅!


[- 11 -] 仿微信的IM聊天时间显示格式(含iOS/Android/Web实现)[图文+源码]

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

[摘要] 作为移动端IM的王者,微信无疑处处是标杆,所以本次的消息时间显示格式,直接参照微信的实现逻辑准没错(随大流虽然没个性,但不至于非主流)。


[- 12 -] Android版仿微信朋友圈图片拖拽返回效果 [源码下载]

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

[摘要] 目前的app的动画效果是越来越炫了,很多主流app的图片预览返回都有类似功能,比较常见的是ios自带相册,微信朋友圈等等。自己项目中也有类似功能,最近整理了一下这个功能的代码,做个笔记记录,有兴趣的朋友可以在文末附件下载源码。


[- 13 -] 手把手教你实现网页端社交应用中的@人功能:技术原理、代码示例等

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

[摘要] 本文分享的@人功能是针对Web网页前端的,跟移动端原生代码的实现,从技术原理和实际实现上,还是有很大差异,所以如果想了解移动端IM这种社交应用中的@人实现功能,可以读一下《Android端IM应用中的@人功能实现:仿微博、QQ、微信,零入侵、高可扩展[图文+源码]》这篇文章。


[- 14 -] SpringBoot集成开源IM框架MobileIMSDK,实现即时通讯IM聊天功能

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

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


[- 15 -] 基于Netty,徒手撸IM(一):IM系统设计篇

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

[摘要] 本篇主要是徒手撸IM系列的开篇,主要讲解的是的IM设计思路,不涉及实践编码,希望给你带来帮助。


👉52im社区本周新文:《总是被低估,从未被超越,揭秘QQ极致丝滑背后的硬核IM技术优化》,欢迎阅读!👈

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

posted @ 2024-05-22 13:53 Jack Jiang 阅读(54) | 评论 (0)编辑 收藏

本文由哔哩哔哩资深开发工程师黄山成分享,原题“千万长连消息系统”,本文进行了排版和内容优化等。

1、引言

在当今数字娱乐时代,弹幕已经成为直播平台上不可或缺的互动元素之一。

用户通过发送弹幕、送礼等,可以实时在直播画面上展现自己的想法、评论和互动内容,从而丰富了用户观看体验。在这个过程中,实时向终端推送互动信息,就需要用到长连接。

长连接,顾名思义,是应用存活期间和服务端一直保持的网络数据通道,能够支持全双工上下行数据传输。其和请求响应模式的短连接服务最大的差异,在于它可以提供服务端主动给用户实时推送数据的能力。

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

 
 
 技术交流:

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

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

(本文已同步发布于:http://www.52im.net/thread-4647-1-1.html

2、关联文章

3、架构设计

3.1概述

长连接服务是多业务方共同使用一条长连接。

因为在设计时,需要考虑到不同业务方、不同业务场景对长连接服务的诉求,同时也要考虑长连接服务的边界,避免介入业务逻辑,影响后续长连接服务的迭代和发展。

长连接服务主要分为三个方面:

  • 1)长连接建立、维护、管理;
  • 2)下行数据推送;
  • 3)上行数据转发(目前只有心跳,还没实际业务场景需求)。

3.2整体架构

长连接服务整体构架如上图所示,整体服务包含以下几个部分。

1)控制层:建连的前置调用,主要做接入合法性校验、身份校验和路由管控。

主要职责:

  • 1)用户身份鉴权;
  • 2)加密组装数据,生成合法token;
  • 3)动态调度分配接入节点。

2)接入层:长连接核心服务,主要做卸载证书、协议对接和长连接维护。

主要职责:

  • 1)卸载证书和协议;
  • 2)负责和客户端建立并维护连接,管理连接id和roomid的映射关系;
  • 3)处理上下行消息。

3)逻辑层:简化接入层,主要做长连的业务功能。

主要职责:

  • 1)在线人数上报记录;
  • 2)记录连接ID各属性和各节点的映射关系。
  • 4)消息分发层:消息推送到接入层。

主要职责:

  • 1)消息封装、压缩和聚合推送给相应的边缘节点;

5)服务层:业务服务对接层,提供下行消息推送入口。

主要职责:

  • 1)管控业务推送权限;
  • 2)消息检测和重组装;
  • 3)消息按一定策略限流,保护自身系统。

3.3核心流程

长连接主要是3个核心流程:

  • 1)建立连接:由客户端发起,先通过控制层,获取该设备合法的token和接入点配置;
  • 2)维持连接:主要是客户端定时发起心跳,来保证长连接活跃;
  • 3)下行推送:下行推送由业务Server发起,经由服务层根据相关标识确定连接标识和接入节点,经过消息分发层,把推送到对应的接入层,写入到指定连接上,然后下发到客户端。

3.4功能列表

结合B站业务场景,下行数据推送,提供如下通用功能:

  • 1)用户级消息:指定推送给某些用户(比如给某个主播发送邀请pk消息);
  • 2)设备级消息:制定推送给某些设备(比如针对未登陆的设备,推送客户端日志上报指令);
  • 3)房间级消息:给某房间内的连接推送消息(比如给直播间的所有在线用户推送弹幕消息);
  • 4)分区消息:给某分区的房间推送消息(比如给某个分区下,所有开播的房间,推送某个营收活动);
  • 5)全区消息:给全平台用户推送消息(比如给全部在线用户推送活动通知)。

4、高吞吐技术设计

随着业务发展壮大,在线用户越来越多,长连系统的压力越来越大,尤其是热门赛事直播,比如s赛期间,全平台在线人数快达到千万,消息吞吐量有上亿,长连系统消息分发平均延迟耗时在1s左右,消息到达率达到99%,下面具体分析下长连做了哪些措施。

4.1网络协议

选择合适的网络协议对于长连接系统的性能至关重要:

  • 1)TCP协议:可以提供可靠的连接和数据传输,适用于对数据可靠性要求较高的场景;
  • 2)UDP协议:是一个不可靠的协议,但是传输效率高,适用于对数据可靠性要求不高的场景;
  • 3)WebSocket协议:也是实现双向通信而不增加太多的开销,更多的用于web端。

接入层拆分成协议模块和连接模块:

  • 1)协议模块:和具体的通讯层协议交互,封装不同通讯协议的接口和逻辑差异。
  • 2)连接模块:维护长连接业务连接状态,支持请求上行、下行等业务逻辑,维护连接各属性,以及和房间id的绑定关系。

针对以上第 1)点,协议模块同时给连接模块提供统一的数据接口,包括连接建立、数据读取、写入等。后续增加新协议,只要在协议模块做适配,不影响其他模块的长连业务逻辑。

优势在于:

  • 1)业务逻辑和通讯协议做了隔离,方便迭代增加通讯协议,简化兼容多通讯协议的实现难度;
  • 2)控制层可以根据客户端的实际情况,下发更优的通讯协议。

4.2负载均衡

采用负载均衡技术可以将请求分发到不同的服务器节点上处理,避免了单一节点的负载过高,提高了系统的扩展性和稳定性。

长连增加控制层,做负载均衡。控制层提供http短连接口,基于客户端和各边缘节点实际情况,根据就近原则,动态选择合适的接入节点。

接入层支持水平扩展,控制层可以实时增加、减少分配节点。在S赛期间,在线人数快到达千万时,平衡调度各接入节点,保障了各节点的CPU和内存都在稳定的范围内。

4.3消息队列

消息推送链路是:业务发送推送,经过服务层推到边缘节点,然后下发给客户端。

服务层实时分发到各边缘节点,如果是房间类型消息,需要推到多个边缘节点,服务层同时还要处理业务逻辑,很影响消息的吞吐量。

所以增加消息队列和消息分发层,消息分发层维护各边缘节点信息和推送消息,提高了系统的并发处理能力和稳定性,避免了因消息推送阻塞而导致的性能问题。

4.4消息聚合

当有热门赛事时,同时在线可能达到千万级别,一条弹幕消息就要扩散到千万个终端,假如在线的每个人每秒发一条,需要发送消息量就是1kw*1kw,消息量非常大,此时消息分发层和接入层,压力都会很大。

分析发现:这些消息都是同一个房间的,属于热点房间,比如s赛房间,观众数量是无法减少的,那只能在消息数上做文章。业务消息推送不能减少,又要减少扩散的消息数,就想到了消息聚合。

针对房间消息,按照一定的规则进行消息聚合,批量推送:

消息聚合上线后,消息分发层对接入层调用QPS下降60%左右,极大的降低了接入层和消息分发层的压力。

4.5压缩算法

消息聚合后,降低了消息的数量,但是增加了消息体的大小,影响了写入IO,需要减少消息体大小,就想到了消息压缩。

压缩算法,选了市面上比较常用的两个:zlib和brotli,进行比较。

抓取了线上业务推送的数据,选择最高等级的压缩等级,进过压缩验证:

由此可见,brotli相比zlib有很大的优势,最后选择了brotli压缩算法。

选择在消息分发层进行消息压缩,避免在各接入节点多次重复压缩,浪费性能。上线后提升吞吐量的同时,也降低的宽带使用成本。

5、服务保障技术设计

现在有些业务是强依赖长连推送消息,消息丢失,轻则影响用户体验,重则阻塞业务后续流程,进而影响业务流水。针对长连服务消息保障,做了如下工作。

5.1多活部署

多活部署,通过在不同地理位置部署相同的系统架构和服务,实现了系统在单一地域故障时的快速故障转移,从而提高了系统的稳定性和可用性。

长连服务部署,主要做了以下几点:

  • 1)长连接在国内华东、华南、华北地域均部署了接入点,支持三大运营商;华南和华中自建机房也部署了接入点;为支持海外用户,增加了新加坡机房独立接入点;
  • 2)针对业务场景不同,在云上节点和自建节点之间,实时切换,因为云上节点和自建机房的成本是不一样的,在保证服务质量的前提下,尽可能的控制成本。

目前线上运行过程中,偶尔会遇到单节点或机房的网络抖动,通过控制层,对有问题的节点,进行秒级摘流,大大减少了对业务的影响。

5.2高低消息通道

多业务消息接入长连接,但不同消息之间的重要性是不一样的,比如弹幕消息和邀请pk消息,丢失几条弹幕对用户体验不会影响很大,但如果邀请pk消息丢失,则会导致pk业务无法进行后续的流程。

针对不同等级的消息,采用了高低优消息通道。重要消息走高优通道,普通消息走低优通道。这样重要和普通消息进行了物理隔离,消息分发优先保证重要消息。

针对高优通道,做了双投递的保障,在接入层做幂等去重。首先重要消息是针对用户级别的,量不会很大,所以对接入层的压力不会增加很大。另外双投递的job是部署在多机房的,这也就降低单机房网络抖动造成的影响。

高低优通道上线后,遇到过内网出网抖动,当时内网部属的job节点推送消息异常,而云上高优job节点可正常推送,很好的保障了高优消息的到达,进而保障了高优业务不受影响。

5.3高达功能

高低优通道解决的是job到接入层的这一个环节,但消息推送联路涉及到多个环节,比如服务层到job、接入层到客户端。

针对整个链路,通过实现必达机制来确保终端的到达率,简称高达功能。

功能实现:

  • 1)每条消息引入msgID,客户端收到消息后进行幂等去重和ack回执;
  • 2)服务端针对msgid进行ack检测,针对未ack的,有效期内再次重试下发。

最终到达率 = (1-(1-r)^(n+1)),其中:r为广播单次到达率,n为最大重试次数。

例如:r = 97%、n=2,那么最终到达率可以达到(1-(1-0.97)^(2+1)) = 99.9973%

6、进出”房“消息的送达保证设计

有些业务场景,需要用到用户进出房消息,比如用户A进入直播间,页面会显示欢迎用户A进入房间,或者是加入在线榜单。

1)进房消息会存在丢失,需要有补偿机制。想到可以通过连接心跳来补偿进房消息,但心跳是持续不断的,连接在线期间,业务希望只收到一次进房消息,所以进房消息需要有幂等机制。

2)出房消息也会存在丢失,如果丢失了,业务无法从在线榜单剔除用户,此时也需要有补偿机制。此时就需要增加连接的状态机,通过心跳维护状态机,当心跳丢失时,认为连接断开,用户退房。

7、未来规划

统一长连接服务经历数次迭代后,目前基本功能已经趋于稳定,后续对长连接服务进行改善和优化。

主要集中在以下几个方向:

  • 1)数据化:进一步完善长连接全链路网络质量数据统计和高价值消息全链路追踪的能力;
  • 2)智能化:端上建联、接入点选择等能够根据实际环境进行自动化调整;
  • 3)性能优化:接入层的连接模块中,处理上下行消息的携程进行共享,减少接入层的携程数,进一步提升单机性能和连接数;
  • 4)功能扩展:新增离线消息功能等。

8、参考资料

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

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

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

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

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

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

[7] WebSocket从入门到精通,半小时就够!

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

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

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

[11] 到底什么是Socket?一文即懂!

[12] 我们在读写Socket时,究竟在读写什么?

[13] 假如你来设计TCP协议,会怎么做?

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

[15] 通俗易懂,高性能服务器到底是如何实现的

[16] 12306抢票带来的启示:看我如何用Go实现百万QPS的秒杀系统(含源码)


(本文已同步发布于:http://www.52im.net/thread-4647-1-1.html

posted @ 2024-05-16 11:44 Jack Jiang 阅读(68) | 评论 (0)编辑 收藏

一、更新内容简介

本次更新为次要版本更新,进行了bug修复和优化升级(更新历史详见:码云 Release NotesGithub Release Notes)。

MobileIMSDK 可能是市面上唯一同时支持 UDP+TCP+WebSocket 三种协议的同类开源IM框架。轻量级、高度提炼,历经10年、久经考验。客户端支持iOSAndroidJavaH5微信小程序Uniapp,服务端基于Netty

二、MobileIMSDK简介

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

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

MobileIMSDK工程始于2013年10月,历经10年,起初用作某产品的即时通讯底层实现,完全从零开发,技术自主可控!

您可能需要:查看关于MobileIMSDK的详细介绍

三、源码托管同步更新

OsChina.net

GitHub.com

四、MobileIMSDK设计目标

让开发者专注于应用逻辑的开发,底层复杂的即时通讯算法交由SDK开发人员,从而解偶即时通讯应用开发的复杂性。

五、MobileIMSDK框架组成

整套MobileIMSDK框架由以下7部分组成:

  1. Android客户端SDK:用于Android版即时通讯客户端,支持Android 4.0及以上,查看API文档
  2. iOS客户端SDK:用于开发iOS版即时通讯客户端,支持iOS 12.0及以上,查看API文档
  3. Java客户端SDK:用于开发跨平台的PC端即时通讯客户端,支持Java 16及以上,查看API文档
  4. H5客户端SDK查看精编注释版
  5. 微信小程序端SDK查看精编注释版
  6. Uniapp端SDK查看精编注释版
  7. 服务端SDK:用于开发即时通讯服务端,支持Java 1.7及以上版本,查看API文档

整套MobileIMSDK框架的架构组成:

 另外:MobileIMSDK可与姊妹工程 MobileIMSDK-Web 无缝互通,从而实现Web网页端聊天或推送等。

六、MobileIMSDK v6.5更新内容 

【重要说明】:

MobileIMSDK v6.5 为次要版本,进行了若干优化! 查看详情 (github

【新增重要特性】:

  • 1. [Android端] 新增了Demo中当APP处于后台时,收到消息时显示系统通知的功能。

【解决的Bug】:

  • 1. [服务端] 尝试解决极小几率下Android端会误把“自已”踢掉的问题。

【其它优化和提升】:

  • 1. [服务端] 升级了log4j2等基础库,解决基础库低版中带来的安全漏洞风险;
  • 2. [服务端] 服务端SDK和Demo工程已迁移至IDEA;
  • 3. [Java端] Java桌面端的TCP和UDP两种协议的SDK和Demo工程已迁移至IDEA;
  • 4. [Android端] 提升targetSdkVersion至34(即Android 14);
  • 5. [Android端] 解决了Demo中绑定前台服务在Android 14中崩溃等问题。
  • 6. [iOS端] 提升最低系统支持版本为iOS 12;
  • 7. [iOS端] 优化了JSON解析库中的一处过时API调用。

【最新版本源码地址】:

七、Demo运行演示

八、技术应用示例

8.1 示例1:基于MobileIMSDK的移动端IM RainbowChat更多运行截图):

 

8.2 示例2:基于MobileIMSDK-Web的Web端IM RainbowChat-Web更多运行截图):

 

posted @ 2024-05-09 11:34 Jack Jiang 阅读(59) | 评论 (0)编辑 收藏

Jack Jiang的 Mail: jb2011@163.com, 联系QQ: 413980957, 微信: hellojackjiang