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

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

鸿蒙OS回顾

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

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

图：鸿蒙OS的四大技术特性

1．分布式架构首次用于终端OS，实现跨终端无缝协同体验

2. 肯定时延引擎和高性能IPC技术实现系统天生流畅

3. 基于微内核架构重塑终端设备可信安全

4. 经过统一IDE支撑一次开发，多端部署，实现跨终端生态共享

什么是跨平台

在之前，平台 ≈ 操做系统。因此，传统意义上的跨平台即不依赖于操做系统，也不依赖硬件环境。一个操做系统下开发的应用，放到另外一个操做系统下依然能够运行。

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

因此，今天咱们谈的跨平台，指的是跨设备。即平台 ≈ 设备

因此，华为但愿鸿蒙OS能够运行在各类各样的设备上，因此，鸿蒙OS必然须要具有跨平台的能力。

并且，鸿蒙想要作的不只仅是操做系统能够跨平台，更重要的是要让用户和开发者真正的感觉到跨平台。

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

Java实现跨平台

先来讲说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实现跨平台

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 的等待时间，又将虚拟机里编译器和解释器能作的优化提高到最大效率了。

Android编译的问题

能够看到，从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的应用。

参考资料：

https://www.jishuwen.com/d/2NN3

https://www.zhihu.com/question/339567108 https://www.cnbeta.com/articles/tech/876171.htm https://www.cnbeta.com/articles/tech/876919.htm https://juejin.cn/post/6844903817637691400

​