【转】安卓Java的虚拟机区别

Google于2007年底正式发布了Android SDK, 作为 Android系统的重要特性，Dalvik虚拟机也第一次进入了人们的视野。它对内存的高效使用，和在低速CPU上表现出的高性能，确实令人刮目相看。 依赖于底层Posix兼容的操作系统，它可以简单的完成进程隔离和线程管理。每一个Android应用在底层都会对应一个独立的Dalvik虚拟机实例， 其代码在虚拟机的解释下得以执行。 
很多人认为Dalvik虚拟机是一个Java虚拟机，因为Android的编程语言恰恰就是Java语言。但是这种说法并不准确，因为Dalvik虚拟机并不是按照Java虚拟机的规范来实现的，两者并不兼容；同时还要两个明显的不同:

• Java虚拟机运行的是Java字节码，而Dalvik虚拟机运行的则是其专有的文件格式DEX（Dalvik Executable）。
• 在Java SE程序中的Java类会被编译成一个或者多个字节码文件（.class）然后打包到JAR文件，而后Java虚拟机会从相应的CLASS文件和JAR文 件中获取相应的字节码；Android应用虽然也是使用Java语言进行编程，但是在编译成CLASS文件后，还会通过一个工具（dx）将应用所有的 CLASS文件转换成一个DEX文件，而后Dalvik虚拟机会从其中读取指令和数据。

Dalvik和Android系统Android作为新一代的基于Linux的开源手机操作系统，其系统架构由下而上可以分为以下几部分：

• Linux内核
• 本地库
• Android运行库
• 应用框架
• 应用

 java虚拟机和Dalvik虚拟机的区别：

	java虚拟机	Dalvik虚拟机
	java虚拟机基于栈。 基于栈的机器必须使用指令来载入和操作栈上数据，所需指令更多更多	dalvik虚拟机是基于寄存器的
	java虚拟机运行的是java字节码。（java类会被编译成一个或多个字节码.class文件，打包到.jar文件中，java虚拟机从相应的.class文件和.jar文件中获取相应的字节码）	Dalvik运行的是自定义的.dex字节码格式。（java类被编译成.class文件后，会通过一个dx工具将所有的.class文件转换成一个.dex文件，然后dalvik虚拟机会从其中读取指令和数据）
		常量池已被修改为只使用32位的索引，以 简化解释器。dalvik的堆和栈的参数可以通过-Xms和-Xmx更改
		一个应用，一个虚拟机实例，一个进程（所有android应用的线程都是对应一个linux线程，都运行在自己的沙盒中，不同的应用在不同的进程中运行。每个android dalvik应用程序都被赋予了一个独立的linux PID(app_*)）

Dalvik和标准Java虚拟机（JVM）之间的首要差别之一，就是Dalvik基于寄存器，而JVM基于栈。

Dalvik和Java之间的另外一大区别就是运行环境——Dalvik经过优化，允许在有限的内存中同时运行多个虚拟机的实例，并且每一个 Dalvik应用作为一个独立的Linux进程执行。

（1）虚拟机很小，使用的空间也小；

（2）Dalvik没有JIT编译器；

（3）常量池已被修改为只使用32位的索引，以简化解释器；

（4）它使用自己的字节码，而非Java字节码。

 

Dalvik虚拟机架构：

在android源码中,Dalvik虚拟机的实现位于“dalvik/”目录下，其中“dalvik/vm”是虚拟机的实现部分，将会编译成libdvm.so;而"dalvik/libdex"将会编译成libdex.a静态库作为dex工具；“dalvik/dexdump”是.dex文件的反编译工具；虚拟机的可执行程序位于“dalvik/dalvikvm”中，将会编译成dalvikvm可执行文件。

dalvik虚拟机架构：

Android应用编译及运行流程：

 Dalvik进程管理：

dalvik进程管理是依赖于linux的进程体系结构的，如要为应用程序创建一个进程，它会使用linux的fork机制来复制一个进程（复制进程往往比创建进程效率更高）。

