Intel® Developer Zone offers tools and how-to information for cross-platform app development, platform and technology information, code samples, and peer expertise to help developers innovate and succeed. Join our communities for Android, Internet of Things, Intel® RealSense™ Technology, and Windows to download tools, access dev kits, share ideas with like-minded developers, and participate in hackathon’s, contests, roadshows, and local events.
One of the most significant Android* 5.x changes is the shift to the relatively new way of executing applications called Android Runtime (ART). The option to use ART has been available since the Android 4.4 (KitKat) release. KitKat users had a choice between ART and its predecessor Dalvik. Now ART is the only runtime environment in Android Lollipop.
ART and Dalvik runtimes are compatible running the same Dex bytecode, therefore apps that are developed for Dalvik should work fine when running with ART. But ART has a number of specific differences that would be explained in this article.
Let’s consider the major features implemented in ART.
Ahead-of-Time Compilation
The main feature that makes ART different from Dalvik is the Ahead-Of-Time (AOT) compilation paradigm. According to the AOT concept, DEX bytecode translation happens only once, while the app is installing on the device. It brings real benefits in contrast with Dalvik’s Just-In-Time (JIT) compilation approach, which translates code every time you run an app. Here is an article where you can find more information on how AOT compilation changes the performance, battery life, installation time, and storage footprint of your users’ devices.
Garbage Collection
Another improvement in ART is memory management. Garbage collection (GC) is a critical process for performance because it can affect user-experience. ART’s garbage collector contains some enhanced features that can outperform Dalvik’s GC.
First, the new GC enumerates all allocated objects and marks all reachable objects in only one pause while Dalvik’s GC pauses twice.
Second, parallelization of the mark-and-sweep algorithm enables the app to reduce pause time noticeably.
Third, ART has a lower total GC time for certain cases where cleaning up recently-allocated, short-lived objects is required.
Fourth, ART makes concurrent GC timelier. As a result, the app does not have to stop if it attempts to allocate memory when the heap is already full.
The final change in memory management is the emergence of the compacting GC feature. Sometimes OutOfMemoryErrors occur not due to the app being out of memory, but due to the absence of any separate block of suitable size to process the app’s request. Such errors are the reason why Android Open-Source Project (AOSP) is developing the compacting GC for ART. Compacting GC merges freed-up single blocks in one location of memory, which can be easily allocated.
It’s a very useful feature, but while compacting GC is still in the development stage, there are some restrictions, especially, for apps with Java* Native Interface (JNI). Android advises developers to avoid incompatible operations and pay more attention to the pointers. Also, it’s wise to use CheckJNI to catch potential errors.
Development & Debugging
The last enhanced ART feature concerns the area of application development and debugging.
ART has added support for a dedicated sampling profiler. Previously, the graphical viewer for execution logs, called TraceView, was commonly used for profiling Android apps. But using this tool had a negative impact on the run-time performance. Sampling profilers measure operating system interrupts. Hence, using a sampling profiler is less intrusive to apps and has many side effects compared to other approaches. This new dedicated profiler added to TraceView now provides an accurate picture of app behavior while apps are running at their natural speed without significant slowdown.
Also, ART supports several new debugging options like monitoring locks, calculating live instances in some classes, setting a field watchpoint to stop the app’s execution when a specific event occurs, and so on.
The other improvement to ART that can accelerate development is clearer diagnostic details in exceptions and crash reports. The latest versions of Dalvik had expanded exception details for java.lang.ArrayIndexOutOfBoundsException and java.lang.ArrayStoreException. ART gives detailed information for java.lang.ClassCastException, java.lang.ClassNotFoundException, and java.lang.NullPointerException.
java.lang.NullPointerException: Attempt to write to field 'int android.accessibilityservice.AccessibilityServiceInfo.flags' on a null object reference
java.lang.NullPointerException: Attempt to invoke virtual method 'java.lang.String java.lang.Object.toString()' on a null object reference
More information is available in the article: Verifying App Behavior on the Android Runtime (ART).
Summary
The AOT compilation, garbage collection, development, and debugging improvements, and the other features discussed here make ART a great improvement over Dalvik. Modern technologies enable devices to be multicore, with large memory and storage capacity to be compatible with ART requirements. Furthermore, some ART functionality, for instance, compacting GC is now under development. The new runtime is at the forefront of Google’s development, which means it will likely see expanded and upgraded capabilities.
References
