Android Runtime (ART) is the heart and soul of Java applications running on Android. Ever since ART was revealed as a developer setting in Android KitKat, I was fascinated by the details of how the apps that I used on a daily basis actually ran on the device I was using, which at the time was a Nexus 4.
There are many parts of the runtime, which includes the compiler, garbage collector, interpreter, and ART’s internal files such as OAT and dex files. I will focus on the runtime’s upcoming new internal file named “Compact Dex” and what it means for the end user.
Compact Dex is very similar to the standard dex file that is generated when compiling a program using Android Studio’s standard dex compiler. What makes Compact Dex special is the fact that it was specifically created to improve interpreter performance, improve RAM usage, and reduce the storage cost associated with the common dex file on low-end devices.
As of Android Nougat 7.0, ART uses a “Mixed Mode” Compilation runtime environment. When you install an app and start it for the first time, it’s interpreted. Interpretation means that the runtime executes the dex code directly with little in the way of optimizations. This is slow. The expectation is that once the dex file is loaded into memory, and the runtime executes the bytecode directly, it will encounter “Hotspots” or code that is frequently executed. Code that is executed frequently is then marked by the runtime as “Hot,” and the Just-In-Time (JIT) Compiler compiles the hot code into binary code. Binary code is then executed directly by the CPU. Which is fast.
Compact Dex increases the performance of the first stage of compilation, which is interpretation. Since interpretation is incredibly slow, the runtime now optimizes and removes unnecessary code from the dex file right after dex2oat selectively compiles the code ahead of time during the maintenance window (when your phone is idle and charging).
Dex2oat uses a subset of dex optimizations that generate smaller dex instructions when generating compact dex. These smaller dex instructions are then passed to the runtime itself for interpretation or compilation if needed.
Interpretation has always been a weak point for ART because of its involvement in the first stages of the launch of an application, and also when executing the less frequently used portions of code in an app. If the interpreter is unable to execute the dex bytecode fast enough, the application you are using may show UI frame drops, increased battery drain, and much higher RAM usage.
What this means for the end user is that the application that you installed on your phone, even after it’s been compiled (Ahead of time and Just in time) will now take up less space on storage, will launch faster, and will take up less memory than before.
Source: Android Source Gerrit
