"Android can never be as smooth as iOS" myth busted
Two months ago, a Google intern kicked off a discussion about why Android is laggy: a sore point in the hearts of Android fans, and gave what seemed like a pretty legitimate explanation to non-developers. It spurred a huge discussion not only on the Internet, but right here with arguments being brought by both sides.
In a nutshell, the former Google intern Andrew Munn said that UI rendering is happening as a main thread in Android while in iOS it’s in a dedicated thread given a real-time priority and that is why many find Android laggy. Moreover, Munn suggested that that’s an inherent flaw of the way Android is built. That’s why Android was to remain somewhat laggy despite dual and quad-core chips roaring under the hood, and actually whatever hardware is thrown in an Android device. We definitely advise you to check out Munn's first post to get all the details he touches on.
However in the recent months many people who really are experts in threaded programming in particular and Android at large have chimed in with comments saying Munn’s statement is uninformed at best and misleading at worst and his conclusions are simply false. We have to admit, that the technicality of Munn’s first post was very convincing to us as well, especially given the fact that Android and apps built for it are indeed often laggy.
The experts have a different opinion, though, and it’s backed by more experience and facts. So here’s the other side: Jay Freeman who made Cydia says that Munn’s post is “simply wrong,” Bob Lee, CTO of Square and former Android core library lead described it as “fallacies” and Matthew Chaboud, senior engineer at Avid brusquely concluded: “uninformed crap.”
Before we quote the developers, let us first include their own disclaimer: “While I'd love to explain why Android is laggy, while iOS, WP7 etc are fluid, I can't. I cannot claim that I know how a lot of little issues managed to cascade to an inferior experience for many of us.”
So with no further ado, here’s the details on all the fallacies of Munn’s initial post:
Matthew Chaboud, Senior Software Engineer at Avid:
Unlike a number of the in-awe comments here, mine will come with a different tone:
I'd reply, point by point, to the big-bucket-of-wrong that you've posted here, but it's just too much effort. That you leave this post up and carry such an air of authority (even after the disclaimer) is mind-boggling. That's just one more name on the do-not-hire-this-guy list.
Your post is uninformed crap.
I'm a threading guy. I've spent more than a decade eating, breathing, and sleeping optimization of threaded interactive user applications. I'm not really a phone guy, but I've dinked around with iOS and Android. Both provide facilities for background threaded render-ahead and non-allocating in-place recycling of resources. I can say, with absolute confidence, that you're suffering heavily from the Dunning-Kruger effect. You know far less about threading and rendering architectures (or, clearly, application architectures) than you think you do, and the assertion that "Android UI will never be completely smooth..." ranks as one of the most tragically idiotic technical assessments that I've seen all month (and I see some real winners).
This suggests that iOS is A) perfectly smooth and B) that way because of threading lock out. It also suggests that software rendering can't manage 60fps, or that threads at normal priority can't be smooth. I can't think of any of my iOS devices (iPhone and iPod Touch on my desk and in my bag) that is always smooth. Smoother? Rendered on a background thread to quell transient interruptions when using CoreAnimation? Sure. Perfect? Oh no. I can easily write you an iOS app that is a stuttering mess.
I've written a sub-pixel accurate software-only compositing engine that could peg 1080/60p using normal priority threads (on x86) on a system with higher priority threads running other tasks, including realtime threads. I am entirely confident that this will become possible on mobile platforms without GPU assistance (though why not use the GPU when it's there?).
Bob Lee, CTO of Square and former Android core library lead:
Some fallacies related to Android vs. iOS UI performance made the rounds recently, inflicting undue damage to Android's reputation. It all started with a misinformed Google+ update written by former Android testing intern Andrew Munn.
I don't claim to have all the answers, but I can tell you that implementing fluid interfaces on both iOS and Android is time consuming and difficult. The challenges are an order of magnitude more complex than Munn suggests. I haven't had an opportunity to try Ice Cream Sandwich yet, so I can't tell you firsthand how it compares to the iPhone. However, Jason Kincaid, quoted by Munn, described ICS as quite smooth and noted that both Android and iOS stutter occasionally.
Time reporter Matt Peckham echoed Andrew's misconceptions the following day, further spreading the FUD about Android. Toward the end of his article, Matt noted:
I’m not an Android or iOS software engineer, so all I can say in response to any of this is that, assuming Munn’s correctly articulated the way rendering takes places on Android and iOS devices, it makes sense (but then so does the idea that Lee Harvey Oswald had help, at least to some people).
Peckham makes no mention of trying to corroborate Munn's claims with a more experienced, knowledgeable engineer, like Romain or Dianne from the Android team, nor does he reference the corrections made by iOS experts in the comments on Munn's post. A more qualified engineer would support their theories with evidence like code, specifications, and performance test results, not Reddit and Hacker News comments as Munn did.
Jay Freeman's, iOS developer and developer of Cydia:
"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 certainly not true. The update of the display for the installation progress might (...might) stop, as that's happening in the UI (aka, "main") thread of SpringBoard (and the event loop management might ignore incoming events that are not related to the touch event until after the gesture completes), but the installation itself is being managed by a background daemon (installd) and will not stop because someone is touching the screen. The operating system is /not/ doing something hilariously insane here, throwing out all computation on the device because someone is accidentally touching it.
AFAIK this is simply wrong: the events that are later described as blocking rendering are coming in on the main thread, not some special "dedicated" one. The reason things block is because of the way the event loop on that thread is managed (and in fact is directly caused by all of that activity operating on the main thread, which we even often call the "UI thread"), and has nothing to do with threading, and certainly has nothing to do with "real-time priority".
"On iOS when an app is installing from the app store and you put your finger on the screen, the installation instantly pauses until all rendering is finished."
Brent Royal-Gordon, iOS developer:
The iOS description here isn't quite accurate. There are several things at work:
This is not a technical difference; it's a cultural difference. Good iOS developers don't ship software until it runs at something near 60 fps while scrolling and tracks touches almost perfectly; good Android developers do.
1. Compositing and previously set-up animations—all the stuff that involves the Core Animation rendering layer tree—do indeed happen on a background thread.
2. Drawing new content into Core Animation layers and setting up their animations happens on the main thread. This is the same thread that user interface actions occur on.
3. In naively written code, all developer-written code would occur on the main thread. However, Apple provides very easy APIs (Grand Central Dispatch and NSOperation) to move things into system-managed background threads. In iOS 5, you can even declare that a Core Data (object-relational database) context cannot be used directly on the main thread.
All that stuff you noticed—the way images aren't drawn into lists while you're scrolling, the way WebKit rendering stops when the system is tracking a touch—isn't inherently built-in by a mechanism that pauses the world when a finger is on the screen.* It's deliberate behavior painstakingly implemented by the developer of each individual app.
source: Andrew Munn via TheVerge
FCC OKs Cingular\'s purchase of AT&T Wireless
Things that are NOT allowed: