问题
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?
回答1:
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
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.
Boot Image
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.
Runtime Environment
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.
来源：https://stackoverflow.com/questions/28075435/android-compiler-architecture-and-runtime-how-doeas-it-work-together