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运行环境的区别
2：Dalvik负责进程隔离和线程管理，每一个Android应用在底层都会对应一个独立的Dalvik虚拟机实例，其代码在虚拟机的解释下得以执行。
4:dex文件格式可以减少整体文件尺寸，提高I/o操作的类查找速度。
5:odex是为了在运行过程中进一步提高性能，对dex文件的进一步优化。
7：有一个特殊的虚拟机进程Zygote，他是虚拟机实例的孵化器。它在系统启动的时候就会产生，它会完成虚拟机的初始化，库的加载，预制类库和初始化的操作。如果系统需要一个新的虚拟机实例，它会迅速复制自身，以最快的数据提供给系统。对于一些只读的系统库，所有虚拟机实例都和Zygote共享一块内存区域。
8：Dalvik是由Dan Bornstein编写的，名字来源于他的祖先曾经居住过名叫Dalvík的小渔村，村子位于冰岛Eyjafjörður
前景
很长时间以来，Dalvik虚拟机一直被用户指责为拖慢安卓系统运行速度不如IOS的根源。
2014年6月25日，Android L 将正式亮相于召开的谷歌I/O大会，Android L 改动幅度较大，谷歌将直接删除Dalvik，代替它的是传闻已久的ART。
由于ART的出现，使Dalvik在安卓系统应用方面注定成为历史。
不同于其他堆栈结构的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）。
自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的一个子集）。
5其他
许可与专利
Dalvik是基于Apache License 2.0发布的。Google说Dalvik是一个清洁室（clean room）的实现，而不是一个在标准Java运行环境的改进，这意味着它不继承标准版本的或开源的Java运行环境的版权许可限制。关于这一点，Oracle和一些专家还在讨论中。
已于2009年4月收购Sun（Sun Microsystems）的Oracle获得了Java的专利，在2010年8月12日起诉Google侵犯其版权和专利。Oracle声明，Google在开发Android当中直接并且多次侵犯关于Java的知识产权。在2012五月，陪审团认为Google没有侵犯Oracle的专利，法官认定Google所使用的Java APIs没有版权。双方同意零美元法定赔偿的9行复制代码（9 lines of copied code）。
非Android平台
2011年，Myriad Group软件公司公布了除了android以外一个新的Dalvik虚拟机平台端口“Alien Dalvik”。
Android runtime
ART 的机制与 Dalvik 不同。在Dalvik下，应用每次运行的时候，字节码都需要通过即时编译器转换为机器码，这会拖慢应用的运行效率，而在ART 环境中，应用在第一次安装的时候，字节码就会预先编译成机器码，使其成为真正的本地应用。这个过程叫做预编译（AOT,Ahead-Of-Time）。这 样的话，应用的启动和执行都会变得更加快速。
[1] 与 iOS 相比，Android 的用户体验有个相对糟糕的开始。在很长的时间里，界面一直丑小鸭，卡顿也是挥不去的痛。不过，在 Google 的全力推动，以及硬件厂商的响应下，Android 还是跨越各种阻碍，逐渐壮大起来了。
在此过程中，Google 也在经历着重大的变化。它逐渐从一个只重视数据的公司，转变为一个重视设计和用户体验的公司。从 Android 4.0 开始，Android 拥有了自己的设计语言和应用设计指导。与此同时，Google 也在着手解决卡顿问题。Android 4.1 的“黄油计划”使系统和应用运行都更加顺畅，而 Android 4.2 的“Project Svelte”提升了内存管理，使得系统能够顺利运行在硬件配置低端的设备上。
但是，所有这些都没有解决核心问题，那就是应用运行环境。Dalvik VM 效率并不是最高的。从 Android 4.4 开始，Google 开发者引进了新的 Android 运行环境 ART（意思就是 Android Runtime。Android 官方页面的介绍中，也将其称作新的虚拟机），以替代旧的 Dalvik VM。它现在是实验选项，系统默认的运行环境仍然是 Dalvik。ART 会为 Android 带来怎样的改变？AndroidPolice 网站对此进行了分析。
根据一些基准测试，新的运行环境能够使大多数应用的执行时间减半。这意味着，CPU 消耗大、运行时间长的应用能够更加快速地完成，而一般的应用也能更加流畅，比如动画效果更顺畅，触控反馈更加即时。在多核处理器的设备上，多数情况下只需 激活少量的核心，或者能够更好的利用 ARM 的 big.LITTLE 架构。另外，它将会显著提升电池的续航能力以及系统的性能。
预编译也会带来一些缺点。一方面，机器码占用的存储空间更大。字节码变为机器码之后，可能会增加 10%-20%，不过在应用包中，可执行的代码常常只是一部分。比如最新的 Google+ APK 是 28.3 MB，但是代码只有 6.9 MB。另一方面，应用的安装时间会变长。至于延长多少时间，取决于应用本身，一些复杂的应用如 Facebook 和 Google+ 会让你等待更长时间。
总的来说，ART 的优点还是远远超越其缺点的。毕竟，影响用户体验的要素中，电池续航和应用顺畅运行更为重要。我们仍然不知道 ART 何时能够替代 Dalvik，不过 AndroidPolice 网站说，Google 已经秘密开发了两年之久。Android 摆脱卡顿的希望，看来就是它了。
2最新消息
11月8日消息，谷歌日前发布了Android 4.4系统，在这一版本中，最大的一个变革就是改变了应用程序的运行模式，即抛弃了原来的Dalvik 运行时，改为采用ART运行时。
ART(Android Runtime)是一种开发更快执行效率更高且更省电的运行时，它是安卓系统赖以生存的底层运行环境。
过去安卓的底层代码由Dalvik Java虚拟机运行，这一机制效率不高，被称作是安卓运行效率低下的“毒瘤”，不过也正是因为有它，才让应用程序能在不同硬件和架构上运行。
ART处理应用程序执行的方式完全不同于Dalvik，运行起来更有效率、耗电更少、占的内存也更低。
