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