漫话：如何给女朋友解释鸿蒙OS是怎样实现跨平台的？

周末在家休息，女朋友在刷朋友圈，突然她问我：

2019年8月9日华为开发者大会上，华为消费者业务CEO余承东正式宣布发布自有操作系统鸿蒙，内核为Linux内核、鸿蒙微内核和LiteOS。未来将摆脱Linux内核和LiteOS，只有鸿蒙微内核。

鸿蒙（英语：Harmony OS，开发代号Ark）是华为自2012年开发的一款可能兼容Android app的跨平台操作系统。

在以前，平台 ≈ 操作系统。所以，传统意义上的跨平台即不依赖于操作系统，也不依赖硬件环境。一个操作系统下开发的应用，放到另一个操作系统下依然可以运行。

但是随着科技的发展，平台 ≈ 操作系统已经不成立了，就像华为推出的鸿蒙OS，他可以支持到多种多样的设备，如手机、手表、电脑、汽车、智能家居设备等。

所以，今天我们谈的跨平台，指的是跨设备。即平台 ≈ 设备

所以，华为希望鸿蒙OS可以运行在各种各样的设备上，所以，鸿蒙OS必然需要具备跨平台的能力。

而且，鸿蒙想要做的不仅仅是操作系统可以跨平台，更重要的是要让用户和开发者真正的感受到跨平台。

所以，跨平台操作系统鸿蒙的目的是：使开发者能够聚焦自身业务逻辑，像开发同一终端一样开发跨终端分布式应用，也使最终消费者享受到强大的跨终端业务协同能力为各使用场景带来的无缝体验。

先来说说Java是如何实现跨平台的。

Java对于跨平台的支持，就像对安全性和网络移动性的支持一样，是分布在整个Java体系结构中的。其中扮演者重要的角色的有Java语言规范、Class文件、Java虚拟机（JVM）等。

首先，在Java语言规范中，规定了Java语言中基本数据类型的取值范围和行为。其次，所有Java文件要编译成统一的Class文件。最后，通过Java虚拟机将Class文件转成对应平台的二进制文件。

Java的平台无关性是建立在Java虚拟机的平台有关性基础之上的，是因为Java虚拟机屏蔽了底层操作系统和硬件的差异。

想要运行一段Java代码，要经过多个步骤，将Java源代码转换成机器可以执行的机器代码，这个过程主要由虚拟机来完成。

在著名的HotSpot虚拟机中，主要有解释执行和即时编译两种形式：

• 解释执行

• 逐条将字节码翻译成机器码并执行

• 即时编译（Just-in-time ，JIT）

• 将一个方法中包含的所有字节码编译成机器码后再执行。

HotSpot 默认采用混合模式，综合了解释执行和即时编译两者的优点。它会先解释执行字节码，而后将其中反复执行的热点代码（热点检测），以方法为单位进行即时编译。

Android其实基于Java语言的，所以同理，想要运行一段Android代码，也要经过多个步骤，将Android源代码转换成机器可以执行的机器代码。

但是这个转换过程在Android的不同版本中实现不尽相同：

Android 1.0（2008 年）：采用一个名为 Dalvik 的虚拟机，并且集成了一个解释器。当 App 运行时，就会调用这个解释器，对代码进行逐句解释，速度很慢。

Android 2.2（2010 年）：引入 JIT（Just In Time）即时编译机制，当 App 运行时，会将用户经常使用的功能编译为机器能直接执行的 010101 机器码，不用一句一句地去翻译。当出现不常用的功能时，再调用解释器来翻译；这样速度加快，但每次启动 App 都要重新编译一次，不能一劳永逸。

Android 5.0（2014 年 10 月）：将虚拟机 Dalvik 换成 ART（Android Run Time），将 JIT 的编译器替换成 AOT（Ahead of Time）。如此，App 在下载后安装到手机上时同时把能编译的代码先编译成机器听得懂的 101010；剩下不太好翻译的代码，就在用户使用时再叫醒解释器来翻译。如此，不用每次打开 App 都需要编译，但安装 App 的时间有点长，而且占用手机空间。

