我们使用Java开发android，在编译打包APK文件时，会经过以下流程
- Java编译器将应用中所有Java文件编译为class文件（JVM运行的是.class文件，而DVM是.dex文件）
- dx工具将应用编译输出的类文件转换为Dalvik字节码，即dex文件
- 之后经过签名、对齐等操作变为APK文件。
Dalvik是Google公司自己设计用于Android平台的Java虚拟机。它可以支持已转换为 .dex（即Dalvik Executable）格式的Java应用程序的运行，.dex格式是专为Dalvik设计的一种压缩格式，适合内存和处理器速度有限的系统。Dalvik 经过优化，允许在有限的内存中同时运行多个虚拟机的实例，并且每一个Dalvik 应用作为一个独立的Linux 进程执行。独立的进程可以防止在虚拟机崩溃的时候所有程序都被关闭。Dalvik虚拟机可以看做是一个Java VM，他负责解释dex文件为机器码，如果我们不做处理的话，每次执行代码，都需要Dalvik将dex代码翻译为微处理器指令，然后交给系统处理，这样效率不高。
为了解决这个问题，Google在2.2版本添加了JIT编译器，当App运行时，每当遇到一个新类，JIT编译器就会对这个类进行编译，经过编译后的代码，会被优化成相当精简的原生型指令码（即native code），这样在下次执行到相同逻辑的时候，速度就会更快。
当然使用JIT也不一定加快执行速度，如果大部分代码的执行次数很少，那么编译花费的时间不一定少于执行dex的时间。所以JIT不对所有dex代码进行编译，而是只编译执行次数较多的dex为本地机器码。
有一点需要注意， dex字节码翻译成本地机器码是发生在应用程序的运行过程中的，并且应用程序每一次重新运行的时候，都要做重做这个翻译工作，所以这个工作并不是一劳永逸，每次重新打开App，都需要JIT编译。
另外，Dalvik虚拟机从Android一出生一直活到4.4版本，而JIT在Android刚发布的时候并不存在，在2.2之后才被添加到Dalvik中。
Android操作系统已经成熟，Google的Android团队开始将注意力转向一些底层组件，其中之一是负责应用程序运行的Dalvik运行时。Google开发者已经花了两年时间开发更快执行效率更高更省电的替代ART运行时。ART代表Android Runtime，其处理应用程序执行的方式完全不同于Dalvik，Dalvik是依靠一个Just-In-Time (JIT, 即时编译技术)编译器去解释字节码。开发者编译后的应用代码需要通过一个解释器在用户的设备上运行，这一机制并不高效，但让应用能更容易在不同硬件和架构上运 行。ART则完全改变了这套做法，在应用安装时就预编译字节码到机器语言，这一机制叫Ahead-Of-Time (AOT）编译。在移除解释代码这一过程后，应用程序执行将更有效率，启动更快。
JIT是运行时编译，这样可以对执行次数频繁的dex代码进行编译和优化，减少以后使用时的翻译时间，虽然可以加快Dalvik运行速度，但是还是有弊病，那就是将dex翻译为本地机器码也要占用时间，所以Google在4.4之后推出了ART，用来替换Dalvik。在4.4版本上，两种运行时环境共存，可以相互切换，但是在5.0+，Dalvik虚拟机则被彻底的丢弃，全部采用ART。
ART的策略与Dalvik不同，在ART 环境中，应用在第一次安装的时候，字节码就会预先编译成机器码，使其成为真正的本地应用。之后打开App的时候，直接使用本地机器码运行,因此运行速度提高。
当然ART与Dalvik相比，还是有缺点的。
ART需要应用程序在安装时，就把程序代码转换成机器语言，所以这会消耗掉更多的存储空间，但消耗掉空间的增幅通常不会超过应用代码包大小的20%。由于有了一个转码的过程，所以应用安装时间难免会延长
但是这些与更流畅的Android体验相比而言，不值一提。
总结：
- JIT代表运行时编译策略，也可以理解成一种运行时编译器，是为了加快Dalvik虚拟机解释dex速度提出的一种技术方案，来缓存频繁使用的本地机器码
- ART和Dalvik都算是一种Android运行时环境，或者叫做虚拟机，用来解释dex类型文件。但是ART是安装时解释，Dalvik是运行时解释
- AOT可以理解为一种编译策略，即运行前编译，ART虚拟机的主要特征就是AOT
- JIT(Just-In-Time)，用来在运行时动态地将执行频率很高的dex字节码编译成本地机器码，然后再执行。通过JIT，就可以有效地提高Dalvik虚拟机的执行效率。但是，应用每次运行的时候，部分字节码都需要通过JIT转换为机器码，降低了应用程序运行效率。而ART则是使用AOT进行处理（Ahead-Of-Time），所谓AOT是指在运行以前就把中间代码静态编译成本地代码，这就减去了JIT运行时的转换时间，因此，即使Dalvik采用了JIT，Dalvik总体性能还是不能与直接执行本地机器码的ART虚拟机相比。
ART优点：
1、系统性能的显著提升。 2、应用启动更快、运行更快、体验更流畅、触感反馈更及时。
3、更长的电池续航能力。 4、支持更低的硬件。
ART缺点：
1、更大的存储空间占用，可能会增加10%-20%。 2、更长的应用安装时间。
Android N引入了一种包含编译、解释和JIT（Just In Time）的混合运行时，以便在安装时间、内存占用、电池消耗和性能之间获得最好的折衷。
应用在安装时不做编译，而是解释字节码，所以可以快速启动。ART中有一种新的、更快的解释器，通过一种新的JIT完成，但是这种JIT的信息不是持久化的。取而代之的是，代码在执行期间被分析，分析结果保存起来。然后，当设备空转和充电的时候，ART会执行针对“热代码”进行的基于分析的编译，其他代码不做编译。为了得到更优的代码，ART采用了几种技巧包括深度内联。
对同一个应用可以编译数次，或者找到变“热”的代码路径或者对已经编译的代码进行新的优化，这取决于分析器在随后的执行中的分析数据。这个步骤仍被简称为AOT，可以理解为“全时段的编译”（All-Of-the-Time compilation）。这种混合使用AOT、解释、JIT的策略的全部优点如下：
- 应用安装时间过长：即使是大应用，安装时间也能缩短到几秒。在N之前，应用在安装时需要对所有ClassN.dex做AOT机器码编译，类似微信这种比较大型的APP可能会耗时数分钟。但是往往我们只会使用一个应用20%的功能，剩下的80%我们付出了时间成本，却没带来太大的收益。
- 降低占ROM空间：同样全量编译AOT机器码，12M的dex编译结果往往可以达到50M之多。只编译用户用到或常用的20%功能，这对于存储空间不足的设备尤其重要。
- 提升系统与应用性能：减少了全量编译，降低了系统的耗电。在boot.art的基础上，每个应用增加了base.art, 通过预加载与缓存提升应用性能。
- 快速的系统升级：系统升级能更快地安装，因为不再需要优化这一步。以往厂商ota时，需要对安装的所有应用做全量的AOT编译，这耗时非常久。事实上，同样只有20%的应用是我们经常使用的，给不常用的应用，不常用的功能付出的这些成本是不值得的。
Android N为了解决这些问题，通过管理 解释，AOT与JIT 三种模式，以达到一种运行效率、内存与耗电的折中。简单来说，在应用运行时分析运行过的代码以及“热代码”，并将配置存储下来。在设备空闲与充电时，ART仅仅编译这份配置中的“热代码”。 Android N上总共有12种编译方法，其中有几个我们是特别关心的，
- install(应用安装)与 first-boot (应用首次启动)使用的是[interpret-only]，即只verify，代码解释执行即不编译任何的机器码，它的性能与Dalvik时完全一致，先让用户愉快的玩耍起来。
- ab-ota(系统升级)与 bg-dexopt (后台编译)使用的是[speed-profile]，即只根据“热代码”的profile配置来编译。这也是N中混合编译的核心模式。
- 对于动态加载的代码，即 forced-dexopt ，它采用的是[speed]模式，即最大限度的编译机器码，它的表现与之前的AOT编译一致。