App Development

The Android Runtime: The Butter We've All Been Waiting For

An important announcement for Android developers from this year’s Google I/O was the full rollout of the Android run time (ART). ART significantly improves Android’s performance, increasing application speed and reducing “jank” across the board.  It provides the “performance boosting thing” that users have long been waiting for.

ART was announced last year as an alpha runtime with the release of KitKat, and with the L developer preview, it is now the standard, fully replacing the Dalvik runtime. Let’s take a look at what ART offers and why it is one of the most important steps in a long-running effort to improve Android’s smoothness.

Explaining runtimes

First, let’s define what a runtime does. A runtime is a library used by a compiler to implement language functions during the execution of a program. It’s essentially the framework or platform on which your code runs. The C++ runtime, for example, is simply a collection of functions, but other runtimes, like .NET, package in a garbage collector and other language tools.

Up to this point, Android apps have used the Dalvik virtual machine to execute code. Java programs are compiled to Java bytecode, which is then translated to Dalvik bytecode by the “dx” tool. The Dalvik bytecode is then packaged as a Dalvik executable file (hence “dexing”), which is designed for constrained systems like you’d traditionally find on mobile devices.

With the L release, which is anticipated to arrive this fall, Dalvik will be replaced by ART.

ART over Dalvik

ART introduces ahead-of-time (AOT) compilation, which can be beneficial for mobile applications as opposed to Dalvik’s just-in-time (JIT) compiler. For apps running on Dalvik, the JIT will compile your DEX files to machine code when your application is launched and as your app is running. Performing this step at launch can slow down app start times, especially on resource-starved devices. AOT compilation eliminates compiling bytecode to machine code at launch and instead performs this step at installation time. When the app is installed the runtime will convert the DEX and ODEX files to OAT (ART) files using the dex2oat tool. ART will compile the application to a device dependent binary that supports the most common architectures.

Architectural families

Compiling the application to native machine code before launch means faster startup times and a significantly more performant runtime while your app is in the foreground. It also allows the Android system to save disk space, memory, and starting time by removing portions of the runtime environment, especially the parts that made the JIT possible, making it especially useful for embedded and mobile devices. Running native binaries may improve speed but only at the cost of larger app storage on the device and a longer installation time.

ART also significantly improves garbage collection (GC). GC impacts app performance and is largely the cause for the jank Android users frequently become frustrated with. Both Dalvik and ART use a concurrent mark and sweep (CMS) GC. This means that when a collection is triggered the collector traverses the heap, marks those objects that are “reachable” or in use, then sweeps through and reallocates the rest. This process is illustrated in the following graphic from the ART presentation at this year’s Google I/O:

GC Process

The Dalvik garbage collector needed to pause your app twice in order to mark objects for collection. ART halves GC pausing, and parallelizes processing during the remaining pause cycle.  It also introduces a new collector that cleans up short-lived objects with a lower pause time, and maintains larger primitives (like bitmaps) in a separate pool. Finally, one of the biggest improvements ART brings is concurrent garbage collection scheduling, which will all but remove the dreaded GC\_FOR\_ALLOC statements that developers see in their log statements.

On top of its inherent performance benefits, ART brings along many improvements to app debugging. ART provides a dedicated profiler for Traceview, which will give developers a more accurate look at their app’s execution without the slowdown that Traceview has previously had with Dalvik. The new runtime also provides additional context and details for exceptions, for example by providing method names and field types for NullPointerExceptions, ClassCastExceptions, and ClassNotFoundExceptions.

There are still a handful of issues being worked out with ART as L is in a developer preview. Check out the known issues section on the Android developer portal for more detail. More importantly, the Android team has a feature roadmap for ART to introduce even more performance enhancements.

I Can’t Believe It’s Butter

Jelly Bean, Android 4.1, introduced Project Butter, one of Google’s first efforts at creating responsiveness and improving speed. It added triple buffering, vsync, and touch responsiveness, all in an effort to reduce jank. Project Butter went a long way towards fixing those issues, but problems still persist.

Project Svelte was introduced with KitKat, Android 4.4, and aimed to reduce the footprint of both the system and apps installed. Svelte provides marked improvements for devices with lower hardware specifications, but doesn’t do a lot to fix things like garbage collection, which is the responsibility of the runtime.

The following graphic shows ART’s improvements over Dalvik in common benchmarks: ART vs. Dalvik CPU Usage

With the improvements ART brings to apps, Android is poised to be a platform that can support both embedded and low memory devices and high-end devices capable of providing rich UI to consumers. ART is Android’s ultimate endeavor to reducing jank. By packaging in new garbage collection algorithms, ahead-of-time compilation, and a new memory allocation manager, ART finally gives us the “performance boosting thing” that we’ve all been waiting for.

App Clips: A New Gateway for Users to Experience

App Clips: A New Gateway for Users to Experience...

Read the article