Android 7.0（2016 年）：采用混合编译机制，安装时先不编译中间代码，而是在用户空闲时将能够编译成机器码的那部分代码，通过 AOT 编译器先静态编译了。如果 AOT 还没来得及编译或者不能编译，再调用 JIT+ 解释器。这种机制，相当于用时间换空间，既缩短了用户安装 APP 的等待时间，又将虚拟机里编译器和解释器能做的优化提升到最大效率了。

可以看到，从2008年的Android 1.0开始，Android在编译优化上面在一直下功夫。

当前的 Android 采用的是解释执行 + JIT + AOT 的综合模式，在 空间占用+安装速度+运行速度 上已经达到了一个很好的平衡。

但是Android的编译问题一直被诟病。尽管在后续的Android 8.0 上改进了解释器，解释模式执行效率大幅提升；Android 10.0 上提供了预先放置热点代码的方式，应用在安装的时候就能知道常用代码会被提前编译。

但是，目前来看，无论如何，Android都没能摆脱这样一个前提：即应用在被打包成 APK 的时候，采用的还是 Java 代码。换句话说，在 APK 变成用户可应用的过程中，还经历了一个在 Android 系统内部的编译过程，这是一个绕不过的坎。

那么，鸿蒙OS的代码编译是怎么样的呢？他又是如何解决跨平台的问题的呢？

从上图中可以看到，在鸿蒙OS架构中，方舟编译器和多终端开发IDE扮演着重要的位置。

跨平台有一个最大的挑战，那就是各个平台的适配问题，尤其是目前各种设备类型越来越多，如何将同一个应用，在手机、手表、汽车、电视上面都可以适配的展示呢？这就是多终端开发IDE所做的事情。

使用华为提供的多终端IDE，多语言统一编译，分布式架构Kit提供屏幕布局控件以及交互的自动适配，支持控件拖拽，面向预览的可视化编程，从而使开发者可以基于同一工程高效构建多端自动运行App，实现真正的一次开发，多端部署，在跨设备之间实现共享生态。

上图就是华为提供的IDE，在里面可以通过图形化界面拖拽控件，并且IDE可以帮助自动适配各种终端设备。

有了IDE，开发可以方便的开发一套代码，这样可以自动适配到各种设备中，但是各种设备所执行的机器指令是不一样的，如何把这一套代码分别编译成各个设备需要的机器指令呢？

Android设备是由不同设备上内置的虚拟机进行编译的，所以编译之前就知道这个设备具体是什么了，那么，鸿蒙OS是怎么做的呢？这就是方舟编译器所干的事情了。

华为方舟编译器是首个取代Android虚拟机模式的静态编译器，可供开发者在开发环境中一次性将高级语言编译为机器码。此外，方舟编译器未来将支持多语言统一编译，可大幅提高开发效率。

Android之所以”慢”，是因为他的编译过程是在终端进行的，也就是说需要在用户的手机上，通过虚拟机进行编译成可执行的机器代码。

而鸿蒙OS使用的方舟编译器，可以将高级语言（Java）直接变成机器码，从而绕过了虚拟机。并且这个编译过程并不是在用户的手机上完成的，而是在应用开发阶段就完成了。

通过方舟编译器，开发者的应用在下载之前就已经转化成为机器可以识别的代码，因而可以在手机上快速安装、启动和运行，而无需在经过 VM 的编译——某种程度上，方舟编译器是将编译过程提前到应用开发阶段，从而大幅度减少了智能手机和操作系统的运行负担。

华为官方介绍，方舟编译器是首家完全替代语言虚拟机的静态编译器，完全不需要解释器。兼顾Java开发效率和C语言运行效率的编译器。

除了代码编译，方舟编译器也提供了更高效的内存机制，它与 Android 内存回收的不同之处在于：

Android 在内存回收上采用集中回收机制，发声全局回收时更需要暂停应用，这也是随机卡顿的根因之一。而方舟编译器采用了引用计数法来进行内存的实时回收，并且配合使用了专门的消除环算法（消除对象互相引用带来的无法回收问题），来避免 GC 集中式回收带来的系统卡顿。相比 GC，方舟的内存回收是实时的而非集中式的，且不需要暂停应用进程，这样便大大消除了卡顿。

另外，就像JVM其实也是支持多种语言一样，华为表示，方舟编译器未来也会支持更过的开发语言。换句话说，其他语言的开发者，日后也能开发基于鸿蒙OS的应用。

​