Android知识巩固—Java虚拟机和Dalvik虚拟机的区别

最新推荐文章于 2024-08-01 14:43:06 发布

咻比嘟哗丶

最新推荐文章于 2024-08-01 14:43:06 发布

阅读量1.7k

点赞数 1

分类专栏： Android随笔文章标签：个人学习知识巩固

本文链接：https://blog.csdn.net/qq_34741451/article/details/87935516

版权

Android随笔专栏收录该内容

9 篇文章 0 订阅

订阅专栏

什么是JVM

JVM是Java Virtual Machine（Java虚拟机）的缩写，JVM是一种用于计算设备的规范，它是一个虚构出来的计算机，是通过在实际的计算机上仿真模拟各种计算机功能来实现的。
Java语言的一个非常重要的特点就是与平台的无关性。而使用Java虚拟机是实现这一特点的关键。一般的高级语言如果要在不同的平台上运行，至少需要编译成不同的目标代码。而引入Java语言虚拟机后，Java语言在不同平台上运行时不需要重新编译。Java语言使用Java虚拟机屏蔽了与具体平台相关的信息，使得Java语言编译程序只需生成在Java虚拟机上运行的目标代码（字节码），就可以在多种平台上不加修改地运行。Java虚拟机在执行字节码时，把字节码解释成具体平台上的机器指令执行。这就是Java的能够“一次编译，到处运行”的原因。
JVM是java的核心和基础，在java编译器和os平台之间的虚拟处理器。它是一种基于下层的操作系统和硬件平台并利用软件方法来实现的抽象的计算机，可以在上面执行java的字节码程序。同时JVM也是操作系统的一个进程,因此他也有他自己的运行的生命周期,也有自己的代码和数据空间。
Java编译器只需面向JVM，生成JVM能理解的代码或字节码文件。Java源文件经编译器，编译成字节码程序，通过JVM将每一条指令翻译成不同平台机器码，通过特定平台运行。

JVM执行程序的过程：

加载.class文件
管理并分配内存
执行垃圾收集

JVM的体系结构：
类装载器（ClassLoader）（用来装载.class文件）
执行引擎（执行字节码，或者执行本地方法）
运行时数据区（方法区、堆、java栈、PC寄存器、本地方法栈）

JVM运行时数据区

PC寄存器：PC寄存器是用于存储每个线程下一步将执行的JVM指令，如该方法为native的，则PC寄存器中不存储任何信息。
JVM栈：JVM栈是线程私有的，每个线程创建的同时都会创建JVM栈，JVM栈中存放的为当前线程中局部基本类型的变量（java中定义的八种基本类型：boolean、char、byte、short、int、long、float、double）、部分的返回结果以及Stack Frame，非基本类型的对象在JVM栈上仅存放一个指向堆上的地址。
堆（Heap）：它是JVM用来存储对象实例以及数组值的区域，可以认为Java中所有通过new创建的对象的内存都在此分配，Heap中的对象的内存需要等待GC进行回收。堆是JVM中所有线程共享的，因此在其上进行对象内存的分配均需要进行加锁，这也导致了new对象的开销是比较大的。Sun Hotspot JVM为了提升对象内存分配的效率，对于所创建的线程都会分配一块独立的空间TLAB（Thread Local Allocation Buffer），其大小由JVM根据运行的情况计算而得，在TLAB上分配对象时不需要加锁，因此JVM在给线程的对象分配内存时会尽量的在TLAB上分配，在这种情况下JVM中分配对象内存的性能和C基本是一样高效的，但如果对象过大的话则仍然是直接使用堆空间分配。TLAB仅作用于新生代的Eden Space，因此在编写Java程序时，通常多个小的对象比大的对象分配起来更加高效。所有新创建的Object 都将会存储在新生代Yong Generation中。如果Young Generation的数据在一次或多次GC后存活下来，那么将被转移到OldGeneration。新的Object总是创建在Eden Space。
方法区域：在Sun JDK中这块区域对应的为PermanetGeneration，又称为持久代。方法区域存放了所加载的类的信息（名称、修饰符等）、类中的静态变量、类中定义为final类型的常量、类中的Field信息、类中的方法信息，当开发人员在程序中通过Class对象中的getName、isInterface等方法来获取信息时，这些数据都来源于方法区域，同时方法区域也是全局共享的，在一定的条件下它也会被GC，当方法区域需要使用的内存超过其允许的大小时，会抛出OutOfMemory的错误信息。
运行时常量池：存放的为类中的固定的常量信息、方法和Field的引用信息等，其空间从方法区域中分配。
本地方法堆栈：JVM采用本地方法堆栈来支持native方法的执行，此区域用于存储每个native方法调用的状态。

