Android Dalvik虚拟机概述

Dalvik虚拟机概述

Dalvik是Google公司自己设计用于Android平台的Java虚拟机。Dalvik虚拟机是Google等厂商合作开发的Android移动设备平台的核心组成部分之一。它可以支持已转换为 .dex（即Dalvik Executable）格式的Java应用程序的运行，.dex格式是专为Dalvik设计的一种压缩格式，适合内存和处理器速度有限的系统。Dalvik 经过优化，允许在有限的内存中同时运行多个虚拟机的实例，并且每一个Dalvik 应用作为一个独立的Linux 进程执行。独立的进程可以防止在虚拟机崩溃的时候所有程序都被关闭。

面试纪要：如果有人面试问泥，应用进程就是linux一个进程，还是说一个liunx进程可以有多个dvk实例？

答案

每一个Android应用程序都在它自己的进程中运行，都拥有一个独立的Dalvik虚拟机实例。而每一个DVM都是在Linux 中的一个进程，所以说可以认为是同一个概念。

发展

Dalvik的诞生也导致人们开始忧虑Java平台的第一次大规模的分道扬镳或许已经是进行时了——有人已经把Davlik和微软的JVM以及Sun 对微软的诉讼联系起来，等着看Google身上是否也会发生类似事情；另外一些人则指出，Google并没有宣称Dalvik是一个Java实现，而微软却是这样做的。Sun也对可能带来的阵营分裂表达了忧虑情绪，并提出和Google合作来保证Dalvik和JVM之间的兼容性——Google对此的解释是，Dalvik是对解决目前Java ME平台上分裂的一次尝试，也是为了提供一个拥有较少限制许可证的平台。甚至还有人怀疑这是否是Sun和Google两大阵营对Java之未来的一次大规模较量。Ian Skerret认为，

Dalvik的诞生是对Sun尝试控制和保护来自Java ME收入来源的一次反应，以及对建立OpenJDK统辖理事会迟迟未果的回答。

这也导致Dalibor Topic怀疑Google是否要重履Sun走过的路：

当然，一个很有意思的问题是，为什么没人有勇气拿Google关于OpenJDK的问题反过来问Google呢？

虽然Android号称开源，但它仍是专有产品。Android做过兼容性保证，是在秘密会议室中签署和保管的。

Android不具备任何治理模型，也没有证据指出将来会出现治理模型。Android没有规范，并且它的许可证禁止任何替代实现的开发，因为这并非Google在SDK许可证中授权许可的使用权。Android完全在Google的掌控之下，一旦有竞争性应用在财政上损害了Google的利益，Google是保有一刀抹杀这些应用的权利的。从设计伊始，Android就受到限制，只能在Google的财务利益允许的条件内开放。专有的Java也不是什么好货色，旧瓶装新酒而已。这就好像我们在见证JCP的重生一样，人们排着队把开源社区的“街头信誉”在一个单一的、

专有的实现的基础上借给另外一个封闭的厂商垄断集团。只不过这次的大头改姓Google，而不是Sun了。(不过大家在叫唤着开源的时候,却似乎全都忘记了开发这一系列软件本身需要巨大的投入,因此利益在前,这其实也无可厚非.)

Stefano Mazzocchi发布了一篇分析报告，深切入里地探讨了围绕Java ME和Dalvik的许可证问题，他得出结论说，Dalvik的市场定位良好，足以给移动电话市场带来冲击。尽管Google一直都很小心避免引起诉讼的几个关键点，但Mazzocchi相信Sun还是会起草知识产权案的状告书（IBM也有可能）。他还指出，由于在JCP之外操作，Google可以非常快地对Android进行更改，而且可以避开Sun对任何JCP更动的否决权——这样他们也可以为诸如USB和蓝牙这样的组件加入接口，而这些组件在基础Java ME实现中是不可用的。

最后，通过在Apache许可证下授权许可Dalvik的源码，移动电话运营商更有可能采用Dalvik，因为运营商可以在不花费许可费用的情况下使用和修改它。

此外，Java也已经不再是人们在Dalvik上开发所选择的唯一语言了——已经有人在Dalvik上运行Scala取得了成功，并且Hecl也已经被成功移植了。另外更有人对运行Groovy做了一次尝试，不过目前为止还不怎么成功。Mono项目的创始人Miguel de Icaza也对在Dalvik源码公开之后将Mono整合到Dalvik上表示了兴趣，

而且也已经有人猜测如何用多种方式来实现整合了，包括与随Android SDK提供的Java到Dalvik重编译器类似的CIL（Common Intermediate Language，通用中间语言）到Dalvik重编译器。

