Skip to Content

Google to Ex-Intern on Android Screen Lagginess: You’re Wrong

So Google Android framework engineer Dianne  Hackborn responded Thursday evening to the accusations leveled by  ex-Android intern Andrew Munn.

Here is Hackborn’s rebuttal. Thanks to readers of my earlier blog on this topic, “Why I still have faith in Ice Cream Sandwich overcoming Android’s Fundamental Lagginess,” Derek Morr and Tom Van Doorslaer, for pointing it out to me, and also sharing their thoughts.

Morr’s comment was pithy: “In short, the intern got it wrong.”

I agree that is the basic gist of Hackborn’s post,  though of course her technical explanation makes it clear that reality  is in shades of grey rather than black and white.

I’ll try to boil her post down into ten statements without hopefully losing all of the nuance.

1) On accusations that Android doesn’t prioritize key threads such as UI rendering, “this is outright wrong.”

2) Android lets app and screen rendering be prioritized as default or background. User interface threads normally run at the main default. Application processes running in the background are forced to run in the background.

3) Background threads are bunched together using a “Linux facility called cgroups.” Collectively, these threads are only allowed to take up 10% CPU utilization maximum.

4) There was a ‘foreground’ priority thread in the original Android but it was abandoned b/c it turned out not to smooth UI rendering all that much.

5) Android uses the two sets of priority threads as part of its goal of creating a ‘sandbox’ architecture that separates all apps, incl. 3rd-party ones, for security reasons. This, says Hackborn, differs from iOS’s design which didn’t originally accommodate 3rd-party apps.

6) It is true that there is not a separate real-time thread just for screen  rendering, as in iOS. However, this is no magic bullet.

7) Rather, setting up a separate thread just for drawing the UI in real-time would not have been worth it,  due to a bunch of complex reasons I don’t quite understand, though  Hackborn seems to be hinting it is related to Android’s overall open app  architecture.

8) Android only “recently” began to use hardware acceleration for drawing inside the UI. That’s because hardware acceleration isn’t as simple as making your graphics chip handle the UI.  It takes a lot of memory and multiple processes to manage the graphics  chips as “most mobile GPUs still have fairly expensive GL context  switching.”

9) “There are of course many things that can be improved in Android today, just as there are many things that have been improved since 1.0. As  other more pressing issues are addressed, and hardware capabilities  improve and change, we continue to push the platform forward and make it  better.”

10) But it’s no technical piece of cake to  enable iOS to touch-scroll at a smooth 60 frames per second, either.  Hackborn quotes a comment to that effect from an outside developer.  “Based on this statement I don’t see any indication that there is  something intrinsically flawed about Android in making lists scroll at  60fps, any more than there is in iOS.”

So what’s your takeaway? The key of course is how  you weigh Hackborn’s admission that no, there is no real-time thread  dedicated specifically to UI rendering, but yes, there are clear ways to  strongly prioritize UI rendering over potentially-interfering  background tasks.

Also, as I point out in my post, “Why I still have faith in Ice Cream Sandwich overcoming Android’s Fundamental Lagginess,”  this may all be simply the equivalent of an arcane philosophical  argument in an advanced college seminar, except between two software  engineers.

The real-world evidence shows that the new  Ice Cream Sandwich update DOES appear to cut the herky-jerky behavior of  Android, vis-a-vis the glowing reviews for the Samsung Galaxy Nexus  smartphone running Ice Cream Sandwich, and the less-glowing reviews for  the ostensibly more-powerful (4 cores!) Asus eee Transformer Prime  running the existing Honeycomb version.

Be the first to leave a comment
You must be Logged on to comment or reply to a post.