JVM垃圾回收

由于程序计数器、Java虚拟机栈、本地方法栈都是线程独享，其占用的内存也是随线程生而生、随线程结束而回收。而Java堆和方法区则不同，线程共享，是GC的所关注的部分。在堆中几乎存在着所有对象，GC之前需要考虑哪些对象还活着不能回收，哪些对象已经死去可以回收。

判断对象是否存活：

引用计数算法：给对象中添加一个引用计数器，每当一个地方应用了对象，计数器加1；当引用失效，计数器减1；当计数器为0表示该对象已死、可回收。但是它很难解决两个对象之间相互循环引用的情况。
可达性分析算法：通过一系列称为“GC Roots”的对象作为起点，从这些节点开始向下搜索，搜索所走过的路径称为引用链，当一个对象到GC Roots没有任何引用链相连（即对象到GC Roots不可达），则证明此对象已死、可回收。Java中可以作为GC Roots的对象包括：虚拟机栈中引用的对象、本地方法栈中Native方法引用的对象、方法区静态属性引用的对象、方法区常量引用的对象。

在主流的商用程序语言（如我们的Java）的主流实现中，都是通过可达性分析算法来判定对象是否存活的。

GC (Garbage Collection)的基本原理：将内存中不再被使用的对象进行回收，GC中用于回收的方法称为收集器，由于GC需要消耗一些资源和时间，Java在对对象的生命周期特征进行分析后，按照新生代、旧生代的方式来对对象进行收集，以尽可能的缩短GC对应用造成的暂停

对新生代的对象的收集称为minor GC。
对旧生代的对象的收集称为Full GC。
程序中主动调用System.gc()强制执行的GC为Full GC。

不同的对象引用类型， GC会采用不同的方法进行回收，JVM对象的引用分为了四种类型：

强引用：默认情况下，对象采用的均为强引用（这个对象的实例没有其他对象引用，GC时才会被回收）
软引用：软引用是Java中提供的一种比较适合于缓存场景的应用（只有在内存不够用的情况下才会被GC）
弱引用：在GC时一定会被GC回收
虚引用：由于虚引用只是用来得知对象是否被GC

回收算法主要有：

标记-清除算法
复制算法
标记-整理算法
分代收集算法

什么是Dalvik

Dalvik是Google公司自己设计用于Android平台的虚拟机。Dalvik虚拟机是Google等厂商合作开发的Android移动设备平台的核心组成部分之一。它可以支持已转换为 .dex（即Dalvik Executable）格式的Java应用程序的运行，.dex格式是专为Dalvik设计的一种压缩格式，适合内存和处理器速度有限的系统。Dalvik 经过优化，允许在有限的内存中同时运行多个虚拟机的实例，并且每一个Dalvik 应用作为一个独立的Linux 进程执行。独立的进程可以防止在虚拟机崩溃的时候所有程序都被关闭。

Dalvik作为面向Linux、为嵌入式操作系统设计的虚拟机，主要负责完成对象生命周期管理、堆栈管理、线程管理、安全和异常管理，以及垃圾回收等。Dalvik充分利用Linux进程管理的特定，对其进行了面向对象的设计，使得可以同时运行多个进程，而传统的Java程序通常只能运行一个进程，这也是为什么Android不采用JVM的原因。Dalvik为了达到优化的目的，底层的操作大多和系统内核相关，或者直接调用内核接口。另外，Dalvik早期并没有JIT编译器，直到Android2.2才加入了对JIT的技术支持。

Dalvik虚拟机和Java虚拟机的区别

Java虚拟机运行的是Java字节码，Dalvik虚拟机运行的是Dalvik字节码。一个dex文件可以包含若干个类，而一个class文件只包括一个类。由于一个dex文件可以包含若干个类，因此它就可以将各个类中重复的字符串和其它常数只保存一次，从而节省了空间，这样就适合在内存和处理器速度有限的手机系统中使用。一般来说，包含有相同类的未压缩dex文件稍小于一个已经压缩的jar文件。
Dalvik虚拟机使用的指令是基于寄存器的，而Java虚拟机使用的指令集是基于堆栈的。数据的访问通过寄存器间直接传递，这样的访问方式比基于栈方式要快很多。

Dalvik虚拟机的优势

在编译时提前优化代码而不是等到运行时。
虚拟机很小，使用的空间也小；被设计来满足可高效运行多种虚拟机实例。
常量池已被修改为只使用32位的索引，以简化解释器。

