方舟编译器和java编译器区别,用方舟编译器

　　继去年华为推出黑科技GPU Turbo之后，今年再次抛出一枚重磅炸弹。安卓性能革命，华为方舟编译器，号称解决安卓程序“解释和执行同时进行”的低效率，全程执行机器码高效运行程序。架构优化，显著提升性能。系统运行流畅度提升24%，系统响应提升44%，三方应用运行流畅度提升60%，并承诺向业界开源。如果你敢开源，这个数据应该没有水分。大家应该都看过网上P30 Pro挂S10的视频。

　　解决安卓程序中“解释执行”的低效。什么是解释和执行？也就是Android如何执行Apk中的代码？这得从机器码说起。

　　机器代码

　　不管是低级语言，比如汇编，还是各种高级语言，Java，C等等。今天广泛使用的，都是CPU的天书。它只知道二进制机器码。当然机器码对你来说也是天书。那么你应该如何指导CPU运行你的程序呢？这时候你需要一个翻译器，把你的代码翻译成机器代码给CPU，它会知道怎么执行。面对不同的终端，翻译内容也不同。如果只知道x86指令集翻译arm，肯定是翻译不出来的，就像拿着英文字典翻译日文一样。还有翻译工具。以下是一些常用的翻译工具：

　　装配工

　　将汇编代码直接翻译成机器代码。因为汇编代码一般和机器码一一对应，所以速度很快。只是汇编语言，可读性差，

　　很难用，普通开发者写大型程序基本不现实。

　　编译程序

　　编译器把我们平时用于开发的高级语言，比如Java/C，翻译成机器代码供CPU使用。这种编译比较慢，但是执行起来会很快。

　　解释者

　　程序不需要编译，运行时翻译成机器语言，每次执行都要翻译。所以效率比较低。可以想象，这种操作模式要慢很多。

　　典型的解释性语言，php/js/python等。

　　JAVA代码是如何执行的？

　　Java程序的执行依赖于Java虚拟机(JVM)，它可以直接识别字节码。Java代码编译后会生成类文件，也就是字节码文件，由JVM处理。而JVM是如何执行类文件的呢？这里

　　以热点为例。在类文件被虚拟机加载后，它将被存储在方法区。在实际操作中，虚拟机将执行方法区域中的代码。

　　将字节码翻译成机器码的工作自然由JVM承担。在HotSpot中，有几种翻译形式。

　　解释和执行

　　将逐字节代码翻译成机器码并执行。

　　准时制

　　在执行之前，将方法中包含的所有字节码编译成机器码。

　　前者的优点是不用等待编译，后者的优点是实际运行速度更快。HotSpot默认采用混合模式，结合了解释执行和即时编译。

　　的优点。它会先解释执行字节码，然后用方法实时编译其中重复执行的热代码。

　　Android代码是如何执行的？

　　目前应用最广泛的Android开发是Java，即使不是Java，也是JVM语言。Android项目中的Java源文件编译生成。

　　类文件，最后打包成DEX字节码文件。Dalvik或Art负责将DEX字节码翻译成机器码。

　　Android 5.0之前，还是以Dalvik为主。Dalvik是解释执行加JIT。app每次运行，都会动态改变Dalvik字节码的一部分。

　　解释为机器码。随着应用程序的运行，更多的字节码被编译和缓存。因为JIT只编译一部分代码，占用的内存少，设备的物理空间也少。但是解释和实现效率低下，这也是后来Dalvik被抛弃的原因。

　　从Android 4.4开始，Android引入了Art，到了Android 5.0，Art正式取代了Dalvik。Art采用AOT(提前)编译方式，即在应用安装过程中，将所有Dex字节码翻译成机器码，存储在设备空间，完全抛弃JIT，带来的好处是显而易见的。

　　Apps运行速度更快，因为安装过程中已经完成了DEX字节码的解释，直接运行机器码。

　　因为可以直接执行本地代码，所以减少了应用程序的启动时间。

　　节省功耗，不需要逐行解释字节码。

　　增强垃圾收集。

　　增强的开发工具。

　　运行直接机器码，嗯，等等，方舟编译器不就是这么干的吗？答案肯定是否定的，否则完全没有存在的必要。事实上，这种基于AOT的模式已经被安卓抛弃了。如果你用过Android 5.0或6.0，你不会忘记安装应用程序的漫长等待。因为字节码需要在安装过程中进行翻译，所以安装过程会非常长，特别是对于

　　对于一些大规模的应用。此外，安装过程中翻译的机器码也占用了更多的机身存储空间。

　　Android 7.0，Android增加了JIT，一个具有代码分析功能的实时(JIT)编译器。事实上，根据二八定律，频繁运行的热代码可能只占20%甚至更少，所以我们没有必要提前通过AOT将所有字节码翻译成机器码。AOT在安装过程中被放弃，以加快安装速度，因此必须在第一次使用时解释和执行它。hxddx在使用应用的时候，JIT就开始分析代码，在合适的时候把字节码翻译成机器码，不断提升Android应用运行时的性能。此外，当设备闲置时，AOT会发挥作用。它会将热代码翻译成机器码并保存，进一步提高运行效率。从这个角度来看，Android现在解释了执行、JIT和AOT同时存在。官网下图说明了Art下的JIT架构。

　　关于解释器，更高版本的Android实现不再那么弱了。根据官网的介绍：

　　通过引入Mterp(用汇编语言编写的具有核心提取/解码/解释机制的解释器)，Android版本中的解释器性能得到了显著提升。Mterp模仿快速Dalvik解释器，支持arm、arm64、x86、x86_64、mips和mips64。就计算代码而言，ART的Mterp大致相当于Dalvik的快速解释器。

　　不过，有时它的速度可能会显著降低，甚至大幅降低：

　　调用性能。

　　操作和Dalvik中其他被视为嵌入式函数的高频用户方法。

　　堆栈内存使用率很高。

　　Android 8.0解决了这些问题。

　　说了这么多，无非就是安装速度，空间占用，运行速度的平衡。Android目前应该做得还不错，但是批评的声音还是很多。

　　现在可以肯定的是，方舟编译器永远不可能是一个完整的AOT。PPT中最后一句话是“希望APP厂商尽快使用”，不是手机厂商，所以不排除Ark编译器可以直接把Apk，或者Apk中的DEX，打包成机器码格式。但是由于机器码与平台不兼容，所以方舟编译器是否必须绑定EMUI还不能确定。其实说到底，这一切都应该是为华为的新手机系统做铺垫。华为的野心，以及极其先进的技术储备，相信一个完整的华为生态系统离我们并不遥远。

　　编译器叫方舟，新系统干脆叫担心的豆豆！

　　文章首发于微信微信官方账号：冰心说，专注分享Java、Android原创知识，解决LeetCode问题。欢迎扫码关注！

郑重声明：本文由网友发布，不代表盛行IT的观点，版权归原作者所有，仅为传播更多信息之目的，如有侵权请联系，我们将第一时间修改或删除，多谢。