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.
😎 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.
