在瞬息萬變的互聯(lián)網(wǎng)行業(yè)中，年過二十四的 QQ 堪稱超長壽的產品，見證了中國互聯(lián)網(wǎng)崛起的完整歷程。然而，如今這個元老級產品經歷了一次從內到外徹底的重構。
在這次重構中，QQ 選擇了 Electron 作為 UI 跨平臺開發(fā)框架。盡管 Electron 被 Slack、Visual Studio Code 和 Discord 等大型產品廣泛使用，但也引發(fā)了一些網(wǎng)友的擔憂，例如內存占用、安裝包體積和啟動速度等方面的問題。
好奇于 QQ 的決策，于是infoQ采訪了 QQ 技術團隊，窺探這次變革的脈絡，揭示出那些潛藏在背后的思考。
QQ 重構背后的思考：24 歲的 QQ 有什么樣的技術債?
QQ 的第一個版本發(fā)布于 1998 年，在 Windows 技術棧的基礎上用純原生的方式開發(fā)，在當時互聯(lián)網(wǎng)帶寬非常小的情況下，QQ 將安裝包控制在了只有 200K 左右。2007 年后智能手機開始露出苗頭，騰訊行動得比較早，部分前端技術開發(fā)開始轉型到了移動端，在桌面端， QQ 隨著業(yè)務和組織的發(fā)展，針對三大操作系統(tǒng)陸續(xù)組建了三支不同的研發(fā)團隊，各自負責自己的一套代碼。
三端不同代碼，老產品歷史包袱，加上移動時代研發(fā)人員的轉型，導致桌面 QQ 維護成本很高。QQ 技術團隊介紹，拿之前的桌面 QQ 為例，WindowsQQ 以前的 UI 框架用的是騰訊自研的 GF 框架，10 多年了，GF 這個框架文檔還不全，新加入這個項目的團隊人員，要基于這個基礎框架去做一些事情，是效率很低的一件事情，慢慢的就沒有人愿意去用這個框架了。簡而言之，就是技術債。
舊版的桌面端 QQ，Windows 的功能最豐富，macOS 次之， Linux 功能非常簡潔。比如“屏幕共享”這個功能，移動端有，Windows 端有，但是 macOS 端是沒有的。那用戶就會遇到一個問題，像 macOS 端無法與其它端 QQ 用戶一起來使用這個功能。
“多端不統(tǒng)一不利于用戶對于 QQ 的統(tǒng)一認知。我們這次的架構升級就是想盡量通過一套核心代碼去拉平所有平臺的體驗，讓它具有更好的可維護性和可擴展性，讓桌面 QQ 能夠更好地迭代產品交互和功能，升級用戶體驗，再次煥發(fā)生長的生命力。”
于是 QQ NT 項目是在 2022 年 3 月份正式啟動， macOS QQ 在 6 月份開始發(fā)布內測， 9 月份正式上架了 App Store，迭代了幾個版本之后，QQ 團隊就同步開發(fā) Linux。在 2022 年，QQ 發(fā)布了新的 macOS 和 Linux 版本，包括 QQ 后臺其實也做了很大的改變和重構，核心系統(tǒng)做了全新重寫，云原生成熟度也得到了很大的提升。從 2023 年開始，QQ 團隊聚焦做 Windows 端的開發(fā)，在 3 月底就開始內測，7 月初上架官網(wǎng)。同時移動端 QQ NT 也在 7 月初完成了核心系統(tǒng)的重寫和全量升級。在目前全新的框架設計下，無論是核心系統(tǒng)、功能迭代還是設計語言上，都可以盡可能地“原子化”，來讓 QQ 后續(xù)更好地迭代功能。
重構之路：最大的壓力與挑戰(zhàn)源自何處?
“QQ 的重構其實是兩方面的重構：一個是面向復雜業(yè)務的梳理重構，一個面向工程技術債的全新技術重構，重構之路也是兩者相互伴隨的過程。”
首先，在整個 QQ 重構過程中最大的挑戰(zhàn)來自于 QQ 功能的復雜化，QQ 有很多十分復雜的歷史功能，這些功能模塊也曾經由非常多不同的人經手負責過。其中哪些功能是不合理的或沒有價值的，如何去做取舍往往是最難的。“雖然技術上我們做了很多事情，但技術上的實現(xiàn)或許并沒有那么難，我們處理起來更有經驗和從容。相比于技術的復雜度，業(yè)務上的往往需要考慮的更多，這本身就是很大的挑戰(zhàn)。”
因為 QQ 已經是近 25 年的產品了，有很多細小復雜的功能。雖然這些功能看看起來很小，但用戶量其實又很大，稍微改動可能就會有很多的用戶反饋，QQ 團隊都得非常的關注。僅從產品功能角度上看，有些功能本身就已經是很重的負債，而 QQ 團隊內部有一個叫做“QQ 節(jié)能計劃”的項目，會有比較嚴謹?shù)捻椖苛鞒倘ピu估是否需要下架。
技術上重構也有不少挑戰(zhàn)，這次重構是一次跨平臺的重構，而在多個平臺里面比較有挑戰(zhàn)則是 Linux 平臺。
作為程序員，很多人免不了要跟 Linux 打交道。但是這么多年來，對于使用 Linux 系統(tǒng)的用戶來講，有一個特別讓人煩惱的問題，那就是沒有一個好用的 IM 聊天工具。被寄予厚望的 QQ，此前在 Linux 版本上功能也沒有 Windows 和 macOS 版本全面，迭代速度也明顯慢過其他兩個版本。業(yè)界甚至猜測 Linux 第一個版本是由騰訊實習生所寫，畢竟這個說法進一步加重了其初版的“簡陋”特性，也為其“停更”的原因提供了更合理的解釋。
QQ 技術團隊表示，較之另兩個版本，Linux 版本的研發(fā)最為復雜：一方面操作系統(tǒng)本身很多碎片化，市面上有非常多的發(fā)行版，也不缺乏一些千奇百怪的版本;另一方面因為機器運行環(huán)境或編譯器的缺失，使得解決適配問題的難度很大。許多發(fā)行版相關的機器和開發(fā)環(huán)境實際上他們并沒有，有時還需要外部公司幫助進行一些測試工作。由于沒有相應的開發(fā)環(huán)境，一旦出現(xiàn)閃退等問題，解決難度自然會變得更大。此外，有時候需要與國產操作系統(tǒng)廠商進行特殊的合作，甚至需要對方寄送特定的編譯好的代碼庫，但前后往往會花費一個月的時間才能收到。而在本次重構之后，“Linux 功能跟 Windows 一樣多了”。
技術上的另一大挑戰(zhàn)便是外界對于 QQ 桌面端使用 Electron 的質疑，尤其是內存方面。外界有些用戶在沒有使用和分析的情況下對此發(fā)表一些夸大和否定的言論，也確實給 QQ 技術團隊帶來不小壓力，但他們卻始終堅定選型方向，也相信其中的問題可以被攻克和解決。
技術選擇之爭：為何 QQ 選擇 Electron 而非純 Native 技術棧?
確實當時有很多人在問，為什么 Windows 不用原生去實現(xiàn)?為什么不用 Qt?
“首先不太想和以前一樣，Windows、macOS、Linux 三端各由一個團隊分開負責。在國內這種人才環(huán)境里面，相關的純原生的開發(fā)人員其實非常難招了，桌面端的人才稀缺，同時也投入比較大。
而對于 Qt 技術棧，他們首先考慮的其實還是人才的問題，國內熟練 Qt 技術棧的人非常少。如果對這個框架不了解，使用它反而是一個負向作用。
至于微軟的 Webview2，從本質上講，Webview2 和 Electron 并沒有太大的區(qū)別，只是相對在其中打包了一些微軟自身的優(yōu)化措施，其他方面也不是很完善，而且還無法跨平臺。雖然內存方面相較于 Electron 做了更多的優(yōu)化。但據(jù)了解，比如微軟 Teams 也沒有完全切到 Webview2。并且由于它沒有開源，因此也沒有辦法基于 Webview2 做定制優(yōu)化。
包括 Flutter，QQ 團隊表示他們當時也有過調研。他們放棄的一個原因是 Flutter 在桌面端的完善程度并不高，也擔心標準化的問題。雖然當前 Flutter 非常流行，但誰也說不好這是不是“2015 年的 React Native”。大家擔心隨著時間推移，這套技術可能會失去維護支持，因為本身 Google 使用 Flutter 的占比也比較小。
“雖然它很熱，但我們歷史上踩過了很多很多非標準化的坑，一旦某個技術棧熱度一過、維護力度不夠，它就會成為全新的負債，做選型時必然也是避免再有類似經歷。”
至于為什么最后選擇 Electron，QQ 技術團隊表示主要是基于以下幾個考量：
首先最看重的是框架成熟度和技術棧的標準化。Electron 基于 Web 技術棧，有足夠低的上手和使用成本，不需要為了使用框架本身，還需要投入額外巨大人力成本去做基建和周邊工具鏈的建設，以前在 RN、Flutter 的實踐上都有類似的情況。而使用 Electron，現(xiàn)有的 Web 前端的大部分基建都可以直接復用，而且使用 Web 開發(fā) UI 的效率，在主流技術棧里算是很高的了。至于迭代效率我覺得從新版桌面 QQ 功能的迭代速度就可以證明，這放在以前是完全辦不到的。另外由于 Web 技術棧是標準化的，假如 Electron 修改開源協(xié)議或者要閉源了，他們也能很方便的去寫出一套類似的框架。只不過現(xiàn)在已經有開源的了，沒必要再去重復建設一個。而且隨著 Web 標準長久發(fā)展，Web 技術棧也不會有大的問題，而且還會越來越好。
其次是技術經驗及人才儲備，技術選型是否適合當前團隊也是一個很重要的考慮點，團隊是否有相關的技術積累，是否有人才儲備來持續(xù)投入這個技術棧。Qt 的確在性能上是一個很好的選擇，但目前團隊對 Qt 沒有太多積累，基建基本沒有，而且相關人才其實比較匱乏，招聘就更難了。而當前 QQ 技術團隊 Web 前端團隊還是有比較多的積累，在 QQ 頻道項目中，也完整驗證了 Electron 的技術可行性。
最后就是 Electron 具備的桌面端跨平臺的優(yōu)勢。但 QQ NT 架構并不是僅指 Electron，Electron 主要是作為 UI 跨平臺的框架，只是占比很小的一部分，并且 QQ 桌面端不是全部用 Electron 實現(xiàn)，QQ NT 最核心的部分還是 QQ 底層通用抽象的模塊，稱之為 NT 內核，包括核心登錄、消息系統(tǒng)、關系鏈、富媒體、長連接、數(shù)據(jù)庫等等模塊，完全用 C++ 實現(xiàn)，全平臺通用。因此底層是完全跨平臺的架構，而 Electron 只是上層桌面端 UI 跨平臺較薄的一層。
“其實我們當時選型的時候，也的確看得到大家對 Electron 的評價褒貶不一，但我們還是有信心去解決這個問題，前期也做了一些技術的 Demo 和預研。實際上 Electron 并沒有糟糕到這個地步。我們覺得可能是國內很多沒有用過 Electron 的開發(fā)者，對這個框架有些忌憚。其實你到 Electron 的網(wǎng)站去看，還是有非常多國內外的億級 DAU 產品都使用 Electron 框架。目前這幾年主流的桌面端應用基本都選擇了 Electron，如 Visual Studio Code、Discord、Slack、Skype、Whatsapp、Figma 等等，新的應用基本上也是首選 Electron，版本的迭代速度和社區(qū)氛圍都很在線。”
“我們覺得不需要單純因為口碑問題，就對這個選型沒有了期待。還是要從實際出發(fā)，哪種技術棧適合你的產品，看看到底能不能有技術實力去把這個事情搞定。”
內存優(yōu)化：如何有效控制 Electron 的內存占用?
外界之所以會覺得 Electron 內存占用高，是因為其本身是一個多進程的架構，主進程基于 Node.js, 而每個窗口都對應一個渲染進程以及 V8 實例?？梢哉f從技術框架層面上，上手寫代碼很容易，但不容易去管控它的內存。
QQ 技術團隊認為 Electron 的開發(fā)者更多的是前端的開發(fā)者，可能在思維上沒有去考慮怎么在這樣一套技術框架里，去對內存數(shù)據(jù)進行管理和管控。開發(fā)者需要從前端開發(fā)者的思維，轉變?yōu)榭蛻舳碎_發(fā)者的思維。
綜合來看，對內存的看法其實不完全是 Electron 的技術框架所導致的，更多的是門檻上、開發(fā)思維上，導致內存沒有得到很好的關注和優(yōu)化。其實最簡單的 Electron 應用大概也就只有幾十兆的內存占用。因為前端原本更多還是停留在開發(fā)即用即走的 Web 站點，很少實現(xiàn)一個超大客戶端，缺乏控制內存的經驗，所以面對 QQ 這么大一個產品的時候，你就必須非常在意內存的使用和管控。
至于優(yōu)化內存的突破口，可以說是從各個層面：從消息的鏈路中的每條消息的收發(fā)上，數(shù)據(jù)是怎么管理，包括像窗口及會話的管理，都得精打細算，也會做一些數(shù)據(jù)本地化和一些機制的按需加載，包括渲染上他們也提出一個根本的原則：“要做到所見才占用”，既我們看到的內容才占用這一部分內存，沒看到和用不到的任何場景的內存就不應該再占用，通過各種方式來去讓內存達到一個設定的目標。
他們也使用了不同維度的內存分析工具，從 V8 引擎到進程，再到整個應用程序，打通整個鏈路進行多角度的細節(jié)分析，以此來定位內存使用的瓶頸。之后采取一系列的針對性優(yōu)化策略，包括緩存策略、按需加載、優(yōu)雅降級等，同時使用線上監(jiān)控、自動化測試手段，包括借助開發(fā)框架、工具建設、代碼審查等，來阻止性能退化。(更多細節(jié)可以參看技術文章：新 QQ NT 桌面版如何實現(xiàn)內存優(yōu)化探索?)
經過一系列組合優(yōu)化之后，QQ 的內存在長時間掛機的條件下，平均穩(wěn)定在 220M 左右。“現(xiàn)在優(yōu)化還是不錯的，比老版本要好很多。我們認為這個難題還是可以被很好的攻克，內存并不是大家認為的這么不可控，但是也需要團隊去花費相當精力去探索和實踐，才能去把內存控制到一個比較理想的狀態(tài)。”
未來展望：QQ 的前端發(fā)展規(guī)劃是怎樣的?
目前 QQ 的前端團隊作為一個公線團隊，不僅負責桌面 QQ 的研發(fā)，還有 QQ 基礎運營、QQ 空間以及基于 QQ 生態(tài)的創(chuàng)新項目研發(fā)，有比較多的線上項目的開發(fā)與維護和內部研效工具的建設。涉及的技術棧，包括 H5、Electron、Cocos、小程序、WebGL、WebAssembly、WebRTC 等。他們也表示會繼續(xù)夯實這些技術，同時也不斷地打破立下的性能目標，希望讓桌面 QQ 覆蓋更多平臺。
他們也正在積極擁抱 AI，讓 AI 在質量和效率上輔助日常開發(fā)。比如：前端設計稿還原，之前更多是一個耗時的體力活，D2C 是 QQ 前端一直探索的方向，之前使用純規(guī)則轉換生成代碼，在視覺還原上效果還不錯，但是代碼可讀性和可維護性不能很好的滿足預期，所以除了一些日拋型的運營活動有些使用之外，比較難擴大成果。現(xiàn)在 D2C 結合大模型，生成的代碼質量高了很多，也能很方便的將代碼與 UI 組件庫做映射，達到可以在核心業(yè)務中高效使用，達到通過 AI 提升研發(fā)效率的目的。針對一些無設計稿的管理平臺開發(fā)，使用 P2C 提效，目前也有了一些不錯的案例。
另外，QQ 技術團隊也在積極探索 AI 更廣闊的應用場景，比如代碼評審，基本的 Lint 檢檢是難以實現(xiàn)的，但將已經掌握的內存泄漏模式通過規(guī)則的形式給到 AI，可以很方便地給開發(fā)同學一些不錯的建議，為性能看家護院提供多一道保障。
寫在最后
QQ NT 項目于 2022 年 3 月份啟動，macOS QQ 花了該團隊 3 個月的開發(fā)時間，9 月份上架 App Store，迭代了幾個版本后同步開始開發(fā) Linux QQ，并于這一年的最后一天上架各 Linux 應用市場，作為給 Linux 用戶的一份特殊的新年禮物。2023 年 QQ 團隊開始去聚焦做 Windows QQ NT 的開發(fā)，7 月正式上架應用市場和官網(wǎng)。同時移動端的 QQ 從 2022 年的 Q4 開始開發(fā)，也已經完成了全量升級和發(fā)布。
另外，桌面 QQ 也是在 NT 版本中第一次支持 64 位，這需要將音視頻、安全、字節(jié)碼、圖形庫等 C++ 模塊，包括 Electron 框架都重新進行編譯，花費了比較大的工作量。但在 64 位系統(tǒng)上，QQ 從此便不再需要以 32 位應用的方式通過額外的兼容和轉換來運行。畢竟額外操作會增加開銷，導致性能下降。
至此，QQ 實現(xiàn)了多個系統(tǒng)平臺之間架構的統(tǒng)一。而團隊的未來規(guī)劃還是不斷地打破性能目標，并覆蓋更多平臺，同時探索更多提升研發(fā)效率的辦法，加快研發(fā)速度。
騰訊 QQ 用跨平臺 Electron 取代之前原生應用程序的開發(fā)模式，這一舉動引發(fā)的反響確實巨大。但我們也能看出，不同于小型產品團隊，在大公司里具有一定規(guī)模的產品組織架構之下，快速滿足用戶需求，并逐漸需要為第三、第四乃至第五種運行平臺提供支持時，保持一致性和協(xié)調性并不是想象中的那么容易。而緩慢而低效，最終會令你輸?shù)舯荣悺?/p>
不管使用什么跨平臺開發(fā)框架，都要去選擇最合適自己團隊的，也因此在 Web 標準技術棧上有豐富積累的 QQ 團隊才會選擇 Electron。并且我們認為沒有人真正討厭 Electron，只是我們對 QQ，對國內 App 寄予了非常高的期盼。
（免責聲明：本網(wǎng)站內容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準確性及可靠性，但不保證有關資料的準確性及可靠性，讀者在使用前請進一步核實，并對任何自主決定的行為負責。本網(wǎng)站對有關資料所引致的錯誤、不確或遺漏，概不負任何法律責任。
任何單位或個人認為本網(wǎng)站中的網(wǎng)頁或鏈接內容可能涉嫌侵犯其知識產權或存在不實內容時，應及時向本網(wǎng)站提出書面權利通知或不實情況說明，并提供身份證明、權屬證明及詳細侵權或不實情況證明。本網(wǎng)站在收到上述法律文件后，將會依法盡快聯(lián)系相關文章源頭核實，溝通刪除相關內容或斷開相關鏈接。 ）
