A Closer Look at Android RunTime (ART) in Android L
by Andrei Frumusanu on July 1, 2014 7:12 PM EST
With the latest I/O conference, Google has finally publicly announced its plans for its new runtime on Android. The Android RunTime, ART, is the successor and replacement for Dalvik, the virtual machine on which Android Java code is executed on. We’ve had traces and previews of it available with KitKat devices since last fall, but there wasn’t much information in terms of technical details and the direction Google was heading with it.
Contrary to other mobile platforms such as iOS, Windows or Tizen, which run software compiled natively to their specific hardware architecture, the majority of Android software is based around a generic code language which is transformed from “byte-code” into native instructions for the hardware on the device itself.
Over the years and from the earliest Android versions, Dalvik started as a simple VM with little complexity. With time, however, Google felt the need to address performance concerns and to be able to keep up with hardware advances of the industry. Google eventually added a JIT-compiler to Dalvik with Android’s 2.2 release, added multi-threading capabilities, and generally tried to improve piece by piece.
However, lately over the last few years the ecosystem had been outpacing Dalvik development, so Google sought to build something new to serve as a solid foundation for the future, where it could scale with the performance of today’s and the future’s 8-core devices, large storage capabilities, and large working memories.
Thus ART was born.
Architecture
First, ART is designed to be fully compatible with Dalvik’s existing byte-code format, “dex” (Dalvik executable). As such, from a developer’s perspective, there are no changes at all in terms of having to write applications for one or the other runtime and no need to worry about compatibilities.
The big paradigm-shift that ART brings, is that instead of being a Just-in-Time (JIT) compiler, it now compiles application code Ahead-of-Time (AOT). The runtime goes from having to compile from bytecode to native code each time you run an application, to having it to do it only once, and any subsequent execution from that point forward is done from the existing compiled native code.
Of course, these native translations of the applications take up space, and this new methodology is something that has been made possible today only due to the vast increases in available storage space on today’s devices, a big shift from the early beginnings of Android devices.
This shift opens up a large amount of optimizations which were not possible in the past; because code is optimized and compiled only once, it is worth to optimize it really well that one time. Google claims that it now is able to achieve higher level optimizations over the whole of an applications code-base, as the compiler has an overview of the totality of the code, as opposed to the current JIT compiler which only does optimizations in local/method chunks. Overhead such as exception checks in code are largely removed, and method and interface calls are vastly sped up. The process which does this is the new “dex2oat” component, replacing the “dexopt” Dalvik equivalent. Odex files (optimized dex) also disappear in ART, replaced by ELF files.
Because ART compiles an ELF executable, the kernel is now able to handle page handling of code pages - this results in possibly much better memory management, and less memory usage too. I’m curious what the effect of KSM (Kernel same-page merging) has on ART, it’s definitely something to keep an eye on.
The implications to battery life are also significant - since there is no more interpretation or JIT-work to be done during the runtime of an app, that results in direct savings of CPU cycles, and thus, power consumption.
The only downside to all of this, is that this one-time compilation takes more time to complete. A device’s first boot, and an application’s first start-up will be much increased compared to an equivalent Dalvik system. Google claims that this is not too dramatic, as they expect the finished shipping runtime to be equivalent or even faster than Dalvik in these aspects.
The performance gains over Dalvik are significant, as pictured above; the gains are roughly a 2x improvement in speed for code running on the VM. Google claimed that applications such as Chessbench that represent an almost 3x increase are a more representative projection of real-world gains that can be expected once the final release of Android L is made available.
Facebook
Twitter
RSS
136 Comments
View All Comments
hechacker1 - Tuesday, July 1, 2014 - link
I experienced the same thing with my droid bionic. After flashing it, I think I had to wait 30 minutes before I could even login due to ART compiling apps. I just left my phone on and plugged in and walked away.But the experience after was much better after that long wait. I assume that production firmware would already have that step included in the restore.
highlnder69 - Thursday, July 3, 2014 - link
Where did you get the new firmware for the Droid Bionic that includes ART?bengildenstein - Wednesday, July 2, 2014 - link
I have the 2012 Nexus 7, and while the performance is far from perfect (it is notably slow when app loading and horrendous when anything is accessing the SSD), the latest Chrome Beta has brought nearly flawless performance and (seeming) 60fps scrolling with little, if no jank for all but very heavy sites. In fact, there are a number of apps that I use regularly that scroll flawlessly on this ageing system.There are still apps that run slower than they should, and typically apps load slower than I would like, and many exhibit jank when scrolling (in fact anything with a list of pictures), and I'm hoping that Android L improves these situations (if the 2012 Nexus 7 is updated at all). But of late, I'm pretty happy with the optimizations made. Ever since the recent 4.4.4 update, it seems that the OS is running apps much more smoothly than ever before.
If L improves the performance as you describe, then Android will attain that fluidity and swiftness that iOS and WP have been known for across most apps, which will be very welcome.
Samus - Wednesday, July 2, 2014 - link
If Google can deliver a product as polished as iOS, Apple has a lot more to be worried about that simply making phones with bigger screens.buckschris - Wednesday, July 2, 2014 - link
I agree to an extent. Google is making great strides, and the L release appears to bring some very useful user experience "fixes." The only issue at this time is the color schemes we have seen recently in Google app updates and in the demoed Material Design Gmail app. The colors remind me of the colors from the basic 12-pack of Crayola crayons. They don't quite fit the slick new interface.What has me most excited is four initiatives by Google to take back control over Android. First, is the lack of customization for 3rd parties using Android Wear, Android Auto and Android TV. Second, is the introduction of stock Android phones under the One program. If the initiative takes off, that would be a lot of phones running Google controlled and delivered stock Android. Third, is the as-of-yet unofficial Android Silver program - bringing Google Play Editions to carriers, with the software side apparently also to be controlled and delivered by Google. Putting "Silver" devices running stock Android in direct competition with the manufacturer's skinned phones should and hopefully will force the Samsung's of the world to up their game. Fourth, is an iOS system for introducing new versions of Android. This sneak peak will, hopefully, allow the manufacturers to do their appropriate skinning and get updates out in a much more timely manner.
All told, exciting times for those who appreciate technology and the advances we've seen over the last 15-20 years. I'm not sure what that next BIG product category is. I'm not sold that it's smart watches. What is the elevator speech for a smart watch? It's not an intuitive buy or justification for a lot of folks.
tacitust - Thursday, July 3, 2014 - link
For watches, once they are hard to distinguish from classic analog watches (thin design, top-quality screen tech, decent battery life) then the pitch is "high-tech fashion accessory" which you will be able to buy from Rolex and other expensive watch manufacturers.But if you're talking about wearables as a class (i.e. not necessarily watches) then I think it has to be personal health monitoring. At first, it'll be just basic stuff like heart rate, blood pressure, exercise monitoring, but eventually (years from now) as the medtech improves, it may be able to do things like warn you of an impending heart attack or stroke, or perhaps a vitamin deficiency, etc.
name99 - Wednesday, July 2, 2014 - link
If Google is willing to ship an update that effectively freezes the system on first launch for 30 minutes while providing no UI to explain what is going on, I don't think Apple has much to be worried about...(Apple is not perfect on this score; in particular there are time when OSX shuts down when one has an uncomfortably long period of watching a spinner while the system is doing god knows what. But they at least understand the principle of user feedback, ESPECIALLY during first boot.)
Devo2007 - Wednesday, July 2, 2014 - link
Right now, L is a Developer Preview. Not even really a beta. I'm sure Google understands user feedback is useful, but this is not something really designed for end users.Given discussions about this and other issues in various places though, it seems many people don't understand this concept and are expecting far too much out of the preview.
darwinosx - Thursday, July 3, 2014 - link
Everything Google does is a beta.Alexey291 - Tuesday, July 8, 2014 - link
so even alpha is a beta? kay