Zygote是一个虚拟机进程，同时也是一个虚拟机实例的孵化器，它通过init进程启动。首先会孵化出System_Server（android绝大多系统服务的守护进程，它会监听socket等待请求命令，当有一个应用程序启动时，就会向它发出请求，zygote就会FORK出一个新的应用程序进程）.每当系统要求执行一个android应用程序时，Zygote就会运用linux的FORK进制产生一个子进程来执行该应用程序。

JVM和Dalvik进程管理：

 

linux中进程间通信的方式有很多，但是dalvik使用的是信号方式来完成进程间通信。

Android的初始化流程：

实际上.dex文件就是把多个class文件中的常量、方法等放到一起。形成如上图所示的结构。

在架构上jvm是基于栈的架构，所以每次访问数据cpu都要到内存中取到数据。

而dalvik是基于寄存器的架构。寄存器是在cpu上的一块存储空间，cpu如果直接从寄存器上读取数据的话就会快很多。

【以下也是转】

(1) Dalvik VM和JVM 的第一个区别是 Dalvik VM是基于寄存器的架构（reg based），而JVM是栈机（stack based）。reg based VM的好处是可以做到更好的提前优化（ahead-of-time optimization）。 另外reg based的VM执行起来更快，但是代价是更大的代码长度。
(2) 另外一个区别是Dalvik可以允许多个instance 运行，也就是说每一个Android 的App是独立跑在一个VM中.这样做的好处是一个App crash只会影响到自身的VM，不会影响到其他。 Dalvik的设计是每一个Dalvik的VM都是Linux下面的一个进程。那么这就需要高效的IPC。另外每一个VM是单独运行的好处还有可以动态active/deactive自己的VM而不会影响到其他VM
(3) 接下来就是关于版权之类争论。（可以参看下面文章）
既然reg based VM有那么多好处，为什么之前设计JAVA的人没有采用reg based而是采用stack based的呢？ 原来stack based的VM也有其优点，就是它不对host平台的reg数量做假设，有利于移植到不同的平台。而Dalvik则不关心这些，因为它本来就是为ARM这样的多reg平台设计的。另外Dalvik被移植到x86也说明，即使是x86这种reg很少的平台，reg based的VM也是没有问题的。

下面着重说下DVM的优势：（部分文字我加黑以突出）
1、在编译时提前优化代码而不是等到运行时 
2、 虚拟机很小，使用的空间也小；被设计来满足可高效运行多种虚拟机实例。 
3、常量池已被修改为只使用32位的索引，以 简化解释器

JVM 的字节码主要是零地址形式的，概念上说JVM是基于栈的架构。Google Android平台上的应用程序的主要开发语言是Java，通过其中的Dalvik VM来运行Java程序。为了能正确实现语义，Dalvik VM的许多设计都考虑到与JVM的兼容性；但它却采用了基于寄存器的架构，其字节码主要是二地址/三地址的混合形式。

基于栈与基于寄存器的 架构，谁更快？现在实际的处理器，大多都是基于寄存器的架构，从侧面反映出基于寄存器比基于栈的架构更与实际的处理器接近。但对于VM来说，源架构的求值 栈或者寄存器都可能是用实际机器的内存来模拟的，所以性能特性与实际硬件又有不同。一般认为基于寄存器架构的Dalvik VM比基于栈架构JVM执行效率更高，原因是：虽然零地址指令更紧凑，但完成操作需要更多的load/store指令，也意味着更多的指令分派 （instruction dispatch）次数与内存访问次数；访问内存是执行速度的一个重要瓶颈，二地址或三地址指令虽然每条指令占的空间较多，但总体来说可以用更少的指令完 成操作，指令分派与内存访问次数都较少。

