1、引言

在瞬息萬變的互聯網行業中，年過二十四的即時通訊IM應用 QQ 堪稱超長壽的產品，見證瞭中國互聯網崛起的完整歷程。

然而，如今這個元老級產品經歷瞭一次從內到外徹底的重構。在這次重構中，QQ 選擇瞭 Electron 作為 UI 跨平臺開發框架。

盡管 Electron 被 Slack、Visual Studio Code 和 Discord 等大型產品廣泛使用，但也引發瞭一些網友的擔憂，例如內存占用、安裝包體積和啟動速度等方面的問題。本文內容整理自 QQ 技術團隊的采訪，我們一起來看看QQ團隊選擇Electron作為桌面版跨端框架背後的決策與思考。

2、系列文章

本文是系列文章中的第8篇，本系列總目錄如下：

• 《IM跨平臺技術學習(一)：快速瞭解新一代跨平臺桌面技術——Electron》
• 《IM跨平臺技術學習(二)：Electron初體驗(快速開始、跨進程通信、打包、踩坑等)》
• 《IM跨平臺技術學習(三)：vivo的Electron技術棧選型、全方位實踐總結》
• 《IM跨平臺技術學習(四)：蘑菇街基於Electron開發IM客戶端的技術實踐》
• 《IM跨平臺技術學習(五)：融雲基於Electron的IM跨平臺SDK改造實踐總結》
• 《IM跨平臺技術學習(六)：網易雲信基於Electron的IM消息全文檢索技術實踐》
• 《IM跨平臺技術學習(七)：得物基於Electron開發客服IM桌面端的技術實踐》
• 《IM跨平臺技術學習(八)：新QQ桌面版為何選擇Electron作為跨端框架》（* 本文）

3、老QQ桌面版的技術債

3.1多端代碼不統一

QQ 的第一個版本發佈於 1998 年，在 Windows 技術棧的基礎上用純原生的方式開發，在當時互聯網帶寬非常小的情況下，QQ 將安裝包控制在瞭隻有 200K 左右。

2007 年後智能手機開始露出苗頭，騰訊行動得比較早，部分前端技術開發開始轉型到瞭移動端，在桌面端， QQ 隨著業務和組織的發展，針對三大操作系統陸續組建瞭三支不同的研發團隊，各自負責自己的一套代碼。

efee84a77f35385a144478152d409f62

▲ 初版QQ的註冊向導頁

35087b53532b9c3f6aa866d9c0a72016

▲ 初版QQ的主要功能為即時聊天

三端不同代碼，老產品歷史包袱，加上移動時代研發人員的轉型，導致桌面 QQ 維護成本很高。

QQ 技術團隊介紹，拿之前的桌面 QQ 為例，Windows QQ 以前的 UI 框架用的是騰訊自研的 GF 框架，10 多年瞭，GF 這個框架文檔還不全，新加入這個項目的團隊人員，要基於這個基礎框架去做一些事情，是效率很低的一件事情，慢慢的就沒有人願意去用這個框架瞭。簡而言之，就是技術債。

PS：如果你對QQ的發展史感興趣可以看看下面這些文章：

1. 《閑話即時通訊：騰訊的成長史本質就是一部QQ成長史》
2. 《技術往事：創業初期的騰訊——16年前的冬天，誰動瞭馬化騰的代碼》
3. 《技術往事：史上最全QQ圖標變遷過程，追尋IM巨人的演進歷史》
4. 《QQ的成功，遠沒有你想象的那麼順利和輕松》
5. 《還原真實的騰訊：從最不被看好，到即時通訊巨頭的草根創業史》

3.2多端功能不一致

舊版的桌面端 QQ，Windows 的功能最豐富，Mac OS 次之， Linux 功能非常簡潔。

比如“屏幕共享”這個功能，移動端有，Windows 端有，但是 Mac OS 端是沒有的。那用戶就會遇到一個問題，像 Mac OS 端無法與其它端 QQ 用戶一起來使用這個功能。

“多端不統一不利於用戶對於 QQ 的統一認知。我們這次的架構升級就是想盡量通過一套核心代碼去拉平所有平臺的體驗，讓它具有更好的可維護性和可擴展性，讓桌面 QQ 能夠更好地迭代產品交互和功能，升級用戶體驗，再次煥發生長的生命力。”

3.3QQ NT 項目的誕生

於是 QQ NT 項目的誕生瞭！

QQ NT 項目是在 2022 年 3 月份正式啟動， Mac OS QQ 在 6 月份開始發佈內測， 9 月份正式上架瞭 App Store，迭代瞭幾個版本之後，QQ 團隊就同步開發 Linux。

