Shared publicly  - 
 
Follow up to “Android graphics true facts”, or The Reason Android is Laggy


Edit: +Dianne Hackborn has written a response to this post. She clarifies things about Android that I got wrong, and fundamentally rejects the thesis of this post by suggesting that the increased security and flexibility of the Android platform over iOS is a cause of performance overhead and that increasingly fast hardware will help resolve the issue:

https://plus.google.com/105051985738280261832/posts/XAZ4CeVP6DC

It would be wise to trust her word over mine, as she is the final word on Android framework issues.

Edit #2: +Bob Lee, CTO of Square, and former lead developer on the Android library has written a post that points out technically inaccuracies I made:

http://blog.crazybob.org/2011/12/truth-about-android-ios-ui-performance.html

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

Yesterday +Dianne Hackborn posted to Google+ an article that dismissed the common accusation that Android is laggy because UI rendering wasn’t hardware accelerated until Honeycomb:

https://plus.google.com/105051985738280261832/posts/2FXDCz8x93s

It’s an insightful post that illuminates many of the complex issues with smooth Android rendering. Unfortunately, it doesn’t answer the fundamental question asked by both technical and nontechnical android users:


Why is Android laggy, while iOS, Windows Phone 7, QNX, and WebOS are fluid?
This post will attempt to answer that question.

However before I jump in, a couple disclaimers. First, I am a 3rd year undergraduate software engineering student. I interned on the Android team, and +Romain Guy who was responsible for much of the hardware acceleration work in Honeycomb, reviewed some of my code, but I was not on the framework team and I never read the Android rendering source code. I do not have any authoritative Android knowledge and I cannot guarantee what I say here is necessarily 100% accurate, but I have done my best to do my homework.

Second, I’m interning with the Windows Phone team starting in January, so it’s possible that this post will be unconsciously biased against Android, but if you ask any of my friends, it’s really hard to shut me up about Android. I have more Android t-shirts than days of the week and I’d rather give away my Macbook than my Nexus S. The Googlplex is like a second home - I’ve slept there on more than a few occasions to the dismay of startled janitors (and if you ever get a chance to visit, the banana french toast at Big Table Cafe is to die for). If anything, I’m probably biased in Android’s favor.

Finally, any opinions expressed in this article are solely my own and do not represent those of any past or future employers.

With that out of the way, lets dive right in.

Dianne starts off her post with a surprising revelation:

“Looking at drawing inside of a window, you don’t necessarily need to do this in hardware to achieve full 60fps rendering. This depends very much on the number of pixels in your display and the speed of your CPU. For example, Nexus S has no trouble doing 60fps rendering of all the normal stuff you see in the Android UI like scrolling lists on its 800x480 screen.”

Hun? How can this be the case? Anybody who’s used a Nexus S knows it slows down in all but the simplest of ListViews. And forget any semblance of decent performance if a background task is occurring, like installing an app or updating the UI from disk. On the other hand, iOS is 100% smooth even when installing apps. But we know Dianne isn’t lying about the potential CPU performance, so what’s going on?

The Root Cause

It’s not GC pauses. It’s not because Android runs bytecode and iOS runs native code. 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 a not an abstract or academic difference. You can see it for yourself. Grab your closest iPad or iPhone and open Safari. Start loading a complex web page like Facebook. Half way through loading, put your finger on the screen and move it around. All rendering instantly stops. The website will literally never load until you remove your finger. This is because the UI thread is intercepting all events and rendering the UI at real-time priority.

If you repeat this exercise on Android, you’ll notice that the browser will attempt to both animate the page and render the HTML, and do an ‘ok’ job at both. On Android, this a case where an efficient dual core processor really helps, which is why the Galaxy S II is famous for its smoothness.

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. Android tries to do both at the same priority, so the frame rate suffers. Once you notice this happening, you’ll see it everywhere on an Android phone. Why is scrolling in the Movies app slow? Because movie cover thumbnails are dynamically added to the movie list as you scroll down, while on iOS they are lazily added after all scrolling stops.

