Dedicated Runtime Thread (ART vs Dalvik)
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)
Really nice..!!! good to have such informational blog.
ReplyDeleteHire Dedicated Resources