ART cache Android guide slow vs fast performance

Understanding ART Cache on Android: A Practical Guide (2026)

Published: May 19, 2026

People hand me their phones and say, “Bro, my phone is slow. I cleared cache, deleted photos, still not working.”

I just smile. They think browser cache will fix everything. No, man.

But is the reality The real problem hides inside /data/dalvik-cache. And this folder is the heart of Android. When it gets corrupted, your phone stutters, apps open slow, the screen freezes.
Look, let me tell you a story.

A friend of mine used a OnePlus 7T. Good phone. Then he got the OxygenOS 12 update. After that, his phone ran at 15 frames per second. You know what that means? Choppy as hell. He wiped app cache twice. Nothing changed.

I took his phone. Booted into recovery. Wiped all the cache partition. Then left the phone on full charge overnight. By morning, the phone was completely fresh. The rebuild took only ninety minutes.

You are probably thinking — why ninety minutes?

Here is the math. Your phone has 200 to 400 apps. Each app converts its DEX bytecode into native machine code. The tool that does this is called dex2oat. An average phone processes 2 to 3 MB per minute. Each app’s compiled output is 5 to 15 MB. Do the math yourself. Ninety minutes is actually efficient. Your phone is working hard to make itself fast again — for other common issues, the troubleshooting guide has practical fixes too.

Now you want to know what lives inside Dalvik Cache.

Let me explain in simple terms.

When you install any app, Android runs a tool called dex2oat. The full name is Dalvik EXecutable to Optimized ART. This tool converts DEX bytecode into native machine code. Native machine code means code your phone’s processor understands directly. No translation needed. The output files have extensions like .odex, .vdex, and .art. They all live inside /data/dalvik-cache.

See, if these files are missing, Android falls back to JIT compilation every time you open an app. JIT means Just In Time. Here is what happens. The app opens, code compiles, app closes, everything is forgotten. Then you open again, compile again. This eats processor power, drains battery, and heats up your phone.

When all three happen together? Your phone feels terrible. Simple.

How the cache gets corrupted

First way. Atomic write failure. Your phone is updating, the battery dies in the middle. The system was doing a rename or fsync system call. A partial file remains. The header looks fine but the instructions inside are garbage. When ART tries to read it, you get an error and the app crashes. I have seen this maybe twenty times.

Second way. OTA update with stale bootclasspath. Old .art files reference symbols that the update removed. When Android tries to load those references, you get a NoSuchMethodError. The app crashes repeatedly. I have seen this often after Android 13 to 14 updates. Very common.

Third way is this. Low storage. When you have less than 500MB free, dexopt fails with an ENOSPC error. Android cannot allocate temporary compilation files. Then it just stops optimization completely. Your phone stays slow forever until you free up space.

Fourth way is this. Aggressive cleaner apps. Apps like Clean Master or Norton Clean remove ART files without telling Android. When you reboot, the system finds a half finished optimization state and goes into safe mode. That means no optimization happens at all. Those apps are garbage anyway. remove them.

Do not think clearing cache is hard. It is very easy. Three methods.

Recovery cache wipe.

Turn off your phone. Press volume up and power to enter recovery. Select wipe cache partition. What happens here? Android deletes everything inside the /cache folder. On the next boot, the ART runtime scans /data/dalvik-cache. For each file, it checks whether the app or system component still matches. If a file is missing or the timestamp does not match, dexopt runs again.

But one problem exists. The system mainly does not verify every byte. It only checks timestamps and signatures. If a corrupted file has a valid timestamp, it can survive. That is why recovery wipe sometimes does not work. I have mostly seen this happen.

If your phone does not rebuild after a recovery wipe, run this command via ADB:

adb shell cmd package bg-dexopt-job

This forces IdleMaintenanceService to run immediately. Otherwise it waits for the phone to charge and the screen to turn off. You do not want to wait.

Method two. Force rebuild via ADB.

This method best works on most every Android phone. Just enable USB debugging. Go to Developer Options. Tap build number seven times. Enable USB debugging. Install platform tools on your PC. Then run this command:

adb shell cmd package compile -a -f –compile-filter=speed

Here is what each part does. -a means all apps. -f forces recompilation even if files look up to date. –compile-filter=speed uses the highest optimization level.

This takes 20 to 60 minutes. During this time, CPU runs at 100 percent. Your phone also will get warm. That is normal. Do not panic.

Overnight charge.

This is the safest method. Wipe the cache. Then leave your phone on charge overnight. Screen off. Battery above 50 percent. Android will run IdleMaintenanceService by itself. Everything rebuilds by morning. It takes 4 to 8 hours. Good if you are not in a hurry.

How do you know your ART cache is healthy?

Run two ADB commands:

adb shell cmd package list packages | wc -l

adb shell ls /data/dalvik-cache | wc -l

The second number should be roughly three times the first number. Because many app makes three files. If the numbers are far off, your cache is definitely incomplete. Simple check.

Another quick test. Open five heavy apps. Instagram, Chrome, YouTube, Camera, WhatsApp. If you have a phone from 2022 or newer and each app opens in under 1.5 seconds, your ART cache is healthy. If an app takes more than 3 seconds to open, consider rebuilding it. I use this test all the time.

Also know when NOT to rebuild.

If your phone is working fine, do not do it. You will waste battery and storage writes. Simple.

If you have less than 800MB free space, do not do it. Dexopt needs room for temporary files. Free up space first.

If a system update is coming, do not do it. Let the OTA handle its own optimization. Do not interfere.

If your battery is below 30 percent, do not do it. The rebuild might drain it completely before finishing. Then you have a dead phone and half done rebuild. Bad situation.

Rebuild your ART cache if your phone became slow after an update. Rebuild if apps crash randomly with no error message. Rebuild if you used any cleaner app in the last six months. Rebuild if your benchmark scores dropped by more than twenty percent for no reason.

Skip it if everything runs fine. Do not fix what is not broken. Skip if you have an old phone with eMMC storage because heavy writes reduce lifespan. Skip if you are in a hurry. Wait for a better time.

I have done this on more than 40 phones. Samsung, Xiaomi, Realme, Pixel. On most phones I tested, the rebuild noticeably improved app loading and reduced random lag. People told me they tried everything. I told them they only cleard browser cache. The real work is in dalvik cache.

Niaz Ali Samon
Latest posts by Niaz Ali Samon (see all)
error: