架构设计，着手为鸿蒙系统适配微信。在这一阶段，团队面临的挑战不仅是满足业务需求，还需要确保微信客户端架构具备高度的解耦性和长期的高可扩展性。目标是使各个相互依赖的模块尽量减少技术上的耦合，避免单一模块故障对整个系统的影响，同时构建一个能够轻松扩展的框架。
到了 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 官方提供的支持。这种分支模式的问题在于，开源社区会持续迭代主干版本，而分支版本往往难以跟上主干的更新进度。
3 微信的加入能否给 Flutter 带来转机？
微信和 Flutter 的渊源可以追溯到 20241 年企业微信的开发。
企业微信作为一款涵盖 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 应用程序）。如果真的是一款 flutter 应用程序，那他们应该会说得更清楚。
当时，Flutter 还是很受欢迎的，不只是腾讯，包括字节跳动、阿里等多个科技巨头都在应用中使用了 Flutter。
“目前，仅在 Play Store 中就有超过 20 万个应用程序使用 Flutter，其中包括拥有超过 10 亿用户的微信，以及仅来自字节跳动的 70 多个 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 表示，Flutter 将尽可能地接近 Flutter，同时充当“释放阀”，直到 Flutter 能够赶上社区要求但尚未解决的各种修复程序。
他希望社区能听取他的意见，给 Flock 一个机会。他在最近的一系列播客中表示，社区中有太多人完全误解了他的意图。
值得注意的是，这并不是 Flutter 第一次被分叉。当被问及 Flock 的创建时，谷歌发言人指出 Flutter 多年来已被分叉数千次，并补充说“出于多种原因（例如研究实验性想法或针对特定用例调整项目），这是开源的正常程序。”
还有这一点：Carroll 多次表示，Flock 实际上并不是一个旨在创建完全独立产品的分叉。
“我们来这里不是为了脱离 Flutter，”Carroll 在播客中告诉基于Dart 的服务器解决方案 Serverpod 的创始人 Viktor Lidholt。“当我们说有人需要某些东西但尚未得到满足时，我们确实是认真的。因此，如果您能得到服务，如果如您所说的那样，您提交的每个错误都会被合并，那就太好了。我希望您继续使用 Flutter 提交错误，我希望他们继续修复您的错误。”
还没有评论，来说两句吧...