Fairly or unfairly, Google's Android often gets knocked for having a lagging or stuttering user interface when compared to Apple's iOS on iPhone and iPad. TiPb's previously guessed that this stemmed from very early architectural decisions made by Apple, who had a full screen, multi-touch UI -- albeit it a highly limited one -- in mind from the outset, as opposed to Google who originally had Android set up as a BlackBerry, Windows Mobile Standard, and Nokia competitor that had no need for high performance, sophisticated UI rendering.
That might turn out to be pretty much the case. In response to a Google+ post about hardware acceleration by Android engineer Dianne Hackborn, ex-Google intern Andrew Munn breaks down why Android's way of handling graphics and event processing hinders the OS from offering users a more fluid, lag-free UI.
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
The iPhone changed things by introducing a dedicated thread with high priority for handling UI rendering, redirecting all power (CPU and GPU) to handling UI element rendering in realtime based on touch input. The result? Smooth-as-butter UI elements, transitions and animations as soon as you touch the screen -- even on older hardware when paired with the latest iOS 5 software. The drawback: everything else, from app downloads to content rendering will pause so the UI can keep that high frame rate, high quality redraw pace.
Munn does disclose that he was only an intern with Google's Android team and never actually got his hands on the raw Android source code, so this could be taken as supposition.
Indeed, our own resident Mobile Nations Android guru, Jerry Hildenbrand from Android Central says there might be a bit more to it:
The way it stands now, as long as you have free resources to run multiple UI threads [in Android] the UI is amazingly smooth -- easily as smooth as the iPhone or WP7 phones. Problem is that nobody sets resource management up in a way to keep them free. A simple customization to the linux lowmemkiller kernel parameter fixes it, at the expense of huge memory hogs like Facebook or HTC applications. One day, when we have Octocore 12NM Cpu's, DDR3 RAM, and huge batteries this way will prove better. For now, you have to hack at it.
So Android can be set up to prioritize UI, if that's what's wanted, but it's not automatic like iOS. That might annoy user experience snobs, like our friends on the Iterate podcast but it might be a fine tradeoff for those with other priorities, like the big screens, different skins, and high customizability that Android's design does allow.
Hit the source for a full technical breakdown.
Source: Dianne Hackborn, Andrew Munn