基于栈与基于寄存器的架构，谁更快？现在实际的处理器，大多都是基于寄存器的架构，从侧面反映出基于寄存器比基于栈的架构更与实际的处理器接近。但对于VM来说，源架构的求值栈或者寄存器都可能是用实际机器的内存来模拟的，所以性能特性与实际硬件又有不同。一般认为基于寄存器架构的Dalvik VM比基于栈架构JVM执行效率更高，原因是：虽然零地址指令更紧凑，但完成操作需要更多的load/store指令，也意味着更多的指令分派（instruction dispatch）次数与内存访问次数；访问内存是执行速度的一个重要瓶颈，二地址或三地址指令虽然每条指令占的空间较多，但总体来说可以用更少的指令完成操作，指令分派与内存访问次数都较少。

每一个Android应用都运行在一个Dalvik虚拟机实例里，而每一个虚拟机实例都是一个独立的进程空间。每个进程之间可以通信（IPC，Binder机制实现）。虚拟机的线程机制，内存分配和管理，Mutex等等都是依赖底层操作系统而实现的。不同的应用在不同的进程空间里运行，当一个虚拟机关闭或意外中止时不会对其它虚拟机造成影响，可以最大程度的保护应用的安全和独立运行。 Zygote是虚拟机实例的孵化器。AndroidRuntime.cpp中ZygoteInit.main()的执行会完成一个分裂，分裂出来的子进程继续初始化Java层的架构，这个分裂出来的进程就是system_server。每当系统要求执行一个Android应用程序，Zygote就会FORK出一个子进程来执行该应用程序。这样做的好处显而易见：Zygote进程是在系统启动时产生的，它会完成虚拟机的初始化，库的加载，预置类库的加载和初始化等等操作，而在系统需要一个新的虚拟机实例时，Zygote通过复制自身，最快速的提供个系统。另外，对于一些只读的系统库，所有虚拟机实例都和Zygote共享一块内存区域，大大节省了内存开销。

Dalvik虚拟机的其它特性，包括内存管理、垃圾收集、JIT、JNI以及进程和线程管理。

一. 内存管理
Dalvik虚拟机的内存大体上可以分为Java Object Heap、Bitmap Memory和Native Heap三种。

Java Object Heap是用来分配Java对象的，也就是我们在代码new出来的对象都是位于Java Object Heap上的。Dalvik虚拟机在启动的时候，可以通过-Xms和-Xmx选项来指定Java Object Heap的最小值和最大值。为了避免Dalvik虚拟机在运行的过程中对Java Object Heap的大小进行调整而影响性能，我们可以通过-Xms和-Xmx选项来将它的最小值和最大值设置为相等。

Bitmap Memory也称为External Memory，它是用来处理图像的。在HoneyComb之前，Bitmap Memory是在Native Heap中分配的，但是这部分内存同样计入Java Object Heap中，也就是说，Bitmap占用的内存和Java Object占用的内存加起来不能超过Java Object Heap的最大值。这就是为什么我们在调用BitmapFactory相关的接口来处理大图像时，会抛出一个OutOfMemoryError异常的原因，在HoneyComb以及更高的版本中，Bitmap Memory就直接是在Java Object Heap中分配了，这样就可以直接接受GC的管理。

Native Heap就是在Native Code中使用malloc等分配出来的内存，这部分内存是不受Java Object Heap的大小限制的，也就是它可以自由使用，当然它是会受到系统的限制。但是有一点需要注意的是，不要因为Native Heap可以自由使用就滥用，因为滥用Native Heap会导致系统可用内存急剧减少，从而引发系统采取激进的措施来Kill掉某些进程，用来补充可用内存，这样会影响系统体验。此外，在HoneyComb以及更高的版本中，我们可以在AndroidManifest.xml的application标签中增加一个值等于“true”的android:largeHeap属性来通知Dalvik虚拟机应用程序需要使用较大的Java Object Heap。事实上，在内存受限的手机上，即使我们将一个应用程序的android:largeHeap属性设置为“true”，也是不能增加它可用的Java Object Heap的大小的，而即便是可以通过这个属性来增大Java Object Heap的大小，一般情况也不应该使用该属性。为了提高系统的整体体验，我们需要做的是致力于降低应用程序的内存需求，而不是增加增加应用程序的Java Object Heap的大小，毕竟系统总共可用的内存是固定的，一个应用程序用得多了，就意味意其它应用程序用得少了。

二. 垃圾收集(GC)
Dalvik虚拟机可以自动回收那些不再使用了的Java Object，也就是那些不再被引用了的Java Object。垃圾自动收集机制将开发者从内存问题中解放出来，极大地提高了开发效率，以及提高了程序的可维护性。

