Shared publicly  - 
A few days ago I wrote a post trying to correct a lot of the inaccurate statements I have seen repeatedly mentioned about how graphics on Android works. This resulted in a lot of nice discussion, but unfortunately has also lead some people to come up with new, novel, and often technically inaccurate complaints about how Android works.

These new topics have been more about some fundamental design decisions in Android, and why they are wrong. I’d like to help people better understand (and judge) these discussions by giving some real background on why Android’s UI was designed the way it is and how it actually works.

One issue that has been raised is that Android doesn’t use thread priorities to reduce how much background work interrupts the user interface. This is outright wrong. It actually uses a number of priorities, which you can even find defined right here in the SDK.

The most important of these are the background and default priorities. User interface threads normally run at the default priority; background threads run in the background priority. Application processes that are in the background have all of their threads forced to the background priority.

Android’s background priority is actually pretty interesting. It uses a Linux facility called cgroups to put all background threads into a special scheduling group which, all together, can’t use more than 10% of the CPU. That is, if you have 10 processes in the background all trying to run at the same time, when combined they can't take away more than 10% of the time needed by foreground threads. This is enough to allow background threads to make some forward progress, without having enough of an impact on the foreground threads to be generally visible to the user.

(You may have noticed that a “foreground” priority is also defined. This is not used in current Android; it was in the original implementation, but we found that the Linux scheduler does not give enough preference to threads based on pure priority, so switched to cgroups in Android 1.6.)

I have also seen a number of claims that the basic Android design is fundamentally flawed and archaic because it doesn’t use a rendering thread like iOS. There are certainly some advantages to how iOS work, but this view is too focused on one specific detail to be useful, and glosses over actual similarities in how they behave.

Android had a number of very different original design goals than iOS did. A key goal of Android was to provide an open application platform, using application sandboxes to create a much more secure environment that doesn’t rely on a central authority to verify that applications do what they claim. To achieve this, it uses Linux process isolation and user IDs to prevent each application from being able to access the system or other application in ways that are not controlled and secure.

This is very different from iOS’s original design constraints, which remember didn’t allow any third party applications at all.

An important part of achieving this security is having a way for (EDIT: It has been pointed out to me that iOS does in fact use multiple windows and multiple GL contexts. Lesson to me, just don't talk about anything I haven't directly verified. :) That still doesn't change things for Android, though, where as I mention later we simply did not have hardware and drivers that could do multiple GL contexts until fairly recently.)
individual UI elements to share the screen in a secure way. This is why there are windows on Android. The status bar and its notification shade are windows owned and drawn by the system. These are separate from the application’s window, so the application can not touch anything about the status bar, such as to scrape the text of SMS messages as they are displayed there. Likewise the soft keyboard is a separate window, owned by a separate application, and it and the application can only interact with each other through a well defined and controlled interface. (This is also why Android can safely support third party input methods.)

Another objective of Android was to allow close collaboration between applications, so that for example it is easy to implement a share API that launches a part of another application integrated with the original application’s flow. As part of this, Android applications traditionally are split into pieces (called “Activities”) that handle a single specific part of the UI of the application. For example, the contacts lists is one activity, the details of a contact is another, and editing a contact is a third. Moving between those parts of the contacts UI means switching between these activities, and each of these activities is its own separate window.

Now we can see something interesting: in almost all of the places in the original Android UI where you see animations, you are actually seeing windows animate. Launching Contacts is an animation of the home screen window and the contacts list window. Tapping on a contact to see its details is an animation of the contacts list window and the contacts details window. Displaying the soft keyboard is an animation of the keyboard window. Showing the dialog where you pick an app to share with is an animation of a window displaying that dialog.

When you see a window on screen, what you are seeing is actually something called a “surface”. This is a separate piece of shared memory that the window draws its UI in, and is composited with the other windows to the screen by a separate system service (in a separate thread, running at a higher than normal priority) called the “surface flinger.” Does this sound familiar? In fact this is very much like what iOS is doing with its views being composited by a separate thread, just at a less fine-grained but significantly more secure level. (And this window composition has been hardware accelerated in Android from the beginning.)

The other main interesting interaction in the UI is tracking your finger -- scrolling and flinging a list, swiping a gallery, etc. These interactions involve updating the contents inside of a window, so require re-rendering that window for each movement. However, being able to do this rendering off the main thread probably doesn’t gain you much. These are not simple “move this part of the UI from X to Y, and maybe tell me when you are done” animations -- each movement is based on events received about the finger on the screen, which need to be processed by the application on its main thread.

That said, being able to avoid redrawing all of the contents of the parts of the UI that are moving can help performance. And this is also a technique that Android has employed since before 1.0; UI elements like a ListView that want to scroll their content can call to have that content rendered into a cache so that only the bitmap needs to be drawn as it moves.

Traditionally on Android, views only have their drawing cache enabled as a transient state, such as while scrolling or tracking a finger. This is because they introduce a fair amount more overhead: extra memory for the bitmap (which can easily total to multiple times larger than the actual frame buffer if there are a number of visual layers), and when the contents inside of a cached view need to be redrawn it is more expensive because there is an additional step required to draw the cached bitmap back to the window.

So, all those things considered, in Android 1.0 having each view drawn into a texture and those textures composited to the window in another thread is just not that much of a gain, with a lot of cost. The cost is also in engineering time -- our time was better spent working on other things like a layout-based view hierarchy (to provide flexibility in adjusting for different screen sizes) and “remote views” for notifications and widgets, which have significantly benefited the platform as it develops.

In fact it was just not feasible to implement hardware accelerated drawing inside windows until recently. Because Android is designed around having multiple windows on the screen, to have the drawing inside each window be hardware accelerated means requiring that the GPU and driver support multiple active GL contexts in different processes running at the same time. The hardware at that time just didn’t support this, even ignoring the additional memory needed for it that was not available. Even today we are in the early stages of this -- most mobile GPUs still have fairly expensive GL context switching.

I hope this helps people better understand how Android works. And just to be clear again from my last point -- I am not writing this to make excuses for whatever things people don’t like about Android, I just get tired of seeing people write egregiously wrong explanations about how Android works and worse present themselves as authorities on the topic.

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

One final thought. I saw an interesting comment from Brent Royal-Gordon on what developers sometimes need to do to achieve 60fps scrolling in iOS lists: “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.”

I am no expert on iOS, so I’ll take that as as true. These are the exact same recommendations that we have given to Android’s app developers, and based on this statement I don't see any indication that there is something intrinsically flawed about Android in making lists scroll at 60fps, any more than there is in iOS.
Sungmoon Cho's profile photoVladimir Bjelakovic's profile photoDavid Ford (FirefighterBlu3)'s profile photoJinpeng Zhu's profile photo
WL Wong
I will read it later since I am at work. But I would like to let you know that you are doing a great job. I know it is uneasy to "clear things up" and when explanations lead to more misconception it may be a morale-defeating uphill battle. I really, really, want to let you know that, you are doing something great, not easy, but great. In the end, I believe it is beneficial to have these discussions. As an Android user and Dev, may I say, a big thank you!
+Dianne Hackborn This is huge that you are posting this! I am just getting started with programming but I see Android being around for a long time to come, and I have no doubt Android will be one of the fastest mobile OS' on the market. I enjoy reading your explanations and it makes me feel good! I hope you continue to write more on these subjects, I know it takes a lot of time and work but I appreciate it!
Always taking your time to drop knowledge, both here and on the android-developers Google Group. Your effort is incredibly appreciated, thank you.
Really enjoy reading these. Even if it's not in response to public issues, I'd like to learn more about other Android inner workings. Keep these posts up!
Rami S.
+Dianne Hackborn I find the stock Android Laucher (2.3) to be choppy and slow, but replacement launchers like GO launcher EX is just as smooth as iOS. why is this the case?
Wow this is great, I was really hoping to hear another official posting by google in this discussion
I like the fact that all the hits to the SDK were API Level 1 content.
Excellent explanation. Thank you for share this to us.
You are the smartest cat in the world.
+Rami S. Pay special attention to how many different things are moving independently of one another from one launcher to another. The stock Android launcher has traditionally done several things that can be more expensive such as more overlapping and partially transparent elements, parallaxed wallpaper, live wallpapers, etc. (Android 3.0 introduced some optimizations for parallaxed wallpapers that made them quite a bit faster.)
"...when combined they can take away more than 10%..."

Should this read "...*can't* take away more..." instead?

I have to admit that I'm doubly impressed by this post. You could easily have let the inanity go, letting outside devs fight dopey fires for you.

Additionally, instead of calling out the wrongness and those who have spouted it directly, you've written a level-headed, clear, straightforward response that is concise and completely approachable.

If I could '80s movie slow-clap in here, I would.
+Tau-Mu Yi There is no simple answer that you seem to be looking for. In fact the question isn't even as simple as you are asking, because you need to specify for what particular part of the UI and what is going on at that point in both systems.
Very enlightening. Thanks for writing this.
Heya +Dianne Hackborn. If you wind up continuing these series of posts, it would be interesting to hear about deprecated APIs. I've encountered this more in sound than graphics where the newer APIs all seem to cause bluetooth/multiple apps/etc to play together better. Are there graphics APIs that developers tend to just use poorly or wrongly that have been cleaned up, etc., possibly since they were originally put in applications? Not necessarily talking to specific APIs, but philosophies or approaches that have changed.
"These are the exact same recommendations that we have given to Android’s app developers, and based on this statement I don't see any indication that there is something intrinsically flawed about Android in making lists scroll at 60fps, any more than there is in iOS."

Are you saying Android app developers just Doing It Wrong™?
+Dianne Hackborn It's a sad thing that there is no simple answer to the question everybody is asking, from what you say it looks like the lagginess is due to a combination of factors (vendors, developers, Android itself, hardware platforms) that makes very hard to expect a "resolution",

Android will get better, some platforms will get better, and some apps will get better, but nothing Android can do will solve the problem completely.
+Dianne Hackborn great post! Now what would be great follow-up posts that would assuage those making all the noise: links to resources for app developers to optimise the speed of their apps, and insight into improvements coming from the Android team. Thanks for taking the time to get this information out!
+Lukito Truong We'll share what we're able to, but the nature of mobile right now is that many things are confidential until a public release. That said, a number of talks that Android team members have given over the years at Google I/O are available to watch on YouTube and many address creating smooth and beautiful apps.


The Android Developers blog also has frequent updates about best practices:

Also don't discount and the official developer mailing lists: a number of us on the Android team post frequently in both places.
+Dianne Hackborn Thank you for explain these professional conceptions to us. As both Android and iOS devices are becoming more and more popular in China, people get starting to compare them and debate. Your article has been translated to Chinese and after reading it, people can understand the Android much deeper. That's really nice of you ^_^
The thing that was so satisfying about the intern's post was that it identified a primary problem and offered a clear solution for Android's lagginess. Whether it was right or wrong I don't know. But Dianne, these posts from you make me worried because I feel like you're essentially saying, "We're already doing everything we can. We don't know what else to do." And that makes me think maybe something is being evaded, and/or that the Android lag is going to be around for some time to come.

This post is a statement of how things work technically. Which is fine, but it's not what people want to know. They want to know why Android doesn't scroll as smoothly as other OSes and they want to know that you guys acknowledge the issue and know how to fix it. Or at least that you're looking into how to fix it, and not sidestepping the issue by simply explaining how Android works.
Thanks for these posts. They are very interesting.
Kun Li
+Craig Hammell Why do you think so? First of all, no matter how satisfying that intern's post looks for you, it's wrong. Just simple like that. You can't say a wrong post identified a primary problem and even offered a "clear" solution because the fundamental tech information is wrong. +Dianne Hackborn could point it out, or not, and she choose to do so and give others a chance to learn more about the underlying mechanism of Android. That's it. When did she ask people to take this as excuse of Android's lag?

+Dianne Hackborn also tells us that one of the main reason for lag is "In fact it was just not feasible to implement hardware accelerated drawing inside windows until recently", and she tells us why it's something related to hardware. And we all know with a proper hardware, what a dramatical improvement ICS brings us already. Have you ever used a Galaxy Prime to see if there is anymore laggy UI in ICS?

