A former intern for Google's Android team has provided explanations for why Android experiences more touch interface lag than competing mobile operating systems from Apple, Microsoft and Research in Motion.

Undergraduate software engineering student Andrew Munn posted his observations on Google+, as noted by Cult of Mac. He did disclaim, however, that he will be starting an internship with Microsoft's Windows Phone team in January, adding that any opinions from the report were his alone.

According to Munn, Android has a difficult time dealing with the touch interface because it handles rendering "on the main thread with normal priority," as opposed to iOS, which treats UI rendering with real-time priority. He cites examples of website loading and the Movies app on Android where the operating system will continue to load while registering touch input.

Munn identified several other factors that contribute to UI lag on Android. For instance, the photo gallery app in either Android 3.0 Honeycomb or 4.0 Ice Cream Sandwich is capped at 30 frames per second in order to prevent a noticeable "hiccup" at 60 FPS.

"Capping the frame rate at 30 fixes the hiccup problem at the expense of buttery smooth animations at all times," he said.

The author also pointed to hardware issues for Android. According to him, Nvidia's Tegra 2 chip limits Android because of its low memory bandwidth and lack of NEON instruction set support. Tablets based on Honeycomb would be "better off with a different GPU," such as the Samsung Hummingbird or Apple A4.

Munn noted that Android "has a ways to go" before achieving more efficient UI compositing, especially when compared against Apple's iOS.

"On iOS, each UI view is rendered separately and stored in memory, so many animations only require the GPU to recomposite UI views," he said. "GPUs are extremely good at this. Unfortunately, on Android, the UI hierarchy is flattened before rendering, so animations require every animating section of the screen to be redrawn."

Another reason for the lag is the limitations of Android's Dalvik virtual machine, which is "not as mature" as a desktop-class Java VM, Munn said. However, the issue with Dalvik will be offset by hardware acceleration from Ice Cream Sandwich on and improvements to Dalvik.

But, in spite of the improvements, Munn believes the Android user interface "will never be completely smooth because of the design constraints" that limit UI rendering to the main thread of an app with normal priority.

"Even with a Galaxy Nexus, or the quad-core EeePad Transformer Prime, there is no way to guarantee a smooth frame rate if these two design constraints remain true," he said. "Its telling that it takes the power of a Galaxy Nexus to approach the smoothness of a three year old iPhone."

According to Munn, the reason behind the design change is that the original Android prototype didn't have a touchscreen, as it was meant to be a BlackBerry competitor. As such, Android's architecture is meant to support a keyboard and trackball. Munn further claimed that after the original iPhone arrived in 2007, Google rushed to complete Android, but "it was too late to rewrite the UI framework."

He cited Windows Mobile 6.5, BlackBerry OS and Symbian as examples of other older operating systems that suffered similar problems with touch performance. Microsoft, RIM and Nokia have all abandoned those OSes in order to start from scratch. "Android is the only mobile OS left that existed pre-iPhone," the report noted.

Android Software Engineer Romain Guy admitted as much when he said that choices made years ago had contributed to work the team has to do now.

"Having the UI thread handle animations is the biggest problem," he said. "We are working on other solutions to try to improve this (schedule drawing on vsync instead of block on vsync after drawing, possible use a separate rendering thread, etc.) An easy solution would of course to create a new UI toolkit but there are many downsides to this also.

According to the report, those downsides include the fact that apps would have to be rewritten to support the new framework, Android would need legacy support for old apps and work on other Android features would be held up while the new framework was being built.

"However, I believe the rewrite must happen, despite the downsides. As an aspiring product manager, I find Androids lagginess absolutely unacceptable. It should be priority #1 for the Android team," Munn said.

UI Lag has long been an area for which reviewers have criticized Android. One recent usability study by Jakob Nielsen on Amazon's Android-based Kindle Fire found erratic scrolling and "huge lag in response after pressing command-buttons." Nielsen suspected that "sloppy programming" was causing the issue.

