Android在4.4就已推出新运行时ART，准备替代用了有些时日的Dalvik。不过当时尚属测试版，主角仍是Dalvik。 直到今年的Google I/O大会，ART才正式取代Dalvik。这个消息在科技界引起不小轰动，也吸引不少技术人员对它的“技术分析”。可惜这些“技术分析”不过是引用了官方的数据和图表而已。这一系列文章将对ART进行真正的技术分析。老规矩，分析前先进行简要介绍和制定学习计划。
老罗的新浪微博：，欢迎关注！
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写的这篇文章：。说起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目录中。
如果寒暄只是打个招呼就了事的话，那与猴子的呼叫声有什么不同呢?事实上，