She also tells us that lots of things still need to improved. Android team know the essential reason and acknowledge the issue already in previous post. Of couse they can't say "xxx is very simple and we just need to do A, B, C and boom, that's it". How could you expect them to say that?
Joe Ching
agreed with Craig... it's all well and good to explain the fine technical details... but to the average joe, all they care about is what they see. when they see that an iOS device is more responsive (in terms of touchscreen and UI) as the latest android devices, they will infer that the apple device is more powerful. the bottom line is, it's taken multiple incarnations of android, plus devices with very high end specs (oodles of RAM and more and more powerful GPUs) to even match the UI response of an old 3GS (i've compared my friends old 3GS to a galaxy s2)
+Craig Hammell It's not what you want to know. I am writing these to explain how things work. I am not trying to make excuses or promises or make you feel better. I just want there to be accurate information about how Android actually works. I think you are looking for a simple answer to a topic that doesn't have one, that doesn't even have simple questions. If you are looking for "by doing X there will be no lag on Android," you are never going to be satisfied; heck, it's not like iOS never suffers from lag. I think all I can really say on this topic is that Android has been improved greatly over the last few years, through a variety of changes including a number I have previously mentioned, and it will continue to be improved.
This the price to pay for a better operating system.I would not trade Android for ios limitations. my phone is faster than the iPhone running applications such maps and that's all I care about.
+Kun Li Yes, I acknowledged that the intern's post could have been wrong. But that wasn't my point. My point was that what Dianne's posts lack that the intern's had is the identification of specific problems with clear solutions. Even if that post was wrong, that's still a good thing, because we can say, "well, at least we know that this specific thing we thought might have been a problem, is not actually the problem, so we need to look elsewhere for a solution."

The "not able to implement hardware accelerated drawing inside windows until recently" is hard to swallow. iOS has been smooth since 2007. It's almost 2012. That just doesn't seem like a valid explanation. If the technology wasn't available to Android, then it wasn't available to iOS either. Which means the problem is something else, which means mentioning anything about hardware acceleration in this debate is an equivocation.

"Of couse she can't say "xxx is very simple and we just need to do A, B, C and boom, that's it". How could you expect them to say that?"

I don't fully expect them to have the answers in front of them clear as day, but I assume they know their own system inside and out. At some point they'll be able to say it like that. You have to before you can fix things. So it's not unreasonable that they could be at that point now.
Thanks for the post. It is very informative and helpful. I noticed iOS app can stutter if app does too much work in main UI thread, but it rarely happens. On Android, most apps seem to do too much work in UI thread on regular basis, including the Google+ app. Given most of Android devices are still running 2.2/2.3. It is better to optimize apps than count on magic OS change.
Kun Li
+Craig Hammell that's not the purpose of this post. You are imposing your purpose here. +Dianne Hackborn didn't say "hey, I don't give it a damn, Android is running really well and let me tell you guys what's the solution for the last missing piece."

And why "not able to implement hardware accelerated drawing inside windows until recently is hard to swallow"? Do you really read this and last post carefully?
+Dianne Hackborn Yes, you've done great work. I love Android and I anticipate greatly its improvements over time. The thing that gets me in this debate is that I'm not sure the topic of "how android works" as a general question was what people were ever really interested in. The question was more, "how does android work, qua improvable system with identifiable UI issues". IE, what can be done to improve it? I appreciate the time you've taken to explain what you have, however I don't think it'll satisfy many, because it's not answering questions that they're asking.

+Kun Li You're right. I'm ignoring the purpose of the post. My apologies, I'll stop.
+Craig Hammell As far as I know, iOS doesn't (or at least didn't originally) need multiple GL contexts, because the current application was the only thing that draws to the screen. And let's be clear: if what you are looking for is someone to identify some specific problem or two that someone can take care of and there is no lag any more, you are looking for someone selling snake oil.

It is probably worth quoting the rest of Brent Royal-Gordon's comment at this point: "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."

These kinds of performance issues can everywhere across the stack -- from the GPU and its driver, through the kernel, the platform and application framework, and in the design of apps. Even if everything under the apps is perfect (and I am certainly not going to claim it is), you can still make it fall apart by not doing things well and putting the work needed into your app.
I really enjoy learning more and more about Android through your Google+ page. I hope it keeps coming!
Pete R.
Great insights!
Thank you +Dianne Hackborn for the great intro into how +Android actually works. I found it to be a very interesting read and hope to learn more in the future. It only goes to verify how robust the Android operating system really is and without that robustness we would undoubtedly not have many of the amazing features and functionality we enjoy in Android. I will take a robust and feature rich operating system that may be slightly ahead of the hardware market over a simple and boring status quo operating system any day.
+ Dianne Hackborn thanks for posting this..
+Dianne Hackborn Very interesting explanations on this issue. Its really great to have direct insight from the people who actually work on the platform. However, I'd like to see a thread posted that details what can or should be done to achieve the same level of smoothness as IOS from today's current devices. I mean, if the full hardware acceleration of ICS is not the full answer, than what is?
Thanks +Dianne Hackborn i love your posts as they actually contain Facts about my prefered platform, like u im sick of morons, mostly iZomies, who assume they know how it all works. At least you admit you dont have any expertise on iOS but you are an expert on droid, i just wish the iOS iZombies would admit the same.
+Adam Powell thanks! +Craig Hammell I get what you're saying and I was going to write a similar comment, but thankfully you did and got all the response :-) These posts about the Android UI have been picked up by the blogosphere and the tone of conversation is unfortunately becoming negative. As hard or even nonsensical as it is to provide a "simple answer" for the lag in Android, it's what people want, to define what the problem is and its solution, as it's just so important to so many people. Not to take anything away from +Dianne Hackborn's posts and what she's done - all respect!
+Craig Hammell Why is the "not able to implement hardware accelerated drawing inside windows until recently" hard to swallow? When she gave a great explanation for it on the very next sentences:

Because Android is designed around having multiple windows on the screen, to have the drawing inside each window be hardware accelerated means requiring that the GPU and driver support multiple active GL contexts in different processes running at the same time. The hardware at that time just didn’t support this, even ignoring the additional memory needed for it that was not available. Even today we are in the early stages of this -- most mobile GPUs still have fairly expensive GL context switching.

iOS does things differently than Android and vice versa. If you want to know some of those differences, just read the entire post again and you'll see tidbits like this: You'll find that iOS didn’t allow any third party applications, but Android does - and in a secure way by having a way for UI elements to share the screen via windows. And according to +Dianne Hackborn, in almost all of the places in the original Android UI where you see animations, you are actually seeing windows animate. And since Android have always supported multitasking, I can imagine how the combination of all these can cause lag. iOS is/was a limited platform with no multitasking, and I can also see how they can make things run smoother in their OS since they control everything - including hardware! Android OS runs on different phone hardware, and each one performs differently. To quote their commercial, "There's only one iPhone"
Very insightful post. Whether one's on the iOS side or the Android side of the divide, the best thing is that this debate is contributing significantly to understanding the Android platform and writing better Apps. Also understanding how mobile app Dev works, irrespective of iOS or Android.
+Xernan Pascua The explanation you're quoting makes sense given that Android works the way it does. If we accept that Android has had to work that way, then we can say "yeah, the hardware just caught up now." What I'm saying is that Android did not/does not have to work the way that it does. I'm saying that given some alternative development of Android, the hardware of the past could have been sufficient for a smooth scrolling experience. When someone says "the hardware just caught up now," they make it sound like it would not have been possible under any circumstances to have developed Android such that it did not have the lag that it did. That seems false, given that other OSes running on on-par technology didn't have that lag. So given that some alternative development of Android could have resulted in a better scrolling experience on the same hardware, the hardware isn't really the issue. The software is.
+Dianne Hackborn Thanks for the last few posts, please keep it up , Although we may not all comment on it here there are a lot of us that want to know as much as we can about how android works. I have owned and worked on 12 android devices (GN & #13 due tomorrow) and can say the topic that spawned all of this is a non issue in the short term, it has never effected me or anyone in a significant manner. Maybe on the g1 it was more of an issue at times. Like you stated above, I can also make IOS lag like a three legged dog in a dog race, with very little effort in fact. Please don't let comments made detract from your original goal in the post, while I appreciate you trying to answer +Craig Hammell 's post's, he answered all you needed to for you. "Yes, I acknowledged that the intern's post could have been wrong." & "Even if that post was wrong, that's still a good thing," As most of us already have learned when arguing out differences between IOS and Android with IOS defenders These people won't be burdened with facts or the truth, perception and Image is what drives them. Arguing with one of them using facts, models, examples, etc will get you nowhere, except confused exhausted and angry. Also trying to be civil and explaining its not about better its about differences and trade offs will not achieve sanity and reasonable discussion. Arguing or offering explanation is fighting a war you can not win, even if you spent the time to have your team develop and run the IOS framework in android and better than Iphone can run it in front of them, you would not win. (ironic isn't it ? Wasn't one of apples big claims a few years ago was how much better they ran windows than pc's?) Point is if and when given time constraints allow please continue to post more info about how the inner workings of Android run, and we would love to hear thought processes and incite as well. Ever watch a good lawyer depose a witness ? If you don't catch on right away, you can't figure it out, Why is he asking that ? why did he say that ? He is going to ruin everything!!... Than it unfolds, the direction and strategy that only he could see and the witness is walked into a corner forced to sob and confess Anyone's decisions are easy to judge from an ignorant outside position, the true beauty is in what the creator has yet to reveal!!
+Dianne Hackborn Thank you. Another very good post.

To the rest of the Android team, thank you. I love building on the platform and am very pleased with my Android devices.

It is understandable that trade-offs have been made for one reason or another; what I don't understand is why people are asking for a magic bullet to cure all lag. Its not going to happen if you expect someone else to do it for you. If you are a developer and you want to improve the performance in your application I suggest you checkout the following resources:

Google I/O Talks:
The World of ListView (+Romain Guy)
Writing Zippy Android Apps: (+Brad Fitzpatrick)
Memory Managment: Google I/O 2011: Memory management for Android Apps
Accelerated Android Rendering: Google I/O 2011: Accelerated Android Rendering

List of Optimization Articles:
Strict Mode:

You cannot blame the platform without profiling your own code first. It makes a world of difference, just try it for yourself.
Summary: Android's design is different from iOS, it's not a flawed design, just different compromises. Hardware will catch up and the Android design will prove good. I agree completely.

+Chris Smith ...there needs to be a "save post" option in google+ for your post.
A question i would like to have answered, why in the world does iOS lag sometimes... and why it is just "buttery" sometimes, stopping you from resolving your tasks as fast as you would like to.
But not from you +Dianne Hackborn , thanks for the answer!
I'd like to bring in another point. What about memory management?
I've always got the feeling Android's determination to multitasking and cooperative memory usage is a problem for UI speed as well. Originally, the heap of each app was limited to 16MB, afaik it's up to 32MB on newer devices. This may look like more than enough on small screen devices, but it sure as hell doesn't allow the app to cache all thumbnails of a big list. So they need to be (re)loaded while the list's scrolled - either in the UI thread, which causes really ugly hangs, or in a background thread, which still needs some processing time and requires subsequent updates of the element views (and for fast scrolling also needs synchronization, otherwise an already recycled view would be updated with the image of the previous entry...). Similar goes for the Home screens: I usually experience the worst hangs when icons or app widgets on other screens need to be (re)loaded/drawn because they're no longer in cache.
+Craig Hammell : Just because an explanation doesn't make sense to you doesn't mean it doesn't make sense.

Android leverages process isolation for security. This is much more important in Android than in iOS because Android allows side-loading from non-market sources. This approach makes it fairly obvious to isolate surfaces, and, similarly, makes it difficult (if not wholly infeasible) to have leveraged OpenGL acceleration for all apps on older hardware. One can imagine a mechanism for sub-section isolation in a display scene-graph for processes, but that's a fairly non-trivial thing to dream up and implement. On top of that, effective enforcement of security policy might put any gains from such an approach out of reach.

So, in the end, you can take comfort in the fact that you're right in saying that the software is responsible for stuttering, but you have to acknowledge the significant differences in approach and resultant capability in Android. Here are a few points:

- Android's home screen ties into 3rd party widget applications (and wallpapers). iOS has no such requirement (read: feature). The launcher of iOS is restricted and curated.

- Android's input mechanism is also 3rd party pluggable. For security reasons, this naturally ends up running in a separate process. iOS doesn't have this requirement (again: feature).

- I don't know what sort of magic iOS devices you have, but mine stall at times. You may notice, if you watch carefully, that iOS devices can sometimes hang up for a moment before appearing to be very smooth in a preset animation. This is CoreAnimation at work. It's clever and effective. Interestingly enough, you'll perceive something to be of lower performance if it has a higher average framerate but greater variance. Basically, dead locked at 30fps looks better to most than 60fps with occasional dips to 25fps. What is less intuitive is that dead locked at 15fps can feel smoother than 30fps with dips to 20fps.

I don't think anyone is arguing that there isn't performance work to be done on Android. I'm not sure if the background system makes use of the blkio cgroup, for instance, but I'm fairly confident that if it doesn't, people are at least aware of it.

Engineering resources aren't free, and seemingly obvious priorities for one person can often have significant ramifications for the system as a whole. It feels like performance has certainly been a priority for the Android development team, but it's not alone.
This is just downright disappointing. Almost all of the information about iOS in this document is wrong. I just lost all hope that the Android project is ever going to fix their interface lag issues: they apparently have no clue what they are talking about.
Hi Diane,

Excellent reply to the debate showing how Android works.
If I understand correctly, a lot of lag issues (if not all) can be fixed by the app developers themselves, by using proper design and using the right performance tweaks?

Apple enforces a quality control on all apps, where Google does not. Would it be an idea if Google creates an "Approved App"-area in the market where they do check the quality of apps?


+Jay Freeman While it would be bad if the iOS facts are wrong, I don't see how that relates to reducing lag on Android? There is usually more than one solution to a problem.
Nice post! Any chance we can get a similar post about the Android audio subsystem? The latency of realtime audio generation and recording through both AudioTrack/AudioRecord in Java and the corresponding C++ OpenSL facilities is still quite bad even on modern devices. iOS can do sub 10ms latency for raw PCM streams, on Android you're lucky to get 150ms latency on most devices.

This problem rules out an entire app category (music apps that do their own audio synthesis) on Android and for many people it's more important than a little bit of UI lag, so it would be cool to have a post on the reasons for this and any plans to fix it.
+Rasmus Backman The reason we are reading this (or the previous) article at all is as a defense against various (also often incorrect) reasons why Android's UI is so much slower than that of iOS. Only, the primary defenses listed in this second article are of the form "iOS does X, we could not do X because we believe Y is more important, forcing us to do Z instead of X as a necessary tradeoff", when in fact (if you spend the time to pull apart how the system works, which a lot of us in the jailbreak scene have done extensively) iOS does not do X, and quite to the contrary actually does Z, but because Apple doesn't particularly want developers doing anything "awesome" (which sucks), simply makes it look like they are doing X, even though the system totally supports the glory that is Z. Unfortunately, this mistake totally undermines any confidence in this analysis being correct, and also brings up serious doubts of whether the people on the Android team actually understand the core problem in the first place. :(
+Jay Freeman I get your point, but I think we are reading +Dianne Hackborn differently :) What I read is a lot of people saying "Do it like iOS does it, rewrite Android, eveythiing sux ..." and Dianne replying "No, we don't want to do it like that". My point is that I don't believe that understanding the finer details of iOS is neccesary to improve on Android - there are probably solutions that would fit better into the Android system. It's not a post about how iOS does things as much as how Android does them. :)
good to read you r article. but I have one conver that how much does GC compact on UI performance? should it be the key factor that android UI works slower that iphone?
Tim Box
Thanks for going into the details. It was a great read and will read it again. What I got from it is that Android actually is more secure at the run time level. iOS has to do it at the front door.
+Craig Hammell I have to agree with you here Craig. All I got from this post was "TL;DR People are wrong about why Android lags. Here's how Android works, but I still don't know why it lags."
+Dianne Hackborn Very interesting post indeed. I don't have the technical knowledge to add to the discussion. But from a user stand point, I'm scrolling through this post on my Samsung Galaxy S II through the google + app and I'd say that the stuttering is quite annoying given the powerful hardware. Although I'd never trade my android phone for an iPhone, the experience on my wife's iPhone 4, which is a less powerful piece of hardware than my Galaxy S II, is much smoother. Never experienced any jitters. I'm quite saddened by that. Especially now that I understand that even with ICS the jitters won't be solved.
Sadly, theories about why things work the way they do seem to get passed around like urban myths - over a pint of beer in the local IRC channel. I too hear too many half-plausible myths get passed around which are just not true. It's always good to read a good in-depth analysis from someone who actually knows what they're talking about.
Nice article, very useful details about the low level implementation.

