Android中的ART和Dalvik对比

概述

之前也一直零零散散的看过Android运行时与Dalvik，但是都没有没有总结成文字，这里总结一下几篇相关博客中的介绍。

维基百科：Dalvik虚拟机
维基百科：Android Runtime

Dalvik 是一个执行dex文件的Java虚拟机
而ART则提供一套完全与Java虚拟机兼容的接口，因此可以在4.4之后无缝将Dalvik替换成ART，这里可以查看：Android ART运行时无缝替换Dalvik虚拟机的过程分析

Dalvik与JVM

Dalvik是Android平台的虚拟机,在应用每次运行的时候会 将 dex文件 编译为 机器码。

• Dalvik使用.dex格式，而Java虚拟机使用的是class格式
• 一个dex文件可以包含若干个类
• Dalvik指令是基于寄存器的，Java虚拟机使用的指令集是基于堆栈的
• 自Android 2.2开始，Dalvik支持JIT技术

Dalvik虚拟机的其它特性（Dalvik虚拟机简要介绍和学习计划）

Dalvik的内存管理

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

Java Object Heap

• Java Object Heap是用来分配Java对象,通过代码new出来的对象都是位于Java Object Heap上的。
• 可以通过ActivityManager类的成员函数getMemoryClass来获得Dalvik虚拟机的Java Object Heap的最大值

Bitmap Memory

也称为External Memory,HoneyComb之前,是用来处理图像的，

• Bitmap Memory是在Native Heap中分配的,但同样计入Java Object Heap中。
• 在HoneyComb以及更高的版本中，Bitmap Memory就直接是在Java Object Heap中分配了，可以直接接受GC的管理。
• 因为Native Heap不受Java Object Heap的大小限制，因此处理大图像时，容易抛出OutOfMemoryError。
• 可通过android:largeHeap来通知Dalvik虚拟机应用程序需要使用较大的Java Object Heap，但不建议这么做。

Native Heap

在Native Code中使用malloc等分配出来的内存

• 不受Java Object Heap的大小限制，但会受到系统的限制,可以自由使用
• 滥用Native Heap会导致系统可用内存急剧减少，导致系统采取激进的措施来Kill掉某些进程

Dalvik垃圾收集(GC)

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

• Stop-the-world，也就是垃圾收集线程在执行的时候，其它的线程都停止；
• Full heap collection，也就是一次收集完全部的垃圾；
• 一次垃圾收集造成的程序中止时间通常都大于100ms。

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

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

即时编译(JIT)

Dalvik虚拟机从Android 2.2版本开始，才支持JIT，而且是可选的

本地调用JNI

• JNI机制既支持在Java函数中调用C/C++函数，也支持在C/C++函数中调用Java函数

进程和线程管理

• 每一个Android应用程序进程都有一个Dalvik虚拟机实例
• 每一个Android应用程序进程都是由一种称为Zygote的进程fork出来的

ART

是一种在Android操作系统上的运行环境，ART能够在第一次安装的时候，把应用程序的字节码转换为机器码。采用了预编译（AOT,Ahead-Of-Time）技术。

• ART运行的仍然是一个包含dex字节码的APK文件；
• AOT在在应用安装的时候将应用的dex字节码翻译成本地机器码；

ART的优点

• ART 性能高于采用JIT的Dalvik
• 应用启动更快、运行更快、体验更流畅、触感反馈更及时
• 更长的电池续航能力
• 支持更低的硬件

ART的缺点

• 字节码变为机器码之后，占用的存储空间更大
• 应用的安装时间会变长。

参考：
Android 中的Dalvik和ART是什么，有啥区别？
Android运行时ART简要介绍和学习计划