Dalvik, ART, JIT, and AOT in Android

I am Amit Shekhar, Co-Founder @ Outcome School, I have taught and mentored many developers, and their efforts landed them high-paying tech jobs, helped many tech companies in solving their unique problems, and created many open-source libraries being used by top companies. I am passionate about sharing knowledge through open-source, blogs, and videos.

Join Outcome School and get high paying tech job: Outcome School

Before we start, I would like to mention that, I have released a video playlist to help you crack the Android Interview: Check out Android Interview Questions and Answers.

In this blog, we will learn about the terms Dalvik, ART, JIT, and AOT in Android.

We, Android Developers keep hearing these terms when we talk about optimization, and performance but have little or no idea about them.

• Dalvik
• ART
• JIT
• AOT

Do not worry, today we will learn about each of them in detail.

These terms are related to Android Runtime, so first we must understand what is Android Runtime.

What is Android Runtime?

We write code in Kotlin/Java, and when we build the APK, it gets converted to bytecode.

In our APK, we will have the .dex files that contain bytecode.

Our Android devices can't run the bytecode directly, so it needs to be translated to the machine code. This translation is done by Android Runtime.

Kotlin/Java > bytecode(.dex files in APK) > machine code

So, now that we know what is Android Runtime, it's time to learn about the different types of Android Runtime and their evolution.

• Dalvik
• ART

Let's first learn about the Dalvik.

Dalvik

Dalvik, our first Android Runtime is based on the JIT compilation.

JIT compilation means Just In Time compilation.

As the .dex contain the bytecode, it needs to be translated to the machine code to be run.

In Dalvik Android Runtime, as it is JIT based, it gets translated when we run the app. As we keep on using the app, only that part of the bytecode gets converted to the machine code. Also, the most frequently used code gets cached so that we don't have to translate them again.

This process is repeated every single time when we open the app using the CPU cycles and hence impacting the battery life.

Disadvantage: Low performance and decreases battery performance.

The performance of the application was not up to the mark as the translation was happening during the application run and it happens every time when we run the app.

So, we needed a solution to make the apps more performant.

In Android L, we were introduced to the new Android Runtime: ART.

Till now, we have learned about the Dalvik and JIT, now it's time to learn about the ART and AOT.

ART

ART, our next Android Runtime is based on the AOT compilation.

AOT compilation means Ahead of Time compilation.

Again, as the .dex contain the bytecode, it needs to be translated to the machine code to be run.

In ART Android Runtime, as it is AOT based, it gets translated before we run the app. It gets translated at the time of app installation only. Basically, when we install the app, it translates the bytecode into the machine code and stores it on the disk.

So, by ART, the problem related to the low performance of Dalvik got solved. Now we have a high-performance application because there is no need for translation during the app run.

Advantage: High Performance

But, we should also talk about the disadvantages.

One disadvantage is more installation time as it translates the bytecode to the machine code at the time of app installation only.

Another disadvantage of ART is that it needs more space as it translates the bytecode into machine code and stores it on the disk. The pre-compiled binary occupies more space than the DEX bytecode. So, it takes more space as compared to the Dalvik runtime.

The last disadvantage is that the boot time is more as compared to the Dalvik as the cache is built during the boot. You might see an "Optimizing apps" dialog box while booting your Android devices.

Disadvantages:

• More install time
• More space on the disk
• More boot time

Time to talk about the solution to these above-mentioned problems.

Before that let's see the difference between Dalvik and ART in a tabular form.

Difference between Dalvik and ART

Now, let's get back to the discussion regarding the solution.

And we all know that users use 20% of the Apps present on their devices 80% of the time. And also, 20% part of an application is used 80% of the time. So, it is unnecessary to keep the translation of the complete bytecode of all the apps. It's a complete waste of space and time.

We could have a better solution.

In Android N, Just In Time compilation was introduced back with the profile-guided compilation.

Profile-guided compilation

In profile-guided compilation, the translation is done using the Just In Time compilation which means when we are using the app. Then, as it learns which part of the apps or which apps are being very frequently used, it caches the translated code for that part only and stores it on disk.

This profile-guided compilation is hybrid ART with both JIT and AOT.

In the initial few runs, the apps run slowly, but with the subsequent run, it becomes faster as it has learned more about the usage and has cached the translated code based on the usage.

Advantages:

• Less install time
• Less space on the disk
• Less boot time
• Improved performance but only after the first few application usages.

Disadvantages:

• Low performance in the initial few runs of the application.

Now, that we have solved most of the issues, now we are left with only one issue which is "Low performance in the initial few runs of the application".

We just need to solve this, and we will win.

The solution: ART Cloud Profiles that was introduced in Android P.

ART Cloud Profiles

As we know that most of the apps are used in a similar pattern by most users, Google collects this usage pattern data about all the apps present on the Play Store. They aggregate the data and call it as "Code Profile".

This Code Profile has information about which part of the app is frequently run by most users.

If we install an app, the Code Profile also gets downloaded along with the APK.

ART uses it to translate the code that is frequently run by most users. It does it during the installation that is before the app run.

And we start getting improved performance from the initial run of the application.

Now that almost all problems have been solved, we are left with only one issue: "Low performance during the initial runs of the application for the initial few new users."

This is because the initial few new users will not have the Code Profile Data.

The solution: Baseline Profiles.

Baseline Profiles

In this process, we create baseline profile data before the app release and upload it along with the APK, making this data available for the initial new users as well.

Previously: Upload APK/AAB

Now: Upload APK/AAB + Baseline Profiles

Now, the Android Runtime (ART) can optimize specified code paths through Ahead-of-Time (AOT) compilation, providing performance enhancements for every new user.

All problems got solved.

Prepare yourself for Android Interview: Android Interview Questions

That's it for now.

Thanks

Amit Shekhar
Co-Founder @ Outcome School

You can connect with me on:

• Twitter
• LinkedIn
• YouTube
• GitHub

Follow Outcome School on:

• Twitter
• LinkedIn
• YouTube
• GitHub

Read all of our high-quality blogs here.