1 月 9 日晚，搭載純血鴻蒙作業系統微信 App 正式登陸華為應用商城，版本號為 1.0.3.42。相比此前的測試版本，正式版微信功能更加齊全，基礎通訊、社交、微信支付、公眾號、小程式、影片號及直播等功能齊備，使用上已經與其他平臺無異。但目前版本的部分功能仍在進一步迭代中，可能會受到限制或暫時不可用。

當正式版本上線之際，，騰訊官方賬號“鵝廠黑板報”發文，講述了內部技術團隊歷時 295 天開發鴻蒙微信 App 的完整過程。此外，騰訊微信事業群（WXG）員工 @客村小蔣也在微博釋出了一篇長文，從“局內人”的角度講述了 App 開發背後的“笑與淚”。

他表示：“原生鴻蒙（HarmonyOS NEXT）完全是一套新的技術框架，程式語言是獨特的 ArkTS 語言，這意味著所有的 App 都要完全重寫。”

由於鴻蒙官宣不再相容安卓應用，業內將其稱之為“純血鴻蒙”。“純血”，也意味著一切都要重做。

2024 年 3 月 21 日，開發團隊收到了“簡單又正式”的通知，由曾經負責開發塞班系統微信的技術負責人帶頭開搞鴻蒙微信。

由於鴻蒙是一個全新的系統，所以技術團隊要手搓 App 的同時，還要和鴻蒙團隊不斷溝透過程中遇到的問題。就這樣這個龐大的工程專案邁出了第一步。

2024 年 4 月，鴻蒙微信開搭基建。團隊憑藉 Alita 跨平臺核心優勢，全力投身鴻蒙系統的適配與基礎庫移植工作，與華為頻繁溝通技術細節，反覆測試驗證。

2024 年 5 月，技術團隊啟動了客戶端架構設計，著手為鴻蒙系統適配微信。在這一階段，團隊面臨的挑戰不僅是滿足業務需求，還需要確保微信客戶端架構具備高度的解耦性和長期的高可擴充套件性。目標是使各個相互依賴的模組儘量減少技術上的耦合，避免單一模組故障對整個系統的影響，同時構建一個能夠輕鬆擴充套件的框架。

到了 2024 年 6 月，微信開始進入實際的開發階段。團隊藉助 Flutter、liteapp 等工具，全力整合支付、VoIP 等功能。

騰訊稱：“Flutter（跨平臺應用程式開發框架）、liteapp（專為移動端設計的跨平臺開發框架）等，都是這個階段的關鍵工作。”

1 月 9 日，鴻蒙微信正式版本上線。使用者除了能穩定下載和使用微信外，還可以用到 QQ、騰訊影片、騰訊新聞、QQ 音樂等 App。

鵝廠黑板報中提到他們前端架構使用了 Flutter，然而，經過深入瞭解後我們發現，這一表述實際上存在細微的差別。據我們從業內專家處瞭解到，鵝廠所提及的 Flutter 應用並非在其主體產品中全面鋪開，而是在其小程式渲染引擎的部分，這一發現與鵝廠黑板報上的某些文章所述內容存在出入但我們尋求官方確認未果。

另一方面，由於谷歌官方版 Flutter 不支援鴻蒙系統，所以一些跨平臺框架，比如 React Native 和 Flutter 都是以分支的形式來支援鴻蒙開發的。比如 React Native (RN) 是從 0.72.5 版本開始，實現對鴻蒙系統的初步支援。然而，這一支援並非由 RN 官方實現，而是由華為開發者基於官方某一版本拉取的分支來實現的。類似地，Flutter 對鴻蒙的支援也是由國內開發者透過拉取分支來完成的，而非 Flutter 官方提供的支援。這種分支模式的問題在於，開源社群會持續迭代主幹版本，而分支版本往往難以跟上主幹的更新進度。

微信和 Flutter 的淵源可以追溯到 2021 年企業微信的開發。

企業微信作為一款涵蓋 Android、iOS、macOS、Windows PC 以及 Web 五大平臺的超大型工程專案（其程式碼量超過千萬行），在每一個功能迭代週期中，實現五端同步開發與釋出是一項極為艱鉅的任務。這對開發團隊、產品經理、設計師以及測試人員而言，都構成了極大的挑戰。

在企業微信的早期架構設計階段，就已經將底層的網路通訊、資料庫管理以及大部分業務邏輯抽象出來，採用 C++ 語言實現，以便能夠在多個平臺上覆用。然而，在使用者介面（UI）層面，各個平臺仍然需要各自處理。這就意味著，對於移動端（Android 和 iOS）與電腦端（macOS 和 Windows PC）來說，即便是相同的介面佈局，也需要編寫兩套邏輯程式碼。因此，UI 跨平臺的需求成為了企業微信面臨的一大難題。

為了解決這個問題，企業微信團隊曾經嘗試過 H5 和小程式等方案，但由於效能和使用者體驗方面的侷限，這些方案並不能滿足大部分業務場景的需求。因此，團隊一直在尋找一個高效能的跨平臺框架。

幸運的是，當谷歌推出了 Flutter 這一框架時，企業微信團隊看到了希望。他們進行了一些 Demo 驗證，發現 Flutter 不僅體驗效果接近原生應用，而且底層採用了 Skia 自繪引擎進行渲染，能夠滿足高複雜度的需求場景。此外，Flutter 還擁有豐富的 Pub 社群支援，這加速了框架的成熟和完善。