我们知道，在C或者C++中，开发者需要手动地管理在堆中分配的内存，但是这往往导致很多问题。例如，内存分配之后忘记释放，造成内存泄漏。又如，非法访问那些已经释放了的内存，引发程序崩溃。如果没有一个好的C或者C++应用程序开发框架，一般的开发者根本无法驾驭内存问题，因为程序大了之后，很容易造成失控。最要命的是，内存被破坏的时候，并不一定就是程序崩溃的时候，它就是一颗不定时炸弹，说不准什么时候会被引爆，因此，查找原因是非常困难的。

从这里我们也可以推断出，Android为什么会选择Java而不是C/C++来作为应用程序开发语言，就是为了能够让开发远离内存问题，而将精力集中在业务上，开发出更多更好的APP来，从而迎头赶超iOS。当然，Android系统内存也存在大量的C/C++代码，这只要考虑性能问题，毕竟C/C++程序的运行性能整体上还是优于运行在虚拟机之上的Java程序的。不过，为了避免出现内存问题，在Android系统内部的C++代码，大量地使用了智能指针来自动管理对象的生命周期。选择Java来作为Android应用程序的开发语言，可以说是技术与商业之间一个折衷，事实证明，这种折衷是成功的。

在GingerBread以及更高的版本中，Dalvik虚拟使用的垃圾收集机制得到了改进

Cocurrent，也就是大多数情况下，垃圾收集线程与其它线程是并发执行的；
Partial collection，也就是一次可能只收集一部分垃圾；
一次垃圾收集造成的程序中止时间通常都小于5ms。

三. 即时编译(JIT)
前面提到，JIT是相对AOT而言的，即JIT是在程序运行的过程中进行编译的，而AOT是在程序运行前进行编译的。在程序运行的过程中进行编译既有好处，也有坏处。好处在于可以利用程序的运行时信息来对编译出来的代码进行优化，而坏处在于占用程序的运行时间，也就是说不能花太多时间在代码编译和优化之上。

为了解决时间问题，JIT可能只会选择那些热点代码进行编译或者优化。根据2-8原则，一个程序80%的时间可能都是在重复执行20%的代码。因此，JIT就可以选择这20%经常执行的代码来进行编译和优化。

为了充分地利用好运行时信息来优化代码，JIT采用一种激进的方法。JIT在编译代码的时候，会对程序的运行情况进行假设，并且按照这种假设来对代码进行优化。随着程序的代码，如果前面的假设一直保持成立，那么JIT就什么也不用做，因此就可以提高程序的运行性能。一旦前面的假设不再成立了，那么JIT就需要对前面编译优化的代码进行调整，以便适应新的情况。这种调整成本可能是很昂贵的，但是只要假设不成立的情况很少或者几乎不会发生，那么获得的好处还是大于坏处的。由于JIT在编译和优化代码的时候，对程序的运行情况进行了假设，因此，它所采取的激进优化措施又称为赌博，即Gambling。

我们以一个例子来说明这种Gambling。我们知道，Java的同步原语涉及到Lock和Unlock操作。Lock和Unlock操作是非常耗时的，而且它们只有在多线程环境中才真的需要。但是一些同步函数或者同步代码，有程序运行的时候，有可能始终都是被单线程执行，也就是说，这些同步函数或者同步代码不会被多线程同时执行。这时候JIT就可以采取一种Lazy Unlocking机制。

当一个线程T1进入到一个同步代码C时，它还是按照正常的流程来获取一个轻量级锁L1，并且线程T1的ID会记录在轻量锁L1上。当经程T1离开同步函数或者同步代码时，它并不会释放前面获得的轻量级锁L1。当线程T1再次进入同步代码C时，它就会发现轻量级锁L的所有者正是自己，因此，它就可以直接执行同步代码C。这时候如果另外一个线程T2也要进入同步代码C，它就会发现轻量级锁L已经被线程T1获取。在这种情况下，JIT就需要检查线程T1的调用堆栈，看看它是否还在执行同步代码C。如果是的话，那么就需要将轻量级锁L1转换成一个重量级锁L2，并且将重量级锁L2的状态设置为锁定，然后再让线程T2在重量级锁L2上睡眠。等线程T1执行完成同步代码C之后，它就会按照正常的流程来释放重量级锁L2，从而唤醒线程T2来执行同步代码C。另一方面，如果线程T2在进入同步代码C的时候，JIT通过检查线程T1的调用堆栈，发现它已经离开同步代码C了，那么它就直接将轻量级锁L1的所有者记录为线程T2，并且让线程T2执行同步代码C。

