Android 4.4 KitKat ushers in several new and exciting features with the new Nexus 5 (and further updates from Google to other Nexuses too). One of the most exciting,underdeveloped feature is a Real time compiler engine ART which has caught many eye balls in the media and among the developer community recently Some say that its due to Google new purchase start-up Flexycore is the reason behind but seeing the commits in the AOSP tells a different story that google was developing it even before the launch of Nexus 4 and So, Flexycore has nothing to do with it until recently when they joined Google for improving the ART run time. In simple words its a near replacement to today’s used Dalvik VM run time, the software responsible for all apps working in Today’s Android Phones
What is ART ?
ART stands for “Android Runtime” written in C/C++ native language which Google claims to replace the way apps are fundamentally handled by Dalvik.The dalvik runtime uses Just-In-time (JIT) compilation method to interpret the bytecode ,a exclusive version of the application code.So if you want to understand this, its like the apps written by developer are partially compiled and build, now this compiled file is ran through a device and its decoded every time it is ran on the device.This process is cumbersome and also not so efficient (though it is used in this way only for now) but the only advantage of this thing to be used is that it allows it to run on variety of Hardware platform ( wiz. ARM,x86 )unlike other platforms like iOS,Windows(to some extent) without developers needing to do anything extra for making it run on other platforms(and this is great).Also ART requires 50% less time for app startup.
Readwrite has a better example to make it understand for people:
Imagine: every time you open an app, all the different parts of the smartphone responsible for making that app work have to scramble to assemble the code for the app to make it work on your device. You close the app and all those parts relax. You open it and they scramble again. This is not a very efficient way to run apps but it allows those apps to run basically anywhere (what dalvik does)
How does ART work then ?
ART doesn’t work anything differently like what we call it in India as Rajnikanth thing ( translate : a task impossible to perform).ART uses a new approach to set-up this task it pre-compiles this task and converts it into Low level Machine language (simplest form a machine understands code) when they are first installed .This pre conversion is called as Ahead-of-Time(AOT) compilation techique which allows the apps to be truly native apps when they are installed during first BOOT (first installation takes a lot of time).At present though its in developing stages and Google warns it to users to use only if you want to risk your phone and stil keep dalvik as your default runtime only (if you run 3rd party-apps).ART can be switched on from
Settings -> Developer options -> Select runtime
Remember first BOOT can take seriously 10-20 minutes to complete as ART converts existing Dalvik runtime (libdvm.so) to the ART compatible (libart.so) and also rather than the ODEX files read by the Dalvik VM, ART appears to use OAT files you can even find file on AOSP.
Android Police Cody toombs:Warning: Do not try this with the Paranoid Android (or other AOSP) build right now. There is an incompatibility with the current gapps package that causes rapid crashing, making the interface unusable and also explains that :
For now, the potential gains in efficiency are difficult to gauge based on the version of ART currently shipping with KitKat, so it isn’t representative of what will be possible once it has been extensively optimized. Thus far, estimates and some benchmarks suggest that the new runtime is already capable of cutting execution time in half for most applications. This means that long-running, processor-intensive tasks will be able to finish faster, allowing the system to idle more often and for longer. Regular applications will also benefit from smoother animations and more instantaneous responses to touch and other sensor data. Additionally, now that the typical device contains a quad-core (or greater) processor, many situations will call for activating fewer cores, and it may be possible to make even better use of the lower-powered cores in ARM’s big.LITTLE architecture. How much this improves battery life and performance will vary quite a bit based on usage scenarios and hardware, but the results could be substantial.
ART actually has two compiler backends, both Ahead-of-Time. And one of them is based on LLVM! (The new rock star in the world of compilers) LLVM(which allows machine language code to be understood), with its more modular design, has managed to evolve at a very fast rate and take on the big guns (GCC, cl.exe) in a very short amount of time. Although most of LLVM’s strengths seem inapplicable here. ART is awesome Strikes a good balance between portability and performance,but ART is not very innovative. There also have been many successful attempts at speeding up Dalvik in the past but failed to do
(P.S:The phrase “Ahead-of-Time” is unnecessary, but when talking about JIT on already compiled code, simply saying “compiling” can be confusing, so AOT hence the redundant phrase.)
So is Dalvik bad?
Answer: Yes(to some extent) but limitations and reason are as follows:
- Dalvik isn’t slow because it is bulky or outdated. It is slow (if you really want to call it that) because it’s a VM. Every VM incurs an overhead simply because of the added layer.The best VMs today can run code at 2X(slow) w.r.t native and so does Dalvik
- Android isn’t slow due to Dalvik.Android is laggy(in use) more because of its massively multitasking nature,and because apps abuse and hog the system and battery (I’m looking at you Facebook)
(Note: if you hate apps hogging up your phone, but can’t live without fat apps, look into Greenify. Requires root though)
- JIT compilation is great, JIT compiler is awesome, JIT compilation technique hardly affects 2% of the code.That 2% being really busy code, which hurt people a lot
- As mentioned above, You can’t have pre-compiled Android app binaries, simply because Android isn’t a single,unified runtime (like iOS or Windows Phone).Android runs on all sorts of hardware (more differentiation than just arm v7, v7a, v8… x86)and for different instruction sets There has to be a single, unified byte code that gets translated to hardware specific code after install and Dalvik is the best for that(untill ART arrived).ART’s benchmarks show 2x speed improvements. Note that Dalvik is 4x slower than native, although the gap isn’t noticeable in regular use,atleast for opening and using apps
- Some one xda actually made a benchmark test: here is the result
What does this mean to developers?
- Thanks to Google, developer workflows shouldn’t change. Current developer workflow doesn’t involve dalvik anyway. As long as ART is able to read bytecode for dalvik, in other words, as long as ART doesn’t necessitate a new bytecode format (which it does till now), app developers shouldn’t have to worry a thing but you never know
- One drawback of AOT Compiling is that developers will start to get bug reports that they can’t reproduce due to issues with compiling for a specific architecture. So developers will need to test apps on more device(like what Facebook did in a Google Lab with 70 Phone)
- Apps will still be developed in Java and distributed as Java bytecode in apks. So no separation from Oracle technologies there.
- AOT frees the developer from having to compile for all current and future architecture, while precompiling would require very fat binaries
- Any language with an LLVM front end could be used to develop apps with ART(not just a language limitation) . I’m especially excited about this.
- Native code is the best way to go but native code can be more dangerous. Programmer has more control, meaning dumb programmers can damage your phone.
- ART will have JNI capabilities .JNI is an interface to native code from Java. The key point to take away is that JNI is for calling on code that was written to be native from the start, and therefore enjoys further optimization. Obviously, I’m simplifying quite a bit, but this is the basic.
What about custom Recovery dalvik cache?
- Dalvik cache is that, By definition that means that anything put there can be wiped to make room for some other stuff (another app that needs to run) so when you run again the original app the JIT compiler acts again.I would think that ART won’t work this way and store complied apps in a more permanent fashion, aka the more space needed (Nexus watch out) So, for using the ART cache the custom recovery(like CWM ,TWPR ) will need to optimise it to clear the ART Cache also (if only ART is default Runtime)
What do we lose from Dalvik?
- ART compiles to machine level language and hence requires much more space for storage
To explain this will take an example: it’s like a zip file where the apk is the .zip file and after extracting the zip what we get is the machine level code.So here zip is what dalvik used to run directly but ART needs the extracted (here machine level code) before hand to run and this can go upto apps using up 200% more space than what dalvik used to run it.
- When an App is first installed it needs time to convert to ART runtime format and this takes time ( not if its for a single app). But for the whole system apps it will require patience .Imagine you have 150-200 right now and you change to ART runtime ,then it seriously tests your patience( at least 20-30mins required ,as mentioned above)
Final thought:
ART sounds like a pretty amazing project, one that I hope to see as a regular part of Android sooner rather than later. Improvements are likely to happen and it will get better and will surely reduce lag and you won’t again think that an iPhone with 1 GB RAM is smooth than a Samsung S4 with 2GB RAM( native support will change it).
The Optimized code, pre compiling , better runtime can all together work out and in the end improve the Battery Life cause at the end what Matters is Battery Life of a Phone
The official google documentation may vary a little bit from this information
Disclaimer :All the Thoughts and opinion mentioned above are just only my opinion,any resemblance to anyone is not intentional
Sanket Shah 