The next version of Google Android will likely include a major change that average users won’t notice at all… unless they notice that apps generally run more quickly.
Google has been working on replacing the Dalvik virtual machine that powers Android apps with something called ART since last year. Now it looks like ART is just about ready for prime time.
Earlier this year, ART became the default runtime in the Android Open Source Project, but users could still switch to Dalvik. Now Dalvik has been removed altogether.
What this means is that instead of using “just-in-time” processing to compile code in real-time, ART will use “ahead-of-time” processing to compile apps before you run them.
This means the first time you reboot your phone after updating to the next version of Android, you’ll probably be in for a long wait while all your apps compile… but after that certain apps should be able to run much more quickly. Other apps will probably function about the same on ART as they did on Dalvik.
The ART runtime has been available for testing for months and during its development there are some apps that might not have supported the framework. Hopefully by the time the next version of Android is released with ART enabled, the vast majority of Android apps will be supported.
One potential dealbreaker for folks with rooted phones and tablets has been that the Xposed framework doesn’t currently support ART. But developer rovo89 plans to update the framework soon so that users can continue to modify the behavior of their phones whether they’re using ART or Dalvik.
via xda-developers
I would rather have the JIT, which is executed only first time and then stored for ever …
I wonder if this effects BlackBerry 10 Android runtime?
NOOOOOOOOOOOOOOOOOOO!
I can’t use memory hack on my games on ART. 🙁
I’m not a specialist in android coding but….
I’m not quite sure that once you’re in the app itself, the gain will be as noticeable as they say: Many of the apps needing a significant amount of CPU power make an important use of JNI native compiled module (EG C/C++/etc… modules called by a main Java module), some are even just a wrapper setting the basic app context and switching to native code module (see OPENTYRIAN, SUPERTUX, which are direct port of linux SDL games)
You wouldn’t notice any difference on even mid range phone.
Yes you’re right, but think of those thousands of little apps that are developed in full Java, and still performing like Windows 95 on a 486SX…If these can benefit from the change, then it makes sense IMO.