Every smartphone user who looks into the section About the phone or goes deeper into the developer settings, sooner or later comes across an abbreviation ART. For many, it's just a bunch of letters on a long list of technical specs, but it's actually the heart of your device's software ecosystem. It is this technology that is responsible for how applications launch, how quickly they respond to touches, and how efficiently battery power is used.
In simple terms, Android Runtime is a runtime environment that allows applications written in Java or Kotlin to run on your Android smartphone. Without it, not a single app would be able to “communicate” with the processor and operating system. Understanding the principles of ART's operation helps you make an informed choice of gadgets and understand why older models can work slower than new ones, even with the same amount of RAM.
Android Runtime replaced the outdated Dalvik virtual machine, radically changing the approach to code processing. This is not just an update, but a fundamental shift in the architecture of the mobile OS, which allowed us to achieve the smooth interface that we are accustomed to today. In this article, we will analyze in detail the internal structure of this technology, its evolution and hidden capabilities available to advanced users.
The evolution of virtual machines: from Dalvik to modern ART
The history of Android development is inextricably linked with the evolution of code execution methods. Initially, Google used a virtual machine Dalvikthat worked on the JIT (Just-In-Time) principle. This meant that the application code was compiled into machine instructions the moment it was launched. This approach had its advantages in the form of quick installation of applications, but created a huge load on the processor while the app was running.
With the release of Android 5.0 Lollipop, Google introduced a new runtime environment - ART (Android Runtime). The main difference was the transition to an AOT (Ahead-Of-Time) model. Now compilation took place in advance, at the time of installation of the application. This required more installation time and took up more memory space, but significantly speeded up the launch of apps and reduced the load on the processor during operation.
⚠️ Attention: Although the AOT model is the main one, modern versions of ART use a hybrid approach. Some code is compiled in advance and some is compiled at runtime to optimize memory usage. Completely disabling JIT compilation in new versions of Android is impossible and impractical.
The transition to ART has become one of the most significant events in the history of the platform. It allowed developers to create more complex and resource-intensive applications without fear that they would slow down on mid-range devices. In addition, the new architecture has improved the performance of the garbage collector (Garbage Collector), which has reduced the number of micro-freezes of the interface, known as “lags”.
The principle of operation and architecture of Android Runtime
The basis of the work ART is the conversion of bytecode, which is created by the Java or Kotlin language compiler, into native machine code that your smartphone's processor can understand. This process occurs through several stages, including optimization and linking. The key component here is the compiler dex2oatwhich does the hard work of preparing the application to run.
When you install an application, the system creates an optimized file with the extension .oat (OAT file). It is a ready-to-execute binary file that loads into memory much faster than interpreted bytecode. As a result, when you click on a app icon, the system does not need to spend precious milliseconds translating instructions - it immediately transfers control to the processor.
However, the architecture Android Runtime is not static. Starting with Android 7.0 Nougat, profiling compilation was introduced. The system tracks which parts of the code are used most often and recompiles only those into highly optimized machine code. The remaining, rarely used areas can be executed through an interpreter or less optimized code, which saves storage space.
- 🚀 Fast launch: Applications open almost instantly thanks to pre-compilation.
- 🔋 Energy efficiency: Reducing the load on the CPU while apps are running extends battery life.
- 🛡️ Security: ART includes improved mechanisms for code verification and process isolation.
- 🗑️ Improved Garbage Collector: Garbage collection occurs in parallel with the application, reducing pauses.
It is important to note that ART is fully compatible with the Java ecosystem, but at the same time provides its own low-level interfaces for interacting with the system. This allows you to achieve high performance even on devices with limited hardware resources, which is critical for the budget segment of the market.
If your device is running slowly after a major system update, let it charge for 1-2 hours with the screen off. At this time, ART performs background optimization of all installed applications.
Performance comparison: ART vs Dalvik
To understand the scale of the changes, it is necessary to conduct a direct comparison of the two technologies. The table below outlines the key differences that define the user experience. The differences concern not only speed, but also resource consumption, which directly affects the choice of device.
| Characteristics | Dalvik (JIT) | ART (AOT + JIT) |
|---|---|---|
| Compilation | At runtime (Just-In-Time) | When installing + during operation (Ahead-Of-Time) |
| Application launch speed | Slower (compilation required) | Faster (code already ready) |
| CPU load | High while applications are running | High when installation, low during operation |
| Space occupied | Less | More (up to 20% due to optimized files) |
| Battery life | Lower (constant compilation) | Higher (optimized execution) |
As can be seen from the comparison, Android Runtime wins in most use cases. The only drawback in the early stages of implementation was considered to be an increase in application installation time and memory footprint. However, with the growth of built-in storage capacity and the acceleration of flash memory, this factor has become unimportant for most users.
Modern ART implementations are so efficient that the difference in performance between high-end and mid-range devices is often due not to the runtime itself, but to memory speed and processor frequency. However, without the transition to AOT compilation, modern heavy games and multitasking interfaces simply could not exist in their current form.
Managing ART settings through developer mode
For advanced users and developers, the Android system provides access to hidden runtime settings. These options are located in the For developersmenu, which is hidden by default. To activate it, you need to click seven times on the build number in the section About phone.
In this menu you can find an item Background process limit or settings related to ART logging and debugging. However, the most interesting thing for enthusiasts is the ability to select a compilation profile via ADB (Android Debug Bridge). This allows you to force recompile applications with different levels of optimization, which sometimes helps solve problems with unstable operation of specific software.
adb shell pm compile -m speed -f com.example.appThis command forces the system to recompile the specified application in maximum speed mode (speed). There is also a mode that prioritizes saving space, and a golden mean. Using such commands requires caution, as incorrect optimization can lead to an increase in the size of the application without a real performance increase. space, which prioritizes saving space, and balanced - the golden mean. Use of such commands requires caution, as improper optimization can result in an increase in application size without any real performance gains.
☑️ Preparing to experiment with ART settings
⚠️ Attention: Changing compilation parameters via ADB can lead to unstable system operation or increased battery consumption. Use these tools only if you understand the consequences and know how to return the default settings.
Also in the developer settings you can enable the display of processes on the screen, which allows you to see in real time how ART manages execution threads. This is a useful tool for diagnosing "brakes" and identifying applications that consume a disproportionate amount of processor resources.
The impact of ART on battery life
One of the most common questions from users concerns the impact of the runtime environment on the battery. Since ART transfers the main compilation load to the installation time, in normal operation the smartphone spends less energy processing application code. This is especially noticeable in scenarios where the user frequently switches between heavy apps.
However, background optimization processes can consume energy. When the system decides to recompile “hot” code sections (profiling), the processor is loaded. This usually happens when the device is connected to charging and is idle, so as not to disturb the user. If you notice a rapid drain immediately after a system update, ART is most likely carrying out a massive optimization of all applications.
Developers are constantly working on ART task scheduler algorithms to minimize this impact. The latest versions of Android use an adaptive battery that learns to predict which applications you will use and optimizes them, ignoring software that is rarely launched. This creates a balance between performance and power consumption.
The main energy consumption of the ART environment occurs during application installation and in the first hours after a system update. In normal operation, ART saves battery power compared to legacy code execution methods.
It is also worth considering that poorly written applications can create excessive load on the garbage collector, regardless of the version of ART. In such cases, the runtime environment is powerless, and the problem lies in the code of the app itself, which requires constant memory allocations and deallocations.
Compatibility issues and future prospects
Despite the maturity of the technology, users sometimes encounter compatibility problems. Old applications written with Dalvik behavior in mind may not work correctly in the ARTenvironment. Most often this is expressed in crashes immediately after launch or strange behavior of the interface. Fortunately, there are fewer and fewer such applications every year.
Google continues to develop the project, introducing support for new languages and standards. One promising technology is Project Mainline, which allows you to update ART components through the Google Play Store, bypassing full firmware updates. This means that performance and security improvements can arrive on your smartphone more often and faster.
⚠️ Attention: If an app crashes right after launch on modern Android, try clearing its cache and data. In rare cases, reinstallation helps, which will start the recompilation process for the current version of ART from scratch.
In the future, even deeper implementation of machine learning in the compilation process is expected. The system will be able to predict user behavior and prepare in advance the code for those applications that you are likely to launch in the next morning. This will make the smartphone experience even smoother and more predictable.
What are PGO profiles?
Profile Guided Optimization (PGO) is a technique in which the compiler uses data about the actual usage of a app to create more efficient machine code. In Android, this allows you to reduce the size of executable files and speed up their operation.
Frequently asked questions (FAQ)
Is it possible to disable ART and return Dalvik?
On modern versions of Android (starting from 5.0 and especially 7.0+), this cannot be done using standard tools. Dalvik has been completely removed from the system as a deprecated component. Attempts to replace libraries manually through root access will lead to system inoperability (bootloop).
Why does installing applications take so long?
During installation ART carries out code optimization (AOT compilation). On older or slow devices this process may be noticeable. This is normal behavior that ensures fast operation of the application in the future.
Does the ART version affect the operation of emulators?
Yes, Android emulators on PC also use ART (or its analogues for x86 architecture). The performance of the emulator directly depends on the efficiency of code translation, so enabling hardware virtualization in the BIOS is critical.
What to do if after the update the phone starts to get warm?
Most likely, the environment is optimizing applications in the background Android Runtime. Let the phone charge with the screen off for several hours. If the problem persists after 1-2 days, there may be an application that is not compatible with the new OS version.
Does ART take up a lot of memory space?
Optimized files (.oat) do take up more space than the original dex files. On average, this increase is 10-20% of the application size. On modern drives with a capacity of 64 GB or more, this difference is almost invisible to the user.