在 2022 年，QQ 發佈瞭新的 macOS 和 Linux 版本，包括 QQ 後臺其實也做瞭很大的改變和重構，核心系統做瞭全新重寫，雲原生成熟度也得到瞭很大的提升。

從 2023 年開始，QQ 團隊聚焦做 Windows 端的開發，在 3 月底就開始內測，7 月初上架官網。

同時移動端 QQ NT 也在 7 月初完成瞭核心系統的重寫和全量升級。

在目前全新的框架設計下，無論是核心系統、功能迭代還是設計語言上，都可以盡可能地“原子化”，來讓 QQ 後續更好地迭代功能。

4、新QQ桌面版重構的技術挑戰

4.1業務功能上的挑戰

QQ 的重構其實是兩方面的重構：

• 1）一個是面向復雜業務的梳理重構；
• 2）一個是面向工程技術債的全新技術重構。

重構之路也是兩者相互伴隨的過程。

首先：在整個 QQ 重構過程中最大的挑戰來自於 QQ 功能的復雜化，QQ 有很多十分復雜的歷史功能，這些功能模塊也曾經由非常多不同的人經手負責過。其中哪些功能是不合理的或沒有價值的，如何去做取舍往往是最難的。“雖然技術上我們做瞭很多事情，但技術上的實現或許並沒有那麼難，我們處理起來更有經驗和從容。相比於技術的復雜度，業務上的往往需要考慮的更多，這本身就是很大的挑戰。”

因為 QQ 已經是近 25 年的產品瞭，有很多細小復雜的功能。雖然這些功能看看起來很小，但用戶量其實又很大，稍微改動可能就會有很多的用戶反饋，QQ 團隊都得非常的關註。僅從產品功能角度上看，有些功能本身就已經是很重的負債，而 QQ 團隊內部有一個叫做“QQ 節能計劃”的項目，會有比較嚴謹的項目流程去評估是否需要下架。

4.2技術重構上的挑戰

技術上重構也有不少挑戰，這次重構是一次跨平臺的重構，而在多個平臺裡面比較有挑戰則是 Linux 平臺。

作為程序員，很多人免不瞭要跟 Linux 打交道。但是這麼多年來，對於使用 Linux 系統的用戶來講，有一個特別讓人煩惱的問題，那就是沒有一個好用的 IM 聊天工具。被寄予厚望的 QQ，此前在 Linux 版本上功能也沒有 Windows 和 Mac OS 版本全面，迭代速度也明顯慢過其他兩個版本。業界甚至猜測 Linux 第一個版本是由騰訊實習生所寫，畢竟這個說法進一步加重瞭其初版的“簡陋”特性，也為其“停更”的原因提供瞭更合理的解釋。

QQ 技術團隊表示，較之另兩個版本，Linux 版本的研發最為復雜：

• 1）一方面操作系統本身很多碎片化，市面上有非常多的發行版，也不缺乏一些千奇百怪的版本；
• 2）另一方面因為機器運行環境或編譯器的缺失，使得解決適配問題的難度很大。

許多發行版相關的機器和開發環境實際上他們並沒有，有時還需要外部公司幫助進行一些測試工作。由於沒有相應的開發環境，一旦出現閃退等問題，解決難度自然會變得更大。此外，有時候需要與國產操作系統廠商進行特殊的合作，甚至需要對方寄送特定的編譯好的代碼庫，但前後往往會花費一個月的時間才能收到。

而在本次重構之後，“Linux 功能跟 Windows 一樣多瞭”。

4.3選型Electron的質疑

技術上的另一大挑戰便是外界對於 QQ 桌面端使用 Electron 的質疑，尤其是內存方面。

外界有些用戶在沒有使用和分析的情況下對此發表一些誇大和否定的言論，也確實給 QQ 技術團隊帶來不小壓力，但他們卻始終堅定選型方向，也相信其中的問題可以被攻克和解決。

5、為何選擇Electron而非純Native技術棧？

5.1為什麼Windows端不用原生實現？

確實當時有很多人在問，為什麼 Windows 不用原生去實現？為什麼不用 Qt？

首先：不太想和以前一樣，Windows、Mac OS、Linux 三端各由一個團隊分開負責。在國內這種人才環境裡面，相關的純原生的開發人員其實非常難招瞭，桌面端的人才稀缺，同時也投入比較大。

而對於 Qt 技術棧，他們首先考慮的其實還是人才的問題，國內熟練 Qt 技術棧的人非常少。如果對這個框架不瞭解，使用它反而是一個負向作用。