As for the pro/cons of iOS I don't really care. What I care about is having a good development environment, which is easy to use and flexible. I can nearly always work around any constraints by careful design of my application.

As for the Android vs iOS debate, well its all noise, what matters is that both are pushing each other on to create better platforms for consumers. And forgetting designers, architects and so on for the moment, it IS the customer who counts. They pay the bills ;)
Andy Turfer
Another attempt at a 'feel good' post full of technical details which has resulted in nothing other than satisfied Android users arguing over semantics with dissatisfied Android users. Way to fracture your user base!

I have a Galaxy Nexus, and while it's much better in many areas, it still struggles with scrolling in most. A simple test: go to and pan around the page. Repeat same test using WinPho or iOS or Nokia N9 and compare the difference. Or better still - take said Galaxy Nexus, and try to open one of these Google+ posts (my Galaxy Nexus simply crashes after freezing for about 3 seconds).

There is a clearly observable problem with the Android user-experience/HCI, and the cause is the choppy performance with the phone's UI and most third-party apps (try scrolling in: IMDB or Engadget or any semi-complex ListView, then do same test on competing platforms). It makes the handset feel unprofessional and unfinished, like something you would expect from a KIRF product purchased from behind the Bamboo Curtain.

Is it just coincidence that Samsung did some work on addressing this issue (and were semi-successful) with the Galaxy S (from 2.2.1) and the Galaxy S2, and that these Android handsets outsell all others?

I'm giving up. Time and time again Google (the Android team) prove that they have zero intention of solving this issue - or even acknowledging that it is an issue (Google I/O 2011: Accelerated Android Rendering). Just wait around for "bigger, better, faster CPUs with more cores" - what a fantastic engineering solution!

I don't mean to harsh out on anyone, but while this problem remains, reviewers will continue pointing it out, and Android users will not get the HCI experience they deserve and which is long overdue (and it also feels good to vent here, as I feel £520 has been stolen from me).
Just fix the lagging please! It totally breaks the user experience. Seeing my N1 and GalaxyTab10.1 stutter makes me really sad. And whenever I use an iPhone it makes me cringe. (and still will never convert to iOS.) Android gets better with newer OS versions and better hardware but it still happens from time to time and comparing to the old iPhone hardware which was smooth from the start is just sad.
+Andy Turfer Well I've just tested with my wife's iPhone and I don't get any of the issues you're mentioning. As I said on my previous post, the lack of smoothness saddens me a bit but as far as browsing is concerned my Galaxy S II feels much better than the iPhone. I went to and the page loaded faster while it was slow on the iOS browser and had checkered boxes. Besides, I didn't experience any of the crashes you are reporting. It might be hardware related here
I'm no geek but as long as iOS/WP feels (that is, without any lags) and works flawlessly 99% of the time, I will not consider Android. And because the perception of the user matters most, I don't even care if your droid has a quad core processor as long as my single core iPhone can do the same UI thing without breaking a sweat.

Great post btw :) very informative
+Jordan Logarta I'm a long-standing Android user, but this is the reason that I'm so hesitant to recommend Android handsets for business use at work. The experience needs to be top-notch and it's just not there yet.

现在网上满天飞的各类关于Android图像渲染的水文实在让我不爽,下面给大家一些关于Android硬件渲染的事实真相,硬件加速并非大家想的那么完美,而我们也一直在改进! 1. Android 一直在使用硬件加速。实际上从1.0版本之后,所有的窗口元素的合成与显示都是通过硬件完成的。



4. 现在我们来关注窗口元素的内部渲染,实际上为了达到每秒60帧的FPS,你并不一定需要硬件加速。帧速取决于要显示的像素的数量以及CPU的速度。比如说,二儿子完全可以以60FPS的速度在它800*480分辨率的屏幕上完成任何普通的原生UI动画,例如列表的滚动等,完全没有问题。而最初的Droid系列却很难达到这样的速度。

5.在Android3.0中可以实现窗口的”完全”的硬件加速绘制。而在Android 4.0中也没有引入更多的功能。 从3.0开始,如果在你的应用中设置了一个标志允许硬件加速,那么此时所有的窗口的绘制都会交给GPU来完成。在Android 4.0中最主要的改变就是:在面向Android4.0或更高版本的应用中,硬件加速是被默认开启的,再也不需要在配置文件中设置 android:handwareAccelerated=”true”.(而我们不允许之前的应用默认打开硬件加速,是因为光靠硬件加速,无法很好的完成某些特殊的绘制操作;同时在应用需要其中一部分UI更新的时候,会影响其的一些表现。对于目前现有的很多应用,强制开启硬件加速,会明显的中断应用的运行)


7.由于OpenGL的额外开销,我们最好不要过多的使用其进行绘制。比如我们现在在做的一些工作,就是为了让Android 4.0能在不使用硬件加速的情况下流畅的在二儿子上使用:这样我们就不需要在系统进程中浪费8MB的内存用,也不需要在手机进程中浪费额外的8M内存,或者是在系统UI进程中的8MB内存 等等等等。相信我,你不会注意到——用OpenGL来绘制一些类似状态栏或是华丽的动画是完全没有好处的。



10.当人们比较Android跟IOS上浏览器的滚动流畅度的时候,他们所看见的差别并非开没开启硬件加速所导致。 最初的时候,Android使用了一种完全不同的渲染策略,并做了一些折中:网页被转换成一个”显示列表“,持续的在屏幕上进行绘制,而非使用块(Tiles)的形式。它有一个优点:就是在滚动或是缩放的时候不会发生有的块还没被渲染出来的现象(译者注:早期的IOS上这种现象非常明显,快速滚动到底部时要等一会网页才会一块一块的绘制出来)。 而这个方法的不给力之处就在于页面复杂的时候,帧速就明显低了。例如Android3.0,浏览器中现在开始使用块的方式进行渲染,于是它可以在滚动或是放大的时候保持一个稳定的帧速,自然也会出现新的块没有被立即渲染出来的情况。 而每个块都是以软件方式绘制的,我相信在IOS中也是这样的。(在3.0之前的版本中,没有开启硬件加速,基于块的策略也可以使用。而且如我之前提到的,二儿子可以很容易的达到60FPS)

11.硬件加速不能如大家所想奇迹般的让绘制的问题统统消失。GPU的性能就是一个很重要的限制。最近一个很有趣的例子:基于英伟达的Tegra2的平板可以很容易的以60FPS的速度访问2.5次1280*800分辨率的屏幕中的任何一个像素。现在考虑到在Android 3.0中切换到所有应用列表的情形:你需要绘制背景(1x 所有的像素)、接着是快捷方式和桌面小工具(假设内容不多,花费0.5x),接着是所有应用的黑色背景(1x),接着是所有应用的ICON(0.5x)。显然,我们已经超过了原先的预算了,而此时我们还没完成各个独立窗口元素的拼接并做最后的显示。想要取得60FPS的动画,Android 3.0以及后续版本使用了一系列的小技巧。 其中主要的一个就是: 它将所有的窗口元素平铺在一个层中,而不是挨个拷贝到CPU的缓存中。但即使是这样,我们已然超出预算,幸好我们使用另一个技巧:因为Android中的背景是一个独立的窗口元素,我们可以将它设置的比屏幕更大来放置整幅位图,现在,用户开始滑动,背景跟着运动,此时并不需要任何特殊的绘制,仅仅是移动窗口即可,而由于这个窗口是在一个平铺层上,我们甚至不需要用GPU来将这个窗口元素组织到屏幕中输出。




而两者之间最大的差别就是三儿子需要同时绘制2.4倍于盖世兔的像素。这相当于在单核上提升到2.4倍的速度。(需要指出 在UI渲染的时候,多核是没有意义的,因为渲染必须要在一个进程中完成,无法并行)

这就是为什么硬件加速非常重要:随着像素的提升,GPU通常能更好的处理图像的运算。事实上,这是我们在Android中引入硬件加速的最大动力。在720*1280的屏幕上,现有的ARM CPU达到60FPS很吃力,但是通过GPU渲染就不同了。同样,在与盖世兔的比较中,同时打开没有硬件加速的应用,在三儿子中无法达到盖世兔同样的60FPS,是因为它得渲染2.4倍于盖世兔的像素。


+Dianne Hackborn is there a way for the community to validate key assumptions about the Android system. I have been digging into Android while publishing this information but there has been a general lack of review/moderation on this topic (certainly on the google groups android groups). We have hit many of the issues you mention like the 2M process overhead or worse the PVR related memory issues. Most of the time are spending huge amount of time trying to figure out how things work to be able to fix problem. The information on these post really deserves to be published to get to a proper place.

