Android 编译器、架构和运行时，它是如何协同工作的? [英] Android compiler, architecture and runtime, how doeas it work together?

问题描述

最近在研究Android运行时，特别关注核心的dex2oat工具.但是 dex2oat 不是孤立的，而是与 Android 的引导映像、android-root、指令集、运行时参数等一起工作.

I am studying Android runtime recently, especially focusing on dex2oat tool which is the heart. However dex2oat is not isolated but works together with Android's boot-image, android-root, instruction-set, runtime-arg etc.

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

Can anyone explain what they are and what they are used for? And their internal connections?

推荐答案

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

Ok so dex2oat comes as a part of the new Android Runtime (ART). The idea is to replace Android's bytecode interpreter (and JIT compiler) with an ahead-of-time compiler and provide a new runtime that can load and execute compiled apps.

dex2oat

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

The dex2oat utility is a full compilation suite that provides a lot of compilation options, several compilers, and code generating backends for each processor platform that Android currently runs on. So if someone is refering to dex2oat, the Android AOT compiler (suite) is meant. Its input format is dex bytecode and it outputs so called oat files which are ELF shared objects. The advantage of AOT compilation in contrast to interpretation (or JIT compilation) is, that we do not slow down the execution time if we apply more complex optimizations as they happen BEFORE the app. Also, as we are talking about an on-device compiler, apps can still be shipped as dex bytecode but are compiled on the device for its concrete architecture. So to my knowledge, there are backends for ARM, MIPS and x86 for 32 and 64 bits each at the moment.

启动图像

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

Pre-ART, Android used the Zygote to fork each app process and preload and preinitialize some classes for optimization purposes. On ART, the set of jar libraries that should be preloaded into each app process is compiled once into the so called boot image. It consists of two files, boot.oat and boot.art. Boot.oat contains the compiled code while boot.art contains a preinitialized heap etc. Both are also generated by dex2oat. This boot image is loaded into each app's process as an optimization.

运行时环境

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

As apps are now compiled oat files, ART provides a new runtime to load and execute them. So the idea is to load the ELF shared object into the preinitialized app process and execute the application. As the code is already compiled, there is no need to interpret at runtime. Some exceptions are systems that run on low permanent storage (oat files are big), apps that are debugged etc. In those cases, ART can fall back to interpretation. But in general, compiling apps AOT is the new default.

这篇关于Android 编译器、架构和运行时，它是如何协同工作的?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！