至於微軟的 Webview2，從本質上講，Webview2 和 Electron 並沒有太大的區別，隻是相對在其中打包瞭一些微軟自身的優化措施，其他方面也不是很完善，而且還無法跨平臺。雖然內存方面相較於 Electron 做瞭更多的優化。但據瞭解，比如微軟 Teams 也沒有完全切到 Webview2。並且由於它沒有開源，因此也沒有辦法基於 Webview2 做定制優化。

包括 Flutter，QQ 團隊表示他們當時也有過調研。他們放棄的一個原因是 Flutter 在桌面端的完善程度並不高，也擔心標準化的問題。雖然當前 Flutter 非常流行，但誰也說不好這是不是“2015 年的 React Native”。大傢擔心隨著時間推移，這套技術可能會失去維護支持，因為本身 Google 使用 Flutter 的占比也比較小。

“雖然它很熱，但我們歷史上踩過瞭很多很多非標準化的坑，一旦某個技術棧熱度一過、維護力度不夠，它就會成為全新的負債，做選型時必然也是避免再有類似經歷。”

5.2選擇Electron的幾個考量

01a78f6f6fb19ef0e34778204ef069d9

至於為什麼最後選擇 Electron，QQ 技術團隊表示主要是基於以下幾個考量。

1）首先最看重的是框架成熟度和技術棧的標準化：

Electron 基於 Web 技術棧，有足夠低的上手和使用成本，不需要為瞭使用框架本身，還需要投入額外巨大人力成本去做基建和周邊工具鏈的建設，以前在 RN、Flutter 的實踐上都有類似的情況。而使用 Electron，現有的 Web 前端的大部分基建都可以直接復用，而且使用 Web 開發 UI 的效率，在主流技術棧裡算是很高的瞭。至於迭代效率我覺得從新版桌面 QQ 功能的迭代速度就可以證明，這放在以前是完全辦不到的。

另外由於 Web 技術棧是標準化的，假如 Electron 修改開源協議或者要閉源瞭，他們也能很方便的去寫出一套類似的框架。隻不過現在已經有開源的瞭，沒必要再去重復建設一個。而且隨著 Web 標準長久發展，Web 技術棧也不會有大的問題，而且還會越來越好。

2）其次是技術經驗及人才儲備：

技術選型是否適合當前團隊也是一個很重要的考慮點，團隊是否有相關的技術積累，是否有人才儲備來持續投入這個技術棧。

Qt 的確在性能上是一個很好的選擇，但目前團隊對 Qt 沒有太多積累，基建基本沒有，而且相關人才其實比較匱乏，招聘就更難瞭。

而當前 QQ 技術團隊 Web 前端團隊還是有比較多的積累，在 QQ 頻道項目中，也完整驗證瞭 Electron 的技術可行性。

3）最後就是 Electron 具備的桌面端跨平臺的優勢：

但 QQ NT 架構並不是僅指 Electron，Electron 主要是作為 UI 跨平臺的框架，隻是占比很小的一部分，並且 QQ 桌面端不是全部用 Electron 實現，QQ NT 最核心的部分還是 QQ 底層通用抽象的模塊，稱之為 NT 內核，包括核心登錄、消息系統、關系鏈、富媒體、長連接、數據庫等等模塊，完全用 C++ 實現，全平臺通用。因此底層是完全跨平臺的架構，而 Electron 隻是上層桌面端 UI 跨平臺較薄的一層。

“其實我們當時選型的時候，也的確看得到大傢對 Electron 的評價褒貶不一，但我們還是有信心去解決這個問題，前期也做瞭一些技術的 Demo 和預研。實際上 Electron 並沒有糟糕到這個地步。我們覺得可能是國內很多沒有用過 Electron 的開發者，對這個框架有些忌憚。其實你到 Electron 的網站去看，還是有非常多國內外的億級 DAU 產品都使用 Electron 框架。目前這幾年主流的桌面端應用基本都選擇瞭 Electron，如 Visual Studio Code、Discord、Slack、Skype、Whatsapp、Figma 等等，新的應用基本上也是首選 Electron，版本的迭代速度和社區氛圍都很在線。”

“我們覺得不需要單純因為口碑問題，就對這個選型沒有瞭期待。還是要從實際出發，哪種技術棧適合你的產品，看看到底能不能有技術實力去把這個事情搞定。”

6、如何有效控制Electron的內存占用？

