JVM,Dalvik,ART对比

一。JVM

基于栈
占用空间更少
为简化编译，常量池使用32位索引
标准JVM施行8位堆栈指令，Dalvic直接使用16位指令集作用于局部变量，局部变量通常来自4位“虚拟寄存器”区，这样减少dalvic指令计数，提高翻译速度
当andrid启动时，dalvic监视所有的程序，并且创建依存关系树，为每个程序优化代码，并存储缓存中，dalvic第一次加载后会生成cache文件，方便下次加载，所以第一次会很慢。
dalvic采取预先算好的Goto地址，每个指令对内存的访问都在64字节边界上对其，这样可以节省一个指令进行查标的时间，为了强化功能，dalvic提供了快速翻译器(fast interpreter)
一般来说，基于堆栈的机器，必须使用指令才能从堆栈中加载和操作数据，
基于寄存器的机器，需要更多的指令才能实现相同的性能。但是基于寄存器的指令必须经过编码，他们的指令往往更强大

二。Dalvic

Dalvic基于寄存器

2.1 JIN(just in time)及时编译技术，

最早android2.2引入Dalvic，程序启动时，JIT通过连续的性能分析，优化程序代码的执行，在程序执行中，dalvic不断进行字节码编译成机器码的工作

三。ART（Android Runtime）

android4.4对外发布，android5.0正式替换
为了保证程序向下兼容，ART使用相同的字节码文件(Dex),即在应用程序下保留dex文件供旧程序调用，可链式格式ELF可执行文件，一旦一个程序被ART的dex2oat命令编译，程序会通过ELF(可执行文件)来运行

调用一个完整的命令行可执行文件

调用完整的可执行文件，这在Android中并不是官方推荐的。但通常基于Linux系统的编程，这又是不可避免的。很多必要操作，如果开发系统的SDK支持不足，或者用起来不方便。都可以通过直接访问系统层参数文件或者系统层可执行文件来完成。
不同的操作系统，有不同的可执行文件格式。比如Windows的EXE/PE格式，macOS的Mach-O。在Linux上，就是ELF格式。
作为C语言为主要编程工具的Linux系统，拥有庞大的ELF可执行资源，几乎所有的程序都是直接、或者间接由ELF可执行程序完成的，甚至包括JVM本身。
一些新兴语言，比如golang，也提供了直接生成Android二进制文件的交叉编译功能。
所以让Android程序直接可以同ELF可执行程序互动，不仅仅是同C语言混合编程的问题，而是这样可以获得大量社区资源的支持。很多开源项目拿来，很少的修改，就可以在Android程序的背后发挥作用。

早期的Android系统调用可执行程序非常容易，把编译好的程序拷贝到Android中，设置为可执行属性，就可以执行了。
随着Android系统的升级，安全性越来越好，除非root，上面这种方式已经不灵了。越来越多的限制让直接执行内嵌的可执行文件变得不再可行。

在当前的Android版本中，在APK程序中内嵌可执行文件，需要通过以下几个步骤：

在NDK中编译对应的源代码。或者在其它语言环境中，使用对应工具，生成在Android环境可以执行的二进制代码。
除了.so之外的编译结果，并不会自动打包到APK中。所以编译出的二进制代码，需要作为数据文件，放入APK的资源区。
在Java代码中，根据检测到的CPU类型，把对应的可执行文件，从数据区拷贝到Android设备上，并设置为可执行。
在Java代码中调用可执行程序，并获取结果。

3.1 AOT(ahead-of-time)预编译技术

在应用的安装中，ART就已经将所有的字节码转换成机器码了

3.2 其他改善

改善了性能：垃圾回收，应用程序除错，性能分析

Android对apk的执行流程

Java文件在编译成class文件，然后经过Android平台的dx工具转换为Dex文件后，同Native code（JNI）和资源一起打包成apk，apk安装到手机后解压出Dex文件。Dalvik会通过dexopt工具将Dex优化，成为Odex文件，Odex文件的效率比Dex高，但其中大部分代码仍然需要每次执行时编译；而ART则会将Dex通过dex2oat工具编译得到一个ELF文件，它是一个可执行的文件。

引用：

1. JVM、Dalvik VM和ART虚拟机之间的区别
2. 理解这一点，JVM原理就简单了
3. Jvm、Dalvik和Art的区别
4. 理解这一点，JVM原理就简单了