从Google Fuchsia看如何实现一个跨全平台的操作系统
Google Fuchsia初探
这几天我花了一点时间简单看了一些Fuchsia的代码，对这个系统有了一个初步的了解。也欢迎在狗家的朋友批评指正。
Fuchsia是Google内部孵化出来的一套新的全部开源操作系统。你能在google的代码仓库看到所有的代码，
https://cs.opensource.google/fuchsia/fuchsia
这个系统有点属于备胎转正的意思，在Google内部前前后后开发了大概有6年多了，如果再考虑到以前的little kernel的积累，这个系统开发的时间更长。
这套系统是一套完全不基于Linux开发的系统，从它的能力和目标来看，他的目标是统一从高端嵌入式设备，手机，手表，汽车，平板电脑，台式电脑的大一统操作系统。
这里面有个假设就是将来的硬件设备主要是ARM64架构或者x86架构，我觉得这个假设没有问题。从代码仓库的代码来看系统支持两种架构即 ARM64 和X86，代码从2014年开始，就在开发了。
ARM端
因为系统支持的ARM64，这么来讲，一些低端的老的ARMv7指令集的CPU， 新操作系统不会支持的。 这就非常明确了，这套系统嵌入式系统的定位时中高端的嵌入式设备。
们公开支持的第一个设备nest hub，就是用了 Cortex-A53架构的。
PC端：
因为系统支持x86, 也就是说它将来能跑在所有的桌面电脑上，不仅仅是chromebook了。这个直接是对着微软的存量桌面系统去的。
代码中写的ACPI模块表明他们对桌面系统的支持是非常广泛的。
平台：
从支持的平台来看现在公开支持的有 如下几个平台
不过在2018年前后，Fuchsia还支持过Raspberry PI 3 但是后来Google 又移除了这个平台，我不清楚google这么做的目的是什么？
不过又爱好者，在把Fuchsia 往Raspberry Pi 4b上搬，去年还搞了一个pull request向主分支提交，但是现在的状态是abandoned的状态，不知道为啥。
这个爱好者代码仓库在
https://github.com/dahliaOS/zircon-rpi
看了一下往rpi4上移植 Fuchsia 难度没有那么大。
安全性：
这个代码系统非常庞大和完整，kernel这块的完成度非常非常高。后面是一些安全机制改进，性能改进，大范围测试，回收dump，再分析改进的过程。
比如他们现在的内核安全机制方面，还没有采用 KASLR， kernel address space layout randomization，不过从注释里看到，他们已经把它看成一个todo item了。
还有不少安全隐患没有去修，比如 null page的问题，ASLR问题，签名问题等等。所以大概还需要一段时间的打磨才可以。
系统层
由于整个工业界已经在linux和anroid上面投入了大量的资源。所以面对Fuchsia需要能够兼容这些legacy的程序。
由于Android和linux之间的深度绑定，你无法只想仅仅支持Android而又把linux给扔掉。举个例子来讲，假设你搞了一个用android app给外置的单反进行美颜的app（功能够怪的，为了说明起见）那么，你的android app包含了两个部分，一个是Android java code部分。一部分是NDK部分，你给你那个奇怪的单反写的特殊linux驱动。
然后你发布的时候，是将驱动和apk一起发出去的。
然后你说我的底层内核改了，改成其他内核了。那么解决方案又几个：
要求开发者重写针对新内核的驱动。重新发布。 在新os中搞个linux的虚拟机。然后相当于Android运行在虚拟机里面。 搞个ABI 二进制兼容的子系统。
重写，重写的钱谁来掏，肯定没人愿意好好的给你重写一个用的好好的app的。现在银行还有用Cobol的呢。
现在看到的方案是 Starnix方案
https://fuchsia-review.googlesource.com/c/fuchsia/+/485181/7/docs/contribute/governance/rfcs/0082_starnix.md#19
This document proposes a mechanism for running unmodified Linux programs on
Fuchsia. The programs are run in a userspace process whose system interface is
compatible with the Linux ABI. Rather than using the Linux kernel to implement
this interface, we will implement the interface in a Fuchsia userspace program,
called `starnix`. Largely, `starnix` will serve as a compatibility layer,
translating requests from the Linux client program to the appropriate Fuchsia
subsystem. Many of these subsystems will need to be elaborated in order to
support all the functionality implied by the Linux system interface.
简而言之就是 在用户态实现一个linux的ABI，类似于Windows 里面的Posix Subsystem， OS/2 subsystem。
UI层
Google采用的是flutter框架，这个框架是未来。我建议小白学python + flutter就够混了。连我这种老帮菜，现在也开始学用flutter了。
为啥？
因为用flutter写的代码，可以同时运行在Android和IOS上，还可以用了开发网站前端。还是native的code！这个就非常厉害了。把原来微软的WPF 这套理念，发扬光大了。
Flutter作为Fuchsia主要的UI框架好处是显而易见的：
大量的代码可以重用。比如你现在为Android开发的flutter代码可以无缝迁移到Fuchsia上作为原生程序来运行。 大量的开发人员社区。 因为flutter能够有效解决跨平台，性能，完整性方面。在短期内就积聚了一大批的开发人员，生态社区完善。一旦Fuchsia 大规模商用，开发者不会是个大问题。
为什么Google要另起炉灶？
Google没有公开的评论，但是Google的动机还是很容易理解的：
从技术角度来看：
linux的内核是单体内核，但是Google的判断是，将来的IoT世界需要的是微内核。这点跟service领域的微服务化有点异曲同工之妙。代价都是性能可能会有一定的损失，但是带来了整体系统的稳健性。
比如Windows臭名昭著的蓝屏，一个很重要的原因是，第三方硬件厂商写的驱动程序很烂，很多程序就在内核态运行，然后，一出问题，系统就蓝屏，直接搞得大家很尴尬。设想在一个自动浇灌系统，一个控制系统，一个温度，湿度，光照的传感器，假设这些驱动 是一帮sb写的，经常有bug，而且经常更新。现在的情况就会把人搞死。一出问题，系统就会重启。而且经常需要系统停机更新。这在IoT领域是非常不好的。
所以，Google的判断就是微内核。
这是fuchsia的内核的架构示意图
在技术上，Google还想放弃JAVA，毕竟JAVA是Oracle的儿子。Oracle又不思进取。
从商业上看
想在iot 领域，复制Android的成功。
Android的成功为Google带来的巨大收益。而后面十几年未来在各种各样的IoT领域。所以能够在IoT领域里面搞出一个事实标准。那么可以给Google带来巨大的收益。
想在desktop领域，干死Windows。
Google搞这些，在旁边瑟瑟发抖的不是华为，而是微软。在疫情期间，Chromebook的增长远远高于Windows的系统。
微软的操作系统部门，如果不做大的调整，基本上会在这场大战中落败。
结语
我们在非常高的层面看了一下Google Fushsia的架构和可能的roadmap。
他们的内核就是那个Zicorn。能做多少事情？不能做什么事情？怎么做的，非常清楚。
另外Android的程序，linux的驱动模块在系统里跑起来是怎么跑的，什么原理，也基本上比较清楚。 他的应用程序开发是怎么开发的，原理是什么也很清楚。
我们通篇说了Fuchsia 但是没有比较鸿蒙，我只能从几张大的历史框图来做个比较。
这是2019年的roadmp
这个应该还是现状
这应该还是未来
还远没有到Fuchsia OS这种一个微内核的成熟度。即便如此，根据 Fuchsia的成熟度，Fuchsia 到大规模使用，至少还需要3-5年时间。。。
给鸿蒙的几点建议：
1. 扩大统一战线
Fuchsia的针对的是中高端的嵌入式设备，低端的嵌入式设备，Fushsia看不上。这块完全是一个机会，低端不代表落后，代表低成本。所以，完全可以不用放弃对中低端arm 平台的支持。
可以扩大统一战线，把自己的队伍搞得多多的。
可以以看看同样的国产实时操作系统RT-Thread, 怎样闷声在江湖里坐稳自己位置的。
|
|
|
|
这就是群众，这就是市场，这就是需求
2. 加快开源社区的建设
让更多的厂商，开发人员上车。
现在Fuchsia是完全开源的，而且已经开始邀请开源社区向其贡献代码了。
这对于很多独立开发者或者设备制造商来讲，肯定会有考虑，如果早上车了。那就是投入成本。随着投入的增加，以后除非有真的难以忍受的bug或者法律法规问题，否则不太会跳车的。现在这方面，现在已经比Fuchsia晚了。
再看看，大家对开源社区的建设进行时
这是fuchsia 主分支上 commit的活跃度，今天是周末，过去26小时内的commit情况
相对比的 open harmonyos 到现在为止，快9个月了，一共才468个commit ，这个活跃度，实在不敢恭维
你可以说大部队在开发 harmonyos2，那我们对比一下只针对IoT领域的国产操作系统RT-Thread,他们总共有11727个commit，RT-Thread 仅仅5月份一个月就 150个commit！
在开源社区方面，不要说打败fuchsia了，打败RT-Thread还有点距离。
3.脚踏实地，培养这个社群需要大量的开发人员
Fuchsia的OS开发了快6年了，不少主创开发人员都干了快20年内核了。
我们可以简单估算一下，要搞出一套真正的跨平台系统。这是一个浩大的工程，需要海量的工程师，在5年内赶上Fuchsia的生态系统。光合格开发，测试人员，至少需要2万人以上（这都是那种跳出来随便随随便便年薪30万以上的那种人才）。
所以，一方面需要培养大量的年轻人才。如果是国家意志。那么现在从大学开始就要培养大量相关专业人才。
另外一方面，为那些脚踏实地安心干活的人员提供合适的空间。比如Fuchsia中留下开发者名字的主创人员，有一个是Travis Geiselbrecht，这个家伙
Zircon内核 tech leader
这个家伙44岁了，还是一个IC，level在Google内部是L6。但是它能在 OS这个领域里面深耕20多年。没有35岁的危机，没有那么多事情。
而国内现在有个非常不好的趋势，就是年龄歧视，很多地方对35岁当不上领导的员工就优化。这是一种非常有害的行为。我也希望，在国家攻关统一操作系统的时候，能够认真培养人才，尊重人才。拿出邓总的勇气，不管是白猫还是黑猫，不管是小猫还是老猫，逮到老鼠才是好猫。
好多年没有看这些底层代码了，翻了翻，感概万千。
如非特殊情况，这个话题over了。