ART登场，Android要和核心虚拟机Dalvik说再见了
Dalvik是Android的核心组成部分之一，Android上的应用程序需要依靠它才可以正常运行。现在Google准备用新的运行环境ART来替代它。在最新的Android4.4上，有两个运行环境供开发者选择——默认的Dalvik和测试中的ART。
在以前的Android系统上，所有的应用程序都是运行在Dalvik中。应用程序每次运行时其中一部分代码都要需要机器重新编译。这个过程即消耗时间又要消耗系统资源，所以执行效率难免会降低。但其优点在于这种机制可以让各种各样的应用程序运行在多种硬件架构上。相比Dalvik，ART的处理机制完全不同，它会在应用程序安装时就把程序代码转换成机器语言，让程序成为真正的本地应用。这样做的好处是程序的启动时间被极大的提高，运行速度也会更快。电量消耗的更少，系统行也跟着更加流畅。
对于想尝鲜的Nexus5用户可以到设置的开发者选项里选择ART选项，确认之后机器会重启，根据手机内安装的应用程序数量不同，第一次开机消耗的时间也不相同。
由于ART还处于测试阶段，所以目前还很难精确地度量出其为Android设备提升的效率。但是一些基准测试表明它将大多数应用程序的执行时间削减了一半左右。这就意味着那些需要大量处理器性能和长时间运行的任务会被更快地执行完毕，系统也会更多地停留在闲置状态。电量损耗会减少，流畅度也自然会提升。
当然ART带来一些优点的同时，也会带来一些缺点。
其一，由于ART需要应用程序在安装时就把程序代码转换成机器语言，所以这会消耗掉更多的存储空间，但消耗掉空间的增幅通常不会超过应用代码包大小的20%。
其二，由于有了一个转码的过程，所以应用安装时间难免会延长。拿最新的Google+应用为例，其apk格式的安装包大小为28.3MB，但其代码仅为6.9MB，所以多消耗掉的存储空间并不惊人。至于第二个缺点那就只能等待了。
事实上，ART项目在Google内部已经进行了2年左右的时间。回溯一下，当时差不多就是Google和甲骨文因为Java专利官司闹得不可开交的那段时期。虽然到今天我们很难判断发起ART项目的初衷是哪一个，但既然它能提升Android设备的性能，我们为什么不欢迎呢？
Dalvik是Google公司自己设计用于Android平台的Java虚拟机。Dalvik虚拟机是Google等厂商合作开发的Android移动设备平台的核心组成部分之一。它可以支持已转换为 .dex（即Dalvik Executable）格式的Java应用程序的运行，.dex格式是专为Dalvik设计的一种压缩格式，适合内存和处理器速度有限的系统。Dalvik 经过优化，允许在有限的内存中同时运行多个虚拟机的实例，并且每一个Dalvik 应用作为一个独立的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重编译器。
2Dalvik简介编辑
[1]（ 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] 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ður3架构编辑
不同于其他堆栈结构的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）。 [3]
4性能编辑
基于堆栈的机器与基于寄存器的机器谁更有优势一直是个争论不休的话题。 一般来说,基于堆栈的机器必须使用指令才能从堆栈上的加载和操作数据,因此,相对基于寄存器的机器，它们需要更多的指令才能实现相同的性能。但是基于寄存器机器上的指令必须经过编码,因此,它们的指令往往更大。这种差异主要是VM机对的操作码调度造成的，它们往往比其他的因素昂贵，比如说及时汇编。 然而,2010年，在Oracle公司(Java技术的拥有者)嵌入式设备上的标准非图形化性能测试表明，Android 2.2(最初的版本包括一个即时编译器)比Java SE嵌入式设备(两者都基于 Java SE 6)慢2-3倍。 [3]5类库编辑
Dalvik虚拟机既不支持Java SE 也不支持Java ME类库(如：Java类,AWT和Swing都不支持)。 相反,它使用自己建立的类库（Apache Harmony Java的一个子集）。 [3]6其他编辑
许可与专利 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）。 [3] 非Android平台 2011年，Myriad Group软件公司公布了除了android以外一个新的Dalvik虚拟机平台端口“Alien Dalvik”。更多相关文章
- Android连接蓝牙打印机实现PDF文档的打印
- 浅谈 Android(安卓)体系结构
- Android中的4.0新布局控件：Space和GridLayout
- 2016年Windows Phone将超越iPhone
- Android(安卓)面试笔试集锦 --- 基本知识点 整理版
- Android(安卓)applicationId与包名的区别
- Android推送通知的实现--PHP+ANDROID做消息推送：基于IBM的MQTT协
- Android虚拟机效率问题
- [置顶] Android开发学习之一——Android全景概述