於是就這樣，企業微信團隊決定引入 Flutter 框架，以進一步提升專案的跨平臺開發效率和使用者體驗。

當時，對於微信選擇 Flutter 在圈內引發了不小的震動。在 X 平臺上，有網友對微信的選擇表示驚訝。

更讓人想不通的是，騰訊到底在哪些內部板塊用到了 Flutter？

當時，Flutter 還是很受歡迎的，不只是騰訊，包括字節跳動、阿里等多個科技巨頭都在應用中使用了 Flutter。

如今，重新寫的鴻蒙依然選擇了 Flutter 作為跨平臺應用程式開發框架。但其實，由於谷歌團隊縮水嚴重，bug 堆積如山等原因，業內對於 Flutter 的期待逐年降低。

早在 2024 年 5 月，谷歌 Flutter 團隊就受到了全公司裁員浪潮的影響。對於那些投入無數時間和精力開發 Flutter 的開發人員們來說，這樣的訊息令人不安，種種焦慮和猜忌的情緒也隨之而來。一位網名叫 xeladu 的 Flutter 與 Firebase 開發人員寫道，“說實話，我寧願勸大家乾脆別學 Flutter。”

他告誡新手們不要把自己的長期職業生涯押注在 Flutter 身上，先觀察谷歌的動作再行決定。“現在玩玩可以，但成為一名專業 Flutter 開發人員可能是在浪費時間。

10 月 30 日，曾在 Flutter 團隊工作的前谷歌員工 Carroll 發表了一篇長文，詳細解釋了他為何要推動對 Flock 的分叉。他認為 Flutter 團隊一直存在“人手不足”的問題——目前全球保守估計有 100 萬 Flutter 開發者，而 Flutter 團隊的規模估計是 50 人，也就是說每 2 萬名 Flutter 使用者只對應一名開發人員。

另外，還有網友分析谷歌 Flutter 團隊甚至不到 50 人：這可以透過 GitHub 的月活躍情況大致估算，還需考慮 CI 機器人帶來的大量提交記錄。

“勞動力短缺通常可以透過增加招聘來解決。然而，由於谷歌內部的整體問題，Flutter 團隊的人員編制在 2023 年前後被凍結，而在 2024 年初還出現了少量裁員。似乎團隊目前可能透過外包擴充人手，但 Flutter 團隊的規模在短期內大幅擴大的可能性不大。”

在他看來，這一令人震驚的投入比例，直接導致越來越多的 bug 積壓和愈發嚴重的功能釋出延遲。

“由於開發人員不足，許多問題會長期停留在待辦清單中，甚至可能多年無人問津，最終被擱置而得不到解決。”

對於這些積壓的 bug，根據 Carroll 的介紹，部分關於 bug 修復和功能釋出的請求多年來一直沒有得到答覆。他還報告了自己的親身經歷，稱直到退出專案很久之後才收到關於申請的反饋意見。可這時候，他早已忘記關於 bug 修復的更多細節資訊。

時間延誤不僅影響故障修復，還會成為產品風險，“設想一下，如果你是某公司的工程總監或 CTO，而你們的下一個版本釋出因 Flutter 的某個問題受阻。假如團隊需要兩年時間才處理這個問題，你會怎麼做？如果這個問題對公司至關重要，你只能放棄 Flutter。你沒有選擇，因為你需要繼續向前推進，而你的團隊並不具備維護 Flutter 框架的能力，而 Flutter 團隊要麼沒有響應，要麼完全沒有解決問題的承諾。於是，只能放棄 Flutter。如果這種情況普遍化，Flutter 的發展將會受到嚴重影響。”

上週， Carroll 又發文控訴 Flutter 內部的混亂情況。Carroll 表示他已經看到了開源醜陋的一面——在不理解的情況下做出反應、強制誤報而忽略真正問題。

Carroll 和 Jesse Ezell 分叉了 Flutter 並建立了 Flock，他和 Ezell 表示，Flock 將盡可能地接近 Flutter，同時充當“釋放閥”，直到 Flutter 能夠趕上社群要求但尚未解決的各種修復程式。

他希望社群能聽取他的意見，給 Flock 一個機會。他在最近的一系列播客中表示，社群中有太多人完全誤解了他的意圖。

值得注意的是，這並不是 Flutter 第一次被分叉。當被問及 Flock 的建立時，谷歌發言人指出 Flutter 多年來已被分叉數千次，並補充說“出於多種原因（例如研究實驗性想法或針對特定用例調整專案），這是開源的正常程式。”

還有這一點：Carroll 多次表示，Flock 實際上並不是一個旨在建立完全獨立產品的分叉。

“我們來這裡不是為了脫離 Flutter，”Carroll 在播客中告訴基於Dart 的伺服器解決方案 Serverpod 的創始人 Viktor Lidholt。“當我們說有人需要某些東西但尚未得到滿足時，我們確實是認真的。因此，如果您能得到服務，如果如您所說的那樣，您提交的每個錯誤都會被合併，那就太好了。我希望您繼續使用 Flutter 提交錯誤，我希望他們繼續修復您的錯誤。”