Here is why Android is laggy and why it’s going to remain like that in the near future

Have you noticed that Android is laggy? It is. We hoped things would change with dual-core processors and when we got the LG Optimus 2X in our trembling hands, the first phone running on the dual-core NVIDIA Tegra 2, we nervously swiped to the homescreen, then to the main menu, then to the weather app. The lag was still there, but we couldn’t understand why - the raw hardware muscle was there already. What was wrong? Turns out, the problems is rooted deeper, in the very origins of the platform. Android's UI was laggy because it was coded differently than iOS and we’re not talking about Android’s bytecode against iOS’s native code.

Now, after Google engineer Dianne Hackborn brought up the topic of hardware graphics acceleration, Android’s lagginess has finally gotten in the limelight for some confessions which 200 million users of the platform are waiting for. Former Google intern Andrew Munn dug deep into the topic with more insights coming from Android software engineer Romain Guy who worked on Honeycomb’s full graphics acceleration and other engineers.

So with no further ado, the core reason why Android is laggy is the way it treats UI rendering. While on iOS UI rendering happens in a separate thread with real-time priority, on Android this happens in the main thread with normal priority. This of course means that other apps can take over your processor resources and hurt basic UI interactions, translating into a noticeable lag. Munn examplifies this with Safari and the Android browser - if you tap and hold into the Safari window while it’s loading a webpage, the loading process stops, as UI rendering has the highest priority and takes over. The result is that the webpage will not load until you lift your finger off, but the UI will remain buttery smooth all the time. Android has a radically different approach - it will try to maintain a reasonable response rate for the UI and load the webpage, but often the framerates would drop causing a visible lag.

[…] This is the same reason why Windows Mobile 6.5, Blackberry OS, and Symbian have terrible touch screen performance. Like Android, they were not designed to prioritize UI rendering. Since the iPhone’s release, RIM, Microsoft, and Nokia have abandoned their mobile OS’s and started from scratch. Android is the only mobile OS left that existed pre-iPhone,” Munn says.

Now, that’s a tradeoff that doesn’t seem acceptable for touchscreen smartphones. Interestingly, with dual-core processors, this is less noticeable, but an occasional hiccup still occurs more often than the user would like to see it. Hardware graphics acceleration alleviates the problem, but that’s where one of the most popular dual-core chips, the Tegra 2, however, falls a bit short as it has a low memory bandwidth and doesn’t support NEON for faster matrix math, so other chips like the Exynos one yield better performance.

We won’t spoil the fun of reading the whole article, but we’d summarize the core reasons for the laggy UI in Android. The lack of full hardware graphics acceleration until Honeycomb for tablets and ICS for phones, the imperfect garbage collection in Dalvik, inefficient UI compositing, and finally Dalvik itself as a virtual machine are all partly to blame.

But most importantly, unless Google changes the way UI rendering happens (to a separate thread) and its priority (to real-time), the issue of some lag on Android will likely persist. Why is this hard to do and what would change if it did happen? Hit the source link for a very interesting read.

source: Andrew Munn via Daring Fireball