鸿蒙技术发展脉络及余承东的”失言”

关于鸿蒙，不论是之前的纸上谈兵，还是跟随着智能电视产品出现的惊鸿一瞥，这个被华为寄予厚望的操作系统与技术平台，其展现出来的技术脉络到底如何？在底层的达成方式是怎样的？真的是出自华为员工的苦心研发，还是对某个技术平台的仿造？

就目前的版本来看，鸿蒙并不是独立的”完全自有”操作系统，基本上他还是基于既有Android的变化设计，跟之前的GPU Turbo可说如出一辙，但这并不代表鸿蒙欺骗了消费者。

事实上，鸿蒙被给予了过多的期待，而这可能要归功于余承东余大嘴的卖力行销。这不是说余承东的说法都是错的，而是他的发言在很大的程度上回避了一款操作系统应该要面对的质疑，从生态到兼容性到性能增长，说的太美好，而故意忽略了那些需要的设计妥协与可能遭遇的挑战。

作为一款操作系统产品，鸿蒙最重要的核心还是在商用化的价值，这些价值的内涵包括了专利、生态以及技术优势能达到何种程度。

另外，自有的操作系统在过去有不少厂商玩过，但基本都以失败告终。目前的鸿蒙则是在既有的Android生态再分裂出一个变种，并希望这个变种最终会取代Android，若Google因此和华为决裂，华为手上的专利是否足够维持一款操作系统的发展，并变成自己的生态，恐怕质疑还是会多过于肯定。

如果只走国内市场，那么鸿蒙可能足够强大，但要面对国际市场，恐怕华为还需要解决更多问题。

现阶段跟微内核没什么关系

余承东曾强调微内核在鸿蒙操作系统中的价值，但实际上，鸿蒙在目前的1.0版，就是个Android操作系统的变体，通过修改既有系统的内核以及执行层，来达到号称的性能增长。

甚至可以说，方舟编译器才是这个阶段的主角。而微内核甚至也不会出现在1.0版的鸿蒙操作系统中。

要解释鸿蒙现在号称的那些性能增长，其实可以从Android操作系统过去的发展脉络来看。Android的应用执行分为几个阶段，从最早的JIT(Just in time)解释执行，也就是Java代码一直是以原始的状态存在手机上，只有在执行时才会动态载入编译，并进行相关的工作执行，这个阶段的应用执行效率极低，效能表现非常差劲。

但后来推出ART(Android RunTime)模式，应用在安装到系统中时，就会全部预编译，应用程式在手机上的存在型态已经是机器码，在省略JIT工作之后，性能有了极大的提升，但机器码有体积庞大的缺点，在当初NAND成本昂贵，主流机器只有4~8GB存储容量的时代，这种作法自然也不能被接受。

后来新的作法一律改成只有最常用的代码会被预编译为机器码，其余还是保留JIT解释执行，但是JIT解释器通过高度优化，提升执行效率。

现阶段的鸿蒙其实有点类似早期Android的ART，但是是在包装成安装档的时候就已经预先编译为机器码，而不是安装到手机上时再进行编译。通过这种作法，可以在维持安装效率的同时，提升应用程序执行的效能表现。

另一方面，与鸿蒙配套的方舟编译器也已经不是单纯的编译器，而是一整套的tootchain(工具链)，事实上，目前鸿蒙的架构就是个Android搭配华为定制的runtime库以及方舟编译器所构成，可以执行针对鸿蒙系统预先编译的执行档，也能同时兼容Android生态。

修改Android核心使其兼容鸿蒙生态

当然，Android核心也会有一定的修改，这部份的修改来自于zygote这个进程。Zygote是Android的固有进程，主要负责的工作是用来初始化Dalvik虚拟机，而方舟编译器与鸿蒙则是另外创造了一套mygote，用来连接华为自定义的鸿蒙runtime库，用以执行鸿蒙的”原生”应用。

Android程序在进行启动时，会使用socket和zygote进行通信，并预先准备好执行的虚拟机环境，而鸿蒙应用程序则会呼叫mygote进程，并准备好相对应的执行环境。

通过这个作法，华为所宣称的，可以兼容Android与鸿蒙两套生态的新一代操作系统就可以顺利达成。

然而整套系统仍然是Android，只不过在执行环境方面进行了修改。另一方面，预先编译为机器码的安装档虽然可以大幅加速安装和执行过程，但会与Android当初的ART执行环境有类似的问题，那就是执行档容量会变大。理论上可以通过压缩的方式来减少执行档的大小，降低这方面的负面影响。

可能通过舍弃虚拟机来取得效能增长

由于舍弃了zygote，转而使用mygote搭配定制的runtime库，每次开启新的应用程序时，就不需要另外复制一套虚拟机，程序启动速度会明显变快，且执行性能以及内存使用效率也会跟著改善，这也符合了华为对其鸿蒙性能增长的预期。