In your post you mention that the foreground” priority is also defined but not used. Still it might be good to mention that starting a service using with the startForeground will impact it's performance as it will be put in the "default" scheduling group.
+Andy Turfer +Zaki Manzanza Ok... I've just done an objective comparision with the "" website. First, let's forget about page load time - there are so many other variables involved it's just not productive - line speed, congenstion, and none of it relates to UI performance. That out of the way, first I loaded the page on my Galaxy Nexus, ICS. Being honest, the results weren't pretty. Scrolling was jerky, and not pleasant. However, it was very usable, just annoying. I then loaded the page on my iPad (I don't have an iPhone for comparison, and only own and iPad because I won it). Actually, the iPad is a better comparison, because it is closer to the resolution of a Galaxy Nexus - a Nexus has 1.5 times the number of pixes to shift as an iPhone 4S, but only 1.17 times as many as an iPad. On the iPad the scrolling was "buttery smooth" HOWEVER, anything that was out-of-view wasn't drawn - I got the checkers. When I stopped scrolling it too a few SECONDS for the rest of the page to draw. Now, let's be very clear, this was NOT the page loading, as it could repeatedly scroll back and forth, and it would have to repaint the screen every time I scrolled.

To me, the behaviour on the iPad was far worse. Ok, so it's a little cringy to have jerkiness when scrolling, but at least I could see where I was scrolling to. On the iPad, if I was looking for a particular point on the page I'd have to stop, wait for it to redraw, and then carry on. To me, a little jerkiness on browsing is a small price to pay for USEABILITY. That's based on a side-by-side comparison, not built up frustrations with a single device.

+Dianne Hackborn really knows her stuff. I am myself quite familiar with the Android sources - I'm a contributor to CM, and know my way around them pretty well now. However, I don't profess to have a fraction of the understanding she has. It's clear there is still work to be done in this area, but the Android team have made certain compromises, and I'm pretty sure the platform is better for them.
I will never expect that there are people on this earth who will basically say: It is ok to have lagging in interface, it is price for better multitasking, open system, whatever. It is insane on same level as accepting iOS walled garden system(we want Apple to filter out some apps for us..meh).
+Martin Long Thanks! I feel a little better now that I know I'm not completely crazy about the jerkiness. I also own a Galaxy S2 and iPhone 4s, and neither of these has a problem with that page. Please keep in mind that page was a single example - the Internet is a very big place :). I'm coming across such 'unpleasant' experiences quite often, especially when using Google News. It's like a lucky dip using any news aggregator ("step right up, try your luck and click on a link, everyone's a winner!"). Google+ pages are even worse - they simply crash the browser (no error dialog).

Samsung worked miracles with the stock browser. I recall my Galaxy S flying after they released the 2.2.1 ROM for that device - one of the reasons why I stuck with Samsung and purchased the S2, and subsequently the Galaxy Nexus. While the S2's browser is fantastic, other parts are not - such as an SMS inbox with a thread of 30 or so messages, or scrolling through a long list of contacts (it seems to 'stutter' when the ListView has to render headings while scrolling is occurring, so it's not 'fluid'). Third party apps suffer the same fate (i.e. IMDB: scrolling through 'Latest Trailers' or the 'Coming Soon' list, same app on iPhone - buttery smooth and flawless fluidity which makes the end-user feel good).

Another test on the Galaxy Nexus: open an SMS thread with 30 or so messages in it from a contact who has a photo, and scroll. Or Skype: install Skype, chat with someone, then scroll up the chat. I'm not even going to start on viewing/panning around PDF files ;(.

