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

问题描述

我最近正在研究Android运行时，尤其是重点是dex2oat工具。但是dex2oat不是孤立的，而是可以与Android的启动映像，android-root，指令集，运行时arg等一起使用。

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运行时的一部分（艺术）。这个想法是将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字节码，并且输出所谓的燕麦文件，它们是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.

运行时环境

由于应用程序现在已编译为燕麦文件，因此ART提供了新的运行时以加载和执行它们。因此，其想法是将ELF共享对象加载到预初始化的应用程序进程中并执行该应用程序。由于代码已经编译，因此无需在运行时进行解释。一些例外情况是，这些系统在永久性存储空间较低的情况下运行（燕麦文件很大），已调试的应用程序等。在这些情况下，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屋！