周末在家歇息，女同伙在刷同伙圈，倏忽她问我：
鸿蒙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的应用。