我们从下面的截图可以明了的看到与同一段Java代码对应的Java bytecode 与Dalvid bytecode的比较：网上一些文章在讨论 Dalvik 时，大都简单提及 Dalvik 执行速度比 JVM 快，但移植性稍差。这里 我们延伸探讨一下。在一个解释器上执行 VM 指令，包含三个步骤，指令分派、访问操作数和执 行计算。 指令分派（Instructions dispatch）负责从内存中读取 VM 指令，然后跳转到相应的解释器代码 指令分派 中。上面提到过，完成同样的事情，基于栈的虚拟机需要更多的指令，意味着更多的指令分派和 内存访问次数，这是 JVM 的执行性能不如 Dalvik VM 的原因之一。
访问操作数 访问操作数（Operands access）是指读取和写回源操作数和目的操作数。Dalvik VM 通过虚拟 操作数 寄存器来访问操作数， 由于具有相近的血缘， Dalvik 的虚拟寄存器在映射到物理寄存器方面具有 更充分的优势， 这也是 Dalvik VM 性能较佳的一个原因。 JVM 的操作数通过操作数栈来访问， 而 因为指令中没有使用任何通用寄存器，在虚拟机的实现中可以比较自由的分配实际机器的寄存 器，因而可移植性高。作为一个优化，操作数栈也可以由编译器映射到物理寄存器上，减少数据 移动的开销。 指令执行（Instructions compute）这个似乎没什么可解释的，老老实实执行就行。 指令执行

一个应用中会定义很多类， 编译完成后即会有很多相应 的CLASS文件，CLASS文件 间会有不少冗余的信息。 
dex字节码和标准Java的字节码（Class）在结构上的一个区别是dex字节码将多个文件整合成一个，这样，除了减少整体的文件尺寸，I/O操作，也提高了类的查找速度。 
原来每个类文件中的常量池现在由DEX文件中一个常量池来管理。 
DEX文件可以进行进一步优化。优化主要是针对以下几个方面：

1、调整所有字段的字节序（LITTLE_ENDIAN）和对齐结构中的没一个域 
2、验证DEX文件中的所有类 
3、对一些特定的类进行优化，对方法里的操作码进行优化

优化 优化后的文件大小会有所增加，应该是原DEX文件的1-4倍。 odex是为了在运行过程中进一步提高性能，对dex文件的进一步优化 
每一个Android应用都运行在一个Dalvik虚拟机实例里，而每一个虚拟机实例都是一个独立的进程空间。每个进程之间可以通信（IPC，Binder机制实现）。虚拟机的线程机制，内存分配和管理，Mutex等等都是依赖底层操作系统而实现的。
不同的应用在不同的进程空间里运行，当一个虚拟机关闭或意外中止时不会对其它虚拟机造成影响，可以最大程度的保护应用的安全和独立运行。
 Zygote是虚拟机实例的孵化器。AndroidRuntime.cpp中ZygoteInit.main()的执行会完成一个分裂，分裂出来的子进程继续初始化Java层的架构，这个分裂出来的进程就是system_server。每当系统要求执行一个Android应用程序，Zygote就会FORK出一个子进程来执行该应用程序。这样做的好处显而易见：Zygote进程是在系统启动时产生的，它会完成虚拟机的初始化，库的加载，预置类库的加载和初始化等等操作，而在系统需要一个新的虚拟机实例时，Zygote通过复制自身，最快速的提供个系统。另外，对于一些只读的系统库，所有虚拟机实例都和Zygote共享一块内存区域，大大节省了内存开销。
=============================分割线===========================
下面我以我的认知来简单总结描述一下，DVM和JVM这种架构上的差异所产生的影响

JVM其核心目的，是为了构建一个真正跨OS平台，跨指令集的程序运行环境（VM）。DVM的目的是为了将android OS的本地资源和环境，以一种统一的界面提供给应用程序开发。严格来说，DVM不是真正的VM，它只是开发的时候提供了VM的环境，并不是在运行的时候提供真正的VM容器。这也是为什么JVM必须设计成stack-based的原因。

