Fuchsia 系统的进度，Android 会被替代吗

那个 2016 年 GitHub 上突然冒出来的神秘仓库

2016 年 8 月，有人注意到 Google 的 GitHub 组织里出现了一个叫 fuchsia 的仓库，没有 README，没有官方说明，代码量却大得离谱。那时候 Android 社区还在吵 Nougat 的 Doze 模式有没有用，结果突然冒出来一个完全不用 Linux 内核的操作系统——Zircon 微内核，Magenta 中间层，后来改名叫 Fuchsia。九年过去了，这个项目的 GitHub star 数早就过了五位数，但大多数人连它长什么样都没见过。

我当年还特地编译过一次，按照那篇流传很广的教程，在 Ubuntu 上装依赖、拉源码、跑 fx set core.x64 && fx build，折腾了三个多小时。最后启动的是一个带鼠标的桌面，图标是 Material Design 风格，能跑一个简陋的浏览器。那时候的感觉很微妙：Google 放着全球最大的移动操作系统不管，偷偷养了一个"备胎"，而且这个备胎从内核到 UI 框架全是自己写的，跟 Android 没有任何血缘关系。

九年后回头看，Fuchsia 的进度到底怎么样了？Android 会不会被它替代？这个问题在 2019 年 Fuchsia 被确认是 Google 官方项目之后，每隔几个月就会被翻出来炒一次。我的判断很直接：Fuchsia 在特定场景里会活下来，但替代 Android 这件事，短期内看不到路径，长期看 Google 自己也没这个动力。

Zircon 微内核的技术债，比 Linux 的还难还

Fuchsia 最核心的卖点是 Zircon 微内核。Linux 是宏内核，驱动、文件系统、网络协议栈全跑在内核空间，一个显卡驱动崩了可能直接带走整个系统。Zircon 把大部分服务放到用户空间，内核只负责最基础的线程调度、内存管理、IPC。理论上更稳定、更安全、更容易做形式化验证。

问题是，这个"理论上"在工程实现里要付的代价太大了。

2022 年 Fuchsia 的源码泄露过一次内部文档，里面提到 Zircon 的 IPC 性能瓶颈。微内核架构下，驱动和文件系统服务之间要通过消息传递通信，而 Linux 里直接就是函数调用。一个简单的文件读取操作，Fuchsia 的上下文切换次数是 Linux 的数倍。Google 的工程师在文档里写得很坦诚："某些场景下的延迟回归（latency regression）仍在调查中。" 这是 Google 内部文档的典型措辞，翻译成人话就是"我们知道慢，但还没想好怎么修"。

更麻烦的是驱动生态。Linux 经过三十年积累，硬件厂商的驱动代码可以直接用，或者稍微改改就能编译。Zircon 的驱动框架叫 Banjo，用一种接口定义语言（IDL）来描述硬件接口，驱动代码要重写。2023 年我注意到 Fuchsia 的源码树里，Realtek 网卡驱动只有几百行，而 Linux 内核里的 r8169.c 超过八千行。这不是 Google 偷懒，是硬件厂商根本不配合。没有厂商愿意为一个市场份额为零的系统维护两套驱动代码。

Google 的解决方案是搞了一个 Linux 驱动的兼容层，叫 starnix。名字很浪漫，但本质是承认失败：既然硬件厂商不鸟你，那就直接在 Fuchsia 里跑一个 Linux 内核的兼容环境，让 Linux 驱动以为自己还在 Linux 上。这等于说，Fuchsia 花了这么大劲摆脱 Linux，最后为了能用还得把 Linux 请回来当外援。这个架构的讽刺程度，堪比 React Native 最后还是要写原生模块。

Flutter 和 Fuchsia 的绑定，是一场双向奔赴的困局

Fuchsia 的 UI 层用的是 Flutter。这不是巧合，是设计上的深度绑定。Fuchsia 的应用框架叫 fuchsia.modular，后来改叫 fuchsia.element，核心概念是 Story、Module、Agent，跟 Android 的 Activity、Service、BroadcastReceiver 完全不是一套东西。但用户看到的界面，确实就是 Flutter 的 Widget 树。

这个绑定对双方都是枷锁。

