1 歷史包袱
2 解耦重構
3 NT 架構升級
4 總結
本文是 QQ 25 周年技術巡禮系列的最終章，在前兩篇文章中,，我們以《QQ 25年技術巡禮丨技術探索下的清新設計,，打造輕盈簡約的 QQ9 》和《QQ 9“傻快傻快”的？,！帶你看看背后的技術秘密》為題,，介紹了QQ 團隊在視覺打磨、性能優(yōu)化背后的探索,，本文則將重點介紹手機 QQ 技術架構升級背后的技術故事,。
手機 QQ 經過20多年發(fā)展，功能不斷增加,，代碼不斷累積,，架構已經變得越來越臃腫，影響到協(xié)作團隊開發(fā)效率,，對用戶體驗,、質量穩(wěn)定都有較大風險，因此手機 QQ 亟需技術架構的升級,。但是對如此龐大的項目進行架構升級,，在行業(yè)內也是少有的，手機 QQ 架構升級面臨的困難和挑戰(zhàn)都十分巨大,，本文將圍繞項目背景、項目歷程、項目挑戰(zhàn),、項目成果等方面進行深入介紹,。
01、歷史包袱
在過去20多年里,，手機 QQ 從原來純粹的即時通訊工具,，成長為承載了空間、頻道,、短視頻,、超秀、增值服務等眾多業(yè)務的平臺,。隨著業(yè)務越來越復雜,，最初設計的技術架構變得越來越不適配，業(yè)務相互之間耦合越來越嚴重,，時常會遇到改一個問題,，牽扯出 N 個問題，問題改不動,，代碼債越積越多的情況,，歷史的包袱如同一座大山橫在每一位手機 QQ 項目成員面前。
2020年,，我們開始著手做架構升級,。鑒于手機 QQ 的業(yè)務復雜度、代碼量級都非常大,，評估下來架構升級的工作量大得驚人,，于是我們采用分階段、逐步演進的策略去進行架構升級,。整體回顧,，手機 QQ 的架構升級時間線是這樣的：
02、解耦重構
2.1 解耦重構架構設計
雖然歷史包袱如同一座大山,，但是手機 QQ 項目成員也有移山的意志和決心,。在2020年，手機 QQ 啟動了名為“工業(yè)化實踐”的技術架構升級項目,，這標志著手機 QQ 工程首次系統(tǒng)性地進行業(yè)務邊界劃分,、解耦和重構升級。
手 Q 舊架構
從上圖可看出,，舊架構雖然有模塊化和插件化,，但存在以下不足：
- 主工程承載基礎和大部分業(yè)務代碼，導致基礎和業(yè)務代碼邊界不清晰,。
- 基礎核心類持續(xù)膨脹,、業(yè)務之間代碼依賴不合理,。
- 開發(fā)效率低：代碼修改擴散造成 CR、解沖突,、定位問題成本高,，同時拖慢編譯速度。
針對以上不足,，對手機 QQ 工程重新設計了架構,。新架構按業(yè)務劃分模塊，業(yè)務模塊之間是相互解耦的,，業(yè)務模塊之間通過接口和路由進行通信,。同時按層級設計劃分，層級自上而下依賴,，上層模塊可依賴下層模塊,，但下層模塊不能逆向依賴上層模塊。
手 Q 新架構
新架構的主要收益：
- 模塊更加內聚,，新特性開發(fā)影響范圍逐步收斂到模塊內部,，提升研發(fā)效率。
- 接口更加清晰,，依賴數減少,，可測性提升，更易于通過單元測試,、接口測試保障代碼邏輯正確性,，提升產品質量。
2.2 解耦重構的演進歷程
手機 QQ 工程各個業(yè)務之間的依賴非常嚴重,，對它進行解耦重構不是一蹴而就的事情,，需要按階段制定目標，一步一步地優(yōu)化,。通過整理,，手機 QQ 工程解耦重構劃分為三個階段：
- 階段一（2020.11 - 2021.2）
基本完成約300萬行核心代碼的解耦，一共約30個基礎模塊和40個基礎組件完成解耦,，核心業(yè)務模塊基本完成解耦,。開發(fā)新功能時，因為接口與服務實現(xiàn)是隔離的,，通過接口依賴的代碼不會再耦合嚴重,。
- 階段二（2021.3 - 2021.6）
目標：業(yè)務模塊繼續(xù)解耦，建設防劣化機制,。
成果：
- API 代碼占比與依賴數不增加,。
- 完成防劣化機制搭建，在合入階段攔住不合理修改,。
- 完善動態(tài)化能力,，優(yōu)化插件與宿主間通信機制和發(fā)布效率,。
- 階段三（2021.7 以后）
目標：進一步完善基礎模塊和組件化，實現(xiàn)子工程化,。
成果：
- 完善基礎模塊和公共組件重構,，建立基礎模塊發(fā)布組件流程。
- 對頻道,、小世界業(yè)務實現(xiàn)子工程化，獨立編譯運行,。
2.3 解耦重構收益
在重構基礎上,，梳理依賴關系，通過三個階段改善模塊化水平,，提高編譯速度和研發(fā)效率,，流水線的編譯耗時提升50%。代碼沖突方面也得到明顯改善,，對比重構前后數據,，沖突文件數減少60%，沖突次數減少30%,，大大提升開發(fā)效率,。
03、NT 架構升級
在成功邁出改革的第一步之后,，我們將注意力轉向了手機 QQ 面臨的版本碎片化問題,。不同端各自發(fā)展，形成了所謂的“煙囪式”結構,，其中代碼的復用率極低,。這種結構帶來了多端體驗不一致、端內業(yè)務體驗參差不齊以及每次版本更新時高昂的開發(fā)和維護成本等問題,。為了解決這些問題,，并在提升用戶體驗、優(yōu)化性能和提高研發(fā)效率方面實現(xiàn)突破,，我們不得不深入思考,。正是這些迫切的需求和挑戰(zhàn)促使我們啟動了改革的第二步——推進手機 QQ NT 架構升級項目。
在 NT 架構設計之初,，我們堅定認為不應該繼續(xù)縫縫補補,，而是應該采用最新且合理的技術理念，摒棄了簡單的修補式方法,。這次升級不僅是技術上的一次大刀闊斧的改造,，更是一場深思熟慮的技術轉型。我們重視在不造成架構大規(guī)模動蕩的前提下,，制定了一條清晰,、可行的實施路徑,。目標是以更少的人力投入實現(xiàn)更高的工作效率和成果，確保了升級過程中的高效和穩(wěn)健,。這種方法不僅保證了項目的順利進行,，也為未來的技術發(fā)展和迭代奠定了堅實的基礎。
3.1 NT 架構落地之難
由于手機 QQ 的歷史悠久且擁有龐大的用戶群,，該項目在業(yè)務和用戶層面都展現(xiàn)了巨大的復雜性,。具體來看，項目層面的挑戰(zhàn)包括：
- 代碼量龐大：手機端代碼近千萬行,，形成了一個技術上的龐然大物,。
- 測試復雜性高：測試用例眾多，功能繁雜,，且存在部分文檔缺失的情況,。
- 依賴組件過時：項目中依賴了一些陳舊且缺乏維護的組件，以及大量無人維護的二進制庫,。
- 研發(fā)流程保障：在進行架構升級的同時,，必須確保研發(fā)工作流程能夠平穩(wěn)過渡，以免影響到研發(fā)效率,。
用戶層面上的挑戰(zhàn)則包括：
- 在長達一年以上的升級過程中,，日常版本需要正常迭代。
- 用戶本地數據量巨大,，如超過 10G 的本地消息數據庫,。
- 項目需在技術優(yōu)化的同時提升用戶體驗與活躍度，確保技術優(yōu)化在用戶端實現(xiàn)價值,。
面對這些復雜度,，項目的核心難點主要集中在以下三個方面：
- 海量功能項目的架構升級和統(tǒng)一：針對全終端、全功能和全項目團隊的整體升級,，確保架構升級過程中不能有任何缺失,。手機 QQ 是在發(fā)展了20多年進行徹底重構，難度空前,，沒有資料可參考,。
- IM 全鏈路架構重寫升級：解決陳年技術債，優(yōu)化消息架構,，平穩(wěn)遷移用戶歷史數據,，并提升消息性能。QQ 消息架構有陳年技術債,，很多 QQ 歷史版本里,，沒有統(tǒng)一的消息 ID 生成規(guī)則，沒有統(tǒng)一的存儲和索引方案,，消息類型也是無序擴張,。所以,，既需要對IM全鏈路重寫優(yōu)化，同時在過程中,，還需要平穩(wěn)遷移用戶歷史數據,，最終完成升級，保護用戶數據,、用戶體驗不受影響,。
- 用戶體驗提升與活躍數據提升：逐步優(yōu)化核心功能體驗，不影響用戶習慣,，通過提升體驗推動產品數據增長,。代碼的重寫不能全盤一次性推倒重來。核心功能體驗要保持,，逐步優(yōu)化，不能影響用戶使用習慣,。
這些挑戰(zhàn)不僅說明了手機 QQ NT 架構升級項目的復雜性,，也證明了我們在面對前所未有的技術難題時的決心。
3.2 NT 架構設計
為了實現(xiàn)架構升級和統(tǒng)一,，項目團隊先用 C++ 開發(fā)了具備 QQ IM 核心功能的跨平臺內核層：把 IM 核心業(yè)務邏輯（好友,、群、頻道等消息邏輯,、資料與關系鏈邏輯,、圖片語音視頻等富媒體收發(fā)邏輯、實時音視頻邏輯等）,，QQ 通用組件（數據庫,、協(xié)議編解碼、網絡傳輸等）,，以及線程/網絡/IO 等通用資源管理模塊和操作系統(tǒng)封裝部分,，由原來的各平臺原生語言實現(xiàn)，統(tǒng)一下沉到 C++ 跨平臺層,。
為了控制項目質量風險,，NT 跨平臺內核先接入用戶量相對較少，對功能補齊緊迫度高的桌面端,，完全用新架構重寫桌面端,。
在桌面端成功完成功能驗證和質量測試之后，我們開始了向移動端的遷移工作,，并順利完成了 iOS 和安卓平臺的集成,。
當然，移動端的接入遠遠不像圖中描述的這般容易,，接下來將介紹其中的解決方案和主要過程,。
3.3 IM 全鏈路重寫升級
在新的 NT 架構基礎上,，對 QQ 來說，最核心的技術升級,，是 IM 全鏈路的升級,。IM 消息數據源復雜，歷史包袱很重,，升級過程的遇到的第一個難點就是數據轉換及存量數據遷移到新版本問題：
- 老版本的 QQ,，好友消息沒有唯一標識字段，導入和去重影響大,。
- 2012年以前的版本,，群消息沒有支持漫游，消息無唯一字段,。
- 各平臺消息數據格式不同,，復雜度高，iOS 和 Android 分別有約200種消息類型,。
- 富媒體（圖片,、視頻、語音,、文件）資源,，存儲的目錄結構、命名都不同,。
- 特殊消息,，如結構化消息、Ark 消息,、小灰條消息,，需要做轉換，完成業(yè)務的梳理和下架工作,。
- 還有因為各種功能的變遷帶來的遺留數據問題,，如已經退出或者解散的群和討論組等。
所以,，首先需要做 IM 的精簡,。項目團隊基于用戶價值考慮，零基思維,，完成消息格式統(tǒng)一,，對消息和會話類型進行徹底精簡，為 QQ 消息長治久安打下基礎,。
有了全端格式統(tǒng)一和類型精簡的基礎,，開始用大小、性能、安全性綜合最優(yōu)方案設計跨平臺統(tǒng)一的全新客戶端 DB,，然后再考慮舊 DB 的數據,，如何平穩(wěn)升級到新 DB。移動端和桌面端不同,，活躍用戶全年在線,，有些手機本地純文本消息的 DB 文件超過10G，加上富媒體,、文件等,，總數據量超過100G，而且移動端又有存儲空間小,、功耗敏感,、后臺殺進程等多方面限制，需要設計出一套周密的升級策略,，保護用戶核心數據資產不丟失,。
方案核心要點：
- 斷點續(xù)導：移動端場景，進程隨時可能被殺或退出,。確保消息不丟失,、不重復。
- 用戶分級：跟進消息數據大小,，用戶分為三類，做不同的體驗優(yōu)化,，減少對用戶的影響,。
- 優(yōu)化發(fā)燙和耗電：限制導入速度，防止手機發(fā)燙,。手機切后臺后停止導入,。對消息數據多的用戶，引導用戶設置在后臺導入,。
- 監(jiān)控：做好各種導入異常上報監(jiān)控,，隨時跟進用戶反饋。
通過設計周密的升級策略,，內部多輪推演,，外部從百級開始放量，全方位監(jiān)控,，并用兜底策略保障不丟消息,。最終結合監(jiān)控數據和用戶反饋數據，完成了全量用戶的全量數據平穩(wěn)遷移新 DB,。
3.4 核心功能優(yōu)化提升
不僅是消息,，在 NT 架構重寫升級過程中，對 QQ 核心功能也一起做了更徹底的重構，手機 QQ 原生功能進行了大規(guī)模解耦,，通用的部分進行優(yōu)化并下沉為統(tǒng)一的 NT-Runtime 原生組件（NT 組件服務及框架層）,。基于重構后的架構,，也對性能進行全面優(yōu)化,。
首先是消息相關核心模塊的優(yōu)化。消息邏輯下沉到 C++ 跨平臺,，也推動上層進行架構刷新,。以聊天窗口（AIO）為例，基于全新數據流架構 + 數據預加載 + UI 邏輯并行化的設計思路,，完成單向數據流驅動與異步加載渲染,，系統(tǒng)資源全力供給 AIO 消息列表，最終性能指標提升明顯,，AIO 內查看,、跳轉、滑動消息,，順暢絲滑,。核心技術優(yōu)化方案：
- 采用基于單向數據流的 MVI 架構，實現(xiàn)業(yè)務解耦,。
- 預加載和異步渲染,，實現(xiàn)消息無縫滑動。
- 消息加載并行化,，減少首屏和滑動時的加載時間,。
- 消息動態(tài)加載、釋放,，優(yōu)化內存占用,。
- 200+業(yè)務組件懶加載，實現(xiàn)數據分層和按需加載,。
其它 QQ 主場景,，如消息列表頁、消息與富媒體收發(fā),、圖片視頻查看等,，也采用相同的路徑進行優(yōu)化，最終性能全面提升,。
04,、總結
在手機 QQ 超過20年的發(fā)展歷程中，應用功能的不斷擴展和代碼量的持續(xù)增長積累了巨大的技術債務,，給原有架構帶來了沉重的負擔,。通過一系列的架構演變和技術升級,，手機 QQ 成功地實現(xiàn)了從臃腫不堪到模塊化、高效,、穩(wěn)定的轉變,。
客戶端架構由各端煙囪式架構逐步升級為多端跨平臺復用的 NT 架構，降低多端維護人力成本,，提升 QQ 全端開發(fā)效率,，為 QQ 的持續(xù)發(fā)展和技術迭代打下了堅實的基礎。
展望未來,，QQ 將基于 NT 架構,，在技術創(chuàng)新的道路上繼續(xù)前行，不斷進行架構優(yōu)化和技術升級,，為用戶提供更加流暢穩(wěn)定的產品體驗,。
-End-
原創(chuàng)作者 | 何金源
本文參與 騰訊云自媒體分享計劃，分享自微信公眾號,。