简介

（dx是一套工具，可以将 Java .class 转换成 .dex 格式. 一个dex档通常会有多个.class。由于dex有时必须进行最佳化，会使档案大小增加1-4倍，以ODEX结尾。）

Dalvik和标准Java虚拟机(JVM)首要差别

Dalvik 基于寄存器，而 JVM 基于栈。

基于寄存器的虚拟机对于编译后变大的程序来说，在它们执行的时候，花费的时间更短。（Also of register-based VMs allow faster execution times at the expense of programs which are larger after compilation.）

Dalvik和Java运行环境的区别

1：Dalvik主要是完成对象生命周期管理，堆栈管理，线程管理，安全和异常管理，以及垃圾回收等等重要功能。

2：Dalvik负责进程隔离和线程管理，每一个Android应用在底层都会对应一个独立的Dalvik虚拟机实例，其代码在虚拟机的解释下得以执行。

3：不同于Java虚拟机运行java字节码，Dalvik虚拟机运行的是其专有的文件格式Dex

4:dex文件格式可以减少整体文件尺寸，提高I/o操作的类查找速度。

5:odex是为了在运行过程中进一步提高性能，对dex文件的进一步优化。

6：所有的Android应用的线程都对应一个Linux线程，虚拟机因而可以更多的依赖操作系统的线程调度和管理机制

7：有一个特殊的虚拟机进程Zygote，他是虚拟机实例的孵化器。它在系统启动的时候就会产生，它会完成虚拟机的初始化，库的加载，预制类库和初始化的操作。如果系统需要一个新的虚拟机实例，它会迅速复制自身，以最快的数据提供给系统。对于一些只读的系统库，所有虚拟机实例都和Zygote共享一块内存区域。

8：Dalvik是由Dan Bornstein编写的，名字来源于他的祖先曾经居住过名叫Dalvík的小渔村，村子位于冰岛Eyjafjörður

架构

不同于其他堆栈结构的Java虚拟机，dalvik采用的是基于寄存器的架构。

dx工具将部分（但不是全部）Java的.class文件转换成.dex格式。多个类被包含在一个.dex文件中。为了节省空间，各个类文件中重复的字符串和其他常数只在.dex输出中存放一次。Java字节码被转换成Dalvik虚拟机所使用的替代指令集。一个未压缩的.dex文件通常比来自相同.class文件的已压缩.jar文档小。

当被安装到移动设备时，Dalvik可执行文件可能会被修改。为了进一步优化，虚拟机可能会调整文件内部分数据的端序、内联一些函数和简单的结构体、并短路掉一些不必要的操作等。
　　自Android 2.2开始，Dalvik支持JIT（just-in-time，即时编译技术）。
　　优化后的Dalvik较其他标准虚拟机存在一些不同特性
　　·占用更少空间
　　·为简化翻译，常量池只使用32位索引
　　·标准Java字节码实行8位堆栈指令。Dalvik使用16位指令集直接作用于局部变量。局部变量通常来自4位的“虚拟寄存器”区。这样减少了Dalvik的指令计数，提高了翻译速度。
　　当Android启动时，Dalvik VM 监视所有的程序（APK），并且创建依存关系树，为每个程序优化代码并存储在Dalvik缓存中。Dalvik第一次加载后会生成Cache文件，以提供下次快速加载，所以第一次会很慢。
　　Dalvik解释器采用预先算好的Goto地址，每个指令对内存的访问都在64字节边界上对其。这样可以节省一个指令后进行查表的时间。为了强化功能, Dalvik还提供了快速翻译器（Fast Interpreter）。

性能

基于堆栈的机器与基于寄存器的机器谁更有优势一直是个争论不休的话题。

一般来说,基于堆栈的机器必须使用指令才能从堆栈上的加载和操作数据,因此,相对基于寄存器的机器，它们需要更多的指令才能实现相同的性能。但是基于寄存器机器上的指令必须经过编码,因此,它们的指令往往更大。这种差异主要是VM机对的操作码调度造成的，它们往往比其他的因素昂贵，比如说及时汇编。

然而,2010年，在Oracle公司(Java技术的拥有者)嵌入式设备上的标准非图形化性能测试表明，Android 2.2(最初的版本包括一个即时编译器)比Java SE嵌入式设备(两者都基于 Java SE 6)慢2-3倍。

类库

Dalvik虚拟机既不支持Java SE 也不支持Java ME类库(如：Java类,AWT和Swing都不支持)。 相反,它使用自己建立的类库（Apache Harmony Java的一个子集）。