Android开发环境为什么需要依赖jvm

     在Java中，你写好Java源文件，用Java编译器将其编译成Java字节代码，然后在Java虚拟机中运行这些字节码。在Android中，情况就有些不同。您编写Java源文件，仍就使用相同的Java编译器将其编译为Java字节代码。但在这之后，你还得再一次使用的Dalvik编译器重新编译成为Dalvik字节码。正是这些Dalvik字节代码，在Dalvik虚拟机上运行。下图展示了在标准Java中（左）与在Android中使用Dalvik（右）编译过程的区别。

     看起来你在Android编程工作中会比在Java中做更多的工作。然而，这些编译工作都会由工具软件自动完成，比如说Eclipse和Ant，你永远不会注意到这些额外的步骤。

     你可能会奇怪，为什么不直接从Java源文件编译成Dalvik字节码？

     有一堆原因造成这一额外的步骤。早在2005年，当Dalvik创建之初，Java语言正在经历频繁的变化，但是Java字节码相对来说是“坚如磐石”。因此，Android团队选择相应的Java字节代码而不是Java源代码用于Dalvik。这样的好处是可以重用已有的jar包。由此产生的“副作用”是，在理论上你可以用任何其他能够编译成Java字节码的语言来编写Android应用。例如，你可以使用Python或Ruby。我说“在理论上“，因为在实践中需要作为SDK组成部分的相应库文件支持。但开源社区很有可能在将来想出了一个解决方案。

  

另外一个值得注意的事情是，Android中的Java类并非一个标准的Java类集合。Java通常按以下形式发布：

  

Java标准版本  

    用于普通桌面应用的开发

Java企业版本

    用于企业应用的开发

Java微版本

    用于移动应用开发

     

      Android的Java库更接近于Java标准版本。最主要的区别是Java用户界面类库（AWT和Swing）被摒弃了，取而代之的是Android特定的用户界面类库。Android还在标准Java类库上增添了不少新属性，能够支持绝大多数的Java标准属性。于是，你就可以任意使用绝大多数的Java类库，同时还会有一些新的可用。

      从Android4.4开始随着Android runtime的出现，编译运行过程有了新的变化。

ART 的机制与 Dalvik 不同。在Dalvik下，应用每次运行的时候，字节码都需要通过即时编译器转换为机器码，这会拖慢应用的运行效率，而在ART 环境中，应用在第一次安装的时候，字节码就会预先编译成机器码，使其成为真正的本地应用。这个过程叫做预编译（AOT,Ahead-Of-Time）。这样的话，应用的启动(首次)和执行都会变得更加快速。