1、ART之所以会比Dalvik快，是由于ART运行的是本地机器指令，而Dalvik运行的是Dex字节码。通过通过解释器运行。
虽然Dalvik也会对频繁运行的代码进行JIT生成本地机器指令来运行，但毕竟在应用程序运行的过程中将Dex字节码翻译成本地机器机器指令也会影响到应用程序本身的运行。因此即使Dalvik使用了JIT，也在一定程度上也比不上直接就能够运行本地机器指令的运行时。
Zygote进程在启动的过程中，正是通过图1所看到的的接口创建Dalvik或者ART虚拟机的，这样看来，ART尽管执行的本地机器指令，可是它表面看来，又是一个不折不扣的虚拟机。
也正是由于这样。ART才干够在不又一次编译APK的基础上，直接能够载入和执行APK。
这也是ART执行时能够无缝替换Dalvik执行时的原理。
因此。我们就能够得出一个结论：ART是一个执行本地机器指令的虚拟机。这个结论似乎有点矛盾。既然是执行本地机器指令，为什么又称为虚拟机呢？从接下来的文章分析能够知道。ART除了实现Java虚拟机接口之外，其内部还有垃圾收集机制。同一时候还有Java核心类库调用。
上面提到，ART才干够在不又一次编译APK的基础上，直接对其进行载入和执行，这是因为APK在安装时被执行了AOT。
AOT（Ahead Of Time）是相对JIT（Just In Time）而言的。也就是在APK运行之前。就对其包括的Dex字节码进行翻译。得到相应的本地机器指令，于是就能够在运行时直接运行了。
这样的技术不但使得我们能够不正确原有的APK作不论什么改动，还能够使得这些APK仅仅须要在安装时翻译一次，就能够无数次以本地机器指令的形式运行。这样的技术与我们用C/C++语言编写一个程序。然后用GCC编译得到一个可运行程序，最后这个可运行程序就能够无数次地载入到系统运行，是几乎相同的。
在ART中，打包在APK里面的Dex字节码是通过LLVM翻译成本地机器指令的。LLVM是一个用来高速开发自己的编译器的框架系统，
假设我们没有忘记，在Dalvik执行时中。APK在安装的时候，安装服务PackageManagerService会通过守护进程installd调用一个工具dexopt对打包在APK里面包括有Dex字节码的classes.dex进行优化，优化得到的文件保存在/data/dalvik-cache文件夹中，而且以.odex为后缀名，表示这是一个优化过的Dex文件。在ART执行时中。APK在安装的时候，相同安装服务PackageManagerService会通过守护进程installd调用另外一个工具dex2oat对打包在APK里面包括有Dex字节码进翻译。这个翻译器实际上就是基于LLVM架构实现的一个编译器。它的前端是一个Dex语法分析器。翻译后得到的是一个ELF格式的oat文件。这个oat文件相同是以.odex后缀结束，而且也是保存在/data/dalvik-cache文件夹中。
ART的执行原理都简要地介绍了。总结例如以下：
1. 在Android系统启动过程中创建的Zygote进程利用ART执行时导出的Java虚拟机接口创建ART虚拟机。
2. APK在安装的时候，打包在里面的classes.dex文件会被工具dex2oat翻译成本地机器指令，终于得到一个ELF格式的oat文件。
3. APK执行时。上述生成的oat文件会被载入到内存中，而且ART虚拟机能够通过里面的oatdata和oatexec段找到随意一个类的方法相应的本地机器指令来执行。
摘至：http://blog.csdn.net/luoshengyang/article/details/39256813