It's not like I'm just coming in here and "hating". I've spent something like £2,500 on Android handsets: a Dell Streak 5, HTC Desire HD, Samsung Galaxy S, Samsung Galaxy Mini, Samsung Galaxy S2 and a Samsung Galaxy Nexus. Each time I look for a fluid and responsive UI, the kind the competition provide, but each time I'm left feeling disappointed (it is getting better in many areas, I have to admit, but it's not consistent and not implemented throughout). I understand that this issue probably effects some folks (like myself) more than others, and perhaps I'm overly sensitive to it, I dunno... What I do know is that as a consumer, I can't play the waiting game any more - waiting for Android to deliver a UI experience that is considered 'normal' in this day and age.
+Martin Long It might be related to the Galaxy nexus. Don't have one to compare. But I just can't reproduce what you guys are experiencing. Scrolling, at least in the browser, is butter smooth. No jitters at all and pages loading fast. I did the test on my 3G network. Twitter and facebook apps are very responsive too. Jitters happen (sometimes) when switching to other apps, swiping across different home screens or opening up an app. They are micro stutters that are pretty annoying I'd say. The average user might not notice them. Still, I'd like the experience to be perfect. Especially as I know that ios, webos or windows phone 7 don't have such problems.
+Andy Turfer I have to admit that you are right about most things. Opening a thread with multiple messages in it is jerky on the stock sms app. But go sms pro is much smoother. It might be because I use a custom rom and kernel but I shouldn't have to and even though modders are doing a pretty good job enhancing the user experience it just lacks the fluidity you are entitled to expect from such a platform
This is a great post, and I understand the purpose wasn't to defend android, but there is still a lot of truth to the criticisms in the comments. I have plenty of android devices, I have recommended android devices to loved ones, etc, but at the end of the day, it does get a little difficult to deffend android when iOS simply looks so much more polished. I feel like I'm trying to sell the primered 4wd truck sitting next to the similarly priced shiney corvette, and saying, "sure that may LOOK great, but what are you going to do when it snows?". People like my mom don't care why android seems glitchy and laggy. People like my mom expect smooth, and it would be nice if someone... anyone on google's side would say, "Yes, this is a problem, and we are working on it." as opposed to saying "don't worry, the phones will get faster". Lets also keep in mind that apple's phones will get faster too, and they'll still be operating with a lean machine.
Any thoughts on how any of this relates to the significantly worse battery life on android vs iOS if at all?
+Ryan O'Neill I would definitely think about the fact that there were background tasks at all in Android that contributed to it. Look at iOS5 and all the issues it had when introducing the notification bar and the related battery issues. Multi-tasking on a mobile device just isn't reasonable without heavy duty battery.
+Ryan O'Neill That's not true anymore. Battery life is much better, at least in my Galaxy S II. Despite having widgets syncing in the background, push mail, browsing the internet I enjoy a greater battery life than my wife's iPhone 4. Seems her battery life went worse since upgrading to iOS 5
+Dianne Hackborn
"Even if everything under the apps is perfect (and I am certainly not going to claim it is), you can still make it fall apart by not doing things well and putting the work needed into your app."

So you're saying Android app developers are generally Doing It Wrong™ and iOS app developers are generally Doing It Right™?
Great post. I've said previously: If you want an ios experience get an ios device, stop trying to force an ios centric notion of how a mobile experience is suppose to be on android. They are two different os's that have had very different design goals from the very beginning.
btw.. I did not read all the comments. There is so much back and forth discussion.

Simple question that is still not answered is
"What do I need to do as a developer and user, to make my apps fluid?"
Please suggest something and please dont tell me that "its not that simple" kind of responses.

What is that iOS developers are doing that Android developers should follow?
Suggest some design patterns, suggest that disable support for installation of 3rd party app.
Kun Li
+Zaki Manzanza Can you tell me which operation generates the stuttering like what you said? I have a iPhone 4(1.5 years) and a GN(1 week), and I didn't notice any more stuttering from GN than iPhone 4. Sometimes when you scroll quickly, both of the phones will have lag, but that's it.
From reading the post and comments, it seems there are some technical issues with android: Android's biggest strength it it's Achilles' Heel. Composition of applications in a secure way.

However there is one thing in control. If an app is not responsive, Apple rejects it. End of story. So yes, you work your ass off to ensure your app works smoothly.

No such thing in android.

Still does not explain why losing service = the phone goes on the fritz barely usable. All resources go to reconnecting the network connection, no consideration to anything else.
Kun Li
+Shiva Mantri Check out +Adam Powell's reply. You will find your answer there.

+Andy Turfer I did that test right after reading your post: open an SMS thread with 30 or so messages in it from a contact who has a photo, and scroll. My thread even has Youtube video thumbnail embedded. Nothing wrong on my side. No lag, no stuttering.

Here is the thing. I'm a developer for iOS and Android platform, and have used iPhone 4 for 1.5 years. I bought a GN in last week and have been using it since then. I barely notice any stuttering on GN more than iPhone 4. Is there any stuttering or lag? Yes there is some. But so does iPhone 4. It's not like iPhone 4 runs smoothly as hell and you never ever see any lag or stuttering, no it's not the case. If out of curiosity you play with your friends/wife's iPhone and see no lag, of course, you need to use it in daily life instead of just 5 minutes.

There is one thing ICS does worse than iOS, it's the ratio of page scrolling speed and your finger swiping speed. On iOS, it feels more natural to scroll since it looks like the scrolling speed is exactly linear proportional to your swiping speed. I guess that's the reason why even though there are some lags on iOS, people barely notice it, since the operation speed beforehand and afterwards feels more natural.

What +Jay Freeman said above is simply nonsense. Android team apparently know what they are talking about and already did a good job addressing it. I used a lot of Android devices, including Droid, Galaxy and Galaxy 2, for development. What I can say is GN is a dramatic improvement over them. And it's primarily due to the new Android system, ICS. GN works so smooth than I couldn't believe it's a Android phone in the beginning. I use the browser, Gtalk, G+, Twitter and camera a lot, and the experience is awesome.
+Daniel Wilson "..stop trying to force an ios centric notion of how a mobile experience is suppose to be on android". Really? Are you trying to suggest that Android should be laggy and jerky because it's not iOS?
+Kun Li I experience stuttering when opening up the stock sms application. When opening a thread with a lot of messages it would stop midway through then goes on. Won't happen the second time you'd open it though. I also have micr stutters when opening up an app when there are some processes running in the background (lookout security scan for instance) or if I swipe through different home screens. Just happens randomly.
I'm quite reassured by the experience you describe with ICS and will eagerly be waiting for the upgrade on my Galaxy S II
Kun Li
+Zaki Manzanza Regarding the first issue, I was doing my test on Gtalk so don't really know if it's the same case for stock sms. Maybe.

Regarding the second one, I also noticed the same thing when I was using Galaxy S II. What I can tell you is in ICS, you generally don't need to completely quit the app, just leave them in the background. And whenever you want to pick them up, just use the new "activity" button to show the background list and tap on the one you want to switch, that's it. I use it more than 20 times per day at least and didn't run into even single stutter.

In terms of home screen switch and app switch, I'm pretty sure you will be very satisfied on ICS.
+Daniel Wilson This isn't even a discussion about walled gardens or app approvals- it's about lag and inconsistent UI experiences for end-users. Ergo, talking about 'iOS-centric notions' is completely pointless and off-topic because you're talking about the open nature of the platform versus " what apple says i can't do". Neither of these things detract from the fact that the Android experience is inconsistent.
+Kun Li Looking forward to that. I'd say the guys from xda have done quite a great job in terms of responsiveness as far as scrolling is concerned. And thanks to +Dianne Hackborn I've learned a lot and feel more confident about Android
This doesn't really address why there is lag on the home screen.
Stan G
It looks like right from the beginning iOS sacrificed struggling multiple windows in favor of one working well.

That was probably a very wise decision back in 2007, and it was still good this year, but moving forward - Android is getting all the benefits of better hardware and is close to having multiple windows working perfectly and adding more and more features to the OS itself while iPhone screens still look like five years ago, notification bar doesn't notify you of anything (it probably has its own window on iOS, too, just not as useful), and some other bits and pieces that feel too old fashioned comparing to Android, like the pitiful list of "Share" options in iOS apps - it can't have its own window and draw the list of all available options from the OS.

What I mean to say is that iOS solution was perfect for the hardware of five years ago but it also put constraints on what the system can do when hardware improves. Open apps and camera faster? That's all? What will iOS look like five years from now? Will Apple have to rebuild the entire thing from scratch? Android will probably have the same problem though not to the same degree.
+Daniel Wilson You just don't get it, do you? I don't give a toss about iOS- it's a toy OS. You cannot, however, disregard the fact that the UX is damn smooth. Why is it so difficult for you to imagine Android as it is now but with no lag? That doesn't make it an iShiny any more than painting a Windows logo on it makes it a WP7 device. It doesn't mean that to have an Android means embracing UI lag because it, in some stupid way, symbolises freedom and choice.
Why should we accept second-best when it comes to UX? No-one's suggesting inheriting parts of iOS for Android; they're merely pointing out that we should damn well be able to have our cake and eat it too. Yes, people are complaining that Android isn't like iOS... in the context of UI lag. That's all. Do you understand now?
+Jay Freeman I would honestly love if you could correct any misinformation about iOS. As I said in the post, I would never claim to be an expert on iOS, and only base my ideas of how it works on information I see people provide that I judge as worthy of trust. There isn't really any way for me to directly get information about it -- I can't look at the source code, and to be honest I have kept myself away from looking at even the SDK to avoid any legal issues (especially since they had that agreement you have to sign to look at it, though I don't know if that is still the case).
In any large software system the people responsible for working on it will always have a few ideas cooking in the back of their minds on how to improve it. These posts are here to describe how things work today.

Just because this post doesn't contain a 3 point plan and a launch date for unwavering 60fps in every app ever written does not mean we've shrugged and decided things are good enough. We're software engineers who care passionately about our work. We're our own worst critics. To us, it's never good enough. ;)
+Daniel Wilson Look Daniel, I appreciate what you're trying to say but you're still missing the point entirely. You talk of making trade-offs with apps and widgets and so forth to reduce lag. I've said it already and I'm saying it again- why should people be forced to make tradeoffs?
Prime example; go grab ES File Explorer. On stock Sensation it's an extreme lag-fest. I can't comment on other phones as I don't have any others lying around. Some custom kernels (Bricked) seem to fix the scrolling lag, some (faux) don't. The point is not how much stuff you have running in the background, nor that it's not a Google app, but that the UX is terrible on some devices with that app.
Smoothness is not "having an iOS experience"; it's a goal if the UX on Android is to be improved. You appear to be so hung-up on the "iOS experience" when you're missing the point that people don't want this "experience"- they want Android the way it is, but without lag. Smoothness should not be "go away and get an iPhone"- it's an example, nothing more.
+Dianne Hackborn <- check out the responses from Xuzz and ryanpetrich.

In particular, iOS in fact has a multi-window architecture: applications can be made up of multiple UIWindows, and you can have UIWindows from different processes on screen at the same time. When you click on applications in SpringBoard, the transitions you see are animations of windows, and it would not at all be difficult to implement (from a rendering perspective) a scheme where different processes registered something similar to Android's activities, where clicking links slid one process's content off-screen while sliding another process's content on, even while sharing a navigation bar.

The status bar actually used to be an example of this, but they changed it at some point (and honestly I do not remember why, but I do not believe it to have been due to a rendering issue); the notification center, however, is a good current example: the window for the notification center is in SpringBoard, but it is rendering over and at the same time as the window for the application you are covering. There is also no issue having these windows alpha composite onto each other: the little popups that happen from clicking the volume buttons are windows in SpringBoard.

The reason for this is that, like with most multi-window environments (including Android), there is a window manager that is handling all of the actual compositing. In this case, it is SpringBoard, the process that manages the home screen, task switcher, notification center, lock screen, and honestly almost anything that has to be "always happening". The way this works is that surfaces (backed by system or video memory) are managed by a driver that allows them to be passed between processes: applications can render directly to their surfaces, while the actual surface hierarchy is maintained by SpringBoard.

Honestly, though: around here is where my knowledge is really fuzzy, and can't be trusted; Ryan Petrich's knowledge can be, so I will quote his comment from Hacker News: """On iOS, all standard rendering is done in a single context by the Core Animation window server which lives in SpringBoard. Only when an app adds an OpenGL ES layer to the view hierarchy does a separate context need to be created. When that happens, the render graph is split into subgraphs that are rendered to surfaces and displayed as overlays (with SpringBoard rendering all the standard layers and the app rendering the OpenGL layer)""".

The result of all this is that your comments regarding iOS's inability to handle multiple applications sharing screen real-estate in an efficient and secure manner are simply false: the fact that Apple does not support the Android notion of seamlessly moving between applications, with a back-button instead of simply an up/home-button, is simply an irritating business decision they make. As mentioned by Xuzz on Hacker News, it would be a simple manner to, for example, modify UIKeyboard to be handled by a separate process from the app that was calling for it: the involved work would not be rendering complexity.

Finally, the reason why you need to be careful with your view hierarchy to get 60fps scrolling is due to the complexity of loading new table cells and rendering them for the first time: once they are rendered they scroll quickly as the entire layer is cached (afaik, and if I'm wrong on this it doesn't actually matter). The problem on Android is that, even in the best possible cases, where you are staring at a trivial table implemented by the Android team itself (such as the Settings/Preferences app), there is noticeable UI latency and slop while moving your finger over the screen. When you read threads like the response to your first article on Hacker News, you can see this is a serious challenge for Android. <- the top-voted comments just lambast this lag issue

Now, I have no clue why that happens, and will certainly not pretend to know enough about Android to even guess (at least in public ;P in private I have tons of theories, and have even discussed the matter with some old-school Apple/NeXT people that chimed in with their own reasons that I sometimes attempt to parrot), but I'd love someone from the Android team to explain what was up. These posts, which I really do appreciate from the "enlightenment regarding Android" perspective, are not instilling any confidence that the Android team understands what is causing this issue, and is in a position to someday fix it. :(

( <- and, I guess while I'm at it, can we get a "true facts" response to this? ;P)

(Oh, and here are a couple possibly interesting references that do not require accepting any agreements. I am not 100% certain this will be useful, however, especially without any context.)
+Jay Freeman Thank-you very much for the great information, it is a lot of stuff I didn't know about their architecture. Unfortunately for us, until recently we just didn't have GPUs that could do multiple contexts, so if our system worked like that we wouldn't have been able to ship. :}

What you say about scrolling lists in iOS is still exactly how Android works -- each item is cached in a layer so scrolling is fast, but introducing a new item can be slow because it needs to be re-computed and re-rendered. For example, a Nexus S can definitely does 60fps on well written lists. It is very hard to address broad statements of "there is always slop and lag," because often this is not broadly true, and the behavior of individual devices can vary greatly. For example, I have seen some touch screens that introduce many frames of lag with the data they report to the kernel. (We have even spent quite a bit of time on some older touch screens we shipped with tuning their parameters to get data out faster at the expense of it being more noisy, and cleaning that up in the platform.)
+Dianne Hackborn While I feel the large number of commenters on a variety of devices would, to me, indicate this is a wide-spread issue and not relegated to "some older touch screens", I will personally state that I have a Nexus S that I find incredibly bothersome with regards to touch interaction, even in simple situations such as the Settings/Preferences application.

It honestly seems to not be having a difficult time rendering the tables (hence why I would not personally attack you on that), but the touch events have a tremendous amount of lag/slop: not only does it react slowly to initial movements, if you sit there and move your finger up and down you get this almost sea-sick feeling where the screen is still going up as your finger is already moving downwards.

Now, this (my device) is still 2.3: maybe you guys made major improvements in ICS. However, the comments from other people (even on brand new hardware: the Galaxy Nexus [1]) seem to indicate that this is not the case; and, if it were, I'd kind of think your article should be trumpeting "old news: we fixed that" rather than "people are misinformed about what causes that known issue" ;P.


Really, it's the kind of thing that could "be anything": touch screen hardware latency, event dispatch context switch costs, rendering and compositing lag, slow bytecode execution performance, poorly thought out momentum calculations, or even explicit code "if (movement.distance < 5) return DelayTouch;" (such as to determine "is this really a movement or just a sloppy click").

So yeah: I understand it is a really complex problem. However, this article seems to try to pin the problem on a false comparison between iOS and Android's rendering pipelines, arguing that Android's entire architecture made a better tradeoff that people should respect, when in fact "we really still don't know". Even if you didn't intend it this way, that is how everyone is interpreting it.

I mean, check out these headlines. Some of these articles are responding to your first article, some to Munn's response, and some to this latest post made by you; the key thread, however, is clear: people are looking for answers, and even if you are just trying to respond with some facts, people are taking what you are both saying and "running with it", reading the discussion as "iOS vs. Android".

To pull a comment from someone summarizing this specific post: """What I took away from her article is that Android decided security was more important early in its development life because they were creating an open operating system that wouldn't have the luxury of a curated app store, but ultimately it was this decision which compromised the UI's ability to exploit graphics hardware because you end up with multiple processes needing to write to the same display (instead of one) and the hardware and drivers which would allow sharing of a hardware accelerated surface across multiple processes haven't started coming out until just now."""

To put into some concrete context how dangerous this all is, the situation at this point could easily be spinned as follows: "The key problem actually /is/ an architecture decision, specifically that Android runs on devices from third party manufacturers, leading to poorly chosen graphics hardware and uncalibrated touch screens in the majority of shipped devices." <- Obvious article-bait. ;P

Obviously, without a bunch of evidence showing that that actually was the underlying problem, getting a bunch of people to run with the new headline "Android's open-ness inherently causes UI lag" would be really bad for everyone, and not something any of us would want to see. However, that's pretty much what this post did, asserting that there was some kind of security issue on iOS due to its graphics performance. :(
+Jay Freeman , since you know a lot about iOS I thought I'd take the opportunity to ask - does the iPhone get touch events at a rate that's equal to or an integer multiple of the 60hz frame rate, or does the OS perform some sort of filtering of the touch events? One source of percieved jitteryness in Android, even when achieving 60fps, is that there seems to be no relation between the touch event frequency and the screen update, so you'll get two touch updates, repaint, one touch update, repaint, two touch updates, repaint, etc, which leads to a subtle but totally visible jitter when scrolling unless you manually lowpass filter the events, which at least in my attempts causes an extra frame of lag.
Kun Li
+Jay Freeman As much as I enjoy the new knowledge you bring in this post, I have to say your out-of-data reference is really misleading here. A article on October 19 about the observation from others that the trial version of Android 4.0 is laggy sometimes? Hey, really, you can do better than that.

What I can tell you is, the touch event on GN doesn't have tremendous lag/stop at all. It doesn't react slowly to initial movements at all. It's MUCH better than Nexus S. Seriously, there are tons of review videos out there at The Verge, TechCrunch, whatever tech site you know. Just read their feeling about the smoothness, and watch the videos to feel by yourself.

And you even don't believe these reviews and comments, just get a damn GN and compare with your iOS device side by side. It's probably still a little bit better on iPhone 4s but the gap is much smaller.
In android ICS and gingerbread, when you open the new google music beta (latest version around 4.1) and going to "songs" and scroll the list there... my whole GALAXY NEXUS's magic just disappeared. How can a simple list like this be laggy?

When you go to landscape mode and go to "recent" tab or "albums" tab, the scrolling is 60 fps at all times/ smoother than iOS. How is this possible?
+Kun Li My arguments that these documents are causing misinformation to be spread about this issue is only further demonstrated if this problem is already fixed, because that is not the message they are sending to the community. If the Android team has fixed these issues already, then Dianne should list that in a new "true facts" document: "been there, done that: we already fixed it"; she didn't, though... instead, these posts are about how everyone's reasons why this problem happens are incorrect (and I am not arguing those people are correct with their reasons: they don't seem to be). Seriously: if you believe that this problem is fixed (and I'm totally willing to believe that it is: I don't even use Android: I only chimed in here as "someone who works on iOS at a low-level to correct misinformation"), then Dianne's documents are just perpetuating the myth that it isn't in addition to now spreading misinformation about why it happens (which in turn is causing people to believe a number of false things about iOS, that I then have to deal with, leading me to come here to try to undo that damage). I mean, come on: read any of the long list of articles that I linked to from the last few days regarding this argument she is having, or even just check the headlines.
+luu hoo Look, I came here to respond to an article that is causing a very specific perception in the community: that Android is slow because of a design tradeoff it took regarding security, and iOS is thereby fast but insecure. That is what this article is claiming and defending, and it lists specific technical points regarding how iOS operates to defend that position. These technical points are incorrect; sufficiently incorrect that one would hope that a retraction is posted regarding them, as no one is going to read this far down into this comment thread to realize that the conclusions people are drawing from these posts is incorrect. Again: I could really care less whether Android is slow or not. The fact that this article exists at all, defending the reasons why Android is slow and claiming it is due to a security tradeoff not made by iOS, would seem to be proof that it is slow; but if it isn't actually slow, then that is just yet another point of misinformation being propagated by this article. :(
+Henrik Rydgård I asked some iOS jailbreak developers to comment on the issue you described regarding touch event rendering synchronization (as I do not work with that); the response I got are as follows, although I do not know if they will be useful for you:

1) "doesn't seem any reason for touches to be designed to be synchronized with screen refresh rate at the hardware level. lots of uses for touches that don't have to do with updating the screen. I don't see how a simple running average filter can cause lag."
2) "I think began/ended events are passed straight through. moved events might be coalesced, not sure" "UIPanGestureRecognizer (and the private subclass used for UIScrollView) uses the timestamp and velocity to estimate where the current position of the touch is"
+Jay Freeman " one is going to read this far down into this comment thread..." - WRONG! This issue is more important than many give it credit for. People are desperate for answers, and will read every word in every post in the hope of finding them. Misinformation no longer works, and containment of the issue is now impossible. I wouldn't be surprised if folks high up in the Google food chain haven't read these comments verbatim.

This issue was reported back in March 2010:
" one is going to read this far down into this comment thread..." +Andy Turfer is right, as a Java developer who's considering to be a full time Android developer I wan't to see more information about this.
Stan G
So it's been shown that iOS does have multiple windows with their own threads. Okay, but are they as complex as Android windows? I mean how much resources is needed to draw volume adjustment popup or notification popups, or even iOS5 notification window, or the basically static status bar? Are these windows there just in name and iOS keeps their simplicity under strict control so as not to compromise screen responsiveness? That would make it a political decision where you sacrifice openness for the fine tuned performance of a tightly controlled system.

Another question is also left unanswered - did iOS have the luxury of GPU managing several windows from the start? Android didn't have that luxury, certainly not on each and every device, and I get the impression that the mass adoption of "multithread" GPUs is still the thing of the future.

I also noticed that people complain about lag on Android when scrolling through settings menus. I suspect they are not being entirely honest. I don't get any lags on my CM7 rom except in one particular place - Applications. It takes my ageing phone at least half a minute to get that list ready for smooth scrolling, beginning with five second "Loading" wheel. The reason for that, I think, is that it's not just the indexed list of available apps, the OS is actually pulling all the app data from the scratch and also makes it instantly available for "sister" lists of "downloaded" and "running" apps and probably each individual app data and storage usage as well.

Apart from that I don't remember even my stock rom having any lags and freezes as far as UI is concerned. It has never been as fluid as my gf's iPhone but I've grown to its inertia, it implies interaction and weight, and I can speed it up with several swipes, pretty much like a carousel or a swing. Just a different experience, which I miss when I pickup an iPhone and scroll down long lists.

Registering clicks and opening apps and screens is a different matter and my gf's iPhone 4 doesn't have any particular advantage there. I guess cleaning up apps cache would speed things up, it does on my Android but on iPhone, afaik, that's not an option.
I have to say, I think one of the biggest areas for concern is the listview. I've had some real problems with this in the past, and it's very easy for developers to get wrong. Calls are made to the list adaptor, which returns views. The app must build the views on the thread it was called, because it has to return the view from the call. Because of the way that views in a ListView are reused, there is no scope for offloading this to another thread, because the view object is only valid for the scope of the call.

It seems to be quite common to load image resources, etc, in this view, which creates horrendous stuttering because of the main (UI) thread being held up loading resource.

There's really very little the developer can do about this. (s)he can use a temporary image, then update when the correct image has loaded, but this results in a series of 'invalidate' calls later, which again causes disruption to scrolling of the ListView. The other option is to pre-load and cache all of the resources, but this needs to be done before the List is populated. It will result in no list visible until everything has been loaded.

In any case, this is a pain point for developers, and one where a good many developers are going to get it 'wrong' - I know that I've started out with many substandard ListAdaptor implementations in the past.

Maybe +Dianne Hackborn or someone else at Google could take a look at the latest version of the Twitter app, and see the painful ListAdaptor implementation they have in there. This looks horrible on my Galaxy Nexus - they appear to have used the temporary image mode.
I'm a very noob developer and my points on this subject are based off my own experience and mostly bass understanding of complex OS matters and behaviors... But there's point in this article that I've always wondered about: the drawing caches.
I realize that doing a simple bitmap blit is really faster than anything else, but the drawing cache system only worths the tradeoff on small views and/or small amount of views.
And its not easy to manage due to the unknown status of the drawing caches creation, where an app cannot start a fluid animation until the drawing caches have been created, but there its no easy way of knowing it like "create the drawing cache and then start the animation/scroll".

Even in ICS source code I continue seeing manual bitmap caching of simple elements like text labels to maintain ui smoothness without relying on the drawing cache system (and why is text so slow to draw in android?).

So for an app to make a smooth full window flip transition (like the ones I hate from ios but clients love and force me to make) we must deal with the amount of time required to build the drawing caches, the amount of objects created and destroyed and garbage collected that we cannot manage, and the huge memory impact those caches have in our heap space.
Or just manually manage the cache bitmaps and solve 2 of the previous issues but yet have to be with an eye on the caching time and manually draw those caches.
Or while scrolling a listview, even with its own managed scrolling cache, recycled views, etc, each rendered item must be cached to a bitmap and garbage collected later. Or do the listview recycle the drawing caches too?

How do people here face these kind of situations?
+Ander Webbs "I'm a very noob developer" - I know who you are Ander; you're not fooling anyone. ;-)
+Martin Long if I weren't a noob I wouldn't do this kind of questions. I really have a lot to learn and that's why I like to read and participate this kind of posts ;)
Speaking as a general Google enthusiast and an android user for the last 3 years, I have to say that while its awesome that someone from Google would take the time to write articles like this about the technical nitty gritty of android, it would be even more awesome if android just WORKED. If there is one thing apple got right with the iphone, its delivering a product that puts usability and responsiveness first. Every android phone I've owned (nexus one, samsung captivate samsung infuse 4g) has been a huge jump in terms of features, but the lagginess and bugginess has really never gone away. When I read the first article from Dianne Hackborn I was actually alot more worried about whether android is moving in the right direction, since the article seemed to suggest that all the things people have been saying would improve android either can't or won't work. Every day I have issues with my phones launcher crashing, apps like netflix overwhelming the RAM and causing restarts, the keyboard text-field input failing, the google search app crashing, and of course the general random lagginess that seems to occur right when I need the phone to move quickly (like quickly taking a picture and uploading it at 2am-when android apparently likes to run a billion background processes at full bore) .
Alot of the reviews of the galaxy nexus say the phone is smooth, but they always seem to be taking it so easy on the phone during the video reviews and yet I still see hints of the same problems. A great example is +Andy Turfer s second video above, or threads like this:

So many people are using android these days, and I think alot of people see this whole situation the way I do. If ICS isn't the smooth OS then when will we see it? This is windows OS all over again, except that Google has Apple, Microsoft, and soon RIM clambering for the same market. There is no way that I'm not sticking with android for the next year, but if ICS ain't it then I'm moving along.
I bought a HTC HD7 the day it was released, but sold it within three days for 2 reasons:

1. I could not connect to my company's Exchange server because my username contained a space, and
2. Scrolling in third-party apps was laggy/choppy.

It appears that Microsoft has addressed the latter:

WP7 Mango scrolling smoothness compared to NoDo

Keep in mind the above is running on old (in mobile terms, "ancient") hardware.

User-experience really is king. Microsoft realized this and acted on it instead of adopting a 'near enough is good enough, just wait for better hardware' approach.

Intel also realized this after conducting a study which (in essence) reversed engineered the iPad user-experience (see The study basically concludes that there are two main ingredients that make for good user-experience:

1. Responsiveness (15ms vs. 200ms upwards).
2. Smoothness (consistent 60 fps).

My point is that while the majority of users may not be so vocal about the laggy/choppy performance of a UI (it's a nuance that non-technical end-users are unable to describe), they do 'experience' it and subconsciously make judgments based on this. How well are Android tablet sales really doing (and note I say 'sales' and not 'shipments' - stockpiles of tablets in warehouses do not count!)?

While former intern, Andrew Munn, may not have been off the mark in his assessment/theories about this issue, at least his post brought media/blogsphere attention to it and opened up some very insightful and interesting discussions (debates) about it. The amount of attention his post received just proves how important this issue is.

Just nail it: an Android experience that is not laggy/glitchy/choppy in any way (including what some have termed: 'micro-lag' - the lag that occurs when a GC cycle kicks in). I understand there are certain (difficult) constraints the Android team must work within, but surely achieving consistent smoothness and responsiveness throughout should be a primary goal!?
How much of one's life is wasted on the lag in Android versus iOS?
Out of purpose of this post. I just envie to express my thougt. Each update of google map add more functionality but slower and slower, I must to revert to stock all the time. I feel like the actual direction of android is going the same way. New features, more and more features.. but see... I laughed at the google map app of my girlfriend's IPhone, but each time I needed it on the way, my android phone & google map takes like 20s to wakes up and run with a bunch of features =) while my girlfriend's IPhone displayed already itineraire! same for Internet Browsing. So, I doubt about the usability of android that you all talk about...
+Minjang Kim Android is very much a compositing window manager according to the definition of that Wikipedia article. This is exactly what I am describing here -- each window has its own surface, which the app draws in to, and the compositor is responsible for rendering to the screen, at which point animations involving translations, scales, alpha, rotations, etc are performed in hardware.
You're still skirting the thread priority issue when it comes to animating system widgets.

If the kernel didn't offer a working scheduler (as Linux historically has problems with), Google could've created its own that was more BSD-like, and very well known to be more fair and responsive for foreground threads, or even real-time threads.

When any standard list-view scrolls, it is now animating. This animation should not belong to any application, but submitted to system "animation engine" (maybe through IPC) which should be running at high-priority levels to make sure the animation never skips. The fact it skips, as well as the initial lag in detecting touches ( which should be a system real-time thread also ), is indicative of the on-going negligence and sloppiness. There should be a special mode for scrolling where the finger movement is interpolated so there isn't more lag waiting for the latest "real" event to get through the laggy system. Afterall, scrolling already has a predictable velocity and inertial.

You shouldn't need multi-GL contexts unless you're doing this threaded, but since RBO and FBOs exist, you should be treating the renderer more like single-threaded blitter server. The only reason to use multi-GL contexts is to load textures (producer) and prep them for the "blit renderer" server (consumer) to churn through its scene-graph independent of rendering. If you're getting slow-down because you're doing all that GLES context switching for each app, you're doing it wrong. This is where the idea of using a mature game engine comes in. They've solved this issue.

Being that Windows Mobile had fairly mature OpenGLES drivers near the end days of v6.5, it's inexcusable to now claim Android's GLES drivers were immature until now, -- 2 years later. Consider, Apple made sure their drivers were fully-usable for the UX level needed even on the OG iPhone -- it obviously was not a priority for Android.

If you can't get lag-free, fully-responsive animation with system widgets on a 600MHz single-core system, you're doing it wrong. I really wish Google would just fix it, for good, now, instead of worrying about "correcting" people, apologizing for, or explaining it. Actions speak louder than words.
+Joseph Lee To be honest, it is hard for me to take this kind of comment seriously, when you are talking about game engines solving the needs for OS platforms and speculating about maybe using IPC. Really? Maybe it is possible that you are a little too convinced in your own understanding of the problems.

For example, drawing a list involves way more than rendering to the screen. You have a touch screen processing low-level input in firmware to generate the higher-level touch data (and less than good touch screens can introduce all kinds of issues here, ones I have seen on shipping devices), you have the kernel pulling this data out of the screen and publishing it in a driver, the framework dispatching these events to the appropriate window, the window interpreting them and updating its state, and finally the UI being updated on screen. Issues can happen at any point in this process, and I have certainly seen a number. And it is ridiculous to say that this interaction can't belong to the application -- each frame of the list view tracking the finger needs to belong to it, since there is actually a lot of complicated logic going on that the application needs to be involved with, from the list view itself deciding how to interpret the events, through populating the list as new items appear, to the application being able to watch them and decide other things like we are now going to do a horizontal swap between pages.

Also you act like a list view widget should be designed as some super-special built-in part of the OS, like it is running way off in some other process that the app has no part in. So, what, an app developer just can't write their own widget that scrolls well because they can't run their code there? That seems like a very bad idea, and there is no need to go there.

Finally, good gracious, stop with the "apologizing" schtick already! As I have said repeatedly, none of this is any kind of apologizing or excuse. As I have said before, a lot of work has gone into Android to improve responsiveness over the last years, and a lot of work continues to go into it. If you hold stock ICS next to 1.0 on the same hardware, ICS is going to be a ton better, due to changes all over the place, not just in the graphics system, and work will always continue on there... because there is never a "it works perfectly now, we are all done" point -- iOS isn't perfect in this regard either, there are always improvements to be made. There is no one magical thing that if done today is going to make all issues go away.
+Yomi Adeyemi I've just ran the same experiment as the one posted by +Andy Turfer on his video first with my Samsung Galaxy S II then with my wife's iPhone 4 S. Surprisingly, on my Galaxy S II, scrolling, zooming in and out was butter smooth. Well to be honest I wasn't that surprised because browsing has always been smooth on my device. What was more surprising was the result when I switched to the iPhone. It was even worse than the nexus S. What's more, the browser just crashed at some point. So it's not that perfect on Apple side.
I do agree though that the lag opening apps or in some third party apps is just annoying and frustrating.
+Steve Gehrman The open source model does have developers from all over the world submitting patches. Haven't you ever heard of Cyanogenmod? And as for updates from Google, you're very soon going to get ICS - before any other phones except the Galaxy Nexus.
Finally your comment "No one has thought to fixed the lag issue so far?" is just ridiculous. Have you read this post or any of the comments?
+Steve Gehrman Flickering list items would have nothing to do with screen rendering, that would only be an artifact of the display. Android's screen is double buffered (actually twice since each window surface is also double buffered) so you never see incomplete frames of drawing.
+Zaki Manzanza open up settings. slide your finger up and down at moderate speed. Look at the screen, see how the image does not transition smoothly from point to point but rather seems to chop off a frame or two in an attempt to keep up with your movement? See how the list does not immediately follow your finger up/down but rather has a split second delay before following (+Jay Freeman describes it as 'sea-sick' inducing movement, I agree). This my friend is the reality of android. as +Steve Gehrman points out it is literally LAG EVERYWHERE.
And this is just the tip of the poorly executed iceberg; as I described in my post above, my issues with android are by no means limited to this lag issue or 'lag opening some third party apps' but to literally all of android with its constant crashing and freezing. +Dianne Hackborn you use an android phone right? Just as a user don't you feel that issues of responsiveness and stability should have been on the 'solved' list at Google from version 1.0, not to mention 3.0 three years later? How do engineers present great new features at your board meetings and ignore the fact that things like the Google search app can regularly crash on the vast majority of devices you have put in people's hands? I don't mean to come across as snide, but really android is mainstream enough now that there really is just no excuse, ordinary people expect a professional quality product when they spend $200-800 on an android phone when Apple and Microsoft have already demonstrated the possibility of a system relatively free of these issues. I know Google likes to release 'Beta' software, but at this rate most consumers will simply see android as a 'Beta' experience, not to be compared with the finished products being offered elsewhere.
+Yomi Adeyemi Don't need to go to settings bro. Scrolling down the google+ app to read this interesting topic is laggy enough I'm afraid. I just meant that I couldn't reproduce what was posted and you may have issues over to apple as well. Their browser is not the best (only my opinion). It is just sad that there is that lag almost everywhere. How a company like google and all their resources can't fix that? The market experience for instance is choppy. You are right. We should be expecting more. Just hope that Android doesn't turn into another microsoft with problems that are never solved while Mac OS is just slick and almost flawless.
+Dianne Hackborn I do appreciate your expertise and your desire to clarify matters. But just one question : do you have a solution to the lag? Could we expect a butter smooth Android experience?
As it stands, however sad this is, from a user perspective, ios is better. Almost everything works out of the box
In android ICS and gingerbread, when you open the new google music beta (latest version around 4.1) and going to "songs" and scroll the list there... my whole GALAXY NEXUS's magic just disappeared. How can a simple list like this be laggy?

When you go to landscape mode and go to "recent" tab or "albums" tab, the scrolling is 60 fps at all times/ smoother than iOS. How is this possible?
+Dianne Hackborn Let me elucidate what I see as apologist: the explaining of "it's complicated" in the stack with unpredictable interruptions from the touch-driver to the app. Why? You control the OS from the driver up to the event stack (and the app itself on the showcase Nexus platfom) for goodness sake. The foreground app and window should get more priority than all other co-running apps, period. Even Windows XP had this tuning. #Android is not an app at the mercy of an indifferent OS/driver/OEM. You entirely own the metrics of how fast a touch-driver needs to respond by (2ms or whatnot), what is allowed to interrupt it, how long any interruption can be, etc etc. You control it. You can profile it. If the response is "stuff happens" - that's apologist to me.

I did specifically point out system widgets or toolkits. If an app writer goes off with custom widgets it's not Google's problem if it lags. Large-scale game-engines are rigorous, cutting-edge, software technical excellence of little compromise, interrupt, or event, driven optimized input/display frameworks. 100% of the performance is analyzed, tuned, and owned. That is what Core Animation, or Clutter, is a part of.

Mediocre example: Opera Mobile on a MSM7x30 device @ 800x600, scrolling/panning v stock Android apps for web pages. Whether it be the high FPS, background scrolling thread, fractional/subpixel -- smooth-scrolling and animation is possible on Android. That NoDo v Mango and Galaxy Nexus videos by +Andy Turfer are good examples of what hasn't happened to Android from my POV yet.

It's ~2012. Why are we still circling how crappy listviews in Android continue to be -- such as Twitter's latest app update? It's ridiculous. App writers shouldn't be wasting time fixing issues like this. If Android isn't as sophisticated as a game-engine, why does it still suck at the simple things?

You can talk up and down that ICS maybe finally achieves fixes all this, but ICS (at this point in time) statistically does not exist. On any other platform, a new release means everybody gets a chance to get it with at least 3 years recent hardware (or more). For Android and ICS, it means tossing in another pound of flesh into the pot to buy into the new hardware hand. Realistically, it's fragmented and trickle down even "with Google" devices. The lack of a consistent Android platform (except AOSP CyanogenMod) is really frustrating and discouraging.

It doesn't help your case to mock me on IPC. Driver ioctls are IPC, OpenGL ES calls are IPC. X-Server calls are IPC. Qualcomm uses ONC RPC in its GL drivers to shuttle command packets around. All are quite performant.

The only Apple product I own is a U2 iPod, but the current state of things could push me elsewhere. I'm disappointed that you don't see it as a mandate and contract for Android to at least measure up to Opera's game engine, or even Angry Bird's snappy UI.
Another example of crappy listviews is the Facebook app. When it did use the Android "native" listview widgets, it was a horrible laggy mess with off-screen portraits reloading much too often even if scrolled off-screen (seconds ago) and back on. FriendCaster was better in this regard because they attempted to do work custom work on the listview.

Now, it may have been Facebook's direction to unify its UI with the iOS version and mobile, but they've entirely converted to an htmlview. Not only has this eliminated the laggy listview, there's no more reloading of portraits and list items within the current canvas. The only limitation left is the laggy Browser scroll animation -- easily shown up by switching to Opera Mobile.

FriendCaster has been left in the dust with Facebook's switchover. What is in webkit-based Browser's engine that's so much better than the native Android listview? It's not believable the whole thing is now a cached bitmap. App developers certainly would love not having the headache to handhold and massage things that should just work.

Android Market really could learn something from Facebook especially with My Apps listview, and so can the native Android widgets.
Joseph Lee You are totally right about Opera Mobile, and new Facebook app! Something REALLY stinks with scrolling, specially with listview widget. Now I don't know what exactly they did, but sure isn't listview and it's much better now, even with 2 years old hardware... so fix the damn listview already!!! And do not tell us it's difficult, or that the hardware is not powerful enough... what kind of hardware you need to scroll normally, quad core maybe? c'mon it's a PHONE... and galaxy s2 has more power than most older laptops :)
Listen that's nice but nobody really cares. The OS is still incapable of maintaining a solid 60fps. Phone hardware capable of playing quake3 at 1600x1200 @ 60fps is "not capable" of rendering Android's UI, which means Android is coded poorly. Just fix it.
One thing I've noticed as well is that these issues get worse and worse with time. May it be because of installing 3rd party apps with poor coding that don't manage memory the right way or the Android infrastructure itself. Either way, if things aren't butter smooth with your brand new phone, chances are it's just going to get worse. Unless the amazing people at Google finally figure out how to fix this issue that is now pretty obvious with the comments from this post...
So, after all your corrections, why is android so laggy?
Asking "why android is so laggy" is like: "Why iPhone doesn't have homescreen widgets?".

My SGS2 is much more smoother than my friend's suxPhone in many applications like web browser or 3D games. If I am going to watch my phone's smoothness while transiting between homescreens, I would go buy an iPhone.
Doing the test on my Galaxy Nexus browser. Generally smooth with some stutter that might be because Flash is turned on, and there is an animating ad going on, advertising what else, the Galaxy Nexus.
Taking things apart. The main problem as Dianne stated is the Emulator, it's a disgrace. It's so slow it makes me wanna rip my hair off i start it for the first time and use it. And working enviroment like Eclipse is over the top too clutterish to ever be user friendly. Something has to be done for it!
Without going through the details of what android is doing behind the scene (which the author already narrated very well) in order to render for our naked eyes, it just dawned on me that Android is really very costly in terms of computing costs. At this point in time, i am not about to point the finger at the hardware manufacturers making the SoC that resides in the numerous Android devices. It is really not easy at all trying to make a SoC that has to punch way above its TDP (thermal design power). The thing i am intrigued here is why Google designed Android to be so incredibly complicated given we are using RISC chips (SoC). RISC is reduced instruction set computing and herein lies my intrigue.
Thanks a lot for sharing these insightful information!
I really enjoyed this post, but there's one key factor in UI lag that I didn't see addressed: Garbage collection.

In Android (at least up to Gingerbread), it's impossible to have a ListView where each row has an image that has to be dynamically loaded (think a Twitter feed for example, where each tweet comes with the user's photo) run smoothly. No matter how much you optimize your drawing code, decoding images so you can display them generates garbage, which makes the garbage collector kick in and freeze your UI until it's done.

This is where I see the most difference between Android and iOS/WP7, in that any ListView containing images that can't reasonably be preloaded and kept in memory (i.e, most real-world case scenarios) will inevitably stutter, while an identical list can run buttery smooth on both iOS and WP7.

I'm by no means an expert, but I believe that problem could be solved by giving us developers more control on the garbage collector so we can hold it off until the UI-freeze won't be noticed by the user (i.e, when the ListView stops scrolling, or we start running out of memory, whichever happens first). A lot of us wouldn't mind putting in the extra work of managing the GC if it means a more fluid UI, but as it stands now, there's simply no way to make our lists flow as smoothly as on competing platforms (at least until Gingerbread, I haven't thoroughly tested this on HC/ICS, but I imagine the GC still freezes the UI until it's done).

Showing blank/placeholder images until the ListView stops scrolling and then loading images (I think I've read +Romain Guy recommending this before, but I'm not sure so please don't quote me on it) to avoid GC-induced stutter is not an option for me, as I believe it makes for a poor user experience.

Would love to hear from +Dianne Hackborn or any other Android engineer if there's anything that can be done on the developer side to get around this issue.
Hello Dianne, thanks for explanation. When talking about threads, we should take into account the following: How responsive UI/input is, depends on how many quants of time it gets from OS scheduler. But Linux default scheduler is not realtime. Have you applied patch to Linux kernel to achive warrantee response time or are you using default scheduler?
think you share
+Dianne Hackborn I just wanted to thank you for putting this info out there. It all makes sense to me, and I'd rather have and develop for my secure open-source platform than an iPhone :) Having worked in both worlds, I can see the tradeoffs made on both sides... and I like the way you guys did it better.
The new HTC One X, a brand new flagship quad-core Android handset, and yet the legacy Android lag still exists:

HTC One X Hands-on -

How many cores will Android need before it is consistently smooth throughout?
Kun Li
+Andy Turfer The lag is due to Twitter application, instead of Android.
Kun Li
+Andy Turfer It's due to their developers. I don't know and I'm curious about this too. Nearly all other applications I am using with such list view are all much more smooth than Twitter.
I decided to turn on one of my old iphones the 3GS (i had three iphones all together) and noticed it had jerky scrolling. The device was so ground breaking we didn't care nor had anything to compare it too.

Anyway, discussion was quite enlightening. I always assumed most of the jerkiness was due to garbage collection similar to early versions of java. But it sounds like there is more to it than that.

I also noticed that iOS smoothness in scrolling in iPad surpassed by far the smoothness of inertial gesture pad scrolling extension in OS X Lion. This was totally counter intuitive to me. With all the horsepower of quad core i7 and a quite beefy graphics chips in comparison, iPad2 inertial scrolling beats OS lion?

Obviously related to architectural changes they made in iOS even though it is a stripped down version of OS X, to enrich the user experience.

Can't wait to use ICS on the Asus Transformer prime. I found Galaxy Nexus very pleasing and sexy phone and it very well might be next.
I do not touch iOS devices (for reasons mentioned elsewhere) so can not address comparisons with them, but I think it is pretty clear that JB is significantly smoother than ICS.  Is it "as good" as iOS?  I have no idea, but from the reviews of the Nexus 7 I have been seeing, it seems to me that this is becoming a pretty subjective area.

For example take with this comment:

"Thanks to Project Butter, the 7 feels nearly as smooth as the iPad. No major kinks, blips, or bumps to speak of — at least so far."

That is the last I am going to post on this discussion.  I am interested in having discussions about technical issues and other such more fact-based areas.
+Dhruvraj Singh Aren't those benchmarks measuring GPU performance?  So you are saying we are running with half or a third the performance of Apple devices and still being competitive?  That doesn't sound so bad. :)
Everyone - it looks like Google have actually addressed the issue with "Project Butter" !! Judging by the blog videos showing Jelly Bean running on the Galaxy Nexus, it looks like they've nailed it!!!

I'm going to buy a Galaxy Nexus today (before Apple bans them over here in the UK too - damn Apple to hell!!) and will patiently wait for the Jelly Bean update.

I can't believe this day has finally come - I thought Android was going to be stuck with this issue forever. One more thing: in your face all you fanbois who defended Google and didn't acknowledge the issue :)

The Android platform has just become a serious contender (rather than a platform relegated to the sub-$100 handsets).
Jelly bean is smooth! Unbelieveable...
This is a very nice post.. I am wondering how a process is assigned to the background cgroup. Dose all the bg priority threads gets assigned to the background cgroup? or there is another mechanism(by android) in assigning tasks to this group? 
+Kanishka Ariyapala Processes are assigned to the background cgroup based on the type of components they have active in them and the state of those components.  Basically, you get to be foreground if you have an activity displayed, you have a foreground service, and a few other conditions that vary over the different platform versions.  Changing the cgroup of a process means changing the cgroup of all of its threads, since Linux doesn't really have per-process state like this.
+Dianne Hackborn - it's really great that you're responding here. As a user of both android and iOS, using JB and ios6 I can still say that Android is quite choppy/ laggy, even with project butter. I hope this is something the team will continue to prioritize as it seems a real shame, as so much work has clearly been put into making android a great os. Touch responsiveness is such an important part of the user experience. 
"Processes are assigned to the background cgroup based on the type of components they have active in them and the state of those components"  implies android keeps track of the services and activities running in a process and switches the cgroup (SP_FOREGROUND/SP_BACKGROUND/SP_SYSTEM..) when an activity switch states.   Could you point to component where this done ?
Also use "adb shell dumpsys activity" to get a summary of the activity manager state, which includes all app processes with their memory management and cgroup state.
+Dianne Hackborn For Java and Android APP's,i am aware there's ANR.I have couple of questions on Android Watchdog in Native User space.
1. Native C Service Watchdog - It is not clear to me how is it handled in Android.
2. ANR is for main thread. If worker thread hangs, how is it handled in Android?
Great info, it is always a joy to read from you. 
Amazing to look back a couple years and see all there comments, this article, and compare it to how far Android has come today.

The Nexus 5 rivals any other phone out there for speed and responsiveness, and even bests the iPhone 5S in many performance areas.

The only thing that really is left to nail down is touch latency. +Dianne Hackborn; I seriously doubt you'll take the time to answer me, but are is the Android tab aware of the large touch latency generally visible on Android (including Nexus) devices, and is it being worked on if so? Outsidee of that, any information at all would be welcome on the subject. Is latency in touch mainly caused by hardware; software; both? It's my last peeve with Android.

It's even visible on my Nexus 5. 
+Kurian Abraham Thampy that I agree with. Android tablets still have to improve.

My Nexus 10 is the best example. The Nexus 4 and 5 are on a different playing field of UI performance than the 10. Probably because any issues are exemplified further due to the large display.

I disagree on standby life, though. My father's Nexus 7 2013 could easily go a few weeks on standby.
+Kurian Abraham Thampy The Nexus 5 and 2013 Nexus 7 actually have the same screen resolution, so trying to make implications about dealing with more pixels being a "problem" in Android does not pan out here.

Also smoothness issues related to the size of the screen (which I assume you are using to imply related to screen resolution / number of pixels), is almost entirely going to be related to just the performance of the chipset's GPU in relation to the screen resolution, not something about Android.  You can certainly find Android devices that have an under-powered GPU in relation to the screen resolution they are driving, and thus have lower frame rates.  This has been a continual struggle on these devices as the screen resolutions have increased so spectacularly.  Apple has also struggled with it, for example the original retina iPad clearly had a fairly underpowered GPU compared to its screen resolution.  But yes, you will see this problem more on Android, since there are actually lower-end Android devices you can buy. :)

And the launcher on the Nexus 7 or any other modern Nexus device is not a custom OpenGL launcher, it is written purely with the standard Android framework.  I assume you haven't used the 2013 Nexus 7 much at all, either, because there are plenty of other smooth apps on it.

(On the other hand, I played around with the original iPad Mini last week, and it is certainly laggy in some significant apps, like the app store.  There is not something magical about i devices where there is no lag in them.)

As far as battery life, yes it is true that you can install apps that will use your battery, since Android does have more flexibility in what apps can do.  It is not some universal truth, however, that if you install apps your battery life will become terrible, it depends very much on the apps you install.  And those apps may well be using your battery because they are doing things that you want...  and if they aren't, generally they will show up in the battery stats so you can know what app is impacting your battery more than you think it is worth and remove it.
+Colton Walker Touch latency on the Nexus 5 is I believe fairly competitive with iOS devices.  There has been a fair amount of work put into the platform over the last couple years to improve touch latency; at this point the primary issue I believe is usually more related to the touch firmware, which is outside the control of the platform and something the hardware manufacturer needs to take care of.

Unfortunately as far as I know the public touch latency comparisons that have been done have never used Nexus devices, so it is hard to infer from them much about the platform itself, since the touch screen firmware is so important to overall latency and outside of the platform's control.  It is also easy to introduce latency elsewhere, such as adding an additional frame (adding 16ms) to the back-end screen updating, etc.
+Dianne Hackborn thanks very much for the reply.

Glad to here it HAS been worked on. Just for the sake of confirmation, I played around a bit with a friend's iPhone 5 today to compare the touch latency to my Nexus 5. They're very close. Much better than, say, the Galaxy Nexus.

It's actually my favorite thing about this device. It's incredible.

The main problem I see with tablets is that ANY issue with the touch controller, OS or otherwise is greatly magnified by the larger display (and hence, greater finger travel while scrolling, swiping, etc.). Regardless of the resolution.

I haven't seen any tests on latency either that include Nexus devices; although I saw one recently which placed the LG G2 only ~15ms behind the iPhone 5S, which is a feat in itself. I'm hoping the touch controller from the G2 is present in the N5.

One final question: I noticed that applications written using the NDK are EXTREMELY touch responsive compared to the standard development kits. Any particular reason for this? Would ART, when finalized, provide a boost to touch response? I'm using it now on my Nexus 5, and overall I do notice a performance boost although not major.
+Kurt Stammberger <****@**> This is not showing "heavy
apps", this is the Chrome browser. The latency being shown there is not
something the Android platform is imposing on apps, it is being introduced
by the browser app.

And by the way, this is also a counter-example to your previous statement
that you can't use the Android UI toolkit to achieve a non-laggy UI, but
need to directly use OpenGL, since Chrome is actually an app that doesn't
really use the UI toolkit, since it is a cross-platform rendering engine.

So yes, individual applications can be implemented in a way that is laggy.
As I said, this isn't unique to Android -- from my use of the iPad Mini,
this can happen on iOS as well, even in Apple's own apps. But certainly in
these days there is nothing intrinsic about the Android platform that
prevents you from implementing a non-laggy UI using the standard toolkit.
You just aren't going to succeed if that is the argument you want to make.

Now, there could be some interesting discussion about the relative
complexity in implementing smooth UIs on Android vs iOS using their
standard UI toolkits. I could certainly accept that it is harder on
Android, and we have been and will continue to work on making it easier.
Unfortunately, I can't have such a discussion, because I don't know iOS
well enough to do so, and for legal reasons it is best for me to continue
to be fairly willfully ignorant in that regard. :(
+Kurian Abraham Thampy the thing is, I don't think that +Dianne Hackborn is a Chrome developer. Yes, she is an Android 'Framework', engineer, but Chrome and Android are two very different beasts. So I doubt she would be aware of all the details in that regard (although it never hurts to try!)

+Dianne Hackborn, thanks again for all the help. We do appreciate it, its very rare to get to discuss these things with someone on the inside. So again, thank you for your valuable time and ongoing contributions.
Hi Dianne,

the horse is quite dead now, but I've stumbled upon this article by Sony explaining the touch input management and redrawing process in Android :

The article definitely mentions the fact that the graphics framework is responsible for the major part of the latency (~40 ms even for simple things). If true, it is the answer we've been waiting from you, +Romain Guy or +Chet Haase since the beginning how these talks : Android's graphics framework is not efficient and does not allow a short response time.... So, are we doomed to lag behing iOS and WP ?
+Julien Guézennec Please keep in mind latency has nothing to do with jank, which was the main discussion here (that is, updating at a solid 60fps without glitches).

I haven't read the Sony doc, but the current platform does have about 3 frames of latency from receiving an event until you see the result drawn on the screen.  This is actually quite good, and the latency here is partly needed to ensure that while you are continually updating that you keep a solid 60fps update rate (to avoid a janky UI), by scheduling the various work at a regular rate that will never be too much to miss a deadline.

There are probably some improvements that can be done in the platform to shave off a frame of latency, but you aren't going get it much less than that.

And that all said...  you really need to put this in to perspective.  For example, consider this article:

The best case of latency shown there is indeed the iPhone, but its latency is 72ms, over 2x what we are talking about for the Android platform's latency.  So there is a lot more going on here than what is happening in the platform.  I believe a lot of the latency you are seeing on the other devices is actually in the touch controller, processing what it detects on the screen before it actually generates touch events for the system to see.  There isn't much the platform can do to improve that, but that also means it is not a restriction that platform is imposing on the minimum latency and something that can be fixed by the touch screen hardware.
+Dianne Hackborn +Julien GuézennecI thought I would point out that the iPhone (or Apple devices in general) is no longer the king of touch latency. The new HTC One is. By a lot. It has a latency of 46ms, to be exact.

This further proves Diane's point, that the framework is not to blame; rather, the OEM implementation of touch is. The Nexus 5 has a relatively low latency, as well. Not lower than the iPhone or One, but not terrible either.
+Dianne Hackborn 3 things on this :

- indeed, latency is different than jank but it is a real annoyance : game developers struggle to keep it as low as possible...

- 72 ms for the iPhone, yes, but for the full chain. On Android you have 40 Ms from the framework + 40 ms MIN for the other steps. Even in best cases Android is slower...

- I don't think that the touch controller is the culprit : so many OEM have developed so many devices for 5 years, they would have found the solution by now... Nexus 5 is good, but the screen still does not "stick to the finger"like on iOS.

So, any "project no latency" in sight ?

+Colton Walker : I was delighted by the news but I've tried it : the latency is still there for the M8... I don't know what has actually been measured... 
It's not due to native code vs bytecode. It's due to shit code. Shit code and monumentally bad fundamental design choices. You've made, more or less, the same mistake IBM made with OS/2 4. You didn't treat the user interface specific code with appropriate respect.
this has helpped me in getting many details few years back thanks.
Google+ "crashes" when trying to display this topic. It freezes for 7 seconds and then a "google+ has stopped responding, wait/report/close"...
But google+ has not crashed, it is just very slow and android thinks it crashed, ignoring the fact that at the moment the little "wait/report/close" window appears, the google+ application has resumed.
So we have 1) google+ freezing for no good reason and 2) android not properly assesing program responsiveness, prompting to kill functioning programs.
Add this to the ever increasing list of spectacular failures of android. 
+Dianne Hackborn "Also smoothness issues related to the size of the screen (which I assume you are using to imply related to screen resolution / number of pixels)"

Physical size of the screen (dimensions, that is) do matter and may affect perceived smoothness, regardless of the same performance(aka fps count) and/or pixel density.

Smoothness is when your animation changes with enough FPS and small enough DISTANCE on the screen (perceived by the eye) that your eye can't see that.

Lets say you have a small 4 inch screen and 60 fps run 2d graphics. And you also have a 6 inch screen with the same 60 fps and with the same pixel density. The result will be this - the larger screen WILL get choppier because you still have 60fps to render animation smoothly, but the screen became larger and now changes between positions of objects in the current and the next frame become too noticeable due to that fact that the moving object "travels" longer distance between two consecutive frames.
Add a comment...