Google
正在从 Dalvik
转向 ART
(Android Runtime)。
我试图理解这将如何提高性能。
我发现的最好的解释是下面的图片:
已更改的主要组件之一是 dexopt
到 dex2oat
。
由于我对此并不了解,所以是否有人可以解释一下差异以及这将如何提高性能呢?
Google
正在从 Dalvik
转向 ART
(Android Runtime)。
我试图理解这将如何提高性能。
我发现的最好的解释是下面的图片:
已更改的主要组件之一是 dexopt
到 dex2oat
。
由于我对此并不了解,所以是否有人可以解释一下差异以及这将如何提高性能呢?
dexopt对dex文件进行了优化。它会将虚拟调用指令替换为一个优化版本,其中包含被调用方法的vtable索引,这样在执行期间就不必执行方法查找。
dexopt的结果是一个odex(优化后的dex)文件。它与原始dex文件非常相似,只是使用了一些优化的操作码,如优化的虚拟调用指令。
dex2oat将dex文件编译成一个elf文件,然后本地执行。因此,它现在具有本机代码,而不是由虚拟机解释的字节码。这称为AOT(预先编译)编译。
这两个工具通常在设备上安装时运行。
另一个需要考虑的因素是dalvik使用JIT(即时编译器)-这意味着它也能够将字节码编译为本机代码。然而,主要的区别在于ART提前编译所有内容,而dalvik仅使用启发式方法编译字节码子集,并在执行期间编译。
Android Runtime (ART)是Android移动操作系统使用的应用程序运行环境。ART替代了最初由Android使用的进程虚拟机Dalvik,并将应用程序的字节码转换为本地指令,以后由设备的运行时环境执行。
与Dalvik不同的是,自Android 2.2“Froyo”开始,Dalvik使用即时(JIT)编译器在每次启动应用程序时编译字节码,而ART则引入了预先编译(AOT)编译,通过在安装应用程序时执行编译来减少应用程序操作中需要执行的总编译量,从而降低移动设备的处理器使用率并提高电池续航时间。同时,ART在性能、垃圾回收、应用程序调试和分析方面也有所改进。
为了保持向后兼容性,ART使用与Dalvik相同的输入字节码,作为APK文件的一部分通过标准的.dex
文件提供,而.odex
文件被替换为可执行和可链接格式(ELF)可执行文件。一旦使用ART的设备上的dex2oat实用程序编译了应用程序,它就仅从编译的ELF可执行文件运行;这种方法消除了与JIT编译相关的各种开销,但在安装应用程序时需要额外的编译时间,并且应用程序需要稍微更多的存储空间来存储已编译的代码。