Earlier quoted context omitted.
This is correct. However, the Android team made their decision with the assumption that Android would power keyboard and trackball devices. That was never the case, so they made the wrong decision based on a faulty premise.
Android would power keyboard and trackball devices. That was never the case Er, there are a lot of Android devices that are keyboard and trackball powered.
Follow up to “Android graphics true facts”, or The Reason Android is Laggy
101–110 of 118 posts
Re: Follow up to “Android graphics true facts”, or The Reason Android is Laggy
#102(In other news, I just ordered my Galaxy Nexus yesterday and am rather looking forward to it. Can you tell?)
The trick is that there is effectively only ever one model iPhone / iPad at a time -- so right now it's the 4S, for example, that captures all the mindshare and forms the basis of comparison. Legacy iOS devices simply cannot keep up, and certainly do not maintain the buttery-smooth experience that people identify with iOS. But nobody appreciates this, because legacy iOS devices aren't an active force on the market. Android devices, meanwhile, come in many hardware configurations, some of which are much more analogous to my old laggy 3G than to the latest iOS hotness.
This isn't an excuse: it just means that Android has set a harder task for itself than iOS has. But that's no reason not to succeed at that task. 15 years ago, my hand-built BeOS box gave me an unbreakably buttery UI -- even during obnoxious geek demos such as simultaneously playing 30 different videos in 30 different windows -- so there's no reason that ANY computing device, even a very cheap one, should not be able to match that performance today. This article gives a good insight into how Android is failing to do so, and what some of the solutions might be.
Re: Follow up to “Android graphics true facts”, or The Reason Android is Laggy
#103Earlier quoted context omitted.
"Proven itself" can mean that iOS grosses more than Android. Last I checked iOS users spend more on apps/services than their Android counterparts.
If that's because Android's interface is laggy, then why do people keep buying Androids? IMHO, iOS users spend more on apps because iTunes is better than Android's Marketplace - this may have been a deliberate decision by Google nonetheless. Did you know that I am not allowed to sell Android apps in the Marketplace because my country is still not approved for registering a Google Merchant account? That's right, it's…
Do they? The big Android surge only came in the last year, so the vast majority of Android users are on their first.
Re: Follow up to “Android graphics true facts”, or The Reason Android is Laggy
#104Earlier quoted context omitted.
On iOS, updates to the UI happen on the main thread, but all animation, surface compositing, and rendered graphics run on the dedicated Core Animation rendering thread.
The user complaints are with regards to delays in event processing ("sloppy" or "laggy" touch events), not general animation that does not involve user input; the specific examples in this article demonstrating how this "dedicated" UI thread with "real-time priority" exists detail touching the screen and watching the system lock up as it is now busy handling the scroll events. Also, it is my understanding that surfac…
Obviously you never went through tunnels. When I am playing a 100% offline game (without internet access) and my bus goes in the tunnel, everything stops. Who cares about this "game" when I have tons of networking to do. Networking takes precedence over animation so what happens is any touch events or animation or anything is heavily delayed.
What about the phone? When the call is ending, it can't render a UI update that the button was touched, thus just a delay. It even delays processing the next input event until after the screen switches states. End result? I make a call when I try to hang up or vice versa. Point being that these problems are not exclusive, but the iOS solution is significantly better for these edge cases which are the ones that cause the biggest headaches, they still happen in iOS but very infrequently vs consistently bad every other time.
Re: Follow up to “Android graphics true facts”, or The Reason Android is Laggy
#105Earlier quoted context omitted.
I think it the takeaway is slightly different: When many of Android's fundamental design decisions were made, specifically making UI animations take place in a normally-scheduled application thread, the prime competition/inspiration was the keyboard- and trackpad-driven interfaces of competitors such as Blackberry. Apple, on the other hand, decided that a touch-based interface was the way to go. As such, Apple design…
If this is true than it blows a hole in the assumption that Android was designed with a touchscreen in mind.
Re: Follow up to “Android graphics true facts”, or The Reason Android is Laggy
#106Good article! But I have to question the default assumption that iOS isn't laggy. I'm using an old iPhone 3G and it has become laggy as hell over the years. Scrolling on a web page is only ever smooth once a page has finished rendering -- and often not even then. The map application has become so laggy as to be completely unusable; every scroll or keypress takes 20-30 seconds to register (not exaggerating). Installin…
That's not the "only" fair comparison. The 3G is a three and a half year old device. It's also severely memory constrained and probably shouldn't have gotten iOS 4 to begin with. You're certainly running into paging issues: iOS doesn't have a backing store for virtual memory, but it will drop and reload read only pages out of flash storage when it's memory constrained.
The iPhone 4 is almost 18 months old and compares quite favorably with year-newer Android devices on the UI responsiveness front.
Re: Follow up to “Android graphics true facts”, or The Reason Android is Laggy
#107This isn't a "follow-up", per se. Nonetheless, while Android continually works to smooth out the rough edges -- helped along by the march of technology -- this is something that is a bit overblown: Minor jutters of the interface is something that primarily irritates people as a relative thing, not as an absolute thing. If you are a developer or a reviewer and you regularly use an iOS device and an Android device, the…
Yes, it is. When people ask me how I like my new smartphone, I always say to them: "I like the idea behind Android, but it sucks in use; this smartphone is too weak to handle the basic OS, which makes using it terribly annoying for most of the time".
Yes, it sucks. There are constant lags in everything from button presses to scrolling. Main screen gets killed by the OS every few minutes, and it takes it 30 seconds to load up and become usable. Activating Wi-Fi and letting Facebook and GMail sync at the same time equals to several-minute long hang followed by me plugging the battery out. The phone occasionally hangs when receiving calls, and often when trying to dial.
Yes, for me, Android phones are piece of crap. I use mine, I put up with it, but it's not pleasant. It's damn annoying every single day.
Re: Follow up to “Android graphics true facts”, or The Reason Android is Laggy
#108This isn't a "follow-up", per se. Nonetheless, while Android continually works to smooth out the rough edges -- helped along by the march of technology -- this is something that is a bit overblown: Minor jutters of the interface is something that primarily irritates people as a relative thing, not as an absolute thing. If you are a developer or a reviewer and you regularly use an iOS device and an Android device, the…
Perhaps. But once the end user notices the lag compared to their friends device, it very quickly becomes an end users (and very shortly, the platforms) problem. My android lags, and it pisses me off. per your quote: "It's the same as getting an upgrade to your PC, a new video card, etc. You were perfectly happy before, but relative to your new reality the old one seems subpar, and you overestimate how much it interfe…
It's not even about that. It's about something usable and working as expected. I have an Android smartphone (LG P350) with bundled Facebook and Twitter, both of which I never use because they're too heavy for the phone. They barely work, they hang up for minutes, and crash my homescreen. And if I try to sync them, it usually ends with me taking the battery out after few minutes of staring at shining screen of a totally non-responsive (hardware buttons included) phone. Not to mention that once or twice an incoming call was too heavy for that phone to handle, => battery removal operation necessary.
Next time before choosing Android, I'll carefully test current devices, and switch to iPhone if I ever find a trace of UI lag.
Re: Follow up to “Android graphics true facts”, or The Reason Android is Laggy
#109Good article! But I have to question the default assumption that iOS isn't laggy. I'm using an old iPhone 3G and it has become laggy as hell over the years. Scrolling on a web page is only ever smooth once a page has finished rendering -- and often not even then. The map application has become so laggy as to be completely unusable; every scroll or keypress takes 20-30 seconds to register (not exaggerating). Installin…
> Installing an app more or less bricks the UI throughout. I'm sure that these problems do not exist on modern iOS hardware -- but on that basis, the only fair comparison is with modern top-of-the-line Android hardware. That's not the "only" fair comparison. The 3G is a three and a half year old device. It's also severely memory constrained and probably shouldn't have gotten iOS 4 to begin with. You're certainly runn…
I have a 3G and like you said it should have never gotten iOS 4. But the 3GS is just fine.
Re: Follow up to “Android graphics true facts”, or The Reason Android is Laggy
#110Earlier quoted context omitted.
If you move code that used to run (and was tested to) on the main thread to another thread, and run that thread in parallel with the main thread, you are creating a huge opportunity for race conditions. Some applications may run fine, but I bet you will find a lot that do not, even ignoring timing differences that may cause problems with games.
I guess I don't see how that's any different than performing any other blocking operation off the main/UI thread, either on a hand-rolled secondary thread or using a util class like AsyncTask which handles that for you. It seems to me race conditions are no more or less of a concern for rendering animations than updating data -- and probably less, actually, since there's probably not much contention for animation res…
That would change the rules from "model updates and screen redraws never run concurrently" to "...will typically run concurrently". I think you agree that is asking for problems.
Of course, it is possible to adjust the system to apply different rules to different apps, but then apps would have to be changed to advertise "I am fine with running updates on a different thread". I think newer versions of Android already have some of that.