Flutter 团队一直想在更多平台上证明自己。2018 年 Flutter 1.0 发布的时候，官方支持 iOS 和 Android，桌面和 Web 还是实验性。现在 Flutter 3.x 号称全平台统一，但每个平台的渲染后端都是独立的：Android 用 Skia 或者 Impeller，iOS 用 Impeller，Web 用 CanvasKit 或 HTML renderer，Windows 用 ANGLE。Fuchsia 本来应该是 Flutter 的"原生主场"，结果反而成了最边缘的平台。

我查过 Flutter engine 的源码，Fuchsia 的 embedder 实现放在 shell/platform/fuchsia 目录下。2023 年的一次 commit 记录显示，Google 把 Fuchsia 的 CI 构建从主流程里移到了次要位置，理由是"资源优化"。这意味着 Flutter 团队对 Fuchsia 的投入在收缩，而不是扩张。一个 UI 框架如果连自己的"亲儿子"平台都不优先支持，说明这个平台的战略优先级在下降。

反过来，Fuchsia 被 Flutter 绑定也限制了它的选择。Fuchsia 早期其实有过其他 UI 方案的尝试，比如一个基于 Vulkan 的直接渲染层，但后来都被废弃了。Flutter 的渲染管线对 GPU 的要求不低，Impeller 虽然比 Skia 轻量，但在低端设备上仍然吃力。Fuchsia 想做的 IoT 设备、嵌入式场景，很多时候根本没有 GPU 或者只有很弱的 2D 加速。Flutter 的重量级架构跟这些场景天然矛盾。

2024 年 Flutter 团队的人事变动也很有意思。Tim Sneath 重新回归负责 Flutter 战略，但 Fuchsia 相关的公开信息反而更少了。Google I/O 2024 的 Keynote 里，Flutter 的演示全是 Android、iOS 和 Web，Fuchsia 一个字都没提。这不是疏忽，是刻意回避。

Nest Hub 上的 Fuchsia，是胜利还是遮羞布？

Fuchsia 唯一大规模商用的设备，是 Google 的 Nest Hub 和 Nest Hub Max。第一代 Nest Hub 在 2021 年通过 OTA 从 Cast OS 升级到了 Fuchsia，当时科技媒体一片惊呼，说"Fuchsia 终于来了"。

三年后再看，这个"终于来了"更像是一个精心控制的实验。

Nest Hub 的硬件配置是什么？Amlogic 芯片，2GB 内存，没有传统意义上的应用生态。用户能做的就是看天气、放视频、控制智能家居。这种场景对 Fuchsia 来说刚刚好：功能单一、没有第三方应用、不需要兼容 Android 的庞大 API。Google 可以在这里验证 Zircon 的稳定性、Flutter 的渲染管线、以及自己的更新机制。

但这也是 Fuchsia 的天花板。Nest Hub 的成功恰恰证明了 Fuchsia 只能活在 Google 完全控制的封闭场景里。一旦需要开放给第三方开发者，需要兼容现有应用，Fuchsia 的短板立刻暴露。

2023 年有个细节被很多人忽略了：Google 发布了 Nest Hub 第二代，但这款设备运行的是基于 Android 的 Google Home 平台，不是 Fuchsia。官方解释是"为了更好的第三方应用支持"。这等于 Google 自己打了自己的脸——Fuchsia 在需要应用生态的场景里，连自家的硬件产品都撑不住。

我专门去翻了 Fuchsia 的 issue tracker，找到一个 2022 年的内部 bug，标题是"Investigate Android runtime on Fuchsia for next-gen devices"。这个 bug 的状态是 WontFix（已拒绝），但评论区的讨论很耐人寻味。有工程师说："如果我们需要 Android 应用，那为什么要用 Fuchsia 而不是直接用 Android？" 这个问题没人能回答。

Android 的护城河，比大多数人想的要深

每次聊 Fuchsia 替代 Android，都要先搞清楚 Android 到底强在哪里。很多人以为是 Linux 内核，是开源，是 Google 的控制力。这些都对，但都不是核心。

Android 真正的护城河是 ART 虚拟机和整个应用生态的绑定关系。

从 Android 5.0 开始，ART 取代了 Dalvik，AOT 编译让性能大幅提升。但更重要的是，ART 的指令格式 dex/odex/vdex 成了事实上的标准。全球数百万应用，数以十亿计的设备，全部基于这个运行时。Google Play 的审核、分发、更新机制，安全扫描的静态分析规则，甚至广告 SDK 的埋点方式，都深度嵌入 ART 的架构里。

