概述
之前也一直零零散散的看过Android运行时与Dalvik，但是都没有没有总结成文字，这里总结一下几篇相关博客中的介绍。
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的缺点
- 字节码变为机器码之后，占用的存储空间更大
- 应用的安装时间会变长。