外界之所以會覺得 Electron 內存占用高，是因為其本身是一個多進程的架構，主進程基於 Node.js, 而每個窗口都對應一個渲染進程以及 V8 實例。可以說從技術框架層面上，上手寫代碼很容易，但不容易去管控它的內存。

QQ 技術團隊認為：Electron 的開發者更多的是前端的開發者，可能在思維上沒有去考慮怎麼在這樣一套技術框架裡，去對內存數據進行管理和管控。開發者需要從前端開發者的思維，轉變為客戶端開發者的思維。

綜合來看：對內存的看法其實不完全是 Electron 的技術框架所導致的，更多的是門檻上、開發思維上，導致內存沒有得到很好的關註和優化。其實最簡單的 Electron 應用大概也就隻有幾十兆的內存占用。因為前端原本更多還是停留在開發即用即走的 Web 站點，很少實現一個超大客戶端，缺乏控制內存的經驗，所以面對 QQ 這麼大一個產品的時候，你就必須非常在意內存的使用和管控。

至於優化內存的突破口，可以說是從各個層面：從消息的鏈路中的每條消息的收發上，數據是怎麼管理，包括像窗口及會話的管理，都得精打細算，也會做一些數據本地化和一些機制的按需加載，包括渲染上他們也提出一個根本的原則：“要做到所見才占用”，既我們看到的內容才占用這一部分內存，沒看到和用不到的任何場景的內存就不應該再占用，通過各種方式來去讓內存達到一個設定的目標。

他們也使用瞭不同維度的內存分析工具，從 V8 引擎到進程，再到整個應用程序，打通整個鏈路進行多角度的細節分析，以此來定位內存使用的瓶頸。之後采取一系列的針對性優化策略，包括緩存策略、按需加載、優雅降級等，同時使用線上監控、自動化測試手段，包括借助開發框架、工具建設、代碼審查等，來阻止性能退化。（更多細節可以參看技術文章：《IM跨平臺技術學習(九)：全面解密新QQ桌面版的Electron內存占用優化》）

經過一系列組合優化之後：QQ 的內存在長時間掛機的條件下，平均穩定在 220M 左右。“現在優化還是不錯的，比老版本要好很多。我們認為這個難題還是可以被很好的攻克，內存並不是大傢認為的這麼不可控，但是也需要團隊去花費相當精力去探索和實踐，才能去把內存控制到一個比較理想的狀態。”

7、未來展望

目前 QQ 的前端團隊作為一個公線團隊，不僅負責桌面 QQ 的研發，還有 QQ 基礎運營、QQ 空間以及基於 QQ 生態的創新項目研發，有比較多的線上項目的開發與維護和內部研效工具的建設。涉及的技術棧，包括 H5、Electron、Cocos、小程序、WebGL、WebAssembly、WebRTC 等。他們也表示會繼續夯實這些技術，同時也不斷地打破立下的性能目標，希望讓桌面 QQ 覆蓋更多平臺。

他們也正在積極擁抱 AI：讓 AI 在質量和效率上輔助日常開發。比如：前端設計稿還原，之前更多是一個耗時的體力活，D2C 是 QQ 前端一直探索的方向，之前使用純規則轉換生成代碼，在視覺還原上效果還不錯，但是代碼可讀性和可維護性不能很好的滿足預期，所以除瞭一些日拋型的運營活動有些使用之外，比較難擴大成果。現在 D2C 結合大模型，生成的代碼質量高瞭很多，也能很方便的將代碼與 UI 組件庫做映射，達到可以在核心業務中高效使用，達到通過 AI 提升研發效率的目的。針對一些無設計稿的管理平臺開發，使用 P2C 提效，目前也有瞭一些不錯的案例。

另外：QQ 技術團隊也在積極探索 AI 更廣闊的應用場景，比如代碼評審，基本的 Lint 檢檢是難以實現的，但將已經掌握的內存泄漏模式通過規則的形式給到 AI，可以很方便地給開發同學一些不錯的建議，為性能看傢護院提供多一道保障。

8、寫在最後

QQ NT 項目於 2022 年 3 月份啟動，Mac OS QQ 花瞭該團隊 3 個月的開發時間，9 月份上架 App Store，迭代瞭幾個版本後同步開始開發 Linux QQ，並於這一年的最後一天上架各 Linux 應用市場，作為給 Linux 用戶的一份特殊的新年禮物。2023 年 QQ 團隊開始去聚焦做 Windows QQ NT 的開發，7 月正式上架應用市場和官網。同時移動端的 QQ 從 2022 年的 Q4 開始開發，也已經完成瞭全量升級和發佈。

