Okay guys,
with the introduction of 4.4 kitkat, Google decided to include ART as an optional second runtime that can be enabled through developer options. Naturally when promised faster app launch times, people will turn it on. ART is not stable however and so problems will be occur. For this reason, in hopes to prevent kernel developers, rom developers, and android developers from having their thread hijacked, I am making a thread dedicated to runtimes here. DO NOT POST ABOUT THIS TO DEVELOPERS ON THEIR THREADS, bugs when you are running ART are not their fault.
What is Dalvik?
Dalvik is the process virtual machine (VM) in Google's Android operating system. It is the software that runs the apps on Android devices. Dalvik is thus an integral part of Android, which is typically used on mobile devices such as mobile phones and tablet computers as well as more recently on embedded devices such as smart TVs and media streamers. Programs are commonly written in Java and compiled to bytecode. They are then converted from Java Virtual Machine-compatible .class files to Dalvik-compatible .dex (Dalvik Executable) files before installation on a device. The compact Dalvik Executable format is designed to be suitable for systems that are constrained in terms of memory and processor speed. Dalvik is open-source software.
Dalvik is named after an Icelandic city.
(source)
Okay so what is ART?
ART is a project Google has been working on for reportedly for 2 years. The goal of ART was to produce a faster runtime that wouldn't suffer from the problems Dalvik suffers. Android Kit Kat 4.4 is the first operating system with ART included in developers options although it is unclear just how recent this version is.
ART stands for Android RunTime
(source)
Great, Whats the Difference Then?
The main difference between ART and Dalvik is when they compile app code. Dalvik operates under a JIT (Just In Time) compilation method which means that when developers make their apps, they partially compile their code into bytecode which is interpreted by the java virtual machine. Dalvik converts bytecode to machinecode as the app runs to increase performance (bytecode execution is slower than machinecode execution). ART differs from Dalvik by performing this compilation of bytecode to machine code at installation of the app and saves this to the phones storage (not ram).
(source)
So Why Use ART?
Using ART instead of Dalvik allows the system to use much less resources during runtime. When apps are running, interpretation of bytecode is not ongoing, this can reduce CPU load and RAM usage. The resulting effect is faster app startup times (reportedly almost twice as fast) and better in app performance.
It should be noted that performance boosts will only really improve for the java components of apps. Apps like games which rely on the NDK or other languages will receive more incremental experience boosts.
(source)
Why Shouldn't I Use ART
Well first and foremost, Google's documentation of ART suggests not using ART because it can cause app instabilities and an unstable android implementation all together. It is still largely in development and it is unknown just how recent the version included in the current kit kat build is. Google is introducing it to the development community but really doesn't intend users to use it as a daily runtime.
Also since ART precompiles and saves that precompiled code upon installation of apps, it takes up more storage. The increase is about 10-20% of the code in the application. Remember the majority of apps usually comprises media files such as images, videos, sounds... so those components will be unaffected. For example, the Google+ apk is about 28Mb yet the code is only comprise of 7Mb. The increase in storage size is nominal, but worth noting.
Also the first start up after enabling ART can take up to 10 minutes due to this compilation occurring. Installation of apps will also take slightly longer but with hardware on the Nexus 5 you are unlikely to even notice.
ART also can cause issues with app backup and restoration.
(source) (source)
Custom Roms and ART
As developers start building Kit Kat roms from source they will have to decide if they would like to include ART in their builds. Google has created a flag to include ART in addition to Dalvik. This is a simple implementation, but if threads keep getting hijacked by discussions of ART and bugs, I wouldn't be surprised if developers choose to exclude ART from their builds.
ART also cannot function with deodexed apps. The odex files are necessary for bytecode to machine code compilation. Flashing a deodexed ROM or gaps with ART enabled will produce force closes and crashes to the point the UI won't be functional.
Also initial setup between Roms will take longer with ART since performing a factory reset as well as clearing caches will clear the stored precompiled code that ART saves. Dalvik will always be enabled at start up, so switching to ART will require a reboot and a wait for set up.
(source)
In my synopsis of ART and Dalvik I may have made a mistake or two or not explained something properly. If you spot a mistake or would like clarification, simply post and I will modify the OP.
Please, please, please send people to this thread if they are asking about runtimes in a developers thread. Having had my kernel thread hijacked by unrelated issues that are outside of my control, I understand the pain.
with the introduction of 4.4 kitkat, Google decided to include ART as an optional second runtime that can be enabled through developer options. Naturally when promised faster app launch times, people will turn it on. ART is not stable however and so problems will be occur. For this reason, in hopes to prevent kernel developers, rom developers, and android developers from having their thread hijacked, I am making a thread dedicated to runtimes here. DO NOT POST ABOUT THIS TO DEVELOPERS ON THEIR THREADS, bugs when you are running ART are not their fault.
What is Dalvik?
Dalvik is the process virtual machine (VM) in Google's Android operating system. It is the software that runs the apps on Android devices. Dalvik is thus an integral part of Android, which is typically used on mobile devices such as mobile phones and tablet computers as well as more recently on embedded devices such as smart TVs and media streamers. Programs are commonly written in Java and compiled to bytecode. They are then converted from Java Virtual Machine-compatible .class files to Dalvik-compatible .dex (Dalvik Executable) files before installation on a device. The compact Dalvik Executable format is designed to be suitable for systems that are constrained in terms of memory and processor speed. Dalvik is open-source software.
Dalvik is named after an Icelandic city.
(source)
Okay so what is ART?
ART is a project Google has been working on for reportedly for 2 years. The goal of ART was to produce a faster runtime that wouldn't suffer from the problems Dalvik suffers. Android Kit Kat 4.4 is the first operating system with ART included in developers options although it is unclear just how recent this version is.
ART stands for Android RunTime
(source)
Great, Whats the Difference Then?
The main difference between ART and Dalvik is when they compile app code. Dalvik operates under a JIT (Just In Time) compilation method which means that when developers make their apps, they partially compile their code into bytecode which is interpreted by the java virtual machine. Dalvik converts bytecode to machinecode as the app runs to increase performance (bytecode execution is slower than machinecode execution). ART differs from Dalvik by performing this compilation of bytecode to machine code at installation of the app and saves this to the phones storage (not ram).
(source)
So Why Use ART?
Using ART instead of Dalvik allows the system to use much less resources during runtime. When apps are running, interpretation of bytecode is not ongoing, this can reduce CPU load and RAM usage. The resulting effect is faster app startup times (reportedly almost twice as fast) and better in app performance.
It should be noted that performance boosts will only really improve for the java components of apps. Apps like games which rely on the NDK or other languages will receive more incremental experience boosts.
(source)
Why Shouldn't I Use ART
Well first and foremost, Google's documentation of ART suggests not using ART because it can cause app instabilities and an unstable android implementation all together. It is still largely in development and it is unknown just how recent the version included in the current kit kat build is. Google is introducing it to the development community but really doesn't intend users to use it as a daily runtime.
Also since ART precompiles and saves that precompiled code upon installation of apps, it takes up more storage. The increase is about 10-20% of the code in the application. Remember the majority of apps usually comprises media files such as images, videos, sounds... so those components will be unaffected. For example, the Google+ apk is about 28Mb yet the code is only comprise of 7Mb. The increase in storage size is nominal, but worth noting.
Also the first start up after enabling ART can take up to 10 minutes due to this compilation occurring. Installation of apps will also take slightly longer but with hardware on the Nexus 5 you are unlikely to even notice.
ART also can cause issues with app backup and restoration.
(source) (source)
Custom Roms and ART
As developers start building Kit Kat roms from source they will have to decide if they would like to include ART in their builds. Google has created a flag to include ART in addition to Dalvik. This is a simple implementation, but if threads keep getting hijacked by discussions of ART and bugs, I wouldn't be surprised if developers choose to exclude ART from their builds.
ART also cannot function with deodexed apps. The odex files are necessary for bytecode to machine code compilation. Flashing a deodexed ROM or gaps with ART enabled will produce force closes and crashes to the point the UI won't be functional.
Also initial setup between Roms will take longer with ART since performing a factory reset as well as clearing caches will clear the stored precompiled code that ART saves. Dalvik will always be enabled at start up, so switching to ART will require a reboot and a wait for set up.
(source)
In my synopsis of ART and Dalvik I may have made a mistake or two or not explained something properly. If you spot a mistake or would like clarification, simply post and I will modify the OP.
Please, please, please send people to this thread if they are asking about runtimes in a developers thread. Having had my kernel thread hijacked by unrelated issues that are outside of my control, I understand the pain.
Last edited:
