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