Even for a dual-core 1.2GHz device like the Samsung Galaxy S II (SGS2), while running on Android 2.3 Gingerbread, I could still really tell the UI lag when scrolling, especially when compared to a single-core device like the iPhone 4.
Take for example the official Twitter app. While swiping your fingers from bottom to top to scroll through earlier tweets in your timeline, sometimes the scrolling would stop at the tweet you last put your fingers to, as if you were trying to select or tap on that particular tweet and not swipe through it. This happened so often it actually got so frustrating.
Andrew Munn has a very good explanation why this is so with any Android device:
It’s not GC pauses. It’s not because Android runs bytecode and iOS runs native code. It’s because on iOS all UI rendering occurs in a dedicated UI thread with real-time priority. On the other hand, Android follows the traditional PC model of rendering occurring on the main thread with normal priority.
This is a not an abstract or academic difference. You can see it for yourself. 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.
In my opinion, it is not a question of efficiency with which resources are used. It’s all about the user experience. And Android should do something about the UI lag soon. Until Google could come up with a new revolutionary version of Android, I guess I’ll have to stick with iOS.