One of the things that really stands out using an iPhone is just how smooth it feels compared to using Android. Where as Android is laggy, with a measurable interim between when you touch the screen and when the OS responds, iOS almost seems to anticipate what you want to do before your finger touches the display.
How has Apple managed this incredible feat? A better question might be: “How has Google managed to screw up Android’s multitouch so much?” According to Andrew Munn — a software engineering student and ex-Google intern — Android is so messed up that Google might never be able to match an iPhone or iPad’s performance. Ouch!
Before we begin, here’s some background. In the past, it has been said that Android’s UI is laggy compared to iOS because the UI elements weren’t hardware accelerated until Honeycomb. In other words, every time you swipe the screen on an Android phone, the CPU needs to draw every single pixel over again, and that’s not something CPUs are very good at.
That argument makes sense, except if it were true, Android would have stopped measurably lagging in touch responsiveness compared to iOS when Android 3.0 Honeycomb was released. Except guess what? Android devices are still laggy even after Honeycomb is installed on them.
Most modern Android phones have specs that are equivalent or even better than the iPhone’s (for example, most Android phones ship with 1GB of RAM, compared to the iPhone 4S’s 512MB); the problem isn’t hardware. So what’s the issue?
Here’s why Android can’t render its touch UI without lagging, according to Munn. In iOS, UI rendering processes occur with dedicated threads in real-time priority, halting other processes and focusing all attention on rendering the UI. . In other words, every time you touch your finger to your iPhone’s display, the OS literally goes crazy: “Someone’s touching us! Someone’s touching us! Stop everything else you’re doing, someone’s touching us!”
In Android, though, UI rendering processes occur along with the main thread with normal priority. In other words, it treats rendering the UI the same way as it would, say, downloading a podcast in the background, checking for SMSes, or anything else. Hence, a choppy UI.
Here’s Munn explaining what this all means, and why Google was stupid enough to design Android this way.
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. So why did the Android team design the rendering framework like this?
Work on Android started before the release of the iPhone, and at the time Android was designed to be a competitor to the Blackberry. The original Android prototype wasn’t a touch screen device. Android’s rendering trade-offs make sense for a keyboard and trackball device. When the iPhone came out, the Android team rushed to release a competitor product, but unfortunately it was too late to rewrite the UI framework.
So why hasn’t Google just changed the UI framework? Well, it’s a daunting task that would involve every app on Android Market to be rewritten to support the new framework. That’s at least a year away, and may never happen.
In other words, for Google to ever fully deal with Android’s lag problems, it needs to basically hit the reset button and destroy its app ecosystem. iOS, on the other hand, was built from the ground up to support multitouch smartphones; hell, Apple was the supreme visionary of it. It’s important to get things right.
[via Redmond Pie]