另外：桌面 QQ 也是在 NT 版本中第一次支持 64 位，這需要將音視頻、安全、字節碼、圖形庫等 C++ 模塊，包括 Electron 框架都重新進行編譯，花費瞭比較大的工作量。但在 64 位系統上，QQ 從此便不再需要以 32 位應用的方式通過額外的兼容和轉換來運行。畢竟額外操作會增加開銷，導致性能下降。

至此：QQ 實現瞭多個系統平臺之間架構的統一。而團隊的未來規劃還是不斷地打破性能目標，並覆蓋更多平臺，同時探索更多提升研發效率的辦法，加快研發速度。

騰訊 QQ 用跨平臺 Electron 取代之前原生應用程序的開發模式，這一舉動引發的反響確實巨大。但我們也能看出，不同於小型產品團隊，在大公司裡具有一定規模的產品組織架構之下，快速滿足用戶需求，並逐漸需要為第三、第四乃至第五種運行平臺提供支持時，保持一致性和協調性並不是想象中的那麼容易。而緩慢而低效，最終會令你輸掉比賽。

不管使用什麼跨平臺開發框架，都要去選擇最合適自己團隊的，也因此在 Web 標準技術棧上有豐富積累的 QQ 團隊才會選擇 Electron。並且我們認為沒有人真正討厭 Electron，隻是我們對 QQ，對國內 App 寄予瞭非常高的期盼。

9、相關資料

[1] Electron官方開發者手冊

[2] 快速瞭解新一代跨平臺桌面技術——Electron

[3] Electron初體驗(快速開始、跨進程通信、打包、踩坑等)

[4] Electron 基礎入門 簡單明瞭，看完啥都懂瞭

[5] vivo的Electron技術棧選型、全方位實踐總結

[6] 融雲基於Electron的IM跨平臺SDK改造實踐總結

[7] 閑魚IM基於Flutter的移動端跨端改造實踐

[8] 網易雲信基於Electron的IM消息全文檢索技術實踐

[9] 閑話即時通訊：騰訊的成長史本質就是一部QQ成長史

[10] 技術往事：創業初期的騰訊——16年前的冬天，誰動瞭馬化騰的代碼

[11] 技術往事：史上最全QQ圖標變遷過程，追尋IM巨人的演進歷史

[12] QQ的成功，遠沒有你想象的那麼順利和輕松

[13] 還原真實的騰訊：從最不被看好，到即時通訊巨頭的草根創業史

附錄：更多有關QQ、微信的技術故事

《技術往事：微信估值已超5千億，雷軍曾有機會收編張小龍及其Foxmail》

《QQ和微信兇猛成長的背後：騰訊網絡基礎架構的這些年》

《2017微信數據報告：日活躍用戶達9億、日發消息380億條》

《騰訊開發微信花瞭多少錢？技術難度真這麼大？難在哪？》

《技術往事：“QQ群”和“微信紅包”是怎麼來的？》

《開發往事：深度講述2010到2015，微信一路風雨的背後》

《開發往事：微信千年不變的那張閃屏圖片的由來》

《開發往事：記錄微信3.0版背後的故事（距微信1.0發佈9個月時）》

《一個微信實習生自述：我眼中的微信開發團隊》

《首次揭秘：QQ實時視頻聊天背後的神秘組織》

《為什麼說即時通訊社交APP創業就是一個坑？》

《微信七年回顧：歷經多少質疑和差評，才配擁有今天的強大》

《前創始團隊成員分享：盤點微信的前世今生——微信成功的必然和偶然》

《即時通訊創業必讀：解密微信的產品定位、創新思維、設計法則等》

《QQ現狀深度剖析：你還認為QQ已經被微信打敗瞭嗎？》

《[技術腦洞] 如果把14億中國人拉到一個微信群裡技術上能實現嗎？》

《QQ和微信止步不前，意味著即時通訊社交應用創業的第2春已來？》

《那些年微信開發過的雞肋功能，及其帶給我們的思考》

《讀懂微信：從1.0到7.0版本，一個主流IM社交工具的進化史》

《同為IM社交產品中的王者，QQ與微信到底有什麼區別》

《QQ設計團隊分享：新版 QQ 8.0 語音消息改版背後的功能設計思路》

《社交應用教父級人物的張小龍和馬化騰的同與不同》

《專訪馬化騰：首次開談個人經歷、管理心得、技術創新、微信的誕生等》

《一文讀懂微信之父張小龍：失敗天才、顛覆者、獨裁者、人性操控師》

技術交流：

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

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

（本文已同步發佈於：http://www.52im.net/thread-4391-1-1.html）