Former Google intern explains why UI lag occurs more often in Android than iOS - Page 4

I have brought up that issue in other threads involving the Galaxy S 2, in answer to the usual blind claim of "technical superiority" of the Galaxy S 2 over the iPhone 4S.

It is good that this article backs up exactly what I described based on using the device and provides an answer based on fundamental flaws with Android which I have noticed on every Android device I have used, going back to the HTC Magic.

There's no counter to your ego. It's hard to debate when you say "I think Android is crap." I was taught a long time ago that debating with opinions is silly. The annoying thing is you like to try and present your opinion as fact. Simply put, it's not. Your rabid fanboyism is why I get weird looks when I walk into my programming classes with my MBP. People like you give Apple users a bad name.

People like him pretty much started the whole Apple/Android beef.

It's so annoying when I'm on an Android site and some stupid fanatic Fandroid says stupid shit. Unprovoked.

It doesn't happen as often as it does on this site but when it does it is usually as unwarranted, untruthful, and idiotic as the vice versa is here.

I always thought it was clear that "rabid fanboys" presented their opinion as opinion, not fact. Are you saying that you can't tell the difference? Of course not. Apple ][ is presenting opinion, you know it is opinion, and you're not interested in debating with opinions. Ok, so is there a problem? You want to pin the "weird looks" you get on this guy? Really?

What's wrong with these people! Don't they know this can't possibly be true since Android was developed at the same time as iOS and is not just a reactionary copy?

Gosh!

I don't believe that I've ever said that "I think Android is crap.". I'm flat out stating that Android is complete crap, I don't merely think that it is, I know that it is.

And of course that particular statement is just my opinion. I don't speak for anybody else here besides myself. Certain statements that I make are fact, such as when I say that the Kindle Fire is 2 touch and the iPad is 11 touch. Other statements that I make are opinion.

And if people are giving you weird looks when you walk into class, then maybe they're jealous of your Mac or maybe you just had a big pimple on your forehead on that particular day. I'm pretty sure that I'm not responsible for anybody who might be giving you weird looks.

You want to be associated with that guy?

You are lightyears more mature and reasonable than Apple ][ could ever dream to be. You do not dehumanize an entire sect of people based solely on their device preference.


And Apple ][ that's an opinion.

I suspect this will fall on deaf ears here, but, for the record, one of Google's engineers has posted a response explaining that the intern got almost everything wrong - https://plus.google.com/?fd=1#105051...ts/XAZ4CeVP6DC

Android ranks among the most fail software projects in terms of performance.

Yes there is a huge performance problem with Android, and no, most of the reasons given by this guy are false. I do not think he has much experience working with modern CPU/GPUs or writing UI systems.

1) Main thread with normal priority - BS
Entire games run on normal priority and they run just fine without any lag. This is not at all the issue, especially considering the UI code is running at the OS level.

2) FPS Cap - BS
Yes most gamers can see the difference between 30fps and 60fps. But if the 30fps is consistent, you should not see jerking or stuttering animations. Your movies run at 24fps, as long as they dont have sudden lag, they appear smooth flowing.

3) Tegra 2 Hardware issues - BS
You dont need a GPU or even a 100mhz CPU to animate 16 icons moving across the screen smoothly. Carmack made Quake which is a full 3D game with polygons and textures with AI and handling multiple inputs run smoothly on a 486 on top of a desktop OS with no stuttering. Blizzard made Starcraft with 200-400 sprites on screen running on a Pentium 1 before GPUs were invented with 0 lag on a desktop OS. Telling me that the 1ghz CPU with a modern GPU is not powerful enough to animate 16 icons is utter BS.

4) Dalvik - Partially true
No matter the hardware, running a non-native language is always a drawback in performance. Moreso if you have a non-incremental garbage collector stopping time to clean up at random times.

5) UI Hierarchy - BS
Yes iOS does it better by pre-rendering each UIView and caching it. Still, there is no reason why everything cannot be rendered every frame. Quake rendered the entire screen every frame without caching(You cant cache rendered output in a 3D game).

So why does Android lag? Its just horribly unoptimised rendering/animation code. Google could have done well to hire a game engine programmer to write efficient code. Google probably said, "But hey hardware is powerful, lets use Java and hire web programmers to write the rendering code" and you get Android.

Actual reviews of ICS on the Galaxy Nexus seem to disagree: Why I Have Faith in Ice Cream Sandwich Overcoming Android's Fundamental Lagginess.

Can you copy/paste the contents over - it's behind a Google login.

from Dianne Hackborn:
"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. Id like to help people better understand (and judge) these discussions by giving some real background on why Androids UI was designed the way it is and how it actually works.

One issue that has been raised is that Android doesnt 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 http://developer.android.com/referen...PRIORITY_AUDIO 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.

