从JVM到ART

众所周知，android系统的底层操作系统是Linux，上层应用程序是用java代码或者kotlin来编写的，那么这些用高级语言编写的应用程序是如何运行在linux系统之上呢？想必大家都知道了，链接这两者的桥梁就是虚拟机。那么android的虚拟机和传统的JVM有什么区别，又有什么关系呢？要回答这些问题，我们先看下两者在编译成虚拟机可以执行的字节码或者机器语言过程的对比：

传统的JVM，以Sun公司的HotSpot为例：

Android ART：

两者的过程看，都会经过javac编译成class 文件，但是之后就走向了不同的方向

HotSpot生成class文件后就通过类加载器加载字节码文件到虚拟机，虚拟机经过解释器或者JIT 生成机器码交由底层操作系统去执行，而android在4.4版本后，Java文件在编译成class文件,然后经过Android平台的dx工具转换为Dex文件后,同Native code(JNI)和资源一起打包成apk,apk安装到手机后解压出Dex文件。Dalvik会通过dexopt工具将Dex优化,成为Odex文件,Odex文件的效率比Dex高,但其中大部分代码仍然需要每次执行时编译;而ART则会将Dex通过dex2oat工具编译得到一个ELF文件,它是一个可执行的文件。 在ART中，打包在APK里面的Dex字节码是通过LLVM翻译成本地机器指令的。所以说经过优化编译后，进入到ART执行的就已经是机器码了，效率大大的提高了。

进入到虚拟机内部后，具体的执行方式又有什么不同呢？这就要回归到基于栈虚拟机和基于寄存器虚拟机两者的对比来看了。

HotSpot基于栈的，基于栈的虚拟机有一个操作数栈的概念，虚拟机在进行真正的运算时都是直接与操作数栈（operand stack）进行交互，不能直接操作内存中数据，也就是说不管进行何种操作都要通过操作数栈来进行，即使是数据传递这种简单的操作。这样做的直接好处就是虚拟机可以无视具体的物理架构，特别是寄存器。但缺点也显而易见，就是速度慢，因为无论什么操作都要通过操作数栈这一结构。

例如执行”a = b + c”，在基于栈的虚拟机上字节码指令如下所示：

I1: LOAD C

I2: LOAD B

I3: ADD

I4: STORE A

操作数栈上的变化如下图所示：

物理上操作如下：

基于寄存器的

比如a= b+c

指令只有一条：

I1: add a, b, c

物理机器上执行：

综上对比：

（1）指令条数：栈式虚拟机多 

（2）代码尺寸：栈式虚拟机 

（3）移植性：栈式虚拟机移植性更好 

（4）指令优化：寄存器式虚拟机更能优化

我们再来看经过编译后生成的class文件和dex文件，class文件java文件经过javac编译器生成的，有多少java文件就有多少个class文件，对于手机这样对内存和存储空间有限的设备来说，太多的class的文件就有点不划算了，而且查找太耗时，必须优化。而Dex记录整个工程中所有类文件的信息，注意是“整个工程”，即所有类文件信息，并去除冗余，区域复用并整合。下面给出两者文件的对比图：

以上只是大概列出了ART区别于传统的JVM比较重大的区别，具体内部实现上也有很大的区别。比如AOT，允许有多个ART实例，内存管理方式等等。最后ART是如何被创建出来呢？

Android系统在启动的时候，会创建一个Zygote进程，充当应用程序进程孵化器。Zygote进程在启动的过程中，又会创建一个ART虚拟机。Zygote进程是通过复制自己来创建新的应用程序进程的。这意味着Zygote进程会将自己的ART虚拟机复制给应用程序进程。通过这种方式就可以大大地提高应用程序的启动速度，因为这种方式避免了每一个应用程序进程在启动的时候都要去创建一个ART。事实上，Zygote进程通过自我复制的方式来创建应用程序进程，省去的不仅仅是应用程序进程创建ART虚拟机的时间，还能省去应用程序进程加载各种系统库和系统资源的时间，因为它们在Zygote进程中已经加载过了，并且也会连同ART虚拟机一起复制到应用程序进程中去。

最后我们总结下本文的主要内容：

1，传统虚拟机和ART编译过程的不一致

2，基于栈和基于寄存器的区别

3，传统虚拟机和ART执行文件的不一致

4，ART的创建过程

ART虽然是一个虚拟机，但是它已经不遵守虚拟机规范，但是一些JVM的核心理念还是保留了，比如垃圾回收机制等，如果想要更好的理解ART，建议还是先阅读JVM规范，循序渐进，慢慢摸索。