ART的发布之所以引起大家的关注，是因为Andoid与iOS相比，一直被人诟病它的流畅性。Android的流畅性问题，有一部分原因就归结于它的应用程序和部分系统服务是运行虚拟机之上的，也就是运行在Dalvik虚拟机之上，而iOS的应用程序和系统服务都是直接执行本地机器指令的。除了使用ART替换Dalvik之外，我们也应当看到，Android从3.0开始，就不遗余力地改进系统的流畅性。例如，3.0增加了对应用程序2D UI的硬件加速渲染，也就是GPU渲染。在此之前，应用程序的2D UI一直都是使用软件渲染，也就是CPU渲染。又如4.1通过Project Butter，在UI架构中引入了VSYNC、Triple Buffer和HWComposer等技术，极大地提高UI的流畅性。

ART之所以会比Dalvik快，是因为ART执行的是本地机器指令，而Dalvik执行的是Dex字节码，通过通过解释器执行。尽管Dalvik也会对频繁执行的代码进行JIT生成本地机器指令来执行，但毕竟在应用程序运行的过程中将Dex字节码翻译成本地机器机器指令也会影响到应用程序本身的执行，因此即使Dalvik使用了JIT，也在一定程度上也比不上直接就可以执行本地机器指令的运行时。

在前面Android ART运行时无缝替换Dalvik虚拟机的过程分析一文中，我们提到，ART像Dalvik一样，都实现Java虚拟机接口，如图1所示：

图1 Dalvik、ART和Java VM的关系

Zygote进程在启动的过程中，正是通过图1所示的接口创建Dalvik或者ART虚拟机的，这样看来，ART虽然执行的本地机器指令，但是它表面看来，又是一个不折不扣的虚拟机。也正是因为这样，ART才可以在不重新编译APK的基础上，直接可以加载和运行APK。这也是ART运行时可以无缝替换Dalvik运行时的原理。因此，我们就可以得出一个结论：ART是一个执行本地机器指令的虚拟机。这个结论似乎有点矛盾，既然是执行本地机器指令，为什么又称为虚拟机呢？从接下来的文章分析可以知道，ART除了实现Java虚拟机接口之外，其内部还有垃圾收集机制，同时还有Java核心类库调用，因此，随着对ART的深入分析，我们就认为这个结论是不矛盾的了。

上面提到，ART才可以在不重新编译APK的基础上，直接对其进行加载和运行，这是由于APK在安装时被执行了AOT。AOT（Ahead Of Time）是相对JIT（Just In Time）而言的。也就是在APK运行之前，就对其包含的Dex字节码进行翻译，得到对应的本地机器指令，于是就可以在运行时直接执行了。这种技术不但使得我们可以不对原有的APK作任何修改，还可以使得这些APK只需要在安装时翻译一次，就可以无数次以本地机器指令的形式运行。这种技术与我们用C/C++语言编写一个程序，然后用GCC编译得到一个可执行程序，最后这个可执行程序就可以无数次地加载到系统执行，是差不多的。

在ART中，打包在APK里面的Dex字节码是通过LLVM翻译成本地机器指令的。LLVM是一个用来快速开发自己的编译器的框架系统，关于它的介绍，可以参考它的作者之一Chris Lattner写的这篇文章：http://www.aosabook.org/en/llvm.html。说起Chris Lattner，他就是Apple今年发布的Swift语言的首席架构师啊，所以我们就可以感受到LLVM有多强大了。总体来说，基于LLVM架构开发的编译器的执行过程如图2所示：

图2 基于LLVM架构开发的编译器执行过程

其中，前端（Frontend）对输入的源代码（Source Code）进行语法分析后，生成一棵抽象语法树（Abstract Syntax Tree，AST），并且可以进一步将得到的抽象语法树转化一种称为LLVM IR的中间语言。LLVM IR是一种与编程语言无关的中间语言，也就是说，不管是C语言，还是Fortran、Ada语言编写的源文件，经过语法分析后，最终都可以得到一个对应的LLVM IR文件。这个LLVM IR文件可以作为后面的优化器（Optimizer）和后端（Backend）的输入文件。优化器对LLVM IR文件进行优化，例如消除代码里面的冗余计算，以提到最终生成的代码的执行效率。后端负责生成最终的机器指令。

LLVM的上述架构大大简化开发编译器的流程，因为开发者需要关注的仅仅是前端，然后就可以利用现成的优化器来进行代码优化，并且利用现成的后端生成各种体系结构相关的机器指令，如图3所示：

图3 利用现成的与语言无关的优化器和后端为语言相关的前端生成各种体系结构相关的机器指令

在图3中，我们分别为C、Fortran和Ada三种语言开发三个不同的前端，然后利用现成的优化器对它们生成的LLVM IR语言进行优化，并且通过现成的后端生成X86、PowerPC和ARM三种不同体系结构的机器指令。

如果我们没有忘记，在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目录中。

ELF是Linux系统使用的一种文件格式，我们平时接触的静态库、动态库和可执行文件都是以这种格式保存的，但是由dex2oat工具生成的oat文件与上述三种文件都不一样，它有两个特殊的段oatdata和oatexec，分别用来储存原来打包在APK里面的dex文件和翻译这个dex文件里面的类方法得到本地机器指令，如图4所示：

图4 ART翻译classes.dex后得到的ELF格式的oat文件

在oat文件的动态段（dymanic section）中，还导出了三个符号oatdata、oatexec和oatlastword，分别用来描述oatdata和oatexec段加段到内存后的起止地址。在oatdata段中，包含了两个重要的信息，一个信息是原来的classes.dex文件的完整内容，另一个信息引导ART找到classes.dex文件里面的类方法所对应的本地机器指令，这些本地机器指令就保存在oatexec段中。