Fuchsia 如果要替代 Android，必须解决一个问题：已有的 Android 应用怎么办？完全重写？不可能。兼容运行？那需要把 ART 或者类似的运行时搬到 Fuchsia 上，这等于把 Android 最大的技术债也一起搬过去。

Google 其实试过。Fuchsia 源码里有一个 android 目录，早期有过一个 android_runner 项目，试图在 Fuchsia 上启动 Android 应用。但 2021 年之后，这个目录的更新频率急剧下降。2023 年的一次 commit 直接删除了大部分代码，只保留了最小化的测试框架。官方没有解释，但社区里有人猜测是性能问题：在微内核上模拟宏内核的运行时，IPC 开销让应用启动时间翻倍。

Android 的另一个护城河是 Google Play 服务（GMS）。这不是技术问题，是商业问题。GMS 的授权协议、兼容性测试套件（CTS）、品牌使用规范，构成了一个庞大的利益网络。手机厂商每卖一台 Android 设备，都要向 Google 支付隐性的"GMS 税"，通过预装 Google 应用和搜索分成来结算。这个体系每年给 Google 带来数百亿美元收入。

Fuchsia 如果替代 Android，这个体系要重建。但重建对谁有好处？Google 自己吗？GMS 在 Android 上的运转已经很成熟了，迁移到 Fuchsia 要重新谈判所有合同，重新认证所有厂商，重新培训所有开发者。这个成本不是技术成本，是交易成本，比重写一个内核高得多。

Google 的战略摇摆，从"替代"到"共存"再到"收缩"

Fuchsia 项目的战略定位，在过去九年里至少有三次明显转向。

第一次是 2016-2018 年的"神秘期"。代码公开但不解释，社区猜测是 Google 对 Linux 的 GPL 许可证不满，想做一个 BSD 许可的替代品。这个动机有一定道理，Android 的 Linux 内核确实让 Google 在 GPL 合规上很头疼，尤其是驱动代码的开放要求。

第二次是 2019-2021 年的"官宣期"。Fuchsia 被确认为 Google 官方项目，负责人是 Android 的联合创始人之一 Andy Rubin 之后的继任者 Hiroshi Lockheimer。这时候的口径是 Fuchsia 不是 Android 的替代品，是"面向多种设备的现代操作系统"。Nest Hub 的升级发生在这个时期，看起来 Google 想从 IoT 切入，逐步扩展。

第三次是 2022 年至今的"模糊期"。Fuchsia 的公开信息越来越少，核心开发者离职的消息时有传出。2022 年 Fuchsia 的工程总监 Chris McKillop 离开 Google，他是从 Palm 时代就跟着做操作系统的老将。2023 年，Fuchsia 团队被重组到 Google 的"设备与服务"部门下面，跟 Pixel 手机、Fitbit 手表放在同一个汇报线里。这个组织架构的调整信号很明显：Fuchsia 不再是一个独立的战略级项目，而是依附于具体硬件产品的技术组件。

2024 年 Google 的裁员潮也波及了 Fuchsia。虽然没有公开数字，但 LinkedIn 上能看到不少 Fuchsia 工程师的离职动态。有人在离职帖里写"很荣幸参与了这个野心勃勃的项目"，这种措辞在硅谷通常意味着"项目还活着，但我的角色没了"。

Google 对 Fuchsia 的投入收缩，跟整个公司的战略聚焦有关。AI 成了唯一的优先级，Gemini、TPU、云计算是资源黑洞。操作系统这种长周期、低回报的基础设施，在资本开支紧缩的环境里天然被挤压。Fuchsia 没有带来收入，没有形成生态，甚至没有一个能说服投资人的"故事"。

微内核的诅咒，历史不会简单重复但会押韵

操作系统史上，微内核的尝试大多以妥协告终。Mach 微内核成就了 NeXTSTEP，最后变成了 macOS 的 XNU 内核——但 XNU 是混合内核，不是纯微内核。Windows NT 最初设计是微内核，最后把图形子系统塞进了内核空间，因为性能扛不住。QNX 在嵌入式领域很成功，但从未进入通用计算的主流。

