Dalvik 虚拟机(Dalvik Virtual Machine ),简称 Dalvik VM 或者 DVM。它是由 Dan Bomstein编写的，名字源于他的祖先居住过的名为Dalvik的小渔村。DVM是Google专门 为Android平台开发的虚拟机，它运行在Android运行时库中。需要注意的是DVM并不是 一个Java虚拟机(以下简称JVM),至于为什么，下文会给你答案。
DVM之所以不是一个JVM,主要原因是DVM并没有遵循JVM规范来实现，DVM 与JVM主要有以下区别。
1.基于的架构不同
JVM基于栈则意味着需要去栈中读写数据，所需的指令会更多，这样会导致速度变慢， 对于性能有限的移动设备，显然不是很适合的。DVM是基于寄存器的，它没有基于栈的虚 拟机在复制数据时而使用的大量的出入栈指令，同时指令更紧凑、更简洁。但是由于显式 指定了操作数，所以基于寄存器的指令会比基于栈的指令要大，但是由于指令数量的减少, 总的代码数不会增加多少。
2 .执行的字节码不同
在Java SE程序中，Java类被编译成一个或多个.class文件，并打包成jar文件，而后 JVM会通过相应的.class文件和jar文件获取相应的字节码。执行顺序为.java文件->.class 文件->.jar文件，而DVM会用dx工具将所有的.class文件转换为一个.dex文件，然后DVM 会从该.dex文件读取指令和数据。执行顺序为.java文件->.class文件->.dex文件。
如图11-1所示，.jar文件里面包含多个.class文件，每个.class文件里面包含了该类的 常量池、类信息、属性等。当JVM加载该.jar文件的时候，会加载里面的所有的.class文件, JVM的这种加载方式很慢，对于内存有限的移动设备并不合适。而在.apk文件中只包含了 一个.dex文件，这个.dex文件将所有的.class里面所包含的信息全部整合在一起了，这样再 加载就加快了速度。.class文件存在很多的冗余信息，dex工具会去除冗余信息，并把所有 的.class文件整合到.dex文件中，减少了 I/O操作，加快了类的査找速度。
3.DVM允许在有限的内存中同时运行多个进程
DVM经过优化，允许在有限的内存中同时运行多个进程。在Android中的每一个应用 都运行在一个DVM实例中，每一个DVM实例都运行在一个独立的进程空间中，独立的 进程可以防止在虚拟机崩溃的时候所有程序都被关闭。
4.DVM由Zygote创建和初始化
我们在第2章学习过Zygote,它是一个DVM进程，同时也用来创建和初始化DVM 实例。每当系统需要创建一个应用程序时，Zygote就会fock自身，快速地创建和初始化一 个DVM实例，用于应用程序的运行。对于一些只读的系统库，所有的DVM实例都会和 Zygote共享一块内存区域，节省了内存开销。
5.DVM有共享机制
DVM拥有预加载一共享的机制，不同应用之间在运行时可以共享相同的类，拥有更高 的效率。而JVM机制不存在这种共享机制，不同的程序，打包以后的程序都是彼此独立的， 即便它们在包里使用了同样的类，运行时也都是单独加载和运行的，无法进行共享。
6.DVM早期没有使用JIT编译器
JVM使用了 JIT编译器（Just In Time Compiler,即时编译器），而DVM早期没有使用 JIT编译器。早期的DVM每次执行代码，都需要通过解释器将dex代码编译成机器码，然 后交给系统处理，效率不是很高。为了解决这一问题，从Android 2.2版本开始DVM使用 了 J1T编译器，它会对多次运行的代码（热点代码）进行编译，生成相当精简的本地机器 码（Native Code）,这样在下次执行到相同逻辑的时候，直接使用编译之后的本地机器码， 而不是每次都需要编译。需要注意的是，应用程序每一次重新运行的时候，都要重做这个 编译工作，因此每次重新打开应用程序，都需要JIT编译。
DVM的源码位于dalvik/目录下,Android 8.0中的DVM源码的部分目录说明如表11-1 所示。
表11-1 DVM的源码目录
目录/文件
说 明
dexdump
生成dex文件的反编译査看工具，主要用来査看编译出来的代码的正确性和结构
dexgen
dex代码生成器项目
docs
DVM相关帮助文档
dx
Java字节码转换为DVM机器码的工具
libdex
生成主机和设备处理dex文件的库
tools
一些编译和运行相关的工具
Android.mk
虚拟机编译的makefile配置文件
MODULE LICENSE APACHE2
APACHE2版权声明文件
NOTICE
虚拟机源码版权注意事项文件
其中，dalvik/libdex会被编译成libdex.a静态库，作为dex工具使用；dalvik/dexdump 是.dex文件的反编译工具，DVM架构如图11-2所示。
图11-2 DVM架构
从图11-2可以看出，首先Java编译器编译的.class文件经过DX工具转换为.dex文 件，.dex文件由类加载器处理，接着解释器根据指令集对Dalvik字节码进行解释、执行， 最后交于Linux处理。
DVM的运行时堆使用标记一清除(Mark-Sweep)算法进行GC,它由两个Space以及 多个辅助数据结构组成，两个Space分别是Zygote Space (Zygote Heap)和Allocation Space (Active Heap)o Zygote Space用来管理Zygote进程在启动过程中预加载和创建的各种对象, Zygote Space中不会触发GC,在Zygote进程和应用程序进程之间会共享Zygote Spaceo在 Zygote进程fork第一个子进程之前，会把Zygote Space分为两个部分，原来的已经被使用 的那部分堆仍旧叫Zygote Space,而未使用的那部分堆就叫Allocation Space,以后的对象 都会在Allocation Space JL进行分配和释放。Allocation Space不是进程间共享的，在每个进 程中都独立拥有一份。除了这两个Space,还包含以下数据结构。
Card Table：用于DVM Concurrent GC,当第一次进行垃圾标记后，记录垃圾信息。Heap Bitmap：有两个Heap Bitmap, 一个用来记录上次GC存活的对象，另一个用 来记录这次GC存活的对象。Mark Stack： DVM的运行时堆使用标记一清除(Mark-Sweep)算法进行GC, Mark Stack就是在GC的标记阶段使用的，它用来遍历存活的对象。在10.6.2节中提到了 Java虚拟机的GC日志。DVM和ART的GC日志与Java虚拟机 的日志有较大的区别。在DVM中每次垃圾收集都会将GC日志打印到logcat中，具体的 格式为：
D/dalvikvm: <GC_Reason> <2kmount_freed>, <Heap_stats>, <External_memory_stats>, <Pause_time>
可以看到DVM的日志共有5个信息，其中GC Reason有很多种，这里将它单独拿出来进行介绍。
1.引起GC的原因
GC Reason就是引起GC的原因，有以下几种。
GC_CONCURRENT：当堆开始填充时，并发GC可以释放内存。GC_FOR_MALLOC：当堆内存已满时，App尝试分配内存而引起的GC,系统必须 停止App并回收内存。GC_HPROF_DUMP_HEAP:当你请求创建HPROF文件来分析堆内存时出现的GCOGC_EXPLICIT：显式的GC,例如调用System.gc（）（应该避免调用显式的GC,信 任GC会在需要时运行）。GC_EXTERNAL_ALLOC:仅适用于API级别小于等于10,且用于外部分配内存的 GCO2.其他的信息
除了引起GC的原因，其他的信息如下。
Amount freed：本次GC释放内存的大小。Heap stats：堆的空闲内存百分比（已用内存）/ （堆的总内存）。Extemal_memory_stats: API小于等于级别10的内存分配（已分配的内存）/ （引起 GC的阈值）。Pause time：暂停时间，更大的堆会有更长的暂停时间。并发暂停时间会显示两个暂 停时间，即一个出现在垃圾收集开始时，另一个出现在垃圾收集快要完成时。3.实例分析
为了让大家更好地理解DVM的GC 0志，举一个具体的GC日志实例，如下所示：
D/dalvikvm: GC_CONCURRENT freed 2012K, 63% free 3213K/9291K, external 4501K/5161K, paused 2ms+2ms
这个GC日志的含义为：引起GC的原因是GC_CONCURRENT；本次GC释放的内存 为2012KB；堆的空闲内存百分比为63%,已用内存为3213KB,堆的总内存为9291KB； 暂停的总时长为4ms。
ART （Android Runtime）虚拟机是 Android 4.4 发布的，用来替换 Dalvik 虚拟机,Android 4.4默认采用的还是DVM,系统会提供一个选项来开启ART。在Android 5.0版本中默认采 用了 ART, DVM从此退出历史舞台。
ART和DVM的区别主要有如下4点。
从11.1节我们知道，DVM中的应用每次运行时，字节码都需要通过JIT编译器编译为机器码，这会使得应用程序的运行效率降低。而在ART中，系统在安装应用程序时会 进行一次AOT (ahead of time compilation,预编译)，将字节码预先编译成机器码并存储在 本地，这样应用程序每次运行时就不需要执行编译了，运行效率会大大提升，设备的耗电 量也会降低。这就好比我们在线阅读漫画，DVM是我们阅读到哪就加载哪，ART则是直 接加载一章的漫画，虽然一开始加载速度有些慢，但是后续的阅读体验会很流畅。采用AOT 也会有缺点，主要有两个：第一个是AOT会使得应用程序的安装时间变长，尤其是一些复 杂的应用；第二个是字节码预先编译成机器码，机器码需要的存储空间会多一些。为了解 决上面的缺点，Android 7.0版本中的ART加入了即时编译器JIT,作为AOT的一个补充， 在应用程序安装时并不会将字节码全部编译成机器码，而是在运行中将热点代码编译成机 器码，从而缩短应用程序的安装时间并节省了存储空间。DVM是为32位CPU设 计的，而ART支持64位并兼容32位CPU,这也是DVM 被淘汰的主要原因之一。ART对垃圾回收机制进行了改进，比如更频繁地执行并行垃圾收集，将GC暂停 由2次减少为1次等。ART的运行时堆空间划分和DVM不同。与DVM的GC不同的是，ART采用了多种垃圾收集方案，每个方案会运行不同的垃圾收集器,默认是采用了 CMS( Concurrent Mark-Sweep)方案，该方案主要使用了 sticky-CMS 和partial-CMS。根据不同的CMS方案，ART的运行时堆的空间也会有不同的划分，默认 是由4个Space和多个辅助数据结构组成的，4个Space分别是Zygote Space、Allocation Space、Image Space 和 Large Object Spaceo Zygote Space、Allocation Space 和 DVM 中的作 用是一样的，Image Space用来存放一些预加载类，Large Object Space用来分配一些大对象 (默认大小为12KB),其中Zygote Space和Image Space是进程间共享的。采用标记一清除算法的运行时堆空间划分如图11-3所示。
除了这四个Space, ART的Java堆中还包括两个Mod Union Table, 一个Card Table, 两个 Heap Bitmap,两个 Object Map,以及三个 Object Stacko
ART的GC H志与DVM不同，ART会为那些主动请求的垃圾收集事件或者认为GC 速度慢时才会打印GC日志。GC速度慢指的是GC暂停超过5ms或者GC持续时间超过 100mso如果App未处于可察觉的暂停进程状态，那么它的GC不会被认为是慢速的。
ART的GC H志具体的格式为：
I/art: <GC_Reason> <GC_Name> <Objects_freed>(<Size_freed>) AllocSpace Objects, <Large_objects_freed>(<Large_object_size_freed>) <Heap_stats> LOS objects, <Pause_time(s)>
下面对GC日志的组成部分进行介绍。
1. 引起GC原因
ART的引起GC原因(GC_Reason)要比DVM多一些，有以下几种。
Concurrent：并发GC,不会使App的线程暂停，该GC是在后台线程运行的，并不 会阻止内存分配。Alloc：当堆内存已满时，App尝试分配内存而引起的GC,这个GC会发生在正在 分配内存的线程中。Explicit： App显示的请求垃圾收集，例如调用System.gc()o与DVM 一样，最佳做 法是应该信任GC并避免显式地请求GC,显式地请求GC会阻止分配线程并不必要 地浪费CPU周期。如果显式地请求GC导致其他线程被抢占，那么有可能会导致jank (App同一帧画了多次)。NativeAlloc： Native内存分配时，比如为Bitmaps或者RenderScript分配对象，这会 导致Native内存压力，从而触发GC。CollectorTransition:由堆转换引起的回收，这是运行时切换GC而引起的。收集器 转换包括将所有对象从空闲列表空间复制到碰撞指针空间(反之亦然)。当前，收集 器转换仅在以下情况下出现：在内存较小的设备上，App将进程状态从可察觉的暂 停状态变更为可察觉的非暂停状态(反之亦然)。HomogeneousSpaceCompact:齐性空间压缩是指空闲列表到压缩的空闲列表空间， 通常发生在当App已经移动到可察觉的暂停进程状态时。这样做的主要原因是减少 了内存使用并对堆内存进行碎片整理。DisableMovingGc：不是真正触发GC的原因，发生并发堆压缩时，由于使用了 GetPrimitiveArrayCritical,收集会被阻塞。在一般情况下，强烈建议不要使用 GetPrimitiveArrayCritical,因为它在移动收集器方面具有限制。HeapTrim：不是触发GC的原因，但是请注意，收集会一直被阻塞，直到堆内存整 理完毕。2.垃圾收集器名称
GC_Name指的是垃圾收集器名称，有以下几种。
Concurrent Mark Sweep (CMS)： CMS收集器是一种以获取最短收集暂停时间为目 标的收集器，采用了标记一清除算法实现。它是完整的堆垃圾收集器，能释放除了 Image Space外的所有的空间。Concurrent Partial Mark Sweep：部分完整的堆垃圾收集器，能释放除了 Image Space 和Zygote Space外的所有空间。Concurrent Sticky Mark Sweep：粘性收集器，基于分代的垃圾收集思想，它只能释 放自上次GC以来分配的对象。这个垃圾收集器比一个完整的或部分完整的垃圾收 集器扫描得更频繁，因为它更快并且有更短的暂停时间。Marksweep + Semispace：非并发的GC,复制GC用于堆转换以及齐性空间压缩(堆 碎片整理)。3.其他信息
Objects freed：本次GC从非Large Object Space中回收的对象的数量。Size freed：本次GC从非Large Object Space中回收的字节数。Large objects freed：本次 GC 从 Large Object Space 中回收的对象的数量。Large object size freed:本次 GC 从 Large Object Space 中回收的字节数。Heap stats：堆的空闲内存百分比，即(已用内存)/ (堆的总内存)。Pause times：暂停时间，暂停时间与在GC运行时修改的对象引用的数量成比例。 目前，ART的CMS收集器仅有一次暂停，它岀现在GC的结尾附近。移动的垃圾 收集器暂停时间会很长，会在大部分垃圾回收期间持续出现。4.实例分析
I/art : Explicit concurrent mark sweep GC free d 104710(7MB) AllocSpace objects,
21 (416KB) LOS objects, 33% free, 25MB/38MB, paused 1.230ms total 67.216ms
这个GC 日志的含义为引起GC原因是Explicit；垃圾收集器为CMS收集器；释放对 象的数量为104710个，释放字节数为7MB；释放大对象的数量为21个，释放大对象字节 数为416KB；堆的空闲内存百分比为33%,已用内存为25MB,堆的总内存为38MB； GC 暂停时长为1.230ms, GC总时长为67.216ms。
虽然DVM和ART的知识体系非常庞大，但是我们仍旧有必要了解DVM是怎么来的。 在2.1.5节中讲过init启动Zygote时会调用app main.cpp的main函数，如下所示：
frameworks/base/cmds/app_process/app_main.cpp
int main(int argc, char* const argv[]){ if (zygote) {//1 runtime.start (ncom.android. internal.os.Zygotelnit1', args, zygote); //2 else if (className) { runtime.start("com.android.internal.os.RuntimeInit", args, zygote); else { fprintf(stderr, ''Error: no class name or --zygote supplied. \n"); app_usage(); LOG_ALWAYS_FATAL("app_process: no class name or --zygote supplied."); return 10; } }在注释1处如果为ture,就说明当前程序运行在Zygote进程中，在注释2处调用 AppRuntime 的 start 函数，start 函数具体在 AppRuntime 的父类 AndroidRuntime 中实现，如 下所示：
frameworks/base/core/jni/AndroidRuntime.cpp
void AndroidRuntime::start(const char* className, const Vector<String8>& options, bool zygote){ Jnilnvocation jni_invocation; jni_invocation.Init(NULL);//1 JNIEnv* env; //启动Java虚拟机 if (startVm(&mJavaVM, &env, zygote) != 0) (//2 return; } onVmCreated(env); //为Java虚拟机注册JNI方法 if (startReg(env) < 0) {//3 ALOGE("Unable to register all android natives\n"); return; } }在注释2处调用startVm函数来创建Java虚拟机，在注释3处调用startReg函数来为 Java虚拟机注册JNI方法。在注释1处调用了 jni invocation的Init函数：
libnativehelper/Jnilnvocation.cpp
bool Jniinvocation::Init(const char* library) ( #ifdef _ANDROID_ char buffer[PROP_VALUE_MAX]; #else char* buffer = NULL; #endif library = GetLibrary(library, buffer);//l const int KDlopenFlags = RTLD_NOW | RTLD_NODELETE; handle_ = dlopen(library, kDlopenFlags);//2 if (handle_ == NULL) { if (strcmp(library, kLibraryFallback) == 0) ( ALOGE("Failed to dlopen %s: %s", library, dlerror()); return false; } } return true; }在注释1处调用了 GetLibrary函数:
libnativehelper/Jnilnvocation.cpp
#ifdef ANDROID//1 static char* kLibrarySystemProperty = "persist.sys.dalvik.vm.lib.2”;//2 static char* kDebuggableSystemProperty = "ro.debuggableM; #endif static const char* kLibraryFallback = "libart.so"; template<typename T> void UNUSED(const T&) (} const char* Jnilnvocation::GetLibrary(const char* library, char* buffer) { #ifdef ANDROID_ const char* default_library; char debuggable[PROP_VALUE_MAX]; system_property_get(kDebuggableSystemProperty, debuggable); if (strcmp(debuggable, "1") != 0) {//3 library = kLibraryFallback;//4 default_library = kLibraryFallback;//5 } else { if (buffer != NULL) { if (system_property_get(kLibrarySystemProperty, buffer) > 0) {//6 default_library = buffer; } else { default_library = kLibraryFallback; } } else { default_library = kLibraryFallback; } } #else UNUSED(buffer); const char* default_library = kLibraryFallback;//7 #endif if (library = NULL) { library = default_library;//8 } return library; }
注释1处代表在Android平台，注释2处的persist.sys.dalvik.vm.lib.2是一个系统属性， 它的取值可以为libdvm.so或者libart.so,值为libdvm.so说明当前用的是DVM,值为libart.so 说明当前用的是ARTO在注释3处如果debuggable不等于”1”，说明当前不是Debug模式 构建的，是不允许动态更改虚拟机动态库的。在注释4和注释5处将libart.so赋值给library 和default library0如果是Debug模式构建会在注释6处读取persist.sys.dalvik.vm.lib.2配置中是否有传入的参数buffer,如果有就将default library赋值为buffer,如果没有将 default library赋值为libart.so。在注释7处如果不是在Android平台，default library的值 为libart.so0在注释8处如果library为NULL就将default !ibrary赋值给library并返回该 library。这里我们知道Android 8.0如果不是Debug模式构建，只能返回libart.so。回到 Jnilnvocation的Init函数，注释1处的GetLibrary函数会返回libart.so或者libdvm.so,接着 在注释2处调用dlopen函数来加载libart.so或者libdvm.so。因此我们知道Jnilnvocation的Init函数的主要作用是初始化ART或者DVM的环境，初始化完毕后会调用startVm函数来 启动相应的虚拟机。讲到这里我们应该知道DVM和ART是如何诞生的了，没错，是在 Zygote进程中诞生的，这样Zygote进程就持有了 DVM或者ART的实例，此后Zygote进 程fork自身创建应用程序进程时，应用程序进程也得到了 DVM或者ART的实例，这样就 不需要每次启动应用程序进程都要创建DVM或者ART,从而加快了应用程序进程的启动 速度。
本章介绍了 DVM和ART的基本原理、如何阅读它们的log和DVM,以及ART的诞生。阅读本章前请阅读第2章、第3章和第10章会有利于对本章的理解。DVM和ART的 知识体系完全可以写一本书，如果想要更多地了解它们请阅读专业的书籍和博客，博客推 荐老罗（罗升阳）的博客，里面有一系列文章专门介绍DVM和ART,虽然文章基于的Android 版本有些老，但仍具有参考价值。