举个例子说，我们在classes.dex文件中有一个类A，那么当我们知道类A的名字后，就可以通过保存在oatdata段的dex文件得到类A的所有信息，比如它的父类、成员变量和成员函数等。另一方面，类A在oatdata段中有一个对应的OatClass结构体。这个OatClass结构体描述了类A的每一个方法所对应的本地机器指令在oatexec段的位置。也就是说，当我们知道一个类及其某一个方法的名字（签名）之后，就可以通过oatdata段的dex文件内容和OatClass结构体找到其在oatexec段的本地机器指令，这样就可以执行这个类方法了。

通过上面的分析，我们就将ART的运行原理都简要地介绍了，总结如下：

1. 在Android系统启动过程中创建的Zygote进程利用ART运行时导出的Java虚拟机接口创建ART虚拟机。

2. APK在安装的时候，打包在里面的classes.dex文件会被工具dex2oat翻译成本地机器指令，最终得到一个ELF格式的oat文件。

3. APK运行时，上述生成的oat文件会被加载到内存中，并且ART虚拟机可以通过里面的oatdata和oatexec段找到任意一个类的方法对应的本地机器指令来执行。

对于第1点，ART虚拟机的创建过程中，可以参考前面Android ART运行时无缝替换Dalvik虚拟机的过程分析一文。

对于第2点，APK里面的Dex字节码被dex2oat工具翻译生本地机器指令的过程，掌握它需要有扎实的编译知识。由于知识、能力、时间有限，因此这一部分的内容我们就略过不分析了，但是这将不会影响我们对ART运行时的理解。

对于第3点，是我们理解ART运行时的关键所在。以ART虚拟机的启动过程为例，从前面Android ART运行时无缝替换Dalvik虚拟机的过程分析一文可以知道，在AndroidRuntime类的成员函数start中，ART虚拟机创建和初始化完成后，Zygote进程就会通过它导出的JNI接口CallStaticVoidMethod使得它以指定的类方法为入口正式进入运行状态，如下所示：

这个函数定义在文件frameworks/base/core/jni/AndroidRuntime.cpp中。

在AndroidRuntime类的成员函数start中，参数className的值等于“com.android.internal.os.ZygoteInit”，本地变量env是从调用另外一个成员函数startVm创建的ART虚拟机获得的JNI接口。函数的目标就是要找到一个名称为com.android.internal.os.ZygoteInit的类，以及它的静态成员函数main，然后就以这个函数为入口，开始运行ART虚拟机。为此，函数执行了以下步骤：

1. 调用JNI接口FindClass加载com.android.internal.os.ZygoteInit类。

2. 调用JNI接口GetStaticMethodID找到com.android.internal.os.ZygoteInit类的静态成员函数main。

3. 调用JNI接口CallStaticVoidMethod开始执行com.android.internal.os.ZygoteInit类的静态成员函数main。

注意，在第3步中，要执行的是CallStaticVoidMethod开始执行com.android.internal.os.ZygoteInit类的静态成员函数main的本地机器指令，而不是Dex字节码。这样就引出以下三个关键问题：

1. ART如何找到com.android.internal.os.ZygoteInit类？

2. ART如何找到com.android.internal.os.ZygoteInit类的静态成员函数main？

3. ART如何找到com.android.internal.os.ZygoteInit类的静态成员函数main的本地机器指令？

解决上述三个问题所需要的信息都存在于dex2oat工具生成的oat文件中。因此，在接下来的文章中，我们将通过分析dex2oat工具生成的oat文件来回答上述三个问题，使得我们可以更加好地理解ART的工作原理。

如上所述，由于ART在查找类方法时，需要用到保存在oat文件的oatdata段的原dex文件内容，实质上就是要对dex文件进行解析，以获得相关的信息。这与Dalvik虚拟机在dex文件中查找类和方法信息的过程是一样的。这意味着要理解ART运行时，必须先要理解Dalvik虚拟机。Dalvik虚拟机的相关知识可以参考Dalvik虚拟机简要介绍和学习计划这个系列的文章。这告诉我们一个道理，旧的知识并没有过时，它对我们学习新的知识是有帮助的，有时候甚至是必须的。所以大家就不要觉得最前面写的那些基于Android 2.3版本的文章是没有用的了。我们在学习一样新东西的时候，无论是新的知识，还是旧的知识，对我们理解它的原理，都是很有帮助的！

我们除了要以dex2oat工具生成的oat文件作为切入点来分析ART运行时之外，还会结合ART运行时的垃圾收集机制来说明ART运行时与Dalvik虚拟机一样也是一个虚拟机，以此加深对ART运行时的理解。与Dalvik虚拟机的垃圾收集机制相比，ART运行时的垃圾收集机制更为复杂，由此带来的垃圾收集效率也更高。因此我们在分析ART运行时的垃圾收集机制之前，先会分析Dalvik虚拟机的垃圾收集机制。一方面是有利于我们循序渐进、由简而繁地讲解ART运行时的垃圾收集原理，另一方面也方便我们对比ART运行时和Dalvik虚拟机的垃圾收集机制有哪些不同，从而可以更好地理解为ART运行时的垃圾收集效率更高。

综上所述，接下来我们就按照以下几个情景来分析ART的工作原理：

1. ART加载oat文件的过程。

2. ART查找类和方法的过程。

3. ART查找类方法的本地机器指令的过程。

4. Dalvik虚拟机的垃圾收集过程。

5. ART的垃圾收集过程。

以上情景将基于Android 4.4源码进行分析，一方面是因为Android L版本的源码还没有放出来，另一方面是相信万变不离其宗，即使Androd L版本的ART实现有变化，但是基本的原理还是一样的。敬请关注！同时更多的信息可以关注老罗的新浪微博：http://weibo.com/shengyangluo。