Androids 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, cant 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 doesnt 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 doesnt 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 iOSs original design constraints, which remember didnt 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 applications 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 applications 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 doesnt 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 http://developer.android.com/referen...nabled(boolean) 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 didnt 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 dont 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 difficultyou 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 Ill take that as as true. These are the exact same recommendations that we have given to Androids 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."

And her disclaimer:
"Edit: there have been a number of comments treating this as being written as an excuse for Android or not mattering to users or such. I'd just like to clarify that I wrote this solely to address a lot of incorrect information that I see posted around the web as truth. This is no attempt to excuse anything, and it is solely for those who already have an interest in writing and reading the often factually incorrect technical information out there.)

I get tired of seeing so much misinformation posted and repeated all over the place about how graphics rendering works on Android."

Wow, Android will have to go through another re-write to correct the ability to run a smooth touch interface? Talk about confusion among developers in an already confusing miss mosh of variables with this open source abortion. Good luck with that. I'll stick with iOS.

According to most available professional reviews, ICS already has addressed most of the "lagginess" noted with earlier versions of Android. Faster hardware doesn't make nearly the difference that Android 4.0 itself does. Google's done a lot of work on their latest OS version. Forbes ran a good story on this just a day or two ago, with lots of references to back it up.

http://www.forbes.com/sites/sap/2011...s-lagginess/4/

It is interesting that out of the 9 reviews, the 3 that still found laggy behavior in the Android OS, were some of the most notorious, being CNET, TechCrunch, and Time. Although I give credence to Gizmodo and Engadget, I'm still not convinced that there is still not an underlying problem with the Android OS that needs correction as blatant as Munn points out.

I do know that whenever I'm sampling Android based, iPad type devices, there is always a lag in the UI. I just happened to come across Sony's implementation this past weekend in HHGregg, and it was extremely bad.

Thanks for that. I think it's good that Dianne has posted this. Some parts do come across as making excuses, trying to say that flexibility and security over iOS are reasons their system performs worse in some areas and judging by the edits inadvertently managed to spread some misinformation about iOS.

I do think on some level they had different design goals but Dianne fails to point out that the original Android design was nothing like iOS either. It looked like a Blackberry/Symbian competitor. They only added iOS-like features to the OS in 2009, a full 2 years after the original iPhone came out, which definitely had hardware acceleration from the start.

They didn't even have a virtual keyboard until 2009:

http://www.youtube.com/watch?v=zpfQISmjmVs
http://www.geek.com/articles/mobile/...id-15-2009058/

So Android 1.5 arrived around the time iOS 3.0 did. They did have 3rd party multitasking first but Dianne simply can't claim that the design goals are what causes the system sluggishness.


Which would suggest that Android is the most secure mobile operating system. And yet it's not:

http://www.zdnet.com/blog/security/c...-security/9698

Not just due to the App Store either and you can trust him, he's a doctor.

The fact of the matter is, Apple was way ahead of everyone when they pushed out the original iPhone and what everyone else has done is scrambled to incrementally improve on a ground-breaking development by copying it as closely as they can and refusing to acknowledge where they got their ideas from and then excusing the flaws instead of just coming out and saying that they can't get it right until they actually xerox Apple's source code and clone their end-to-end business model.

AppleInsider has been promoting the intern's story at the top of their homepage for most of the week. They have yet to run a new story about Hackborn's response, or update this story. Munn has since editing his post with this proviso: "A LOT OF MY ANALYSIS OF ANDROID PERFORMANCE IS WRONG."

So, AppleInsider editorial staff -- will you either publish an update to this piece, or write a new story?

All good points Marvin. Consider this tho: Using Charlie Miller's reasoning, Linux/Ubantu should be the least secure of all. In essence it boils down to the choices made when given the freedom to do so. You won't get in a car wreck if you're never allowed to leave your home.

EDIT: Now Andrew Munn, the story source, has modified his Android views as follows:
"BEFORE READING: A LOT OF MY ANALYSIS OF ANDROID PERFORMANCE IS WRONG, HOWEVER I AM LEAVING THIS POST UP BECAUSE OF MY COMMENTARY ON THE ISSUE."
https://plus.google.com/100838276097...ts/VDkV9XaJRGS

Besides now noting that he had some fundamental claims wrong and "It would be wise to trust (Dianne Hackborn's) word over mine, as she is the final word on Android framework issues".
https://plus.google.com/105051985738...ts/XAZ4CeVP6DC
the respected Bob Lee has also posted several instances where the former intern was incorrect, as noted and acknowledged by Mr. Munn.
http://blog.crazybob.org/2011/12/tru...rformance.html

(thanks for noting it derekmorr. I had missed that, tho I think based on some comments Marvin may have been aware of it.)

Android definitely has lag on my Droid. My iPad 2 is butter smoooooth. Never slows down. Despite this I prefer Android for my phone, but I have to admit on this point Apple is the best in class, as mrdriftmeyer points out, thanks to their talented engineers at NeXT and then Apple. Mrdfriftmeyer, thanks to you and your colleagues for designing awesome software that gave birth to iOS!