The New York Times' David Pogue also took issue with the Kindle Fire. "Animations are sluggish and jerky -- even the page turns that you'd think would be the pride of the Kindle team," he said in his review. "Taps sometimes don't register. There are no progress or 'wait' indicators, so you frequently don't know if the machine has even registered your touch commands. The momentum of the animations hasn't been calculated right, so the whole thing feels ornery."

Munn himself viewed the issue as damaging to Android's image. He also saw it as a violation of Google's guiding principles, which have generally led to faster, optimized products. Finally, he mentioned that UI lag breaks the direct 1-to-1 relationship that touch screens offer.

"The device no longer feels natural. It loses the magic. The user is pulled out of their interaction and must implicitly acknowledge they are using an imperfect computer simulation. I often get lost in an iPad, but I cringe when a Xoom stutters between home screens," he said.

To conclude, the report ended on a more upbeat note, with Munn voicing his belief that the Android rendering framework is in the hands of a capable team. "I know they will have it eventually," he said.

Funny out pre iPhone is used as a distinction when the iPhone is OS X, which is NeXTStep, which was designed in the 80s.

Certainly Apple designed Cocoa Touch specifically for the iPhone, but much of what is discussed here (i.e. caching object bitmaps) are things NeXTStep 1.0 did correctly. Which enabled things like live scrolling, live window movement, etc on the desktop with the same fluidity as the UI on iOS devices.

And that is one of the main reasons why every Android device has sucked so far. Some pathetic people even go as far as denying that there is any lag on Android. They're either serial liars or they're blind.

On a touch screen device, all user interaction needs to be instantaneous, not seconds after you press something. And everything needs to be smooth, not jerky.

There's also another big thing that Android can not do well, it doesn't handle audio properly, and realtime music apps is something else that doesn't exist on Android, because of the terrible latency.

But he is right, user experience is everything on these devices, so if their GUI framework is not up to scratch, it's needs to be job 1.

It can't be though because it means having to rewrite hundreds of thousands of apps to take advantage of it. Apple made sure to get this right from the start and Google should have too - same with have 32-bit rendering in every part of the OS.

I expect they will correct all the issues over time but the honesty of the engineer speaks volumes:

"Its telling that it takes the power of a Galaxy Nexus to approach the smoothness of a three year old iPhone."

Is there an explanation for the UI lag on iPhone 3G running IOS 4, even with the IOS update that was supposed to address that?

Yes.. the hardware.

Although when I had my 3G I used a jailbroken iOS 4 (with backgrounds and multi-tasking enabled) and didn't find it to be that bad. Periodically it would get a little sluggish and I would use SBSettings to free up some memory.

