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

Question

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

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

Answer 1

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

dex2oat

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

启动图像

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

运行时环境

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