Android Lag, Attributed To Core System Framework, Here To Stay

Last night, Android engineer Dianne Hackborn published a blog entry detailing some of the hurdles her platform faces in working its way toward the lofty goal of a completely lag-free UI. However, according to former Android team intern Andrew Munn, Hackborn's essay fails to address the fundamental cause of Android's nigh-constant visual and touch-tracking hiccups. Munn's example is illuminating, his frustration palpable:

Anybody who’s used a Nexus S knows it slows down in all but the simplest of ListViews. And forget any semblance of decent performance if a background task is occurring, like installing an app or updating the UI from disk. On the other hand, iOS is 100% smooth even when installing apps.

To remedy this oversight, Munn wrote his own piece about Android's root problems, identifying six obstacles (one major, five minor) blocking the platform from achieving the smoothness we Apple users all know and love. Paramount in the discussion is the fact that, unlike iOS, Android neither allows UI rendering its own dedicated processor thread, nor does it give such functions real-time priority. The result is that Android "follows the traditional PC model of rendering occurring on the main thread with normal priority." This is a huge oversight, says Munn, and he describes it in easy-to-understand terms:

Grab your closest iPad or iPhone and open Safari. Start loading a complex web page like Facebook. Half way through loading, put your finger on the screen and move it around. All rendering instantly stops. The website will literally never load until you remove your finger. This is because the UI thread is intercepting all events and rendering the UI at real-time priority. ... If you repeat this exercise on Android, you’ll notice that the browser will attempt to both animate the page and render the HTML, and do an ‘ok’ job at both.

The remaining five hurdles are less impactful to Android's jitters, but matter some all the same. The absence of true hardware acceleration--which is being rapidly fixed as the platform relies more and more on dedicated GPUs--has been a sticking point, as has inefficient garbage collection. General hardware issues, like the Nvidia Tegra 2's bottlenecked output (due to low memory bandwidth and no advanced instruction support), is also a problem. Even Android's method of UI compositing needs repairs, as it always "require[s] every animating section of the screen to be redrawn." And, finally, the Dalvik Virtual Machine is still fairly immature, lacking the refinement to run Android with the swiftness and polish that native code would better provide. While these minor hangups are fixable "without radical changes to Android," Munn soberly informs us that the

Android UI will never be completely smooth because of the design constraints I discussed at the beginning: - UI rendering occurs on the main thread of an app - UI rendering has normal priority Even with a Galaxy Nexus, or the quad-core EeePad Transformer Prime, there is no way to guarantee a smooth frame rate if these two design constraints remain true. It’s telling that it takes the power of a Galaxy Nexus to approach the smoothness of a three year old iPhone.

Why, then, doesn't Google simply start over? Well, to do so, every Android app would have to be completely rewritten to support the new rendering framework, and Android would also need to add a "legacy mode" to support older apps. Meanwhile, further Android development would be slowed as the engineering team rebuilds several years of past work. But Munn thinks the rewrite will happen, simply because it must happen. Android's lag, he says,

should be priority #1 for the Android team. ... A laggy UI breaks the core affordance language of a touch screen. The device no longer feels natural. It loses the magic.

As if Android ever had any magic to lose...

Related articles