JIT vs AOT Compilation | Android Runtime

 

    

    Did you ever think, what happens when you install your app in your Android device, it shows INSTALLING for fraction of second and app get opens. What happens exactly behiend the scene? Found Interesting????

Cool !!! let’s clear all the doubt in this blog. You would have definetely read the buzz words JIT(Just-in-time) and AOT(Ahead of time) at many ocassions. We’ll dig it down in details in this article, stay tuned….

Android apps run on Android Runtime (ART), which replaced Dalvik since Android 5.0 (Lollipop). ART supports both JIT (Just-In-Time) Compilation and AOT (Ahead-Of-Time) Compilation to improve performance and efficiency.

JIT (Just-In-Time) Compilation

How it Works:

  • Compiles bytecode into native machine code at runtime (when the app is executed).
  • Stores frequently used methods in memory to speed up subsequent executions.

Advantages:

  • Faster app installation because it doesn’t require full compilation beforehand.
  • Reduces storage usage as apps are stored in a compact format and compiled dynamically.
  • Adaptive optimization: The runtime optimizes frequently used methods over time.

Disadvantages:

  • Higher CPU and battery usage due to on-the-fly compilation.
  • Increased memory usage because compiled code must be stored temporarily.

AOT (Ahead-Of-Time) Compilation

How it Works:

  • Compiles the entire app before execution during installation, converting bytecode into native machine code.

Advantages:

  • Faster app startup time since code is already compiled.
  • Lower CPU and battery usage at runtime, improving efficiency.
  • Better performance for compute-heavy apps.

Disadvantages:

  • Longer installation time because the app is compiled during installation.
  • Increases storage space usage since compiled binaries are stored on disk.

Now you would have thinking, which one from both explained above is used by Android App, I would say, BOTH.

Android Runtime (ART) — Hybrid Approach

Modern Android versions use a hybrid approach, combining both JIT and AOT:

  1. JIT during runtime for faster optimizations.
  2. AOT compilation using Profile-Guided Optimizations (PGO): ART captures frequently used methods and compiles them AOT for future launches.

This approach balances fast installations, efficient memory usage, and improved runtime performance.

Hybrid Approach in Modern Android (JIT + AOT with Profile-Guided Optimization)

ART profiles app usage to determine which parts of the code should be compiled AOT for better efficiency.

Profile-Guided Optimization (PGO) in Action

Step 1: First Launch (JIT Mode)

  • The app is installed, and all methods run in interpreter mode.
  • Frequently used methods (hot code paths) are JIT-compiled.

Step 2: Profile Generation

  • ART records which methods are used most and stores this data in a profile (/data/misc/profiles).

Step 3: Background AOT Compilation

  • During idle time, ART compiles frequently used methods AOT for future launches.

Checking ART Compilation with ADB

You can check ART compilation by running:

adb shell cmd package compile -m speed -f com.yourapp.package

🔹 Result:

  • The first app launch is slightly slower due to JIT compilation.
  • Future launches are much faster due to AOT optimization.

Comparing JIT vs AOT with a Real-World Scenario

Scenario: Loading a Large RecyclerView in an Android App

Imagine an Android app that loads 1000+ items in a RecyclerView.

  • With JIT:
  • The first time onBindViewHolder() is called, it is interpreted.
  • After a few calls, JIT compiles it, improving performance gradually.
  • With AOT:
  • onBindViewHolder() is already compiled at installation.
  • No runtime overhead, resulting in faster list loading from the start.

✅ Conclusion:

  • JIT is good for adaptive performance (e.g., apps that frequently change or load dynamic content).
  • AOT is better for consistent performance (e.g., apps with heavy computation).
  • Hybrid (JIT + AOT) is the best for balancing performance and installation time.

Controlling JIT/AOT in gradle.properties

You can force ART optimizations during app builds using gradle properties.

Example: Enable JIT for Debug Builds

android.useJIT=true

Example: Force AOT Compilation for Release Builds

android.compileMode=speed

🔹 Use Case:

  • Enable JIT for faster iteration in development.
  • Use AOT for production to optimize performance.

Using ART Profile-Guided Compilation (PGO)

How to Use PGO for Better AOT Optimization?

  1. Run your app in Debug Mode to generate a profile:
adb shell kill -SIGUSR1 $(pidof your.app.package)

Extract the profile:

adb pull /data/misc/profiles/cur/0/com.yourapp.package/primary.prof
  1. Bundle this profile into your APK (androidTest module).
  2. When the app is installed, ART will optimize based on this profile.

🔹 Use Case:

  • Improves cold start time by pre-compiling frequently used methods.

Hope, I could have explained the things clearly, still have queries, feel free post a comment or write me on vikasacsoni9211@gmail.com. 

Happy Coding :)

Comments

Post a Comment

Popular posts from this blog

Optimize Jetpack Compose: Performance & Best Practices

Image
      Jetpack Compose offers a declarative approach to building UIs in Android. However, like any UI framework, optimization is key to achieving smooth performance and a great user experience. This detailed guide expands on the provided checklist, offering in-depth explanations and practical code examples for each optimization technique. I. Core Principles: Laying the Foundation for Performance Use Stable Types:  Compose relies on stable types to efficiently track changes and minimize recompositions. A stable type guarantees that if two instances of the type are equal according to  equals() , they will always be equal. Using unstable types can force unnecessary recompositions.   // Stable data class (recommended) data   class   User ( val  name: String,  val  age:  Int ) // Unstable list (avoid directly in Compose state) // Use SnapshotStateList instead val users = remember { mutableStateListOf<User>() } // Cor...
Read more

From ‘Master’ to ‘Main’: The Meaning Behind Git’s Naming Shift

Image
                             Git changed its default branch name from master to main due to concerns about inclusivity and to remove references to terms with problematic historical connotations. The term master has been associated with slavery, and many tech communities sought to use more neutral and inclusive language. Reason for the Change: Inclusivity & Sensitivity- Many organizations aimed to remove racially charged terminology from software development. Consistency Across Communities- Other projects and platforms, such as Github, Gitlab, and software frameworks, also made similar changes. Modern Naming Conventions- main is a cleaner and more intuitive name, as it represents the primary branch of a repository. Interesting Facts —  It wasn’t originally about slavery  — The term Git did not originate from the master/slave concept used in computing. It likely came from Bitkeeper , a version contro...
Read more