Android has gone through tremendous amount of growth over the years, with Google spearheading a mission to make it a prime computing platform. Within half a decade, android has gone from a mediocre cupcake to ingenuity driven kitkat version, boosting it to the forefront. Google has already phased out most of the issues related to the platform, making it a viable choice for end users as well as developers.
The architecture on which it was processed initially was not much viable option leading to huge amounts of redundancies. Hence the evolution of Android was speedy yet disoriented. Now after years of evolution, Android team has geared up to assess components that have not shown critical improvement and needed careful advancement. Dalvik, that implements Just-In-Time (JIT) compilation, has been the software responsible for running android apps till date. Despite all innovations and growth in mobile application development, there were issues with Android applications. Considering this fact, Google began to secretly work on a runtime that could aid in power-packed performance of Android-based applications. Two years of cut-throat pressure and Google has finally ushered with yet another runtime software, called ART, which is a replacement of Dalvik.
ART, which stands for Android Runtime, manages app execution in a concertedly different manner. The current runtime uses Just-In-Time (JIT) compiler to interpret byte-code, which compiles the code partially on developer’s side and the proceeding code undergoes compiling through interpreter every time the application is launched on user's device. This process of compiling and interpreting is not particularly useful but has been successful over various architectures.
ART compiles byte-code into machine language when apps are primarily installed and hence turns them into native apps. This process is termed as Ahead-Of-Time (AOT) compilation. By eliminating the need to re-execute interpreted code, the start up time of apps is cut down to great extent, making ongoing activity of app faster.
ART is not yet ready for its peak time and trying it could risk breaking apps and system stability but if users are curious enough, they must turn to Settings, followed by Developer options and finally select the runtime. The system will require reboot because internal file switch from libdvm.so to libart.so will occur, which might take about ten minutes for preparing the device for new run time.
Potentially, nothing can be gauged of its overall success as a runtime, unless and until ART gets fully optimized. Estimates, nevertheless, suggest that duration of executing compiled machine code at runtime will be lessened to half, thereby offering enormous idle time to system, accelerating overall speed and efficiency of device along with saving battery life. Presently, the quad-core is mostly implying usage of ARM but exhibiting ART shall make it possible for lower end devices with not that consolidated cores to function effectively under Android. The profitability of ART is yet a mystery but substantial gains are definitely anticipated.
Couple of shortcomings might come handy with AOT compilations as preloaded machine code will occupy more storage space and installations will take longer time. This might not be true for smaller applications but huge apps like games or other resource hungry applications might take significant time to get compiled initially. AOT surely calls for a test of patience but it is still worthwhile if it saves battery life and adds fluidity to Android-based applications.