For some time we have been commenting on ART the new virtual machine using Android L ( above explain how to activate ART in KitKat). This time go into more detail on the impact of ART and considerations that must be both users and developers.
JIT vs. AOT
As we know, Android apps are distributed in the apk format. Apk contains a Java class compiled into a bytecode format called DEX. The DEX format is independent of processor architecture, so to be executed needs to be translated to native “machine code” for the processor of our device.
The fundamental difference between Dalvik and ART is when to make this translation or compilation. Dalvik uses what is called “just in time” compilation (just-in-time, or JIT), while pre-compile using ART (ahead-of-time, or AOT).
With the Dalvik JIT compiler, each we started an app, the virtual machine dynamically translates a part of DEX bytecode to machine code. As you continue running the app, more bytecode compiled and stored in cache memory. That is why it is said that the app is being compiled “just in time” as we use it. For ART, the apps are compiled from that are installed on the device, and since the machine ready to run code without compiling allowed greater installed.
Impact Network
In general, applications perform better with ART, as the processor does not have to devote resources to be compiled the app while it is used. This will also result in lower energy consumption.
Obviously, these improvements come at a cost. For one, the apps take longer to settle (so we said that is being compiled when installing the full app for our specific processor). But do not worry, do not think that an app will take 30 minutes to install, typically it will be a matter of seconds or tens of seconds at most. The other negative consequence is that the installed apps take up more storage space than before (about 20% more).
In short: better execution performance and efficiency at the cost of increased installation time and storage space. I think it’s a sacrifice well worth it.
Impact Developer
The vast majority of apps for Dalvik ART should function without problem. However, there are some cases where it is better to adjust your code to ensure that your app works well on ART.
A handy relatively common Android apps so far is that the code included explicit calls to garbage collector using System.gc (). Typically this is done to prevent occurrences of GC_FOR_ALLOC (when the system runs out of memory and call forced the garbage collector so at a time that may not be the ideal). In ART, due to improvements in the system of garbage collection, no longer need to be making explicit calls to System.gc ().
From the code of your app can detect if it is running on Dalvik or ART, checking the value of System. getProperty (“java.vm.version”) . If the value is 2.0.0 or higher, then the app is running on ART.
ART is stricter than in Dalvik verification code. The produced with the Android SDK code should have no problem, but it can be another tool to generate code that ART does not accept. For example, this could be the case with tools for code obfuscation. Third-party providers are adjusting their tools to ensure they are compatible with ART so that such recommendation is to upgrade your tools to the latest version.
A positive aspect is that it will be easier to track errors NullPointerException type because ART will provide information on what was the method that the code tried to access.
Conclusion
ART certainly best to bring the Android platform. For users, this will be transparent but is important to know what is happening “behind the scenes” . For developers, general promises ART make things easier and help developers make their apps have better performance.
For further reference, I invite you to visit the Developer Zone Intel, where you’ll find more technical information resources for the development of Android apps.
References:
No comments:
Post a Comment