EDIT:[Several people (+Chi-Ho Kwok and +Brent Royal-Gordon especially) have taken the time to explain some mistakes I made in my description of iOS. The fundamental distinction between Android and iOS rendering I identified still stands, but I made some over simpliifcations in my description of iOS because I wasn't familar enough with the workings. I'll let +Brent Royal-Gordon explain:

"The iOS description here isn't quite accurate. There are several things at work:

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.

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.

* This isn't strictly true: the main thread is put into a special mode during touch tracking, and by default, certain callbacks are delayed in that mode. However, a lot of other things, like loads from disk or network activity kept completely on a background thread, are not paused; nor is anything automatically paused during momentum scrolling. The developer has to explicitly delay those things." ]

Other Reasons

The fundamental reason Android is laggy is UI rendering threading and priority, but it’s not the only reason. First, hardware acceleration, despite Dianna’s reservations, does help. My Nexus S has never been snappier since upgrading to ICS. Hardware acceleration makes a huge difference in apps like the home screen and Android market. Offloading rendering to the GPU also increases battery life, because GPUs are fixed-function hardware, so they operate at a lower power envelope.

Second, contrary to what I claimed earlier, garbage collection is still a problem, even with the work on concurrent GC in Dalvik. For example, if you’ve ever used the photo gallery app in Honeycomb or ICS you may wonder why the frame rate is low. It turns out the frame rate is capped at 30 FPS because without the cap, swiping through photos proceeds at 60 FPS most of the time, but occasionally a GC pause causes a noticeable “hiccup”. Capping the frame rate at 30 fixes the hiccup problem at the expense of buttery smooth animations at all times.

Third, there are the hardware problems that Dianne discussed. The Tegra 2, despite Nvidia’s grandiose marketing claims, is hurt by low memory bandwidth and no NEON instruction set support (NEON instructions are the ARM equivalent of Intel’s SSE, which allow for faster matrix math on CPUs). Honeycomb tablets would be better off with a different GPU, even if it was theoretically less powerful in some respects than the Tegra 2. For example, the Samsung Hummingbird in the Nexus S or Apple A4. It’s telling that the fastest released Honeycomb tablet, the Galaxy Tab 7.7, is running the Exynos CPU from the Galaxy S II.

Fourth, Android has a ways to go toward more efficient UI compositing. On iOS, each UI view is rendered separately and stored in memory, so many animations only require the GPU to recomposite UI views. 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.

Fifth, the Dalvik VM is not as mature as a desktop class JVM. Java is notorious for terrible GUI performance on desktop. However, many of the issues don’t carry over to the Dalvik implementation. Swing was terrible because it was a cross platform layer on top of native APIs. It is interesting to note that Windows Phone 7’s core UI is built in native code, even though the original plan was to base it entirely on Silverlight. Microsoft ultimately decided that to get the kind of UI performance required, the code would have to be native. It’s easy to see the difference between native and bytecode on Windows Phone 7, because third party apps are written in Silverlight and have inferior performance (NoDo and Mango have alleviated this problem and the Silverlight UIs are generally very smooth now).

Thankfully, each of the five issues listed above is solvable without radical changes to Android. Hardware acceleration will be on all Android phones running ICS, Dalvik continues to improve GC efficiency, the Tegra 2 is finally obsolete, there are existing workarounds for the UI compositing problems, and Dalvik becomes a faster VM with every release. I recently asked +Jason Kincaid of +TechCrunch if his Galaxy Nexus was smooth, and he had this to say:

“In general I've found ICS on the Galaxy Nexus to be quite smooth. There are occasional stutters — the one place where I can consistently get jitters on the Galaxy Nexus is when I hit the multitasking button, where it often will pause for a quarter second. That said, I find that the iPhone 4S also jitters more than I had expected, especially when I go to access the systemwide search (where you swipe left from the home screen).”

So there you go, the Android lag problem is mostly solved, right? Not so fast.

Going Forward

Android UI will never be completely smooth because of the design constraints I discussed at the beginning:

- UI rendering occurs on the main thread of an app
- UI rendering has 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. It’s telling that it takes the power of a Galaxy Nexus to approach the smoothness of a three year old iPhone. So why did the Android team design the rendering framework like this?

Work on Android started before the release of the iPhone, and at the time Android was designed to be a competitor to the Blackberry. The original Android prototype wasn’t a touch screen device. Android’s rendering trade-offs make sense for a keyboard and trackball device. When the iPhone came out, the Android team rushed to release a competitor product, but unfortunately it was too late to rewrite the UI framework.

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

So, why doesn’t the Android team rewrite the rendering framework? I’ll let Romain Guy explain:

“...a lot of the work we have to do today is because of certain choices made years ago... ...having the UI thread handle animations is the biggest problem. 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.”

Romain doesn’t elaborate on what the downsides are, but it’s not difficult to speculate:

- All Apps would have to be re-written to support the new framework
- Android would need a legacy support mode for old apps
- Work on other Android features would be stalled while the new framework is developed

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

When the topic of Android comes up with both technical and nontechnical friends, I hear over and over that Android is laggy and slow. The reality is that Android can open apps and render web pages as fast or faster than iOS, but perception is everything. Fixing the UI lag will go a long way to repairing Android’s image.

Beyond the perception issue, lag is a violation of one of Google’s core philosophies. Google believes that things should be fast. That’s a driving philosophy behind Google Search, Gmail, and Chrome. It’s why Google created SPDY to improve on HTTP. It’s why Google builds tools to help websites optimize their site. It’s why Google runs it’s own CDN. It’s why Google Maps is rendered in WebGL. It’s why buffering on Youtube is something most of us remember, but rarely see anymore.

But perhaps the most salient reason why UI lag in Android is unacceptable comes from the field of Human-Computer Interaction (HCI). Modern touch screens imply an affordance language of 1 to 1 mapping between your finger and animations on the screen. This is why the iOS over-scroll (elastic band) effect is so cool, fun, and intuitive. And this is why the touch screens on Virgin America Flights are so frustrating: they are incredibly laggy, unresponsive, and imprecise.

A laggy UI breaks the core affordance language of a touch screen. 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. The 200 million users of Android deserve better.

And I know they will have it eventually. The Android team is one of the most dedicated and talented development teams in the world. With stars like +Dianne Hackborn and +Romain Guy around, the Android rendering framework is in good hands.

I hope this post has reduced confusion surrounding Android lag. With some luck, Android 5.0 will bring the buttery-smooth Android we’ve all dreamed about since we first held an HTC G1. In the mean time, I’ll be in Redmond working my butt off trying to get a beautiful and smooth mobile OS some of the recognition it deserves.

Credits

Parts of this post was inspired by this reddit comment by ddtro who explained the UI thread and real-time issue:
http://www.reddit.com/r/Android/comments/mztwk/facts_and_fiction_about_android_graphics/c358f0x

This explanation of Android versus iOS UI compositing on Hacker News by Corun was illuminating:
http://news.ycombinator.com/item?id=3310475

Information about Android’s historical roots taken from In the Plex by +Steven Levy and Steve Jobs by Walter Isaacson
2525
2296
Daniele Mazzini's profile photoScott Le Grand's profile photoJoe Lancaster's profile photoNisachar singh's profile photo
227 comments
 
I guess this is a prime example of effort != quality. There are just so many issues with this article I don't know where to start, but as you've basically shortened the whole thing into two points halfway, I'll react on those two:


"UI rendering occurs on the main thread of an app" means you've violated the most important contract of Android coding: do NOT place anything slow on the UI thread. Strict mode checks for most causes of blocked UI threads and posts it to the error log, there's no excuse to have a laggy UI.

"UI rendering has normal priority" is solved by the standard solution to #1: AsyncTask sets itself to background priority before execution so it will never interrupt the UI thread and only run when it yields.

None of this is new, as this API is already here since Android 1.5. Yes, it takes more effort to get it right, but you know what? I prefer to control when my threads run and use every bit of spare time to do useful work, whenever the UI thread yields and using all the spare cores. Stop the world to run an animation is so crude.

[edit] I've gathered my two comments in this thread at https://plus.google.com/u/0/100952146715427669835/posts/MWAJ73cT4t7, and created a follow up on how to make sure your app doesn't lag on https://plus.google.com/u/0/100952146715427669835/posts/fyXcLqYADqF
 
Thanks for explaining this.
 
+Chi-Ho Kwok What your saying is correct. Using background threads for work is the standard Android design pattern, but it's still not good enough for the reasons I explain in my post. If it was, Android wouldn't continue to have this problem. The only thing that can really fix it is framework redesign.
 
Great post, very informative. However, I'm a bit curious as to how the underpinnings of Android work since it is based on Linux. Does Android have its own window manager like GTK / Aura and does it use anything like X11 or Wayland to talk directly to the hardware? Or is it all together entirely different?
 
This was much more informative than the post it was responding to.

With all due respect to the Android team and the amazing things they have done, pointing fingers at design decisions doesn't address or mollify anyone, particularly if more than one other groups have working solutions in the market.
 
After reading this I can't say I completely agree that a UI framework re-write is the only choice. Perhaps a new, amazing, and dare I say revolutionary approach is needed. Something no one's done before. That's the path Google should take I think.
 
A 'revolutionary path' that doesn't involve re-writing the current 'path'? That would be quite a feat, no? :)
 
Let me rephrase: A new UI framework based upon existing ideas(Such as those used by apple) may not be the best choice. Insteady, letting the current UI mature while in a seperate project working on a completely new way of going about UI threading would suit google better. Once this is in hand, THEN you overhaul the UI Framework.
 
"""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.""" <- 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.""" <- 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.
Matt R
+
3
4
3
 
wait, isnt' what you're talking about doing what would cause the exact same problem as iOS? as in: rendering thread takes priority over processing and thus touching the screen basically = processing problem (if they didn't' go the rewrite the UI route)? Haven't we basically experienced fundamental design and UI revisions to some degree with every iteration of android?
 
+Chi-Ho Kwok "you've violated the most important contract of Android coding". But... from my reading, it seems the Android team themselves are violating this important contract in their own apps, no? Pretty much every experience I've had on any Android device has included laggy/bad scrolling in the UI. So... if this is just an "app layer" problem, why does the default Android stuff also exhibit this?
 
Thanks for this, was linked in an Android thread on a forum.
 
All very good except saying Dalvik is "not as mature" as a desktop JVM. Hotspot would be a terrible approach for mobile devices, for example. And you rightly say Swing would be terrible, too. Android, on the other hand, has native code fairly thinly covered by, for example, the View class.
 
+Andrew Munn It's not the only thing that's wrong in the post, but I guess I'll take on a few more points. Threading and priority is the #1 issue everywhere, but in a world of broken and half broken apps, I don't expect everyone to do it right unless you force them.

Note that while the "UI thread" on iOS and WP7 may look like a real time thread, it's just another thread in the system, but one that stops everything else. It "fixes" the problem, but in my opinion, it's undesirable.


For the rest of the points:
"second": no, not really. Even if an app GC's frequently, it's a 50ms pause on ancient devices, or 3 skipped frames, and less on the hardware mentioned. It won't be laggy, as in, visible jerky animations with 10 or less FPS, lasting seconds. Capping in the gallery is probably done so background threads have breathing room to load data and catch up. If we would do if your way, it means we'll be scrolling a huge list of grey rectangles and never show anything while the finger is on the screen or if you keep flinging. The Windows phone 7's gallery does it right - it loads pictures faster than you can flick while having a butter smooth UI. It's the best, but as that's not available, I'll take a 30 FPS gallery over the HTC gallery any day. In my experience, we can fetch a hundred rows from the DB, do postprocessing and setup the views before a 250ms animation is over. In your world, the user would have to wait longer to see any useful data on the screen.

"third": Yes, hardware differs. No, it doesn't matter for rendering UI's and smoothness. Most of the laggy apps are beyond redemption, and a faster canvas implementation by using NEON (http://www.google.com/codesearch#search&q=NEON+package:http://skia\.googlecode\.com) won't save it.

"forth": composition is defined by me, the programmer. I can tell android to do composition via bitmaps and off screen buffers like iOS does, or just draw these 4 lines and a string directly on the target frame buffer. Both methods have pros and cons, and I use both depending on the view. Composition is done by the GPU since Honeycomb, but as I can hit a solid 60 FPS on a layout with 3x 200+ View elements on ancient hardware, so it's basically PEBCAK. If you must cheat more because the view is even more complex, just draw it into a bitmap and show that instead. Voila, the iOS way of animation. It's just one call to setDrawingCacheEnabled, but it isn't done by default because changing content inside that off screen buffer means drawing it twice, once to the bitmap and then to the screen, or even worse if it's deeply nested.

"fifth": Swing has nothing to do with this, but calling it slow "because it's a cross platform layer" shows ignorance. It uses Direct3d for composition and off screen buffers on the GPU for rendering, and it's a whole lot more manageable than win32. It doesn't have weird issues like deeply nesting panels causes resizes to go wrong (http://news.jrsoftware.org/news/toolbar2000/msg07779.html, a huge problem in Adobe reader 9.x). It's interesting that you mention windows phone, because it works just the same like Android: a native .net CLR running bytecodes above it.


I agree that Android's laggyness will never fix itself, but for a different reason. If you allow programmers to slack and do stuff on the UI thread, they will. There's no fix for that.
 
Finally someone who explains Android's problem without assuming it's actually OK. The tone of the article versus that of Hackborn's is immensely welcome.
 
Great post! You're right, the perception is what matters of all things.

The Android team should definitely focus on a more innovative framework, one that would be even better than iOS. Keeping things fundamental always pays off...
 
Good luck working on windows mobile, I hope that pays off for you.
 
I'd just like to say that BeOS has had threaded UI for this reason (and its old) :)
 
Great post, thanks! Since the advent of dual core, I always thought that one core would be dedicated to the UI thread with real time priority. Sadly, that didn't happen. The other factor for me in creating smooth UI has been the limited heap space an app gets in Android. This seriously limits how much you can cache in memory. This means, for example, that with PressReader in Android, you can fling the page previews and they lazily load as the scrolling slows down (hence you see mostly empty boxes) but on iOS, all the previews are preloaded into RAM so flinging is smooth and all the page reviews are visible all the time. It would be great if an app's heap space could grow to use up all available RAM if need be.
 
+Andrew Munn Is there a programmatic way to test UI responsiveness on an Android device? I'd like to develop a benchmark. Is there a good way to try to cause lag and then see how bad it is? The lag always seems to be random and hard to measure.
 
Thank you. As and avid android user, I have always wanted an explanation. Now if someone could only explain the whole Android phone degradation over time phenomenon.
 
Awesome article! Clears up a lot of things :)
 
+Jonathan El-Bizri I feel your pain... I had realtime generative audio running fine on an iPad 1 but had to switch to rendered audio for Android due to the lag in audio processing.

When my old iPhone 3G (not 3Gs, just 3G) feels snappier than my Dual Core Atrix, you know there's a fundamental issue with the OS.
Min Lee
+
4
5
4
 
So what is samsung doing differently than the rest of the android manufacturer to make the GUI related tasks so smooth on the SGSII?
 
Change Android framework from Java/Dalvik to C++0x/Qt ((dead) MeeGo (with Qt and QML) is still the smoothest and stable mobile OS (even more than iOS) and much easier to write application than Java).
 
I've had 2 android devices now, and I've loved them both for their immense tweakability. I've never really noticed any lag that I would consider to be irritating because I'm too busy fiddling with stuff. Not everyone is bothered by trivial things like barely noticable lag - something that the market share figures prove.
 
It's funny that google hires so many PhDs but managed to get basic assumptions/priorities wrong. 
 
Something wrong in the post anyway, why the ui should lag why installing an application for example? Are 2 different threads, so it can't handle 2 threads at same time and at the same priority? Why the ui thread should require much priority? (just some curious questions)
I think something is releated to the dalvik cache being regenerated (too much load for the cpu? ) for the app you are installing, in that case
Min Lee
 
+Peter Walker Which two devices? If you have tendencies to go back and fourth between different devices, lags will be the first thing you will notice. SGSII is the sole reason why i got rid of the 10.1 and waited for the 7.7. SGSII is also the reason why i replaced the ipad1 with 10.1..
 
+Min Lee The SGSII uses the Exynos 4210 processor which is dual core, and has more memory bandwidth than the Tegra 2 or Hummingbird.
 
Considering that Android is at API #14 without any real movement in the core problem area through 14 revisions (separate UI rendering with highest priority), it's heading for an WinMobile legacy death at this rate. They need to cut and fix it now, or it's already too late.
 
+Domenico Casillo thanks! That means a lot :) Although it turns out I made a couple mistakes about how iOS works, so I may release a revised version.
 
+Andrew Munn your response to +Dianne Hackborn gets right to the point in plain English without skirting around the issues. Probably the best post I've read on Android and UI rendering.
 
+Chi-Ho Kwok mentioned that many laggy android apps are doing non-UI work in their UI thread, then +Andrew Munn said fixing this is not sufficient because it lacks the high priority UI render thread that iOS has. However the lack of a high priority UI thread can easily be resolved by fixing the OS's thread scheduling algorithm. Foreground tasks could have their scheduling priority raised and if needed give a larger boost if certain IO is in progress. This would create an equivalent system to iOS's without needing a redesign.
 
Really well written, and diagnosis. Bravo.
 
Very informative and to the point...thanks for this post
 
+Michael Kimsal I've no idea what they are thinking. I've noticed that on older devices, apps like Maps just have too much to do with too little power. If you remember the old, png tiles based Maps application, that one used to run fine, but the newer vector & eGL/3D (= hardware accelerated!) one has serious lag issues on the Nexus one. It's just too much work for the poor phone; boost the UI priority and the map may never load, but don't, and it will be crazily laggy. They picked content over UI response there.

Lighter apps like GMail, the browser (excluding the first setup and .js running pass) all scroll fine, but whenever it gets data heavy, it fails. Ironically, Google+ is one of the worst, with an infinite amount of posts to display and being very image heavy, I wish they'd spend more time polishing it for older devices. It's kinda silly that Google wants you to target every device since 1.6/2.0 with your own apps, but fail hard to set the right example.
 
Incredible post and explanation. Roaring applause. Bravo!
 
This gives me the reason that my Samsung Nexus is UI laggy, and its battery lasts so short.
Jobs will say, what's a holyshit.
 
Well...thats a situation they got in there!!!! Its hard to choose between fixing the lag and put on second plan the development of new features, however definitely this will have to be fixed, its almost inadmissible these days its happens....and by the way, so the 7.7tab has better cpu that the 10.1 tab....not good news...

In my point of view, Android lack of a good image UI, fortunately the new ICS seems to fix this also honeycomb gave a good help :) screen lag and from an outsider view, Android lacks marketing team like the apple one and Nokia....have you seen the Lumia presentation in London? Jesus Christ!! It was wonderful, and the phone isnt even nothing special......
Android remains for appasionate of good stuff......

PS: Im and Android lover.....
 
I'm sorry but I'm fairly confident that most of what's what's written in your post just isn't true even if it seems to be a plausible simple explanation.
 
Perhaps since Android is open source, members of the AOSP community could be the ones who offer a solution if Google assigns this a lower priority.
 
Great article, +Andrew Munn, thanks for that!

However, choppy/stuttery != laggy. 'Lag' implies consistent but delayed reaction, as if when moving the finger, the UI waits, and then follows the movement of the finger at a delay (which is not Android's issue). ;)
 
Ok... but why does my android lag especially when im receiving an SMS or an MMS. Like, if I'm doing anything and my phone suddenly starts trying to download a simple text message of about 5 words, the whole phone process turns into molasses and it's a good minute at least until my phone in useable again.
 
Thanks for a good explaination!
Most apps needed to be ported to ICS anyway, so Google could have implemented it in ICS itself. What better place was there to start?
 
Is GC running on the same thread as UI? If it is just offloading that to another thread with lower priority would help
 
+Alex Volovoy Android's GC is already concurrent (ie, in another thread), but not all the work of a GC can be done concurrently. There will always be GC pauses. However, in theory, an incremental garbage collector can reduce the length of each pause to a point where they wouldn't be noticed by the end user.
 
Technical talk aside. I agree completely that "perception is everything." People use the newest apps/features, while streaming music, playing angry birds, then suddenly jump to the browser to watch a youtube video and wonder why it "lags" for 10 seconds. Not to mention the fact many android phones are garbage loaded with "OEM customizations" and preinstalled apps.

Although I don't think it is acceptable, and I want android phones to muli-task like my desktop. It really is more about perception than any actual difference.

Also my xoom runs so smooth, so not sure what you are talking about there.
 
Open contacts on Xoom. Grab iPad and open address book. Scroll both. It's not even funny. 
 
My contacts scrolls fine? How many contacts would it take to make it slow?
Ian Laird
+
1
2
3
2
 
my thoughts:

android kicks ass in every department.

/mutepost
 
+Andrew Munn >> However, in theory, an incremental garbage collector can reduce the length of each pause

this is what happened on server side when better-than-default GCs were introduced. Seems like this issue (and UI thread issue) are simply a replay of the situation "big" Java VMs faced a decade ago. Platform will mature and this will go away.
 
Informative, interesting and very well written. It still won't change my opinion at all. I might notice some lag on my stock, Gingerbread Nexus S, but it does not detract from the functionality of the OS, which is my primary concern. It's still pretty neat.
 
When is Sprint going to push the ICS update on my Nexus S?
 
Thanks for a well written article and explanation!
 
Good explanation. Looks like apple had it right all along.
 
+Mikhail Garber Uhm, Java had it "a decade ago" and Android is at Version 4.0. Doesn’t it make you wonder how long still people will have to wait for the platform to "mature"? Seriously, it’s like with every release of Android, its tagline is "but it will get better in the next version". Well, thank God there are features like the completely reliable and fool-proof Face Unlock being added, then.

This all keeps reminding me waay too much of the "Next year will be the year of the Linux Desktop™". And I have lost faith that Google is even able to focus enough to make it really happen—I’m even more impressed with Microsoft’s efforts, lately. The longer Team Android Freedom Force keeps up this kind of quality work, the more Android will slip towards simply being Feature Phone 2.0, instead of Smart Phone in people’s minds.
 
weird. Why does my previous iphone 4 lags so much when I'm installing from the appstore. One time it actually freezed and I have to wait for the battery to run out. My ipod touch 4th gen does the same when going into the search screen. Is apple fucking with me? Nevermind the wp7, cause it doesn't exist
 
Actually your assumption for how iOS works is not quite correct. It is correct that all UI activity has to takes place on a dedicated thread, however everything else doesn't stop while it does it. The reason why your safari example works the way it does is because even though more stuff has downloaded, the commands to update the interface are queued behind the finger drag / scroll UI update.

I know this for a fact as I recently realised that my timers stopped firing when I was scrolling a UIScrollView and I needed the. To continue. There was a simple change to how I created the timers that forced them onto a different thread and then they continued to fire while scrolling.
 
Beautifully written! Thanks for the wonderful explanation!
 
webOS is not smooth, not by a long shot. My nexus one is smoother than my touch pad.
 
+Salvador Diaz my experience with webOS was with the original Palm Pre. I guess it went downhill from there.
 
+Mateusz Marek "Change Android framework from Java/Dalvik to C++0x/Qt ((dead) MeeGo (with Qt and QML) is still the smoothest and stable mobile OS (even more than iOS) and much easier to write application than Java)."

I don't know if that would really solve the problem. It might have been the specific implementation on the N9, but the MeeGo on the N9 had several issues with lag and pauses in very simple UI situations (like the menu). Not really less than my SGS II to be honest, but in a more predictable way (and thus easier to fix? Haven't seen the last update of the N9 to be honest).
 
The iOS description here isn't quite accurate. There are several things at work:

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.

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.



* This isn't strictly true: the main thread is put into a special mode during touch tracking, and by default, certain callbacks are delayed in that mode. However, a lot of other things, like loads from disk or network activity kept completely on a background thread, are not paused; nor is anything automatically paused during momentum scrolling. The developer has to explicitly delay those things.
 
Android is laggy? Give this guy a Galaxy S2 and please give us a break. Is this all just because you weren't offered a Job at google at end of your internship? Have u used iphone 3 and iphone 3gs? aren't they laggy?
 
so many truths in there! Google, get your act together!
 
+Brent Royal-Gordon iOS laglessness for handling touch event cannot rely only on developers. I can't find any app in which touch events rendering is delayed as it is on Android home screen.
 
+Sam Shedd The crappiness of the xoom and other tergra2 power tablets shows when you try scrolling between home screens while in portrait more. or when you try rotating the screen from portrait to landscape. From what I read tegra2 can not handle screen rotation hence it passes it to cpu which makes the whole transition and process less than graceful
 
+Min Lee I had the HTC Hero, and now the SGS2 - both of which I installed Cyanogen mod upon. I've never owned any Apple products.
 
Thanks for the informative article!
 
This is an awesome post! Hopefully the big G will save Android from itself.
 
First of all great article! But I have to question the default assumption that iOS isn't laggy. I'm using an old iPhone 3G and it has become laggy as hell over the years. Scrolling on a web page is only ever smooth once a page has finished rendering -- and often not even then. The map application has become so laggy as to be completely unusable; every scroll or keypress takes 20-30 seconds to register (not exaggerating). Installing an app more or less bricks the UI throughout. I'm sure that these problems do not exist on modern iOS hardware -- but on that basis, the only fair comparison is with modern top-of-the-line Android hardware.

(In other news, I just ordered my Galaxy Nexus yesterday and am rather looking forward to it. Can you tell?)

The trick is that there is effectively only ever one model iPhone / iPad at a time -- so right now it's the 4S, for example, that captures all the mindshare and forms the basis of comparison. Legacy iOS devices simply cannot keep up, and certainly do not maintain the buttery-smooth experience that people identify with iOS. But nobody appreciates this, because legacy iOS devices aren't an active force on the market. Android devices, meanwhile, come in many hardware configurations, some of which are much more analogous to my old laggy 3G than to the latest iOS hotness.

This isn't an excuse: it just means that Android has set a harder task for itself than iOS has. But that's no reason not to succeed at that task. 15 years ago, my hand-built BeOS box gave me an unbreakably buttery UI -- even during obnoxious geek demos such as simultaneously playing 30 different videos in 30 different windows -- so there's no reason that ANY computing device, even a very cheap one, should not be able to match that performance today. Your article has given me a good insight into how Android is failing to do so, and what some of the solutions might be.
 
As an Android fan/user my view might very well be biased, but I hardly notice the lags in android. If anything, the one thing that bothers me most in android is the loading times on certain apps, but that has more to do with my phones processor I would be inclined to believe. The "stutter" is something I have gotten used too early on and now I hardly notice it. So my point is, if I understood this article correctly I believe that in order for android to be "lagless" it would sacrifice the processing of other tasks whenever I put my finger on the screen like with iOS? I for one, hope it doesn't come to this. I can't count the amount of times that I scrolled down a website (mostly to the comment section) while the website was still loading. Had it been similar to iOS, the rest of the page would stop loading because I was scrolling. One could argue that those websites just need to load the important parts faster so that when you scroll the meaningfull parts of the website are viewable, but I do not know if this is always an option for websites. So, therefore I'd rather have the option of scrolling and otherwise interacting with the screen while the website is still loading, even if it implies the inherit laggyness.
Then again, I hope I understood this post correctly and if not, please correct me :)
 
I have read the post and all the comments and seen the number of shares. I don´t think this article was worth of sharing that much as it´s not at all the authorative source it pretends to be. I have read the disclaimer of +Andrew Munn but that´s not sufficient to warrant the determined tone in the article. Getting IOS wrong, a lack of insight in the hardware software equation, an easy going ´just start anew´ position which would hurt Android´s installed base enormously are just a few examples
This is not the answer to +Dianne Hackborn´s post which admittedly raised more questions than it answered. I would like to challenge +Chi-Ho Kwok to redo this article with more technical depth. I hope he takes up the gauntlet.

edit: after writing this I see he collected his comments in a separate post but I would like him to tackle the answer why Android has issues in lagging.
 
if I understood your post correctly, the laggness occur because of android itself. but we all know that SGS2 is way smother than galaxy nexus, while galaxy nexus has ICS with complete hardware acceleration and the gpu and cpu used in both devices has almost the same power. so why SGS2 is smoother than galaxy nexus?
 
Did Google give you permission to release this information to the public? You should REALLY be careful.
 
Good write-up. Just leave the personal stuff out. Explaining that you was intern at Google, but don't know the Android rendering code is OK, but not "As an aspiring product manager I'd..." or "I’ll be in Redmond working my butt off trying to get a beautiful and smooth mobile OS some of the recognition it deserves". Sounds like you're going to MS to fix WP7. It's a bit too much pride for a college intern. I wonder what your boss and co-workers would think if they'd read that. ;)
 
I get a few of things from this. Many of the people +1ing the article probably dont understand either the original or reply and just like to pile in on anything claiming that Android is laggy. I often wonder if some of these folks are even Android users as they quickly get irritated when real Android users state they have no problems. I don't understand though how they refute videos where theres no lag to be seen.

Second as many have replied...what lag? Many experience no lag at all or not enough to even care. Forget the SGS2. A friend of mine has the original GS with a custom ROM than never lags and I highly doubt the ROM completely rewrites the UI system. It looks like the argument boils down to older hardware which then makes the solution simlple which brings me to my third point......crippling the OS.

In the comments there are people claiming that older iphones now lag. Thats probabky because iOS adds features when hardware can handle it smoothly. Jobs said it himself speaking about the lack of a background and multitasking. Apple solved the pro lem of background processing by simply not allowing any. Here this post talks about more crippling by way of stopping all processing so that the device appears responsive. While thats good for someone thats only concerned with how their device looks it may be annoying to someone concerned with what their device does and how fast it does it. Basically the two companies seem to have two different philosophies. Google does things now that hardware will take care of in the future in terms of performance. Apple comes back to offer the same the same things later once hardware can handle it.

There are more deep technical differences but looking at the difference in visual performance in modern Android hardware and the iPhone is it really worth talking about? I'd prefer Google continue to focus on guiding the mobile industry in terms of features rather than focus on something that many people dont even see or care about. Prior to iOS 5 what was the point of a smooth UI when a notification bubble could jump in the way at any point. For me their focus is in the wrong place.
 
Great post, +Andrew Munn . But if the SGS2 is buttery smooth, wouldn't it be easier for the Android team to just wait until the critical mass of Android users are running dual/quad/oct cores and sweep the lag issue under the rug? I run HC and GB on 3 devices and the lag when updating an app is frustrating! So, thanks for ELI5!
Stan G
 
Is Android fixable at all? It wasn't designed with touch interface in mind, according to this post, so nothing will ever change that. Perhaps we should just hope that with more powerful hardware and some fine trickery its UI performance will be satisfactory on most of the devices for most of the people. It would still not remove the initial design constraints, though.

Or should Android make a big political decision, drop legacy support, and redo itself from the scratch? Offer people sort of Android 2.0. The transition period shouldn't take longer than three years during which the current Android could still be maintained and developed but with a firm view that the platform is going to die.

It's going to die anyway, why not replace it with it's own child rather than wait for it be replaced by some competitor. It will be more painful later on - just watch the slow decline of iOS, right now they are the ones primed for a major OS overhaul and they might very well have teams working on it already. Just my two cents.
 
WINDOWS 7??? Come on MAN!!!! You could do better
 
Why make this priority #1 when new devices like the SII or Tab 7.7 hardly have problems with smoothness (as pointed out by the author)?
Sure, there is no way for Android to guarantee a smooth experience under all circumstances, but with a proper dual core CPU there are hardly situations where you will notice it.

I often have the urge to yell at my LG Speed 2X (never Tegra again for me, but that's also because of their proprietary 3D extensions) with Froyo (LG NL is really slow with Gingerbread, while the rest of Europe already has it) and my Honeycomb Archos 80 with TI OMAP dual core still feels laggy at times, but as time goes by, things will improve with newer Android versions and also newer hardware (quad core). So should a rewrite of the UI engine really be priority #1?

I do think it is true that Android has become the Windows for mobile devices. It doesn't matter how good your hardware is, you do need proper software support (drivers) to get a smooth experience. Also on Windows a new GFX driver can make a big difference in smoothness.
 
Thanks for the insightful post Andrew, and to the fanboy 2 posts above: stop being such a tool. 
 
4 posts*, referring to the "omg windows 7" guy. Damn you ninja commenters. 
 
If you think WebOS is smooth, then you have never used a WebOS device.
 
Wonderful post. It's amusing to watch people throw the figurative baby out with the bathwater due to missing some technical trivia, while it seems like the overarching point that Apple focused on the user experience while Android focused on multitasking remains valid. Even speaking as an engineer, I think Apple made the right decision. And that's because phones are a consumer device, not a workstation. Feel free to agree to disagree.

In my case, my original droid went from the coolest toy I'd ever bought 2 years ago to a useless brick by August of 2011. I fixed the problem with a factory reset, but any attempt to add more than a minimal set of apps, that come with their obligatory batch of background processes, returns the phone to its zombie-like state. Googlers have told me to buy a new phone - it's just over 2 years old now and it was still under contract at the time - get real. Any gadget that's abandoned by its makers less than 5 years after its release isn't worth buying to me.

That said, if this is Google's unyielding design philosophy, then there's big money in course-correcting hardware roadmaps to accelerate performance by addressing their mistakes. Nothing beats dedicated transistors if you have them to spare. But beware, software companies, and their deceptive proclamations of "standards" (Hello Microsoft), are capricious entities at best. I remember Charles Petzold admonishing windows developers to never ever ever ever use modal dialogs only to find Microsoft Office and Internet Explorer flat out rely on them. Not to mention NVIDIA almost losing its shirt targeting a DirectX 9 standard that never happened but which instead saved ATI from one of its many near-death experiences. Perhaps we are about to relive the 1990s graphics hardwars. Good times, good times...
 
Congratulations, +Andrew Munn ! That was incredibly informative, and I really hope Android get the proper rewrite in its UI framework. Really good job. By the way, I think you have a bright future as a Product Manager. Congrats!
 
Gee, when I was a certified OS/2 engineer, one of our mantras was that if anything would ever take longer than 1/10th of a second, we spawned another thread. Why? To keep the UI responsive. So OS/2 is gone now, sadly, but the issue is still real, it seems :-)
Preemptive multitasking.
 
+Sanchit Sharma I still use the original 2007 iPhone and it is not laggy. Find someone who has one and try for yourself. Properly written software can be responsive on downright prehistoric hardware. Badly written software will remain laggy no matter how many CPU cores you have.

See http://en.wikipedia.org/wiki/WriteNow -- the WriteNow word processor on ancient Macs ran rings around word processors on machines that were 100s or 1000s of times more powerful.
 
Interesting to see the two sides. Though I agree with you Andrew: if the solution to fixing Android's scrolling problem was so easy, we wouldn't be talking about the very issue of UI lag now. 
 
+Andrew Munn Man... you had just enlighten me... ohhh.... thanks so much, this info was delicious.
 
One thing I disagree with... "Work on Android started before the release of the iPhone, and at the time Android was designed to be a competitor to the Blackberry. The original Android prototype wasn’t a touch screen device. Android’s rendering trade-offs make sense for a keyboard and trackball device. When the iPhone came out, the Android team rushed to release a competitor product, but unfortunately it was too late to rewrite the UI framework."

In 2007, Google showed off a touchscreen prototype running Android. This was still before the iPhone was announced. I don't think you can definitively say that they developed Android without touch capabilities in mind, or that they "rushed" the capabilities to market.
 
+Ted Todorov the example of WriteNow is a bad one as a) it was not that much faster as other code in these days. My self written fully graphical editor managed to get the same speed on an X8086 and b) it was so fast because of the use of tuned assembly so completely unportable to other chips.
That´s certainly not the way Android should go. The need to stay hardware agnostic will only grow with developments like Android for Intel Arm chips.
An abstraction layer is not a bad thing and I doubt +Andrew Munn ´s statement about the bad performance of Dalvik.
 
The real time dedicated thread bit, that's just not correct.
 
This post is amazing! very informative! I love android, but I also admire your impartiality and willingness to work on Windows.
 
+Amir Haleem Why look at a video when we can look at our own phones and see that there's no lag. This also fails to address videos where you see no lag. It also fails to address the lag people have witnessed in iPhones. Part of the problem is that some maybe even much of the lag issue is myth.
 
+Dude Kartaguez To be clear, it isn't completely cultural. UIKit is fast and is designed to make it easy for your code to be fast. For example, consider the way UITableView's -tableView:cellForRowAtIndexPath: callback is supposed to work.

One rule of scrolling performance is "do not allocate views during scrolling". Instead, you should try to reuse views that have recently scrolled offscreen. (The Photos app doesn't have you side-scrolling between hundreds of image views—it just has two, playing an invisible game of leapfrog.) The UITableView helps you comply with this rule by keeping a built-in queue of table cells that have scrolled off the screen. The common idiom for getting a table view cell is this (leading dots are used to indent code):

....// Try to get a cell from the table view's reuse queue. The string identifies which sort of
....// cell we want to get if the table view has several different kinds.
....UITableViewCell * cell = [myTableView dequeueCellWithReuseIdentifier:@"MyCellType"];
....
....// If there aren't any suitable cells in the queue...
....if(!cell) {
........// We allocate one.
........cell = [[UITableViewCell alloc] initWithStyle:UITableViewCellDefaultStyle reuseIdentifier:@"MyCellType"];
....}


If you follow this idiom—which in practice means you don't delete it from the table view templates, because it's there by default—and you don't do anything really stupid like pull a large image off the disk and put it into the cell, you will get about 30 fps without further optimization, because you'll only allocate cells when the view is first displayed, and thereafter you'll cheaply reuse cells.

[EDIT: Several people have noted that Android has similar mechanisms for table cell reuse, and Android developers are increasingly adopting them. My apologies—my quick scan of the Android docs didn't reveal that fact.]

Getting it up to sixty is more difficult—you may have to simplify the cell's view hierarchy, or delay adding some of the content, or remove text formatting that would otherwise require a more expensive text rendering API, or even rip the subviews out of the cell altogether and draw everything by hand. But that's where the cultural difference lies—iOS developers will do those things. They will redesign a table view so it has a chance of scrolling faster. They will write a bunch of manual drawing code, see if it's faster than the view-based stuff, and act accordingly. The iOS culture tells them that this is what you have to do to make a good product.

I'm sure you could do all these things with an Android ListView too, but as far as I can tell the queueing is not done by default. And Apple's built-in apps, which all scroll like butter, set the example for iOS that you'd better have smooth scrolling. What example do Google's built-in apps set?
 
+Brent Royal-Gordon thank you for your clear explanations. I am not as familiar as I should be with iOS app development for the purpose of this blog post. I've taken your first comment and edited it into the original post. Please Let me know if you want me to add anything or change it.
 
Sorry, but how can one discuss a topic with so much semi knowledge and limited information. Why should it not be possible to decouple the window manager and animations from the activity thread (from my observations they already are), because it would need to call onPaint and onLayout which reside in the activity? laughable.

Drawing and View/Window-Managment are two pair of shoes and what should the priority of the app have to do with it? Why should the window composing process in Android not use caching for drawing, fading, backgrounds, scrolling etc. and reside in a completly different process?

This whole rant seems about some personal observations and someone guessing around on a very mediocre niveau.
 
+Toine Diepstraten Well I felt like giving it a shot. Nobody has written an article that actually tried to explain why Android was laggy in any detail. I'm certainly not an expert, and I made that clear at the beginning. However, I think I've helped people understand the reasons Android behaves the way it does, and I always welcome constructive feedback.
 
+Brent Royal-Gordon "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."

You did later refer to the run loop modes, but in the context of lag-free scrolling and smoothness I feel they deseve more attention. After all it's exactly the switch to the "event tracking" run loop mode that stops the WebKit rendering etc. WebKit only receives events on the "default" run loop mode and actually making it render while the user is touching the screen is the part that requires the "painstaking" implementation.

ps. About the lag.. My SGS2 lags considerably more than the ancient iPhone 3GS ever did.
 
I suspected they were drawing the UI on the main thread. That lag annoys me to no end. :-/

Great explanation!
 
Sharing this post was the hardest thing ever. Too much scrolling.
 
WebOS is NOT fluid. It's actually worse than Android in terms of UI performance.
 
Decent article, with descent point.

But can you please explain in detail, how Microsoft got around the issue of multitasking with the UI having such a strong presence? Google might be inspired... since you are famous now.
 
Apps are racing for CPU and the UI rendering thread is more likely to miss a few frames if something is heavy on CPU. Android team needs to focus on priority tuning, scheduler tweaks (CFS might not be tuned up to work as well on ARM as on powerful x86 chips), and Linux kernel might need some work as well, maybe in areas such as IO scheduling (Linux desktops still aren't butter smooth either). Then there are also GPU drivers/hw - hardware (and/or driver implementation) might not be prepared to seamlessly render a few threads in parallel, so when app process does some heavy drawing, UI process is blocked and misses frames until full rendering batch is finished. I guess iOS design decision to block everything else is related to this behavior particularly. High end graphic cards have been going in direction of allowing more fine-grained scheduling, particularly with DX10/11 and Vista/Windows7 UI in mind, but I'm not familiar with how far they got with hw scheduling and gpu virtualization stuff. ARM and mobile hardware is probably not getting this yet.
 
I really hope Android will soon not be famous for its lag! Someone in the Android team please fix the issue whatever the cause is!
 
Interesting post. But no matter what the problem is, that won't be the real issue. Android won't have a class 1 UX. Never. Why? Because UX is not a top level priority at Google. It is that simple.

Well maybe saying never is way too much, but Google would need to redefine all the company in order to change this.

This does not pretend to be a hater comment, I love Google, and I love a lot of their stuff, they are great tech innovators, but when it comes to UX... they suck big time.
 
+Romain Guy Thanks for the info. I've never written for Android before, and my quick scan of the docs didn't reveal any signs of a recycling mechanism. Do developers often ignore the recycling mechanism? I see some results in Google that indicates they might, but I'm sure some people do the same on iOS...

+Ari-Pekka Viitanen I didn't realize that—I've rarely had to use UIWebView, so I wasn't aware it was scheduled only on default modes. Nevertheless, in apps that rely heavily on native controls like UIScrollView and UITableView, the runloop modes aren't generally used to delay work until scrolling is finished.

(Or at least I don't use them that way, and I don't think I've seen sample code that does. Maybe I'm just a poor coder!)
 
+Chi-Ho Kwok "Stop the world to run an animation is so crude". Ignoring the User experience to complete a desired task is cruder still esp for devices like phones and Tablets. Agree with +Scott Le Grand
 
+Nisachar singh the user asked for the task to complete, surely making that take longer to complete is also not good user experience.
 
To be fair couple of points that +Brent Royal-Gordon made - in my experience it is as easy to offload stuff from UI thread in android as in iOS ( coded on both ) May be even easier on android to be frank. ListView in android, surprise !, does reuse layouts THE SAME WAY as iOS - again with more elegance for my taste.
 
Also i'm surprised with the tales of bad android developers who do things on UI Thread. Who are these people ? All people i know read docs and don't do such things.
But scrolling does suck on android compare to iOS and Win7 - truth. ICS on Nexus S is much much better, but still doesn't feels as good as scroll on 4S.
 
+Romain Guy iOS developers have the same issue. The conventional solution seems to be to keep track of whether the table view is currently scrolling, and if it is, delay the slow accesses until it's done. I think perhaps Android developers are a little less aggressive about this sort of thing.

It might even just be a matter of tooling—Instruments, the tool for analyzing the performance of an iOS app, is extremely polished, while at first glance Android's Traceview looks a bit more primitive. (Though don't get me wrong—it seems like they do provide many of the same basic functions, just in a form that's less convenient and nicely-packaged.)
 
I had wondered about this - we created an HTML5 app to replace CAPTCHAs that requires a line-drawing action by the user, and while it works okay on Android it's kludgy on most Android tablets compared with the smooth and completely intuitive performance on the iPad.
 
I just have to say, webOS is not fluid. People think so when they imagine the devices, which look better in stills than in motion. I went through three Pres, and the third one I over clocked to 1.2 GHz and hacked on webOS 2. The only place where it ever matched iOS and Windows Phone's level of touch response is in the Stacks-era Launcher (that HP-Palm rewrote in C) without any cards open. Otherwise, the framerate even during simple menu operations was actually worse than comparable androids I've seen, such as the Samsung Moment. However infrequently, Android occasionally hit 60fps — webOS is lucky to reach what I perceive to be the 30s.

It's really hard to stand when you spend ten seconds with someone's first generation iPod touch. Like playing violin underwater, decent response is like jumping out and getting a breath of air.

I've never graded a phone on a curve so hard.
 
I don't buy t-shirts with things that I find absolutely unacceptable.
 
Android team set of mind states:The faster CPUs will be & bigger the memory will be, they both will compensate the lag until one day the lag will be gone. This just means they can keep rely on Java bytecode machine as long as hardware will be faster in time. While the software remain slow.
 
this post is a gem, thanks for helping us understand so many interesting stuff behind android rendering model
Shane L
 
Now that we know, can we do something about it?
 
+Andrew Munn "The original Android prototype wasn’t a touch screen device. " Can you explain this? Because the first prototypes seen of Android were both, Blacberry like an touch only like
 
I completely agree that nowadays, apple seems to be benifiting from focusing on one single task to give better performance (using the example you used when pausing the download of an app to give better scrolling). however, in a year or tow, when a powerful chips come out, this will be disadvantage for them, as you won't be able to do several things at once, while with android you can, just like the pc, you use several apps at the same time and you have excellent response. please correct me if I am wrong.
 
Very interesting post, but... Can you explain to me one thing:

iOS on my 3GS has been a jerky mess since iOS 4 came out. I agree, Windows Phone 7 (I have a Mozart) is very smooth, but then so is my Sensation. It is only iOS which has any real problems with smooth scrolling and App loading has really gone down hill - the Settings app currently takes over 10 seconds to load up!

The iPhone also seems to pause when an app finishes installing.

Putting the iPhone to sleep mid "Angry Birds", then turning it back on results in a second or so delay, before the pause screen appears and clicking continue and launching a bird sees him stutter across the screen.

Doing the same on WP7 or Android and it is smooth from the get-go.

Okay, the iPhone 3GS is getting on a bit, but this stuttering has been going on since 4.0 and it is still a current model on sale today.
 
Very interesting, and detailed post. Thanks for the explanation, and also for interesting pointers for UI design strategies! Thanks again!
 
Great post! As an android developer I'm always making compromises because things like Android animations are so laggy. It's a hard thing to try to explain to a CEO that we can't do things that we can do on iOS because the frame rate will suck.
 
Thank you so very much for clarifying this in a way that enables me to retell it to would-be Android haters.
I always suspected something was going on behind the scenes, and now I have a very detailed and easily understandable explanation!

If your upcoming internship with the WP7 team receives the same dedication and attention to detail that this post has, I'd say there's hope for it as a mobile platform yet.
 
Thanks for this explanation. I agree that whatever the cause, the lag is unacceptable and should be fixed. It is the reason I switched to a windows phone as my daily driver.
 
So many stuff runs buttery smooth on my galaxy nexus with android 4.0. It s awesome and so much fun. I totally don t mind some tiny micro stutters on the homescreens and stuff like that. But then there are always (yes always, with every knew Android version) some apps that run like shit. Google apps. This time, the galery app runs like shit. It s not even close to 30 fps like stated above... it s more like 15 fps. May i ask why that is? I love my android device and using it is a blast ... then i want to watch some photos and i can t believe how shitti it runs on my brandnew dualcore device. The old galery on my nexus one had more animations and it was smooth. Why google? Why do you guys stop to optimate so close before you are done completely and ship it as if everything is fine? God damnit!
 
It's worth mentioning MeeGo on the Nokia n9 and n950, this is a far more purely Linux based phone than Android or WebOS. For example installs are done with dpkg and the GUI is an OpenGL assisted Window manager on relatively stock X11. xmodmap and xrandr work, even remotely if you ssh from the phone with -X! (In fact I had to do this initially as I didn't have arm compiled binaries for these). The xrandr will rotate the phone display just as using the accelerometer. If reading email in pine and I select to view a url, I was surprised to see firefox fire up on my display rather than lynx (I'd forgotten $DISPLAY was set via ssh).

Anyway enough rambling about an essentially dead OS (Elop, Nokia's CEO is ex Microsoft and decided they were to dump it and use Windows mobile)... The point is, this is silky smooth compared to Android and yet suffers from the same prioritisation of UI vs background tasks as Android does.
 
+ahomad hosin Those phones and tablets are here today, and they are glitchy/laggy. It's the architecture, not the horsepower.
 
+Andrew Munn As an Android intern, you didn't do your homework that well: "The original Android prototype wasn’t a touch screen device" - WRONG! They made several prototypes, one of which was a touch screen device.
See for yourself (@2:55): Android Demo
 
After reading this who knows maybe will find Chrome Os on a phone to replace Android. I believe Google is aware of the issues that they bought into and in time will do revamp.
 
The main issue is that companies like Samsung obviously suck at making software, creating really slow firmware. Look at Cyanogenmod ROMs, they are much faster than stock ROMs. Atleast tell the companies to release phone with firmware that are well optimized, so that people will complain much less about the lag.
Shyam S
 
+Damion Yates Yates - One can tinker with CFS in maemo and there was even a BFS Kernel.
 
This is what happens,when an android converts to an IOS...He stops tending to infinity and starts tending to zero...
 
wow, it defenitely is great to know that the lagginess can be solved sometime in the future...and i believe in the great developers of android and google..i hope one day...android's UI will be buttery smooth
 
Umm I'm not so sure about your post, shouldn't using a scheduler like BFS solve some of those troubles? I think CM use it a while, but after a blind test there was no measure improvement. Also, I would add that the new SQLite libs helped a LOT in the scrolling smoothness.
 
+Romain Guy as this post is now doing the rounds through blogs and self declared ´tech´ sites is it possible to do a proper write up on behalf of the Android team?
This is now becoming an urban myth which will never away.
Earlier I wrote:

I have read the post and all the comments and seen the number of shares. I don´t think this article was worth of sharing that much as it´s not at all the authorative source it pretends to be. I have read the disclaimer of +Andrew Munn but that´s not sufficient to warrant the determined tone in the article. Getting IOS wrong, a lack of insight in the hardware software equation, an easy going ´just start anew´ position which would hurt Android´s installed base enormously are just a few examples
This is not the answer to +Dianne Hackborn ´s post which admittedly raised more questions than it answered. I would like to challenge +Chi-Ho Kwok to redo this article with more technical depth. I hope he takes up the gauntlet.
 
+Andrew Munn While I appreciate your update in the post, as it makes your arguments a bit less misleading, I still think you're oversimplifying the issues here. When it comes to app design, it is the developer that has to ensure a proper decoupling of the UI rendering from the actual work of the application itself. This is something that the Android developer guidelines have stressed from the beginning. Furthermore, the same design concerns come into play when designing for any platform. Also, considering you "never read the Android rendering source code," and that you presumably don't have an intimate knowledge of the Android UI framework, I don't know how you can possibly claim that "the only thing that can really fix it is framework redesign." Having used many well-designed apps on my honeycomb tablet, I can say with confidence that when applications are threaded properly, the issues you describe are all non-issues. These apps are buttery-smooth. While the Android UI framework has a long ways to go, it has made ENORMOUS progress, and I think you are a bit presumptuous to think that you completely understand the supposed single simple issue with Android UI responsiveness.
 
iOS is designed based on 2 ipad models, couple of ipods and 3 iphones. Microsoft has minimum hardware specs so you won't see any laggy Windows phone. Android though, can be found even on a device without dedicated GPU. Performance must be sacrificed in order to achieve best compatibility.
 
+Dan Hansen So what you are saying is Android needs more better developers? "Developers!, developers!, developers!, developers!... "(Spoken in a Ballmer voice)
 
I don't know why, but this page crashes my Mobile Safari, as well as the web control in general.
 
UI > all. These are HIDs we're talking about; the most valuable resource is the user's attention. Making a user wait is essentially disabling the person it's supposed to be empowering.
 
I have a crazy idea: look at Windows. Or maybe Ubuntu. The article mentioned that "Android follows the traditional PC model of rendering occurring on the main thread with normal priority". On Windows and Ubuntu, I never get lag like that and I don't know anyone who does either. Android devices have eclipsed low-end laptops in raw power; they should be able to match those same devices in smoothness. Windows 7 on a 1.6GHz Atom-based netbook is smoother than Android on my Thunderbolt overclocked to 1.6GHz on a smaller resolution. To be fair, Honeycomb 3.2 on my Transformer never lags, and I haven't even overclocked it since the last update (I do have a custom ROM, though).
 
I read this article with interest but I must say it did make me chuckle a bit because it the same kind of article that has been floating around the swing community for years. I've worked as a swing consultant for some time and EVERYONE always hits me with the 'Swing is slow' argument. I then break out a few demo's, one I wrote is like a supped up google maps with realtime tracking and overlay updates built into it. Suddenly their eyes open wide as they had memories of Swing showing grey looking screens with 1990's looking buttons, but no there are gradients, rounded corners, fancy looking widgets... Then they start scrolling the maps around, no lag, everything instant even on a low spec machine. All their pre-conceived idea's fall away in a snap.

It's easy when there are lags in applications (phone or desktop) to blame the OS, the GUI system, the task switch, GC ...... however in my experience 8 times out of 10 its down to badly written application code.

I've got a Nexus S and personally I think it quick compared to my iTouch and as a user experience its way ahead, but thats just a personal experience. Something worth keeping in mind is the speed of a phone now will be nothing compared to the speed in a couple of years!

I'd also like to add that I have done some development for iPhones and now for Android and I find the whole Android development environment to be a lot more of a pleasurable experience. However one area where it really needs sorting out is the Graphical Layout tool, its buggy as hell and miles behind the similar swing tool in Netbeans. iPhone development felt like going back 10yrs after using Netbeans for development for my normal Java development.

+Romain Guy The recycling trick is similar to techniques I try to incorporate into swing programming, things like that make such a difference, especially when memory is restricted. I've tweaked Swing apps in the past that are struggling to run an a users low spec machine and with a couple of well considered tweaks to object re-use and better use of layouts they suddenly fly. As I say it's nearly always a problem with the app!
 
I feel that one of the fundamental reasons for this "lagginess" is the lack of screening process with app submission when compared to iOS and Windows Phone 7. Despite the numerous advantage of this approach, it makes developers slack off and cut corners.

A prime example is violating "recommendations" such as not performing long running tasks in the main/UI thread. The developer documentation spells it out clearly, but the framework doesn't enforce it. Therefore, the developers are free to do whatever they want to in the main thread leading to laggy/slow applications. To make things worse, people reward mediocre programmers by downloading their apps and putting glorious reviews. In turn others would also be tempted to sacrifice performance to get a decent enough (but not great) app out of the door - this makes sense both financially and time-wise when you do a simple cost-benefit analysis. It is a vicious cycle.

You can still make snappy apps on Android if you follow most of the good Android programming conventions recommended by Google & others. It is both an issue with platform as well as developer mentality.
 
Just a quick correction. iOS on both the iPhone 4s and iPhone 3 is NOT fluid. That fact only applies to iPhone 4. Just use all three models side by side, and you can see that ... ...
 
Unlike a number of the in-awe comments here, mine will come with a different tone:

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?).

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.

You want to catch a beer and explain where you're coming from before you roll out of the bay? Let me know. Honestly, I think you overreached here, but I'm always up for a solid technical debate.
 
+Matthew Chaboud You're absolutely right about everything you said. You certainly have more experience than I do writing multithreaded code. I'm not going to argue that.

My post was purposely overly-simplistic and incomplete. In the same way that an 11th grade science teacher neglects to mention to her students the existence of general relativity when describing the laws of physics, I gave very high level and technically incorrect description of iOS and Android rendering. An 11th grader doesn't need to know that GPS satellites correct for the speed of light when making calculations. However, it is useful for them to understand why it takes cars longer to stop when it's raining. Similarly, the average Android user doesn't need to know most of the complex details about operating systems, threading, priority, etc etc. For that, +Dianne Hackborn's post is a better place to turn.

I wanted to give nontechnical users an understanding of the major differences between Android and iOS and I think I've succeeded. You're missing the forest for the trees.

Oh, and I'd love to grab a beer, but I'm currently studying for final exams in Waterloo, Ontario. Actually, my concurrency exam is coming up on Tuesday, haha.
 
On the "you're missing the forest for the trees" comment, I don't think so. These are pretty detailed points, and people naturally correlate precision with accuracy (it's why people trot out detailed points in arguments, and why Everest was declared to be 29,002 ft tall in 1856). I get the need to dumb things down, but that shouldn't come with the baggage of seemingly undumb statements. These at least imply a particular insight, while also carrying some inaccuracy.

Bummer that you're back north. Get to studying, and let me know when you're in the bay area (or I'll bug you when I'm in Seattle). I'd wager that you'll be too neck-deep in Metro to make it out, but the first beer is on me.

Best of luck on the finals.
 
Good article. Very informative. I am seriously considering to buy my first android device after reading this. Thanks
Nik H
+
5
6
5
 
I'll go out on a limb here and join the chorus of critics. Android is laggy, that's true, but I don't think it has anything to do with the two main points you are trying to make here:

- UI rendering occurs on the main thread of an app
- UI rendering has normal priority

On iOS, UI rendering happens on the main thread of an app. Go ahead, write a simple iOS app that has a wait loop on the main thread. Guess what happens? That's right, drawing stops. The iOS developer documentation is full of examples on how to provide a responsive UI using various tricks (list scrolling in particular works the same in every app, and it's using quite a few tricks to get heavyweight table cells to scroll smoothly - I know this first hand as I was implementing table cells without using those tricks at first, and, well, surprise, it was slow, laggy, stutter-y).

I am not sure about thread priority of the drawing thread on iOS but I am pretty sure iOS is not a RT operating system. And if it's just running at higher priority then it would be trivial for Android to copy - so I can't really imagine that that is a critical difference either.
My guess is that the critical difference is in the extremely mature, and tuned frameworks that iOS provides for animation. Coming from the horrible mess that is Java/Swing, I was just amazed and astounded at the animation capabilities built into iOS. The frameworks are fantastic, and they're backed by a rendering pipeline that sits on top of on OpenGL. Pairing that with even just a basic mobile GPU - as has been in the iPhone since the iPhone 1 in 2007 - is sufficient to explain iOS drawing performance. Quartz has been around for a very long time on OS X, from a time when desktop GPUs were weaker than mobile GPUs are now - and it's worked perfectly back then, providing buttery smooth UI animations in OS X. With the much smaller screen in the iPhone, I am not at all surprised at the performance there.

My point is: iOS doesn't need a real time thread, or even prioritized threads. A Quartz rendering pipeline running on top of a GPU is all it takes.

Android had none of this when it was first designed, and it's hard to impossible to graft on an efficient rendering pipeline on a later date. Remember when Steve Jobs said iOS was "5 years ahead" of the competition - this is one of those details that's very hard to copy for existing software, without starting over from scratch.
 
+Nikolaus Heger Nikolaus you mention the mess that is Swing. On some points I agree, tables for instance are a total mess and need re-writing from the ground up. However in general I find writing Android apps very similar to writing Swing apps and there is NO reason at all Swing applications can't be fancy looking and slick. The point you make about animation, well thats all possible. You may need to dig around for none standard libraries or even write your own but there is no reason why you can't do it. Oracle at the moment are pushing JavaFX for such a thing. Now I can't say I'm a total fan of it but its worth a look. Personally I wish they would put half the effort in to a few Swing tweaks. As a base GUI system Swing is used a hell of a lot more than people give it credit for, it's just that the applications go a bit under the hood http://blogs.oracle.com/geertjan/entry/what_is_happening_vs_what
 
This is the best explanation anyone could have asked for. Thanks!
 
Great post! I haven't read through all the comments here so this might already have been described. If so, ignore this. :)

The solution I find most useful for making an Android UI responsive, apart from the typical solutions like handling recycled ListView items correctly etc, is to create two Handler objects in my Activity. I call the first one mUiHandler and give it the main Looper (getMainLooper()) and its own Callback object as parameters. The second one (I usually call it mBackgroundHandler) I give its own Looper, using a HandlerThread which you give the lowest priority, as well as a Callback object. The code would look something like this:


public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
mUiHandler = new Handler(getMainLooper(), new UiHandlerCallback());

HandlerThread handlerThread = new HandlerThread("BackgroundOperationThread");
handlerThread.setPriority(Thread.MIN_PRIORITY);
handlerThread.start();
mBackgroundHandler = new Handler(handlerThread.getLooper(), new BackgroundHandlerCallback());

mBackgroundHandler.sendEmptyMessage(START_RETRIEVING_ONLINE_DATA);

// All the other stuff we do in onCreate() below...
}

Now, any time you need to do something that requires updates on the UI (animations etc.) you implement the code for this in the UiHandlerCallback object that you gave to the mUiHandler. Assign a constant (declare a public static final int in your Activity) to this operation and you can trigger this by simply calling mUiHandler.sentEmptyMessage(SOME_CONSTANT). This is a much better way to do UI operations than by calling Activity.runOnUiThread(new Runnable() {....}); which creates unnecessary anonymous objects and adds extra overhead, especially if it is something that you do often.

The seconds Handler (mBackgroundHandler) you created should be used for all operations that doesn't need to be executed on the main thread. Since this Handler runs on a thread with lower priority it shouldn't compete as hard with the main thread that does the UI stuff. I typically use this second Handler for everything from starting other activities, retrieving stuff from network or loading resources. As a rule, anything that doesn't have to happen on the main thread I do here.

You still have to take care when doing operations in the callbacks for the Activity or Views (e.g., onResume, onTouch, onClick, onItemSelected etc.). For instance, onClick and similar operations does of course happen on the main thread, so if you are going to load an image, start another activity, read or write to SharedPreferences, database operations or make a network call, you should always implement the code inside the BackgroundHandlerCallback object of the second Handler and only call mBackgroundHandler.sendEmptyMessage(CONSTANT_FOR_A_NON_UI_OPERATION) to trigger it.

This won't solve all the problems and you will still have occasions where the UI will be slow at times due to all the reasons listed so thoroughly in +Andrew Munn's post. However, I've noticed than my apps are generally much more smooth when I strictly stick to this pattern.

Hope that can help you out. Feel free to ask me directly if you have questions. :)
 
thanks for your post Andrew, super useful. correct thread:)
 
I can't replicate any of these Android GUI lag "issues" on my Galaxy S2 at all. Not even a little bit.

I can get a couple of them to happen on my Xoom, but only if I push it beyond reasonable limits. For instance I got a half-second lag while vertical scrolling the longest list (Action Adventure) in Movies so fast that it was just a blur (because it was scrolling that fast and smooth before the stop). But then after that half-second lag it was back to a blur all the way to the bottom of the list. Trying to use it like this is senseless though as you can't read anything and so I don't consider this a drawback at all.

Besides, the issues described in this article are decreasingly relevant as the number of cores and power of each core increases. Single-cores had far more significant issues that the first generation of dual-core devices. The second generation of dual-core devices already have almost no problem with this at all, and once the quad-cores come out this issue will be gone entirely. This is one case where throwing more power at it really will fix the issue.... At least as long as they don't do what MS has done and make the software and OS get more complex and demanding faster than the hardware improves.
 
I think the most telling part of this conversation is the fact that it is happening at all. In the iOS world, you simply don't see extensive conversations about poor graphics performance, because it's largely a non-issue. Having used and programmed both for a few years, it's pretty clear to me that the multitasking model in Android is a bad idea for end users, and so is having GC on a phone rather than managing your own memory. It's easier for the programmer, but worse for the user.
 
为什么Android没有iOS那么顺滑

Google+用户Andrew Munn透露他之前是Google和Microsoft内部的实习生。据报道他曾做过短时间的Android工作以及在Microsoft做过短时间的Windows Phone 7相关工作——事先声明是短时间的。此前也有报道称在Google+上某些用户透露了Android的硬件加速的更多内幕,据称在Android 3.0推出和更进一步推出Android 4.0之前并没有完整的硬件加速,他们一直在通过硬件加速绘制某些UI元素,他也承认硬件加速并不像我们认为的那样乐观。 而文章开头的工程师Munn是想告诉我们为什么Android没有硬件加速,而且永远不会,这使得它不会像iOS和Windows Phone 7一样流畅,Android效率低下的设计框架使得它需要通过强大的CPU/GPU才能确保具有100%的流畅体验。

不过国外读者也对此吐嘈了一番比如:“因为他是一名实习生”“这是线程优先级问题,而非框架问题,真是一个白痴……”“第一句话已经说明了问题……”“我们不能自欺欺人,Apple有一个他们自己控制的系统,它可以对用户体验和操作系统做到最好的优化,而iPhone 4S仍然是800MHz处理器所以还是比较向Galaxy Nexus看齐,只是不喜欢Apple”“貌似是一个刻薄的前员工噢……”真是差不多要让灭掉了……
Translate
 
Hi I don't know if the points brought up in this thread are true or not but based on replies and rebuttals from Dianne Hackborn, it seems the UI issue could be boiled down to different philosophies in Android and iOS camps. Assuming the points are valid, from end user point of view, I would prefer iOS UI foremost strategy. From a developer point of view, I would prefer Android strategy as it actually perform (as in getting tasks to finish) in an allocated time span faster.

But I would side with end users for a simple reason. End users drives apps. If the UI is not fast enough to them, they thought you have an inferior product. Even if the background task will take longer to finish it will not be noticed too much by end users as they will be engrossed in the UI screen stuff. During those times they are engrossed, the time is compensated for the background task to finish. So overall although the whole process of UI render + back-end task take longer compared to Android, user will still rate this approach as more superior.

Again I hope the real reasons are as what is posted. Then I would think Android should put more emphasis on the UI aspects. Perhaps slow down research on other component and get this component up first. At least to please the end users and win them over. Other components can slowly do later. My personal opinion.
 
+John Drinkwater yes but if in the middle of that task I want to scroll, swipe or switch applications or anything that I want to do next, the UI should allow me to do that with immediate effect.
Jeff Y
 
S/O for taking the corrections in stride and posting everything transparently. Everyone messes up from time to time, and when they do, programmers are ready with the pitchforks to crucify.
 
+Andrew Munn I am grateful for you post, even if not accurate, it sparked a lot of knowledge sharing. There is a lack of quality resources about Android architecture, it's priceless to read deep technical explanations, especially comparative between iOS and Android and other platform, without all the marketing fluff in the middle.
You took a lot of hate, much more than you deserved, and all the engineer pickyness i see in posts is just miserable: we're all engineers, some good, some stars some just plain average, but let's talk about code not pride.

Good luck with your Microsoft work experience.
 
+Andrew Munn So you may have been wrong on a couple of points. Nevertheless, I'm sending out a big THANK YOU your way for bringing attention to this issue.

It was inevitable that ALDs ("Android Lag Deniers") would attack your theories/analysis/post, as they had to discredit you to save face. The fact still remains, Android is laggy/choppy (especially in the scrolling department), and I for one do not believe the solution is to wait around for better hardware. It has already been mentioned in other posts that even the quad-core Transformer STILL suffers from Android lag. Here are a couple of videos I have posted of my Galaxy Nexus:

Galaxy Nexus Browser and Browsing Experience

and

Native Google+ App on Galaxy Nexus - foreign language lag

Also, in Dianne Hackborn's rebuttal of your post, please look at comments by Jay Freeman (Cydia). He points out the untruths Dianne Hackborn tried to pedal, and even goes so far as to suggest that she should retract them.

Google are being stubborn as mules about this issue, and it's costing those who embrace Android. I have read a number of articles about major retailers claiming they simply can't move Android tablets resulting it stock piling up in their warehouses (http://news.yahoo.com/android-tablets-not-selling-well-claimed-145600449.html)

In the mobile/tablet space, user-experience is king, and Android simply don't seem to be able to pull it off. I am convinced it's primarily because of this issue.
 
Its all about the performance of the device. I have owned a few android phones that were pretty laggy. However, with faster processors comes better performance. Im surprised this was even a question to begin with. I have yet to see one instance of lag on my Galaxy S2.
 
+Andy Turfer , the untruths (if they indeed are present there) Jay Freeman was talking about were about iOS architecture, and weren't concerning her points regarding Android. This post above is already was refuted through and through, patched up and literally negated in the follow-up. I don't think even the author of it is pleased to have a bunch of Apple fans who froth at their mouths and yell without real knowledge of the subject. Enough already that the refuted, wrong points from the post above were widely cited by media and served as a weapon in troll battles - not a thing to be proud with.
Mat Pet
+
2
3
2
 
Well I have a Android 2.3.5 Device with a 1.15 ghz (OC from 1ghz) singlecore prozessor and 768mb ram (DesireHD) and most of the time stuff is as smooth as i want it to be. Of course i can notice what is explained here, a homepage will lag until its fully loaded for example, App list lags until all information is loaded. Etc. But, and maybe i'm strange, i like to feel my device working, and the important stuff like homescreen transitions (even with the Sense 3.5 3d effect) run smoothly at 60fps. Anyway i'd rather have some secs of lag than a page not loading completely.
Imagine a real situation: You want to load a webpage and start browsing. On Android you would wait until its loaded because you know its choppy until that happened. Or you just start and accept 2-3secs of laggy scrolling. On iOS you would wait until the page is fully loaded because if you dont, the page wont load at all.

My fiancee has an ipodtouch 3g and a good friend of mine has an ipodtouch 4g and i have to say iOS isnt 100% smooth neither. Big lists are sometimes laggy as well also with the ipod touch 4g (settings for example).
The same happens on my PC for example go to youtube klick the middle mousebutton and scoll that way. It lags! And thats on my 4gb ram 3.2ghz quadcore machine.

So all devices lag sometime. They're not perfect. I'd say Android is simply worse than the others at concealing it. I'm no software engineer or something but with only dualcores coming out, why not dedicate one core to rendering UI while the other does the rest?
 
It´s a shame that even after +Andrew Munn is completely corrected by authorities on this subject like +Dianne Hackborn and +Bob Lee people still find this a useful post. It illustrates how FUD will always spread better than real tech and how marketing always will win over a technical debate.
 
I hate it that nearly every blog talks about this and saying Android would NEVER be as smooth as iOS or Windows Phone. While the author clearly says he's convinced it will eventually become as smooth.
 
You really fucked things up. I can't believe someone who was able to talk out their ass on something that they're so fundamentally misinformed about has the audacity to publish something like this. Seriously, who do you think you are?

Idiot.
 
I don't CARE the reasons!!! I'm holding a Galaxy Nexus in my hands and I STILL SEE UI LAG!!! What the HELL Android?!?!?!
The iPhone 3G I just ditched had smoother response than this! And I'm not even talking about UI on some random app by some random developer! Simply swiping the screen left or right gives me ample evidence of UI lag! JEEEEEEEEEZ!!!
 
Thank you for very much for the explanation, and, for posting this, and, for asking this "Question".
Really thank you!

I can be at peace next time my Android phone stutters, instead of feeling Irritated! :)
 
+Михаил Никонов - "This post above is already was refuted through and through, patched up and literally negated in the follow-up". If that's the case, why is my Galaxy Nexus running 4.0.3 still stuttering when I scroll in most listviews (including those in native apps)? While this post may have been refuted, I still see no admission that Android is laggy/stuttery/jerky in the scrolling department, and no explanation as to why this is the case, and no clear plan detailing how this problem will be addressed (other than a Google IO video 'questioning' the need to use the GPU right now because CPUs are getting more cores, and are faster, better etc - Google I/O 2011: Accelerated Android Rendering).

This has nothing to do with 'troll battles', and everything to do with fixing a problem that severely damages the Android end-user experience. While this post may have been used as "troll fodder", it still drew attention to the issue (hopefully some attention from someone at Google who recognizes the importance of a smooth and responsive UI).

In regards to users "not knowing what they're talking about" - they shouldn't have to! A user should be able to pick up a handset and feel like he/she was born with it in his hand. A listview or webview (or anything that scrolls/pans) should follow the user's finger like a magnet. See +Arvind Gautam comment above, and many comments in Dianne Hackborn's rebuttal.

I understand that Google can't officially admit "Yeah, scrolling on Android is jerky and laggy in a lot of places", in which case they should simply fix it! Google have had years to address this problem, and while ICS has made vast improvements, the improvements feel like fire-fighting patch work (i.e. not fixed throughout, only in various places). Even Microsoft only took 11 (or so) months to fix the same issue in Windows Phone (WP7 Mango scrolling smoothness compared to NoDo).

Even after reading many "Android hater" articles/posts referencing this inaccurate post, I still feel that what this post did was a very positive thing for Android - drawing attention to Android lagginess/stuttering so that it will hopefully be addressed (something that Android users deserve, and which is long overdue).
 
+Andy Turfer, so, you suggest that one should draw attention to the lack of fluidity in Android's UI in any way possible, even making technical mistakes while trying to invent an explanation to this fact? I have an impression that you've hastily assumed that I'm arguing with the existence of the problem. Well, in fact I don't: the problem does exist, and in fact, until developers have started paying more attention to guidelines and proper techniques of development, it will persist. What I'm arguing against is the factually incorrect attempts to make some claims regarding UI's architecture.

Please, draw a strict line between «we need to draw developers' attention to Android's UI smoothness» and «I see it being laggy, so I'll blindly take any explanation and will fight anybody who questions it, even if it's technically incorrect». The former is an admirable endeavor, while the latter makes troll battles. The fact that attention is required - and it is - is no excuse for drawing it without having enough insight into the problem. Drawing attention may be a positive effect, but the negative effect of spreading misinformation vastly outweighs the upsides; you can't fight a problem while being incorrect about its reasons - you'd simply be refuted and forgotten; and more so, nobody would believe you anymore, even if you'd say that white is white and black is black. That's what I'm standing against. Get me right, I don't want to offend neither you nor the post's author, but with those methods of drawing attention one will not get anywhere.
 
Android is laggy. There's no question. But when the Google built apps are laggy, how are people supposed to assume that the entire OS isn't flawed. To get people "educated about proper thread handling" they need to show us how it's done, and how good it can look through their own apps like their web browser. Load up a graphically intense page in THEIR browser and scroll while it's loading, and it's still laggy. Why? Show us it's possible!

Right now, I'm not seeing Google pushing for a smoother OS feel, and I don't see them harping on it in the developer docs. The only thing I see is a greater push for better hardware, as opposed to better software. If it really "isn't their fault", then they need to be leaders and show us how it's done. It's their ecosystem.
 
+Михаил Никонов - I'm certainly not offended, this is nothing more than a discussion :). I was offended when Google closed Android issue 6914 (http://code.google.com/p/android/issues/detail?id=6914 - post 197). I was stunned when Google questioned the need for hardware acceleration because CPUs are getting faster and have more cores (Google I/O 2011: Accelerated Android Rendering). I was angry when I purchased my 6th high-end Android handset (the Galaxy Nexus) only to find the Android legacy lag was still there (despite the "it's incredibly fast" marketing and hype: Samsung Galaxy S2, Samsung Nexus, iPhone 4s - browser scrolling comparison and Galaxy Nexus Browser and Browsing Experience and Native Google+ App on Galaxy Nexus - foreign language lag).

I do not believe that this problem is due to developers not paying attention to guidelines. There is an overwhelming amount of evidence that shows Google are in denial are are belligerent in regards to this issue (http://www.satine.org/archives/2011/01/01/the-care-and-feeding-of-the-android-gpu/). I've run some simple tests at home with complex listviews and simple double buffering openGL - whenever a 'stutter' occurs you can clearly see a GC cycle occurring in logcat. Instead of telling developers their apps are jerky because they've coded it wrong, how about informing developers on how to do it right (I'm not talking about vague 'guidelines', and I'm talking about a 'definitive how-to')?

Perhaps some of my views on the issue are distorted because of the experience I have had with Android handsets - I am acutely aware of faults, even minor ones. I find it difficult to comprehend why Google receive praise for ignoring this issue (and people attempt to point the finger at devs) while someone like Andrew Munn is scorned for attempting to provide an explanation (albeit one that may not have been 100% accurate). Had it not been for Andrew Munn, this issue would be marginalized and rarely discussed outside of tech circles.

While I can acknowledge and accept the obvious negatives of posting information that is not correct in its entirety, I still think it has had a positive impact. I guess we'll just have to agree to disagree.
 
Interesting because of what is not said. To be short, no empirical data. Not one logic trace from any tool. Lots of hand waving from all the responses but not one set of numbers. No timers at the simplest level. No semaphore tracking data. No logic flow analysis. Neat. Sorry to rain on the parade. Keep those hands waving.
 
legacy support is the most bad things to do :'(
 
+Eastern Fish - The HTC One X, a brand new quad-core Android device:

HTC One X Hands-on - MobileSyrup.com

Does that constitute evidence? Oh wait, I should totally dismiss what my eyes see and get suckered in to buying one of these units (which I was thinking about until I saw the legacy lag in the video link above).

Perhaps when there are 16 cores scrolling will become smoother on Android.
 
thanks for posting the edits, but if the edits are accurate, then why is Android still laggy?
It seems ridiculous to me that a brand new Samsung Galaxy Note can be laggy while doing something as simple as taking a photo while my 1 year old iPhone has no such issue at all and is smooth like butter when it comes to all things UI and touch.

Is it possible for you to write another article (taking into account all the feedback you've gotten from the various people on the android team) to explain the Android lagg problem?

Or is there an article out there (hopefully written by someone on the android team) already?

many thanks!
 
but there are stuff that are ultra smooth in android like the launcher pro or tsf shell and some lists are smoother than others
it's just good or bad programming!
 
Would love to see a similar post for audio lag too
 
+1 for the audio lag issues, lovely post though, i've followed all the commentaries on this one, thanks!
 
Great ! Our PM also ask me "why ios so smooth,our android app can't,you should try more way to solution this problem, we can make our app very smooth on android like on ios ..."  
 
It is interesting how an intern working on Android for just a mere couple of months thinking that he knows more about Android than experienced Google engineers who have been working on this for 10-15 years. The sheer arrogance of this guy simply turned me off and it really puzzled me to see so many people completely disregarded this fact when reading his completely BS posts. If you don't know enough about the topic, if I were you, I would just shut my trap and let more experienced people do the talking. How much did you know about Android to write up this crap anyway ? Is spreading BS about Android the first thing you were assigned to do when joining Microsoft ? It looks like it because buried deep in your wall of text, I didn't see anything scientific about your study, just a bunch of 3rd party observation and random rambling that any untrained and uninformed people can do. Hey if I want to, I can write shit about physics and about the Higg Boson to and everybody would just believe me like I am some kind of Nobel physicist. That was what happened here pretty much. Back to the subject of lags, if you are bothered by it, switch to iOS and please stop complaining. Your problem is because you have so much time on your hand to even care about things such as "microsecond" lags. I use Android because it suits my needs and allow me to do thing I can never accomplish in iOS or Windows Phone. Hey, Windows 7 does lag too but professionals never complain because they use Windows 7 to develop new stuffs and they have more important things to do than to observe "lags". Seriously, I have an advice for all of you complaining about the lags, switch to iOS and Windows Phone and please stop complaining, no OS is perfect, period.
 
Dude what a bull shit post, seriously if you would make some android apps you would know that this is bs... and why some apps lags and some don't... 

thumbs up didn't notice thats 2011 :D back then there was some lag, but now if you know what you do your app wont lag on serious devices not some garbage phones 
 
Then explain to me why are there apps that all they do is provide me with a
list of apps/contacts and they scroll at about 2 fps and others that shows
the same information or even more and are smooth in 60 fps?
Apps that lag: aosp messaging app whatsapp lucky patcher app settings and
more apps that lag for seconds when you flick the list.
While Apollo titanium backup and most other apps do it super smooth.
 
in iOS7, when you are loading a web page and you touch the screen, it doesn't stop anymore, I used to tried this in iOS5 and it stopped, anyone know why it doesn't anymore? 
 
+Ivan Lee because iPhones got stronger?
Maybe Apple understood that people like to play with the scrolling while stuff loads and disabled this behaviour.
I think that animations like count downs still stops though...
Ios 7 is really slow on the iPhone 4
 
Also I noticed that kitkat fixed the scroll lag I talked about 4 posts above this one WhatsApp is better so does other apps
Nothing lags on the nexus 5.
Add a comment...