Google 已经用一个 AOT 编译器替代了 Android 中的 JIT 编译器。这个 AOT 编译器可以在安装阶段把字节码转换成原生的机器码。
在 2014 年的 I/O 大会上,Google 发布了下一代 Android 操作系统,代号“L 版本”,这个版本有一些重大的系统架构方面的修改,其中之一就是用一个全新的运行时库,就叫 Anroid RunTime(ART)以及 AOT 编译器替代了 Dalvik 虚拟机和它的 JIT 编译器。
在不同的条件下,AOT 和 JIT 编译策略具有不一样的优势和缺点。Google 实现的 ART 保持了 JIT 编译策略对硬件的灵活性,同时调整了 JIT 对于空间和速度的取舍。这种 AOT 策略是针对 Android 使用的硬件平台优化的。其他移动平台针对它们的硬件和软件环境,会有不同的选择。
- iOS 主要依靠静态编译,在开发者的电脑上,构建过程会产生优化过的原生指令,然后直接上传这个应用。
- Windows Phone 使用云编译策略,安装时应用商店会先生成那些依赖于具体硬件的指令,然后再把应用安装到手机上。
这两种策略分别是这两家公司针对自己情况的最优选择,苹果紧紧地控制着硬件生态系统,而微软的系统则有着五花八门的硬件执行环境。
在这个新的 Android 运行时库的实现中,操作系统在应用安装的时候,直接在设备上把字节码转换成机器码,并把这些原生的指令存储起来,以备今后使用。无论是在永久存储区域还是内存方面,这份原生指令都会占更大的空间。和 Dalvik 加传统的 JIT 编译器相反,每次应用执行的时候不需要重复这个编译过程。
但 ART 也丧失了 JIT 编译的一个关键优势:在手机、平板电脑或其他设备上安装应用程序的时候,操作系统只有知道底下运行的硬件细节,才能把应用转换成原生的机器码。它知道硬件是不会变的,所以才能针对这种硬件产生最优的指令。这和静态编译器形成了鲜明的对比,静态编译器通常不会针对特定的处理器做优化,也不会为不同的处理器产生多份指令。
Google 声称 ART 总体上能把性能提高到 Dalvik 的 200%,这部分是因为 AOT 编译器对指令的全貌有一个概览,而 JIT 编译器只执行本地优化。Andre Frumusanu 在为 AnandTech 网站写的文章中指出“异常检查等带来的开销大大减少,方法和接口调用的速度极大地提升了”。
因为 ART 编译出来的是一个 ELF 可执行文件,所以内核可以管理它的代码页——这个结果可能会大大改进内存管理,并且降低内存使用。
Android L 现在有一个开发者预览版,正式版预计将在秋天发布,所以最终能提升到什么程度,以及是否会有更多的取舍,还要拭目以待。这个版本在通用的编译方面看起来并没有多大进步,Google 对此并没有什么新计划,也没有在跟踪这件事。随着硬件功能的不断进步,Google 不断关注的是针对Android 特定硬件的优化编译策略。
参考原文链接: http://www.infoq.com/news/2014/07/ahead-of-time-compiler-os
评论