By Since its conception, Android apps have largely been run in the Dalvik runtime, which features just-in-time compilation instructions that allow app resources to be compiled and run on the fly.
Starting with Android 4.4 KitKat, Google began testing a new Android Runtime (dubbed ART) that features ahead-of-time compilation which translates all of the app’s bytecode to machine language at the time of the first installation. The benefits of ART are supposed to be faster app performance (no need to compile at each startup) and potentially better battery life (less compilation instructions = less CPU time = less battery drain).
Google introduced it as an experimental feature for developers and to gain early feedback, but we could be close to seeing it enabled as the default runtime in an upcoming version of Android. An Android code commit at Google’s git foretells a change that would make ART the preferred option while still maintaining Dalvik as a secondary option for those finding it hard to say goodbye.
It was always Google’s intention to replace Dalvik, though the earlier years of Android forced their hand in putting up with what is generally seen as a less efficient process. Devices back in the early days had very limited RAM and storage, and less capable CPUs, and the Dalvik runtime’s “only compile what you need” architecture made it perfect for those devices as it kept the memory footprint to a minimum.
But entry-level devices of today don’t go much lower than 512MB of RAM and 4GB of storage, and they use very capable processors compared to the same class of devices just a few years ago. With Google optimizing Android 4.4 KitKat to make it perform great on these entry-level devices, they can finally use this more traditional compilation engine without worry that someone’s phone isn’t up to par.
The jury is still out on ART and its benefits. Some users have reported that ART doesn’t show any glaring performance improvements, and some even profess that battery life savings are minimal in some cases and worse in others.
We can’t take any of that to mean anything this early on, though, as many developers and OEMs are still adapting their apps to work properly with the new runtime. Still, this source commit serves to tell us that Google feels ART is almost ready for prime time, and we’ll have to see if any new changes they’ve made since introducing it in the initial Android 4.4 KitKat release will do anything to significantly impact application and device performance.
[Google via Liliputing]
ART is only here because of the Orcle court mess…that is the only real benefit…
hell with oracle…. its also good that ART is written from scratch… dalvik was getting old
Performance on my Nexus 5 seems slightly better with ART but it’s not that noticeable, however on my old Galaxy Nexus the difference is night and day.
What did you have to do to use it on the GNex? I gave mine to my sister when I got the N5 but if there is a fairly simple way to switch, I can walk her through it. I’m sure she would be happy to have more battery life!
I used the ROM available at http://rootzwiki.com/topic/36706-romaosp12014-shiny-rom-ota-like-stock-android-442-kot49h/
I set it up for my girlfriend who is still on Verizon and was using an even older Droid X still.
Dalvik is not being replaced. Apps will still be delivered as Dalvik bytecode.
What is being done is pre-compiling the app into native code — once — at installation time, instead of every time the program is launched.
On Apple’s platform, code is compiled to native code in the development toolchain. The application is delivered as native code. This means that it is much more difficult for Apple to change processor instruction sets. If Apple suddenly wanted to switch iPhones from ARM chips to, let’s just say, Intel chips, all of the existing apps would need to be recompiled — by their developers. Developers would now have to submit two binaries to the iTunes store, and the store would need to know which version to install on the user’s device.
Android devices already run on multiple processors (ARM and Intel). The Dalvik bytecode is either (1) Interpreted (in original Android versions), of (2) compiled as it is run (present day), or (3) compiled to native code once at Installation time (coming soon).
One minor drawback (compared to today’s Android, but not compared to Apple) is that installed apps will now occupy more storage space. But this is not a huge problem. In Apple’s case, code has always been stored as native code on the device, using more code than a compact representation such as Dalvik would have used.
In addition to the benefits described (saves battery because saves CPU because code is not compiled again and again each time it is launched) there is another benefit. The compiler that runs at App Install time can spend more time and generate a more efficient optimized binary — because the compilation will only happen once.
Whether Dalvik bytecode is compiled to native code at runtime (as today) or at install time (coming soon), either approach has an advantage over Apple’s. If there are variations in ARM (or Intel) processor models, the compiler can take advantage of that. I’m saying that the compiled native code is compiled for your specific model of processor, not just the ARM instruction set in general. For example, suppose on one ARM model, a certain operation is performed by a short series of instructions. On a later model, this operation can be done in a single instruction. The Dalvik to native compiler (whether at runtime, or install time) could recognize which model of processor you have and generate the more optimized single instruction if your hardware supports it.
wow! very impressive post. thank you.
Good explanation but where does the ART substitute/replacement come into this picture? Right now you can manually set ART as mentioned in the post, doesn’t that effectively replace Dalvik then?
Maybe the labels on the two option buttons are poorly chosen. Imagine if they two options were:
1. JIT Compiler
2. ART Compiler
Both compilers compile Dalvik bytecode into native machine code. The only difference is WHEN the compilation is done (quick and dirty compile at runtime, or slow and highly optimized job only once at install time). But both compilers compile Dalvik bytescodes. All apps are and will continue to be delivered as Dalvik bytecodes.
Thanks for all this great info, and for making it easy for us laymen to understand. One random, curiosity question – which do you prefer for your daily driver? iPhone or Android on ART? (or neither?) Like I said, simply curiosity about someone who clearly knows the ins and outs of the software.
In the 1980’s and 1990’s I was a loyal card-carrying Apple fanboy. That was a time when Apple was driven by innovation and was light years ahead of Microsoft and PCs. The pipeline was constantly full of innovations and they just kept coming.
Sometime in the late 1990’s this stopped happening. I became a Linux fanboy. I switched exclusively to Linux in 1999 and never looked back. (This means that from 1980 onward, I never used a Microsoft product.)
I am an Android fanboy for the same reasons I am a Linux fanboy. The openness and freedom. I want an open ecosystem with multiple vendors competing at every level. I also want the freedom of open source. People can complain that Google controls Android through their Play store, but the OS is still open. Even if Google somehow hypothetically disappeared, Android would continue. Amazon already has an alternate play store, and the platform is attractive enough that others would appear to replace Google’s Play store. So IMO the platform’s survival is assured for a very long time.
By 2000 I wasn’t an Apple fanboy anymore, but I had no ill will towards Apple. Now that Apple has gone full patent troll, I see them as dangerous to innovators and they must be put down. It should now be clear that Apple is nothing but a high priced boutique product brand. Everything they do is use other innovators’ off the shelf hardware technologies, pick the best ones, design a pretty exterior, and sell their nice boutique product. Nothing wrong with selling great high end products, but most people drive Honda and not ${insert-very-expensive-brand-here}. It should also be clear that Apple no longer innovates. Everything they’ve done lately is following the rapid innovation of everyone else.
I hope that answers your question.
I could grow to like Apple again. Nothing is impossible. But the company would have to change a great deal. For a long time I strongly disliked IBM. Then for a decade in the 2000’s I really liked IBM. Now that IBM has gone full patent troll against Twitter, I don’t like IBM.
Down vote must own an iphone, you hurt his feelings :(
I apologize if I hurt the downvoter’s feelings. I thought I was being fair to Apple.
But Apple made these engineering choices. There is another one, and that is Garbage Collection. Apple does not have a managed runtime, introspection, nor exact GC. Apple doesn’t allow dynamic interpreters within apps which rules out quite a few possible types of applications.
I think the choices Apple made were excellent short term decisions, but not so good long term decisions.
I can just imagine the arguments over the greatly added complexity of a new bytecode system, and it’s interpreter. Then later significant investment to build a JIT compiler (which we use today). Now working on ART, which we’ll use tomorrow. But look at the long term advantages.
You do know your stuff mate.
I own nexus 5, and i have never owned an iPhone, but I don’t agree on some points.
I just switched my Nexus 5 over to ART the other day. Now I understand why it took longer for the apps to be optimized than it did with Dalvik. :)
It’s mostly true, except the case that apple uses the same cpu on all their devices. So this means there is no advantage of being able to use instructions for specific processor, because they all are the same.
It means there is no advantage to Apple *today*. It is interesting that Apple has switched processor architectures twice now.
Yes all iPhones have the same processor now. But that is a long term disadvantage. There will be improvements and evolution in the ARM processor lineup.
Oh, but wait. Apple now has TWO processors not just one. 32-bit. 64-bit.
See how early (and wisely) Apple introduced 64-bit ARM chips and developer toolchain to support it rather than waiting until it became a big problem. (hypothetical: OMG! We’ve got to switch to 64-bit now, but our developers’ apps are all compiled for 32-bit.)
Android doesn’t need to deal with this in as big a way. Non native Android apps (most of them) will have their Dalvik code compiled to 64-bit instructions on 64-bit phones when such phones begin to appear. Developers don’t have to do anything. Samsung could ship a phone with a 64-bit processor, and suitable Dalvik compilers, and most apps wouldn’t even care.
Once new version of OS (android or iOS) is released, new apis are introduced and usually developers would want to take advantage of it. Another thing is that apps are (or should be) regularly updated ( bug fixes, new features ), so there is no problem to recompile application. That would only be problem for apps, which are not maintained anymore, or maintenance is good enough. Have you seen how ugly android 2.X apps look on android 4.X?
I completely agree that dalvik is much better for android than apple-like toolchain would be ( because of lots of different devices, processors, manufacturers and so on). But it’s not disadvantage to apple devices.
Great explanation! You’ve done all of us a great service :)
does ORACLE have any reason to sue google for ART in the same way that it’s suing Google for use of Dalvik?
Oracle originally sued over patent infringement, listing a lot of patents. The judge made them whittle down their case to ‘a trialable number’. I think it was about 3. Google was limited to, IIRC, about 3 defenses for each accused patent. A jury trial ended this nonsense as Oracle morphed their case into their APIs being copyrighted and Google violating copyright.
The idea of APIs even being copyrightable is a huge uproar in the developer community. This would turn everything upside down. The very purpose of APIs is to open up an interface for outsiders to interact with a module through it’s API.
At this point it seems there is little of chance of this going anywhere. I haven’t heard any more since Groklaw closed down. Groklaw was a fantastic and informative source of information on these cases.
The issue of the APIs goes to whether it is okay for Google to have a very Java-like system at the source code level. Dalvik has nothing to do with it. Certainly a change to the Dalvik compiler, or when Dalvik bytecodes are compiled to native code would not be in the realm of anything to do with Oracle.
Oracle is appealing the court’s decision… I’m curious to pick your brain on your thoughts to this article, http://www.eweek.com/enterprise-apps/appeals-court-revives-oracle-v.-google-java-copyright-case.html …. this headline caught my attention, “The judge says the Java APIs could be considered software tools, not simply techniques to build software, which legally cannot be copyrighted.” what are your thoughts?
What I wrote is what I sorta kinda remember, and it may be wrong. Legal issues are not my expertise. That’s why Groklaw was such a great resourse.
My, and many software developers opinion is simply that APIs should not be copyrightable. Courts and lawyers live in a world removed from reality, so they may differ.
You were right when you said that ORACLE lost the lawsuit because a jury trial ended the nonsense. which is why I am troubled by the fact that ORACLE appealed, and they have brought their nonsense back into another courtroom. I was trying to gather your opinion on whether or not you think the appeals court would favor ORACLE… but I most certainly hope they do not. Furthermore, what if Oracle loses again? do you think they would appeal the appeal ? Also, are there any groklaw alternatives out there?
old news
Well I can say using ART on my HTC One X on CyanogenMod has made my battery life last around 40% longer. It’s a vast improvement. Wish CM11 had come sooner for it as I’m getting ready for the HTC M8 now lol Only going to see this benefit for a few weeks.
Interesting. Ever since using ART on my DROID MAXX my battery life has gotten worse, though I can’t say why, exactly, that is. I enabled ART as soon as I got the upgrade to KitKat, so it’s entirely possible that my battery life could be impacted by something else. I tried using Gsams to try and track it down but most of the battery drain is coming from the Android system, and I don’t have root so I can’t pinpoint which part, exactly. :(
” the Dalvik runtime’s “only compile what you need” architecture made it
perfect for those devices as it kept the memory footprint to a minimum.” Isn’t that what we want though?
An app that in Dalvik only needed 200MB of ram might need 400 in ART. (I have no idea what actual memory use differences are, this is just an example) On any semi-current device with 512MB+ of RAM there’s more than enough memory to handle it, while an old one with 258MB couldn’t even run it anymore. In exchange for using a larger percentage of available memory we get speed and battery life improvements. Keeping as much memory as possible free really isn’t necessary as Android manages it just fine. This is why automatic task killers are useless at best,
Free memory is wasted memory.
The Kernel is a better memory manager than any of us will ever be.
It’s a speed – memory tradeoff.
Newer devices are getting more and more memory.
But with each phone upgrade, you still have only 24 hours in a day.
Pretty sure my battery life improved significantly when I moved my N5 to ART.
From what it sounds, ART should be good for those that use their phones heavily. Those who play games all the time may notice some difference.
I haven’t tried ART. There were some kernel compatibility issues, so I just strayed away. Like always, I wanna give this a try and see how things turn out.
*Bricks phone* =.[
You don’t really notice any speedup in games (or other apps) once it’s already running. The biggest speedup in is in the snappiness of launching and switching between apps. It’s not a HUGE difference, but it’s definitely noticeable, especially after JUST switching from dalvik for pointofreference.
Also, most of the compatibility issues With TiBu, WhatsApp and other big apps are fixed (‘cept for Xposed). Here’s the master list: androidruntime dot com / list (<- i didn't make it an actual link because comments get auto-banned as spam when you do)
That’s why I didn’t use it!! I’m still using Xposed. I knew it was something deeply integrated. Eh…? Well maybe not kernel deep, but yea.
From what it sounds like, I’ll have to go do some reading about Dalvik and ART.
My Uncle Connor got Mercedes-Benz SLS AMG use this link Jump999.ℂom