android - Android 编译器、架构和运行时，它们如何协同工作？

Question

最近在研究Android runtime，特别关注dex2oat这个核心工具。然而 dex2oat 并不是孤立的，而是与 Android 的 boot-image、android-root、指令集、runtime-arg 等一起工作。

谁能解释它们是什么以及它们的用途？他们的内部联系呢？

Answer 1

好的，所以dex2oat是新的 Android 运行时 (ART) 的一部分。这个想法是用一个提前编译器替换 Android 的字节码解释器（和 JIT 编译器），并提供一个可以加载和执行已编译应用程序的新运行时。

右旋燕麦

dex2oat 实用程序是一个完整的编译套件，它为 Android 当前运行的每个处理器平台提供了许多编译选项、多个编译器和代码生成后端。所以如果有人指的是dex2oat，是指Android AOT编译器（套件）。它的输入格式是 dex 字节码，它输出所谓的 oat 文件，它们是 ELF 共享对象。与解释（或 JIT 编译）相比，AOT 编译的优势在于，如果我们在应用程序之前应用更复杂的优化，我们不会减慢执行时间。此外，正如我们所讨论的设备上编译器，应用程序仍然可以作为 dex 字节码发布，但会在设备上针对其具体架构进行编译。所以据我所知，目前有 32 位和 64 位的 ARM、MIPS 和 x86 的后端。

启动映像

Pre-ART，Android 使用 Zygote 分叉每个应用程序进程并预加载和预初始化一些类以进行优化。在 ART 上，应该预加载到每个应用程序进程中的一组 jar 库被编译一次，成为所谓的启动映像。它由两个文件组成，boot.oat 和 boot.art。Boot.oat 包含编译后的代码，而 boot.art 包含一个预初始化的堆等。两者也是由dex2oat生成的。此启动映像作为优化加载到每个应用程序的进程中。

运行环境

由于应用程序现在是编译的 oat 文件，因此 ART 提供了一个新的运行时来加载和执行它们。所以想法是将ELF共享对象加载到预初始化的app进程中并执行应用程序。由于代码已经编译，因此无需在运行时进行解释。一些例外是在低永久存储上运行的系统（oat 文件很大）、经过调试的应用程序等。在这些情况下，ART 可以回退到解释。但总的来说，编译应用程序 AOT 是新的默认设置。