我们使用Java开发android,在编译打包APK文件时,会经过以下流程

  1. Java编译器将应用中所有Java文件编译为class文件(JVM运行的是.class文件,而DVM.dex文件
  2. dx工具将应用编译输出的类文件转换为Dalvik字节码,即dex文件
  3. 之后经过签名、对齐等操作变为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体验相比而言,不值一提。

总结:

  1. JIT代表运行时编译策略,也可以理解成一种运行时编译器,是为了加快Dalvik虚拟机解释dex速度提出的一种技术方案,来缓存频繁使用的本地机器码
  2. ARTDalvik都算是一种Android运行时环境,或者叫做虚拟机,用来解释dex类型文件。但是ART是安装时解释,Dalvik是运行时解释
  3. AOT可以理解为一种编译策略,即运行前编译,ART虚拟机的主要特征就是AOT
  4. 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的策略的全部优点如下:

  1. 应用安装时间过长:即使是大应用,安装时间也能缩短到几秒。在N之前,应用在安装时需要对所有ClassN.dex做AOT机器码编译,类似微信这种比较大型的APP可能会耗时数分钟。但是往往我们只会使用一个应用20%的功能,剩下的80%我们付出了时间成本,却没带来太大的收益。
  2. 降低占ROM空间:同样全量编译AOT机器码,12M的dex编译结果往往可以达到50M之多。只编译用户用到或常用的20%功能,这对于存储空间不足的设备尤其重要。
  3. 提升系统与应用性能:减少了全量编译,降低了系统的耗电。在boot.art的基础上,每个应用增加了base.art, 通过预加载与缓存提升应用性能。
  4. 快速的系统升级:系统升级能更快地安装,因为不再需要优化这一步。以往厂商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编译一致。