Dalvik虚拟机解析-优快云博客

本文详细介绍了Dalvik虚拟机的特点及工作原理，包括其与Java虚拟机的主要区别、内存管理方式、垃圾回收机制以及即时编译技术。同时，还探讨了Dalvik虚拟机在Android系统中的应用。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

2019独角兽企业重金招聘Python工程师标准>>>

Dalvik虚拟机是Android应用程序运行的环境，并且每一个应用程序对应有一个单独的Dalvik虚拟机实例。Dalvik虚拟机与Java虚拟机的最显著区别是它们分别具有不同的类文件格式以及指令集。Dalvik虚拟机使用的是dex（Dalvik Executable）格式的类文件，而Java虚拟机使用的是class格式的类文件。一个dex文件可以包含若干个类，而一个class文件只包括一个类。由于一个dex文件可以包含若干个类，因此它就可以将各个类中重复的字符串和其它常数只保存一次，从而节省了空间，这样就适合在内存和处理器速度有限的手机系统中使用。除了指令集和类文件格式不同，Dalvik虚拟机与Java虚拟机有差不多的特性，例如，它们都是解释执行，并且支持即时编译（JIT）、垃圾收集（GC）、Java本地方法调用（JNI）和Java远程调试协议（JDWP）等。

Dalvik虚拟机使用的指令是基于寄存器的，而Java虚拟机使用的指令集是基于堆栈的。基于堆栈的指令很紧凑，例如，Java虚拟机使用的指令只占一个字节，因而称为字节码。基于寄存器的指令由于需要指定源地址和目标地址，因此需要占用更多的指令空间，例如，Dalvik虚拟机的某些指令需要占用两个字节。基于堆栈和基于寄存器的指令集各有优劣，一般而言，执行同样的功能，前者需要更多的指令（主要是load和store指令），而后者需要更多的指令空间。需要更多指令意味着要多占用CPU时间，而需要更多指令空间意味着数据缓冲（d-cache）更易失效。

内存管理

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选项来将它的最小值和最大值设置为相等。

Dalvik虚拟机在启动的时候，就是通过读取系统属性dalvik.vm.heapsize的值来获得Java Object Heap的最大值的，而ActivityManager（frameworks/base/core/java/android/app/ActivityManager.java）类的成员函数getMemoryClass最终也通过读取这个系统属性的值来获得Java Object Heap的最大值。

这个Java Object Heap的最大值也就是我们平时所说的Android应用程序进程能够使用的最大内存。这里必须要注意的是，Android应用程序进程能够使用的最大内存指的是能够用来分配Java Object的堆。

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的大小，毕竟系统总共可用的内存是固定的，一个应用程序用得多了，就意味意其它应用程序用得少了。

垃圾回收

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

在GingerBread之前，Dalvik虚拟使用的垃圾收集机制有以下特点：

    1. Stop-the-world，也就是垃圾收集线程在执行的时候，其它的线程都停止；

    2. Full heap collection，也就是一次收集完全部的垃圾；

    3. 一次垃圾收集造成的程序中止时间通常都大于100ms。

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

    1.  Cocurrent，也就是大多数情况下，垃圾收集线程与其它线程是并发执行的；

    2.  Partial collection，也就是一次可能只收集一部分垃圾；

    3.  一次垃圾收集造成的程序中止时间通常都小于5ms。

即时编译（JIT）

JIT（just-in-time）是相对AOT（ahead-of-time）而言的，即JIT是在程序运行的过程中进行编译的，而AOT是在程序运行前进行编译的。在程序运行的过程中进行编译既有好处，也有坏处。好处在于可以利用程序的运行时信息来对编译出来的代码进行优化，而坏处在于占用程序的运行时间，也就是说不能花太多时间在代码编译和优化之上。

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

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

关于Android应用程序进程，它有两个很大的特点：

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

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

转载于:https://my.oschina.net/shenhuniurou/blog/847354