The cold truth is that the hardware in the iPhone 3G is not really fit for running iOS 4. (It's like trying to run leopard on a G4 with only 1gig of ram. Sure, it will do it... but it will get sluggish on occasion.)

I'm going to be upfront that I'm a non-expert but I think this sounds so similar to the mindset of the folks in Redmond: any time Windows got more complicated and slow the solution was to throw faster hardware at the problem. It's a brute force approach in contrast to careful refining, optimizing, and perfecting.

Android seems similar in that things such as processor type and speed are bandied about in marketing materials like celebrity name dropping at a party. The measure-bators boast about things like GHz and Snapdragon or Tegra or processor du jour. I probably used the wrong names but I don't care: consumers shouldn't need to know this sort of information. Really, it's not the name or speed of the processor that counts but how efficiently those cycles are utilized.

I have an older iPhone, the 3GS. Its processor must be totally obsolete by now - I'm two cycles behind the latest and greatest iPhone. However, there is absolutely no lag on my touchscreen! I've used my friends' Android-based phones and touch-response lag was very distracting.

I like my iPhone because it works well! Android just doesn't seem to be there yet. And if the intern is to be believed it sounds like it's due to some bad choices in the foundation of the Android OS...

I'm going to be upfront that I'm a non-expert but I think this sounds so similar to the mindset of the folks in Redmond: any time Windows got more complicated and slow the solution was to throw faster hardware at the problem. It's a brute force approach in contrast to careful refining, optimizing, and perfecting.

Android seems similar in that things such as processor type and speed are bandied about in marketing materials like celebrity name dropping at a party. The measure-bators boast about things like GHz and Snapdragon or Tegra or processor du jour. I probably used the wrong names but I don't care: consumers shouldn't need to know this sort of information. Really, it's not the name or speed of the processor that counts but how efficiently those cycles are utilized.

I have an older iPhone, the 3GS. Its processor must be totally obsolete by now - I'm two cycles behind the latest and greatest iPhone. However, there is absolutely no lag on my touchscreen! I've used my friends' Android-based phones and touch-response lag was very distracting.

I like my iPhone because it works well! Android just doesn't seem to be there yet. And if the intern is to be believed it sounds like it's due to some bad choices in the foundation of the Android OS...

I like your analogy. In both cases Microsoft and Google made the same mistakes: rush to release something to compete with Apple. (While sacrificing quality along the way)

Imagine what Windows and Android would be like if MS and Google took time to do things right and proper the first time...

And that is one of the main reasons why every Android device has sucked so far. Some pathetic people even go as far as denying that there is any lag on Android. They're either serial liars or they're blind.

Plenty of people (I wager also on this forum) play console games which are fixed to 30FPS, like that Android photo gallery mentioned in the original post, and seem happy even if they have previously owned a proper gaming PC which did solid 60FPS. Then there are Mac owners who watch 24p movies on a 60Hz screen which causes a stutter of similar magnitude once a second. Are all of these people serial liars or blind if they say they don't have a problem?

Quote:

On a touch screen device, all user interaction needs to be instantaneous, not seconds after you press something. And everything needs to be smooth, not jerky.

Android was made for these kind of phones. This is a Google prototype Android phone. It was only after the iPhone came out, that Touch ever entered their minds.

Silly comment.

First of all, that is a HTC Android prototype, not a Google prototype. Secondly, Android is software. If software wasn't scalable and able to be used on different form factors iOS (which is derived from OSX) would not exist as it does today.

The earliest Android SDK and prototypes were designed for touch and physical interfaces and Android as it is today is fully usable using a dpad and hardware keyboard.

"Very disappointing to have people judging something without all the facts." - charlituna.

Funny out pre iPhone is used as a distinction when the iPhone is OS X, which is NeXTStep, which was designed in the 80s.

Certainly Apple designed Cocoa Touch specifically for the iPhone, but much of what is discussed here (i.e. caching object bitmaps) are things NeXTStep 1.0 did correctly. Which enabled things like live scrolling, live window movement, etc on the desktop with the same fluidity as the UI on iOS devices.

Correct. Then again the caliber of talent at NeXT that later became infused at Apple is head and shoulders above Microsoft, RIM, Google and the rest.

Us former NeXT/Apple Engineers were always called snobs back when NeXT was doing stuff the rest of the industry called 10 years ahead and thus too far ahead for the general consumer.

These companies will not catch up. The fundamental design patterns, the design decisions with the kernel, to the mach runtime, to the happy marriage of C/C99/ObjC2.0 and even C++ with Clang [and it's compiler design has Google, RIM, ARM, Intel, IBM, Cray, AMD, Adobe, Borland and everyone else getting involved to start using it] makes it clear the teams built from this NeXT foundation continue to evolve and flourish with this latest generational talents coming from around the globe.

Plenty of people (I wager also on this forum) play console games which are fixed to 30FPS, like that Android photo gallery mentioned in the original post, and seem happy even if they have previously owned a proper gaming PC which did solid 60FPS. Then there are Mac owners who watch 24p movies on a 60Hz screen which causes a stutter of similar magnitude once a second. Are all of these people serial liars or blind if they say they don't have a problem?
Article said nothing about seconds. Hyperbole?

Watching a movie or playing a game on a non-touch device is very different than actually interacting with a touch screen device. It is very frustrating and extremely noticeable when a touch screen device is laggy, jerky and unsmooth.

Take the Kindle Fire for example. I've seen more than a few good quality videos of that in action, and if anybody denies that it is laggy, jerky, choppy and unsmooth, then they are definitely lying or they have very poor eyesight.

If you take the link in the AI article, you'll see that intern Munn was responding to a post by an Android engineer, Dianne Hackborn. She described a lot of issues related to the implementation of hardware acceleration in Android past and present. It's a good thing to read before commenting on this article as it seems to be fact-laden and free of bias, pointing out both the shortcomings and the progress in that area.

On a touch screen device, all user interaction needs to be instantaneous, not seconds after you press something. And everything needs to be smooth, not jerky.

There's also another big thing that Android can not do well, it doesn't handle audio properly, and realtime music apps is something else that doesn't exist on Android, because of the terrible latency.

And with regards to you Apple ][, I love my Apple products as much as the next guy, but your comments really make me sick. You look utterly ignorant in about half of your posts. Sure, you're totally anonymous here on the internet, but have a little respect for yourself.

I agree with what you wrote, but I also think that it's pretty much impossible for them to have gotten it right on the first try, as they both basically copied whatever Apple came out with.

That's exactly my point. They sacrificed quality for a quicker release to compete. Even if they said "oh wow, look at the iPhone... let's go touchscreen!" they should have taken the proper time to do it right. Even if it took longer to ship... they'd have a stronger product today.

Then again... the strategy of "we didn't do it first, but we did it best" could also be used to accuse them of copying Apple. (not by product but by method)

And with regards to you Apple ][, I love my Apple products as much as the next guy, but your comments really make me sick. You look utterly ignorant in about half of your posts. Sure, you're totally anonymous here on the internet, but have a little respect for yourself.

Ignorant would mean that you're claiming that I don't know what I'm talking about.

You are welcome to refute anything that I've written in this thread, if you feel that something is incorrect. Otherwise, whining will get you nowhere.

Watching a movie or playing a game on a non-touch device is very different than actually interacting with a touch screen device. It is very frustrating and extremely noticeable when a touch screen device is laggy, jerky and unsmooth.

Naturally those things make experience worse. But they are largely quantifiable things. When you say there are seconds of lag, that's an actual time unit. Please be more specific with your criticism: what devices, what software, what situation?

I disagree that playing a game on screen is very different, BTW. There are certain games (mainly ports of arcade games) which I would simply not buy if a review tells me they fail to reach 60Hz, because lag is so completely destructive to those experiences.

Quote:

Take the Kindle Fire for example. I've seen more than a few good quality videos of that in action, and if anybody denies that it is laggy, jerky, choppy and unsmooth, then they are definitely lying or they have very poor eyesight.

No, I will not take Kindle Fire for example. It's an almost-bottom-of-the-barrel product, built on an ancient version of Android that is not designed for tablets, and tuned by Amazon. Amazon doesn't even call it an "Android" device, which I commend them for.

Naturally those things make experience worse. But they are largely quantifiable things. When you say there are seconds of lag, that's an actual time unit. Please be more specific with your criticism: what devices, what software, what situation?

You're acting as if you never heard anybody mention anything about Android lag before. People have been talking about it on various sites for ages now, ever since Android was first introduced. There is plenty of evidence on the internet all over the place. It's been mentioned in countless reviews for a variety of different devices.

This whole thread and the article in the OP is about Android in general. It is a problem that exists on the Android OS, though some of the newer devices attempt to mask the problem with the OS by using brute force and more powerful CPU's.

Quote:

Originally Posted by Gon

I disagree that playing a game on screen is very different, BTW. There are certain games (mainly ports of arcade games) which I would simply not buy if a review tells me they fail to reach 60Hz, because lag is so completely destructive to those experiences.

I'm no expert on gaming, but I thought that Hz has more to do with the monitor/tv than the software. I always see frames per second being used when people talk about how good games run. But I agree that having a good framerate for a game is pretty important. I don't often play games, but when I do, it has to be on a powerful machine.

Quote:

Originally Posted by Gon

No, I will not take Kindle Fire for example. It's an almost-bottom-of-the-barrel product, built on an ancient version of Android that is not designed for tablets, and tuned by Amazon. Amazon doesn't even call it an "Android" device, which I commend them for.

So you can name an Android tablet then. Which one do you claim does not suffer from any lag, choppiness and has a smooth operation?

9to5 had an article on this a few days ago. The "lag" referred to here is real, and has been addressed in many ways in ICS according to them. New API's, reworking display layering, etc. have made the experience much improved. Rather than quote an entire page, if anyone is interested in reading a much cleaner and easier to understand explanation of the causes and changes, here's the link:

For those that don't feel it's worth the time to read, continue on with posting misinformation.

EDIT 12/11:
Andrew Munn, the source for this story, has now modified his views on Android. To quote "BEFORE READING: A LOT OF MY ANALYSIS OF ANDROID PERFORMANCE IS WRONG, HOWEVER I AM LEAVING THIS POST UP BECAUSE OF MY COMMENTARY ON THE ISSUE."

You're acting as if you never heard anybody mention anything about Android lag before. People have been talking about it on various sites for ages now, ever since Android was first introduced. There is plenty of evidence on the internet all over the place. It's been mentioned in countless reviews for a variety of different devices.

I have heard mentions of it. So has everyone else. That's exactly why you should stop repeating these general statements ad nauseaum. Specifics contribute to the discussion, repeating what has already been said does not. Compare these discussions --

A: [Specific Android 3.0 tablet] lags in ways X, Y, Z.
B: Z seems to be unique to the device. X should be fixed in 4.0 but problem W will still be there.
(week goes by)
A: W is probably because Q. BTW, iOS5 doesn't do Q so it has no W problem, but it has trouble with S which is related.
B: Looks like the upcoming 4.1 fixes Y

I'm no expert on gaming, but I thought that Hz has more to do with the monitor/tv than the software. I always see frames per second being used when people talk about how good games run. But I agree that having a good framerate for a game is pretty important. I don't often play games, but when I do, it has to be on a powerful machine.

Hz is just s^-1, basic physics, so I can use it to describe framerate, screen refresh rate, game logic and whatnot.

Quote:

So you can name an Android tablet then. Which one do you claim does not suffer from any lag, choppiness and has a smooth operation?

9to5 had an article on this a few days ago. The "lag" referred to here is real, and has been addressed in many ways in ICS according to them. New API's, reworking display layering, etc. have made the experience much improved. Rather than quote an entire page, if anyone is interested in reading a much cleaner and easier to understand explanation of the causes and changes, here's the link:

I have heard mentions of it. So has everyone else. That's exactly why you should stop repeating these general statements ad nauseaum. Specifics contribute to the discussion, repeating what has already been said does not.

Specifics have been discussed here before, whenever there is a topic about a specific tablet. The most recent tablet that is getting specifically talked about is the Kindle Fire, since that it is the one that is most recent and in the news and on this forum. You mentioned that it's practically bottom of the barrel, and I obviously agree with that, but other tablets have been talked about here that were not supposed to be bottom of the barrel.

I remember specifics being talked about other tablets, like the Xoom and the Touchpad a while ago on this forum.

For those that don't feel it's worth the time to read, continue on with posting misinformation.

The article basically confirms that those people (like me) who have been calling Android laggy and choppy all this time have been 100% correct, and anybody denying that was living in a perverse fantasy world and they were wrong, as even Google's engineers are now attempting to explain the problems they've been having and what they're trying to do to fix it.

Specifics have been discussed here before, whenever there is a topic about a specific tablet. The most recent tablet that is getting specifically talked about is the Kindle Fire, since that it is the one that is most recent and in the news and on this forum. You mentioned that it's practically bottom of the barrel, and I obviously agree with that, but other tablets have been talked about here that were not supposed to be bottom of the barrel.

I remember specifics being talked about other tablets, like the Xoom and the Touchpad a while ago on this forum.

I'm sure you have on occasion made insightful posts in other threads. It doesn't follow that it's cool to spout empty and/or unfounded generalities in this thread.

Quote:

Originally Posted by Apple ][

And that [lag] is one of the main reasons why every Android device has sucked so far.

Emphasis mine. In which ways does the Galaxy Nexus or the Galaxy S II lag so badly it makes the whole device suck?

Quote:

Some pathetic people even go as far as denying that there is any lag on Android. They're either serial liars or they're blind.

Who says this? If it's a lone nutcase, why does it matter what he says? Why would you even bother to insult him?

Many ardent Apple fans molest children. In light of statistics that's almost certainly a true statement, but the only reason to say it is to associate ardent Apple fans with child molestation where no actual correlation exists.

Quote:

On a touch screen device, all user interaction needs to be instantaneous, not seconds after you press something. And everything needs to be smooth, not jerky.

Do all Android devices have seconds of lag? Any 4.0 devices? 3.2 devices?

Is there an explanation for the UI lag on iPhone 3G running IOS 4, even with the IOS update that was supposed to address that?

I'd argue that, iOS 4.0 GM aside, the 3G generally acknowledges your input and THEN takes forever to complete the requested action. Even today, scrolling an already loaded web page on the 3G is flawlessly smooth, even if you quickly get to an unrendered portion of the page. Sure, it shows you the tiled blocks before it paints the image, but it still feels smooth because those blocks move perfectly with your touch. Brand freakin' new Android phones can't manage this yet. Straight out of the box, scrolling a web page appears to happen at maybe 10fps and never does the animation start and stop perfectly in tune with the position of your finger on the screen.

Just as I thought. iOS is a real-time operating system. It is harder to master,

... you say this based on what experience with iOS and Android development?

Quote:

but infinitely more efficient than a run-time virtual machine that "interpret" instructions on the fly like the Android.

"Infinitely more efficient"? Please. Virtual machines have been sporadically reaching close-to-native-compiled performance many years ago. There are more and less efficient ones, but simply knowing the code is running on a virtual machine doesn't tell you much of anything about performance.

Also, it sounds suspiciously like you haven't heard of this thing called Android NDK.

Quote:

Android camp choose to use the Java VM, which helps it to get to market faster, but needs faster hardware to compensate its inefficiencies.

Note, this is the same approach Microsoft did with Windows. We'll see what happens this time around

Same approach Microsoft did with Windows... huh? Are you talking about .NET common language runtime or what?

Just as I thought. iOS is a real-time operating system. It is harder to master, but infinitely more efficient than a run-time virtual machine that "interpret" instructions on the fly like the Android.

Android camp choose to use the Java VM, which helps it to get to market faster, but needs faster hardware to compensate its inefficiencies.

Note, this is the same approach Microsoft did with Windows. We'll see what happens this time around

He said Apple gives UI updates a real time priority. There's a difference between the use of the term real time to refer to thread priority and a true Real Time operating system. That being said, iOS could possibly be classified as a RTOS depending on how its scheduler works, timing predictability, and architecture.

despite what is said in the article, it seems that a smooth UI isn't that high of a priority for google..

Despite how bad I really hated the few times I had to work in Android because of its 'way more beta than even Siri' feeling, this is an intern who probably has little clue about what the upper boys are thinking in terms of priority. Any perception that they don't care is really just his personal view.

And I wouldn't really trust him to know what's up in iOS given a lack of any qualifying data like say just the fact that he's written an app for the device. His only listed qualification to talk about anything was 'intern at Google' and 'undergraduate student'. Not really confidence inspiring. Now give me 'Senior App Engineer for Halfbrick/Rovio/another big app developer that has worked with both systems' and I'd feel more confident

This is going to be in the history books! Having been closely involved in the history of this industry since 1978 this is amazing absolutely amazing, you couldn't write a novel as good as this.

By rushing to copy iOS as soon as Schmidt ran over from his Apple Board seat to spill the beans using their Blackberry copy as a base rather than starting over and ripping off iOS from scratch. It was obviously either a calculated risk based on timing or simply ignorance of what a mess they were creating going the route they did. Lack of any previous knowledge of touch UI most likely means option 2.

I would love to know who pushed for speed over good reverse engineering Microsoft style if they'd waited to get their hands on iOS Android would work properly. My money is on Schmidt who must have become obsessed with doing this before Apple realized his duplicity and asked him to resign.

What an ironic corner Google have painted themselves into. It's like Windows all over again, it's a total mess but their own success makes it almost impossible to fix due the sheer number of apps that would cease to work if they brought Android up to iOS standards.

From Apple ][ - to new Mac Pro I've owned them all.Long on AAPL so biased"Google doesn't sell you anything, Google just sells you!"