Fuchsia 的困境是结构性的。微内核的安全性和模块化优势，在桌面和服务器领域被性能劣势抵消；在嵌入式领域，Linux 的实时补丁（PREEMPT_RT）和轻量级发行版（如 Buildroot、Yocto）已经能满足大部分需求，Fuchsia 没有不可替代的价值。

Google 内部对 Fuchsia 的争议，从一些泄露的邮件和文档里能窥见端倪。2021 年的一次内部技术评审，有人提问："Fuchsia 的 TCO（总拥有成本）相比 Android + Linux 的优势在哪里？" 回答文档里的措辞很模糊，主要强调的是"长期技术债务的减少"和"安全模型的改进"。这种回答在工程评审里通常意味着"我们算不出 ROI，只能讲愿景"。

愿景不能当饭吃。Android 的 Linux 内核确实有很多历史包袱，binder 驱动、ashmem、ion 这些 Google 自己加的补丁，跟上游内核的合入过程常年扯皮。但这些都是"能跑的问题"，不是"不能跑的问题"。Google 的工程师文化里，对"能跑的问题"的容忍度很高，除非有明确的商业压力推动重构。

那个被反复问到的"如果"

每次技术社区讨论 Fuchsia，最后都会落到同一个假设：如果 Google 真的被逼到墙角，比如 Android 的 GPL 诉讼爆发，或者 Linux 社区跟 Google 彻底闹翻，Fuchsia 能不能立刻顶上？

这个假设本身就有问题。Google 跟 Linux 基金会的关系，远比外人看到的紧密。Linux 内核的维护者里，Google 的员工占相当比例。GPL 合规的问题，Google 通过 AOSP 的代码释放策略已经处理得差不多了。真正敏感的驱动代码，厂商以二进制 blob 形式提供，并不触发 GPL 的传染条款。这个灰色地带运转了十几年，各方心照不宣。

退一步说，即使出现极端情况，Fuchsia 也顶不上。一个操作系统从"能编译"到"能商用"，中间隔着的是驱动生态、开发者工具、应用兼容性、安全认证、厂商支持、法律合规的完整链条。Android 从 2008 年 1.0 到 2011 年 4.0 才算真正成熟，用了三年。Fuchsia 如果明天被强制扶正，面对的是比 2008 年复杂一百倍的硬件和应用生态。

Google 自己清楚这一点。2023 年 Android 14 的发布说明里，有一个很小的改动：ART 的编译器配置文件格式更新，跟 Fuchsia 的格式完全不兼容。这种细节通常不会出现在新闻里，但它表明两个项目的底层数据格式在分道扬镳，而不是 converging（收敛）。如果 Google 真有替代计划，这种基础格式应该是优先统一的。

我的判断，以及一个还没想明白的问题

Fuchsia 不会替代 Android。它会在 Google 的封闭硬件里继续存在，比如未来的 Nest 设备、 maybe 某个实验性的产品线上。但作为一个开放的、通用的、有第三方生态的操作系统，Fuchsia 的机会窗口正在关闭。不是技术不行，是时间不够，是生态的惯性太大，是 Google 自己的战略优先级变了。

这个判断有一个风险：AI 时代的交互范式如果发生剧变，比如大模型驱动的自然语言交互完全取代触屏应用，那么操作系统本身的形态也会改变。Fuchsia 的模块化架构在这种场景下可能有优势——但这也是所有新操作系统的优势，不是 Fuchsia 独有的。而且 Google 完全可以把 AI 能力以 Google Play 服务的形式塞进 Android，不需要换内核。

最后留一个我琢磨了很久但没想透的问题：Google 在 Fuchsia 上投入的工程师总量，九年累计下来，估计够重写两三个 Android 子系统了。这些人力如果拿去优化 Android 的内存管理、推进 ART 的 AOT 编译效率、或者把 Linux 内核的实时性做好，回报会不会更高？Google 内部有没有做过这个 ROI 的对比分析？如果有，结论是什么？如果没有，那 Fuchsia 的存在本身，是不是某种技术理想主义对商业理性的胜利——或者反过来，是一种无法止损的沉没成本？

这个问题可能只有 Google 的 SVP 们能回答，而他们大概不会说。