首次公開，最新手機QQ客戶端架構的技術演進實踐

Posted on 2024-05-30 10:24 Jack Jiang 閱讀(75) 評論(0) 編輯收藏

本文由騰訊技術何金源分享，原題“不畏移山，手機QQ技術架構升級變遷史”，本文進行了排版和內容優化等。

1、引言

接上篇《總是被低估，從未被超越，揭秘QQ極致絲滑背后的硬核IM技術優化》，本文則將重點介紹手機 QQ 客戶端技術架構升級背后的故事。

手機 QQ 經過20多年發展，功能不斷增加，代碼不斷累積，架構已經變得越來越臃腫，影響到協作團隊開發效率，對用戶體驗、質量穩定都有較大風險，因此手機 QQ 亟需技術架構的升級。但是對如此龐大的項目進行架構升級，在行業內也是少有的，手機 QQ 架構升級面臨的困難和挑戰都十分巨大，本文將圍繞最新手機 QQ 客戶端項目背景、項目歷程、項目挑戰、項目成果等方面進行深入介紹。

技術交流：

- 移動端IM開發入門文章：《新手入門一篇就夠：從零開發移動端IM》

- 開源IM框架源碼：https://github.com/JackJiang2011/MobileIMSDK（備用地址點此）

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

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++ 跨平臺層。