JVM：所有的jar程序，其运行环境完全是由JVM来提供，包括运行时，各类资源的调度，而JVM的架构，其设计为一个JVM里面可以运行多个java程序，JVM就像一个真正的“机器”，可以跑着多个程序。如果去看看一些企业级的JVM（例如tom cat，WAS），从OS的进程管理中，一般你只能看见一个JVM的进程（当然，你也可以起多个JVM，但JVM架构就是OS-JVM-APP的3层运行时模式），而看不见JVM里面运行的程序，而一个JVM里，可以跑多个java app。简单得说，JVM完全屏蔽了应用程序和OS之间的联系，而改用JVM充当了中间层，这也是一个真正跨平台运行时VM必须要做到的。只要是相同的JDK，JVM为所有在其中运行的程序，提供了完全一致的运行环境，而不论你是什么样的底层OS和硬件条件。因此这也是我在其他一篇答案中提到，JVM的特点是取底层OS和硬件环境的交集，从而保障这种一致性。而所有应用程序和底层资源的互动，一定是依赖JVM的传递和转换来实现。JVM真正实现了一个OS对应用程序运行时管理的所有功能。从开发环境角度和运行时角度，都是完全一致的真正VM

DVM：而DVM的特点在于使用了Zygote，Zygote有几个非常有意思的特点。
一是Zygote采用预加载，由其首先判定安装的APK的需要以及相互依存树，以及OS及硬件环境的特点，在每次启动的时候进行预加载（现在你明白为什么android的app在应用管理里你能轻易查到它都调用了那些关键性的本地资源的原因了吧？），这就意味着，你安装的应用越多，Zygote的加载就越慢，一般来说你的手机启动就会越慢。另外来说，在不同的硬件环境里（例如有无GPS芯片）Zygote初始化的实例是不同的。也就是说，zygote并不提供一个统一的运行环境，具有更好的弹性，这种机制意味着DVM可以取底层资源的合集来提供上层应用使用，差别只是在程序安装或者启动的过程中，DVM可以提示程序需求资源，本地环境可能未能满足而导致无法运行。DVM的Zygote并不是提供一个运行时容器，它提供的只是一个用于共享的进程，所有的应用程序运行，都是独立的，OS级别的进程，直接受到OS层面的资源控制以及调度的影响，只是他们共享Zygote说预加载的类而已。这也就是我为什么说，DVM就像是给每个应用程序在底层加了个套子，而不是提供了一个真正的运行时的VM。也就是说，DVM在开发环境中说提供的VM平台，和运行时的环境是很有可能不一致的。开发环境中提供的VM平台，是一个各种运行时可能环境的合集。
从这点上来说，一般我们认为，JVM中的JAVA程序的崩溃，最多导致JVM的崩溃，而不会导致OS崩溃，但是apk的崩溃，可以直接导致OS崩溃，android手机会因为应用程序死机，大家应该是很常见了。但是大家一般是不会看到java程序导致死机吧？因为运行时中间隔着一个JVM。（当然，其实还是有些小门道可以用java程序让OS崩溃，因为这个，我和某些JAVA大拿打赌赢过饭局，呵呵，不过这是其他话题，不在这里展开了）

除此之外，在JVM的机制中，不同的程序，打包以后，他们都是在运行层级真正独立的程序（指程序应用他们相互之间的关系，而不是和JVM的关系），即便他们在包里使用了同样的类，运行时都是单独加载，单独运行的（及加载多遍）。
DVM这种预加载-共享的机制，使得不同应用之间，在运行时，是共享相同的类的，一般来说，在系统资源消耗方面，拥有更高的效率。

最后，补充一点，byte code并不意味着就是解释执行，也能是加载编译，安装编译，预编译等等。实际上，不同的byte code的程序，不同的技术，不同的具体语言，其真正执行的情况是挺复杂，难以一概而论的，好多都是混合技术的案例，从我对odex的技术来看，就是个典型案例。当然这是题外话，不多展开了