通过上述的Lazy Unlocking机制，我们就可以充分地利用程序的运行时信息来提高程序的执行性能，这种优化对于静态编译的语言来说，是无法做到的。从这个角度来看，我们就可以说，静态编译语言（如C++）并不一定比在虚拟机上执行的语言（如Java）快，这是因为后者可以有一种强大的武器叫做JIT。

Dalvik虚拟机从Android 2.2版本开始，才支持JIT，而且是可选的。在编译Dalvik虚拟机的时候，可以通过WITH_JIT宏来将JIT也编译进去，而在启动Dalvik虚拟机的时候，可以通过-Xint:jit选项来开启JIT功能。

四. Java本地调用(JNI)
无论如何，虚拟机最终都是运行在目标机器之上的，也就是说，它需要将自己的指令翻译成目标机器指令来执行，并且有些功能，需要通过调用目标机器运行的操作系统接口来完成。这样就需要有一个机制，使得函数调用可以从Java层穿越到Native层，也就是C/C++层。这种机制就称为Java本地调用，即JNI。当然，我们在执行Native代码的时候，有时候也是需要调用到Java函数的，这同样是可以通过JNI机制来实现。也就是说，JNI机制既支持在Java函数中调用C/C++函数，也支持在C/C++函数中调用Java函数。

事实上，Dalvik虚拟机提供的Java运行时库，大部分都是通过调用目标机器操作系统接口来实现的，也就是通过调用Linux系统接口来实现的。例如，当我们调用android.os.Process类的成员函数start来创建一个进程的时候，最终会调用到Linux系统提供的fork系统调用来创建一个进程。

同时，为了方便开发者使用C/C++语言来开发应用程序，Android官方提供了NDK。通过NDK，我们就可以使用JNI机制来在Java函数中调用到C/C++函数。不过Android官方是不提倡使用NDK来开发应用程序的，这从它对NDK的支持远远不如SDK的支持就可以看得出来。

五. 进程和线程管理
一般来说，虚拟机的进程和线程都是与目标机器本地操作系统的进程和线程一一对应的，这样做的好处是可以使本地操作系统来调度进程和线程。进程和线程调度是操作系统的核心模块，它的实现是非常复杂的，特别是考虑到多核的情况，因此，就完全没有必要在虚拟机中提供一个进程和线程库。

Dalvik虚拟机运行在Linux操作系统之上。我们知道，Linux操作系统并没有纯粹的线程概念，只要两个进程共享同一个地址空间，那么就可以认为它们同一个进程的两个线程。Linux操作系统提供了两个fork和clone两个调用，其中，前者就是用来创建进程的，而后者就是用来创建线程的。关于Linux操作系统的进程和线程的实现，可以参考在前面Android学习启动篇一文中提到的经典Linux内核书籍。

关于Android应用程序进程，它有两个很大的特点，下面我们就简要介绍一下。

第一个特点是每一个Android应用程序进程都有一个Dalvik虚拟机实例。这样做的好处是Android应用程序进程之间不会相互影响，也就是说，一个Android应用程序进程的意外中止，不会影响到其它的Android应用程序进程的正常运行。

第二个特点是每一个Android应用程序进程都是由一种称为Zygote的进程fork出来的。Zygote进程是由init进程启动起来的，也就是在系统启动的时候启动的。Zygote进程在启动的时候，会创建一个虚拟机实例，并且在这个虚拟机实例将所有的Java核心库都加载起来。每当Zygote进程需要创建一个Android应用程序进程的时候，它就通过复制自身来实现，也就是通过fork系统调用来实现。这些被fork出来的Android应用程序进程，一方面是复制了Zygote进程中的虚拟机实例，另一方面是与Zygote进程共享了同一套Java核心库。这样不仅Android应用程序进程的创建过程很快，而且由于所有的Android应用程序进程都共享同一套Java核心库而节省了内存空间。

Dalvik虚拟机和ART虚拟机

什么是ART虚拟机

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

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翻译成本地机器指令的。

如果我们没有忘记，在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文件里面的类方法得到本地机器指令。

在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的运行原理都简要地介绍了，总结如下：

在Android系统启动过程中创建的Zygote进程利用ART运行时导出的Java虚拟机接口创建ART虚拟机。
APK在安装的时候，打包在里面的classes.dex文件会被工具dex2oat翻译成本地机器指令，最终得到一个ELF格式的oat文件。
APK运行时，上述生成的oat文件会被加载到内存中，并且ART虚拟机可以通过里面的oatdata和oatexec段找到任意一个类的方法对应的本地机器指令来执行。

参考资料：
Dalvik虚拟机简要介绍和学习计划