当然，这么一来，鸿蒙就是个在既有汤药里面添加了新药方的产物，没换汤不换药，也不舍弃原本的汤药配方，希望能够在维持既有疗效的前提下，增加其他疗效。

但这么一来，鸿蒙还算是个全新的操作系统吗？

鸿蒙还没有微内核，支持ADB也是天经地义

为了兼容Android，原本的Android宏内核就无法舍弃，在目前的1.0版作业系统中，其实还没有整合鸿蒙内核，也就是主打的微内核，取而代之的是引进额外的鸿蒙执行环境。而这在华为的发布会简报中也同样有提到，目前的版本是基于开源框架，只有在部份的模块进行自研，也就是前面提到的，现有的鸿蒙操作系统就是在Android系统上的加料版本。

另一方面，发布会上虽然强调微内核带来的效率改进，但其并非改善执行效率的有效方式，这个作法更多的是增加弹性，而在效率上，微内核模块之间的互相功能呼叫延迟要高于传统的宏内核在内核直接执行，因此整体执行效率上反而可能有所折损。

而既然目前的鸿蒙还是基于既有Android框架下的系统，那么前几天被网友在鸿蒙智能电视上发现ADB调试授权模式，也就天经地义了，毕竟现在的鸿蒙基本上就是Android。

Google本家的微内核操作系统Fuchsia和鸿蒙对抗？

值得注意的是，Google本家也正在研发真正基于微内核的操作系统Fuchsia，未来也可能会以之取代既有的Android，该操作系统已经在2016年释放完整初版源码，后续也持续更新，鸿蒙在2016年立项，2017年释放出1.0版内核，Fuchsia的推出与源码的释放，可说是鸿蒙的启蒙之一。

Fuchsia基于Zircon的微内核设计，早了鸿蒙一步，概念上与鸿蒙也有著相似之处。

Zircore包括一个微内核，以及一组用户空间服务、驱动和软件库，可处理系统启动、进程加载等一些经典内核任务。Zircon的系统调用除了wait_one, wait_many, port_wait and sleep之外，一般是非阻塞的。Zircon支持在Linux或macOS上构建，进而创建一个可引导的bootfs镜像。

Zircon最初是LK的一个分支。LK是Google为嵌入式系统开发的另一种内核，意在实现对FreeRTOS或ThreadX的开源替代。但是Zircon没有LK那么严格的需求，因为它是设计运行在具有充足内存和高速处理器的现代设备上。

目前Fuchsia已经可以编译成功并安装于现有的Android手机上，并已经实现部份的核心功能操作。鸿蒙想要创造自有生态，同时延续Android生态，但Google则是要创造新的Android生态，鸿蒙和Fuchsia势必走向不同的道路，在商业市场上谁会成为市场赢家，还有待时间证明。

未来鸿蒙的发展：微内核与开源？

关于鸿蒙的未来，华为也已经在发布会上提出了2.0和3.0版的规划，包和技术层面以及商用脚步都有相当合理的布局。

而在发布会上强调的，基于微内核的种种优化设计，基本上会在2.0版鸿蒙上获得实现，但即便如此，鸿蒙也不会是第一个商用化的微内核操作系统，至于全场景分布式操作系统的称号，也不过就是形容微内核可以通过不同的内核模块搭配用在不同设备的作法，要说首创也会有不小的争议。

事实上，微内核缺点很多，过去商用的微内核操作系统中，仅有少数几个还留存在市场中，过去微软的Windows，以及苹果的Mac OS X也曾尝试过使用微内核，但后来为了效能，他们都进行了妥协，也就是把高权限的服务组件放进核心中，借以达成更高的通信效率，但这么一来就违反了微内核的定义。

而目前所有的主流操作系统核心都采用了这种混合式的作法，纯粹的微内核基本上都面临了商用应用上的失败。

鸿蒙能否成为第一个成功在商用市场持续存活的微内核操作系统？除了微内核的先天限制以外，操作系统的开发更是极为复杂的工作，即便是专注于开发操作系统的微软，也没有在商业市场中一直维持成功。另一方面，操作系统复杂度极高，后续效能或安全问题的维护也需要极大的功夫，而从来没有在操作系统耕耘过的华为，是否有能力维持这么复杂的生态，这也是让人质疑的一点。

当然，开源可以把很多的维护工作让社群分担，但是在寄望社群可以提供帮助之前，恐怕要先确定鸿蒙对于社群是否有如此大的吸引力，毕竟目前鸿蒙的商业生态规划还是针对华为既有的封闭产品，如果只有华为的产品能用，对于推广鸿蒙生态，开源的意义也就不大。

另一方面，华为承诺的开放源码至今仍未实现，因此开发者也不能自行编译并安装测试，这也让开源社群颇为质疑。