As you’re aware that most Custom ROM installation asks you to wipe dalvik cache, but do you know what dalvik cache is? Well, one of the best functions of Android has to be the Dalvik cache. The Dalvik virtual machine was designed specifically for the Android mobile platform. The target systems have little RAM, store data on slow internal flash memory, and generally have the performance characteristics of decade-old desktop systems. They also run Linux, which provides virtual memory, processes and threads, and UID-based security mechanisms.
Dalvik cache is a wonder from the point your Android starts up, runs, hibernates and all the way till you device shuts down. Dalvik cache collects the information about the installed applications and frameworks, and organizes them into a writeable cache. Under this writeable cache, it stores the “optimized” bytecode of the applications which is used by the applications themselves later for a smoother operation. This dalvik cache can grow immensely huge as more applications are installed on your phone. It is safe to wipe dalvik-cache. It will be rebuilt again when the phone boots.
This also explains why your phone takes ages to start up for the first time. As for my Nexus One, having about 145 applications installed, it takes about 13 minutes to build the cache.
If you ever extract an APK installer file, you will always find a file named classes.dex. This is the file Dalvik finds to build the cache. What makes the process slow? APK is an archive (which is why you can open it up with an unarchiver such as WinRAR or 7-Zip). Being an archive, it provides limited write access to the files contained within and the fact that archives are compressed. Not to forget, APKs are encrypted archives too. Therefore, DalvikVM has to extract the classes.dex files and build the Dalvik table accordingly which makes it easier to write data on it too. With this collective set of data, the Android OS no longer needs to index the applications and find their classes.dex when the phone is already running. Instead, it will just look into one place, and will know what to do next. Nifty huh?
The features and limitations caused us to focus on certain goals:
- Class data, notably bytecode, must be shared between multiple processes to minimize total system memory usage.
- The overhead in launching a new app must be minimized to keep the device responsive.
- Storing class data in individual files results in a lot of redundancy, especially with respect to strings. To conserve disk space we need to factor this out.
- Parsing class data fields adds unnecessary overhead during class loading. Accessing data values (e.g. integers and strings) directly as C types is better.
- Bytecode verification is necessary, but slow, so we want to verify as much as possible outside app execution.
- Bytecode optimization (quickened instructions, method pruning) is important for speed and battery life.
- For security reasons, processes may not edit shared code.
The goals led us to make some fundamental decisions:
- Multiple classes are aggregated into a single “DEX” file.
- DEX files are mapped read-only and shared between processes.
- Byte ordering and word alignment are adjusted to suit the local system.
- Bytecode verification is mandatory for all classes, but we want to “pre-verify” whatever we can.
- Optimizations that require rewriting bytecode must be done ahead of time.
