11 ms·

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

330 points by andrewmunn 15y ago

sedev 15y ago
The takeaway for me is this: Android and iOS' creators made different tradeoffs in their UI programming. The iOS creators, overall, correctly predicted that a fast, smooth, responsive UI was something that users would care about enough that it was okay to pay a performance cost in other areas in order to make the UI as responsive as it is on iOS devices. Android's creators made a different tradeoff, and the UI on Android devices showed clearly - and continues to show - the problems with that tradeoff.
- andrewmunn 15y ago
  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.
  - YooLi 15y ago
    I don't know about saying "That was never the case...". At the time the decision was made, a blackberry-style device was indeed the target. The problem was when the target shifted to iPhone instead.
  - untog 15y ago
    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.
    - msh 15y ago
      I think he meant to say kb devices without touch screens.
- daniel_solano 15y ago
  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 designed iOS to make rendering in a special, real-time priority thread to ensure responsiveness.
  - perssontm 15y ago
    The interesting thing would be an estimate of the amount of work needed to move the android ui-rendering to its separate real-time thread. Would it even be realistically possible?
  - yardie 15y ago
    If this is true than it blows a hole in the assumption that Android was designed with a touchscreen in mind.
    - checker 15y ago
      It wasn't: http://news.cnet.com/8301-10784_3-9869123-7.html?tag=mncol;txt http://news.cnet.com/8301-10784_3-9869123-7.html?tag=mncol;t...
- interlagos 15y ago
  How was the iOS decision more "correct"? Android is clearly succeeding despite the lack of UI refinement, so it's hard to hold one as victorious. There is definitely a different philosophy, though. The Android approach was that it was better to be correct -- if you scroll a page or a webpage, that what scrolls into the viewport needs to be correct, while iOS happily scrolled in a checkerboard. I prefer the stock Android approach (some devices, such as the GS II, sub in the "better to be fast" approach, giving smoother superficial interactivity) so long as there is enough hardware that the result isn't too painful.
  - illumin8 15y ago
    The iOS decision was more correct because it has proven itself in the marketplace. Consumers overwhelmingly demand touch interfaces on their smartphones and tablets, as opposed to stylus, trackball, or any other that has come before it. Android started as a platform trying to out-Blackberry RIM. When the iPhone was released in 2007 they switched to a model of trying to out-do iOS.
    - interlagos 15y ago
      That wasn't at all the focus of the comment that I replied to. I get that you're on this "keyboard/trackball" thing (sidenote -- did you know that Android devices still come out with keyboards and trackballs?), however the difference between the two platforms is largely simple architectural differences having nothing to do with form factor.
    - ajross 15y ago
      "Proven itself" how, exactly? Last I checked Android devices were outselling iOS. Now, there's room for argument here about what the proper design is for a mobile OS. But if you're going to support your platform flamage with statements like "Consumers overwhelmingly demand" you need to synchronize the argument with the facts.
      - reidmain 15y ago
        "Proven itself" can mean that iOS grosses more than Android. Last I checked iOS users spend more on apps/services than their Android counterparts.
- wvenable 15y ago
  Apple is also willing to put a lot of burden on the developers. Having a separate UI thread is more difficult than doing all rendering in the main application thread. Supporting only native code without garbage collection is also more difficult on developers too.
  - calloc 15y ago
    Except that all UI stuff is done in the applications main thread ...
- gnaffle 15y ago
  I'm not so sure that the iOS creators predicted anything. They started off with OS X, which already had a smooth, responsive, GPU backed UI (Cocoa/Quartz Extreme). I don't think that they had to compromise on performance, but they did have to spend extra money on a GPU. Likewise, a good low latency sound system with MIDI support was added to iOS not because Apple correctly predicted that smartphones and tablets would be popular for music production, but because those were features already present in OSX. AFAIK, the Android designers started out making a Blackberry clone, and creating a similar software stack would have been a lot more work at a time when the competitors were all running 2D GUIs with no GPU acceleration or fancy animations.
Legion 15y ago
I don't know if his technical explanation is correct or not, but he is absolutely right about the importance of responsiveness. I was an Android early adopter (G1) and while I could put up with slower HTML rendering (for example), I could not tolerate the poor responsiveness.
davesims 15y ago
“...a lot of the work we have to do today is because of certain choices made years ago... ...having the UI thread handle animations is the biggest problem...An easy solution would of course to create a new UI toolkit but there are many downsides to this also.” What would such a re-write look like, from a practical coding point-of-view? Couldn't this be done in a way that is transparent to the calling code, or would there have to be a fundamental re-write of the SDK, i.e., the UI thread no longer be the main thread?
- patrickgzill 15y ago
  That jumped out at me as well. I think there would definitely be a way to have most if not all of the underlying API calls set up to do this, without even needing to recompile the application.
  - Someone 15y ago
    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.
    - davesims 15y ago
      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 resources, and if there is contention, synchronization of access to drawables should be straightforward.
      - Someone 15y ago
        The post I replied to speculated that it would be possible to change the system's behavior without recompiling apps. 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.
interlagos 15y ago
This 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 difference is evident and jarring. If you're an end-use it quickly disappears and is a non-issue. It just isn't a real problem for end users. 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 interferes with your enjoyment of the device.
- MichaelGG 15y ago
  Not quite. For instance, on a Galaxy S II, going to the home screen while in the mail app takes ~2 seconds. Doesn't matter how many times I do it, or even if I just do it in a loop, switching between mail and home. It's probably not even Android's direct fault - I wouldn't be surprised if this is Samsung's horrible software shining through - but it's very frustrating, and I don't use other devices to compare it to.
  - interlagos 15y ago
    A big part of the delay on the GS II is the Vlingo voice functionality. Did you know (I ask because many people don't know) that if you tap the home button twice it brings up voice mode? The ability to recognize double clicks imposes a certain floor on the responsiveness of that button. That most certainly does bother me, and I've yet to discover how to disable it so it simply reacts immediately.
    - illumin8 15y ago
      Why should it? The iPhone uses a home double-click to pull up the task manager/switcher interface. Yet single clicking the home button still instantly gives you the response you expect.
dshep 15y ago
Finally an answer and seems like a reasonable one. For a time I had both a Nexus One and iPhone 3GS. The Nexus One was faster in just about about everything, but using it just felt like work. The iPhone comparatively was a pleasure to use.
saurik 15y ago
"""It’s because on iOS all UI rendering occurs in a dedicated UI thread with real-time priority. On the other hand, Android follows the traditional PC model of rendering occurring on the main thread with normal priority.""" <- AFAIK this is simply wrong: the events that are later described as blocking rendering are coming in on the main thread, not some special "dedicated" one. The reason things block is because of the way the event loop on that thread is managed (and in fact is directly caused by all of that activity operating on the main thread, which we even often call the "UI thread"), and has nothing to do with threading, and certainly has nothing to do with "real-time priority". """On iOS when an app is installing from the app store and you put your finger on the screen, the installation instantly pauses until all rendering is finished.""" <- This is certainly not true. The update of the display for the installation progress might (...might) stop, as that's happening in the UI (aka, "main") thread of SpringBoard (and the event loop management might ignore incoming events that are not related to the touch event until after the gesture completes), but the installation itself is being managed by a background daemon (installd) and will not stop because someone is touching the screen. The operating system is /not/ doing something hilariously insane here, throwing out all computation on the device because someone is accidentally touching it.
- illumin8 15y ago
  +1 I think this Saurik guy knows what he's talking about... Now where have I heard that name before? (hint his software runs on over 2 million devices)
  - deleted 15y ago
    [deleted]
- waqf 15y ago
  I'm totally confused. When you say "the events that are later described as blocking rendering are coming in on the main thread, not some special "dedicated" one" are you talking about iOS or Android? I can't make sense of your post either way.
  - 15y ago
code_duck 15y ago
I'd be interested to learn what the deal is with sound on Android. I'm a musician and love the software instruments on the iPhone/iPod touch... they're a joy to play. On my relatively modern Android phone (Motorola Droid 2), instruments are so laggy they are absolutely unplayable. A key press results in a sound up to half a second later, sometimes never. The response improved slightly with the upgrade to Gingerbread, but not enough. iOS instruments are responsive enough you could play them in concert if desired... on the other hand, I can't even entertain myself with the Android music apps. Is this just the difference between Java and Obj. C?
- anon1385 15y ago
  It's a known issue and people have been complaining about it for years now: http://code.google.com/p/android/issues/detail?id=3434 http://code.google.com/p/android/issues/detail?id=3434
- charliesome 15y ago
  This was on HN a couple of days ago and it turns out that it's down to the sizes of the sample buffers each OS allocates. From what I understand, Android will only give an app a large buffer, so when the app starts filling up that buffed, it may take a little while for the 'playhead' (is there a more technical term?) to get around to playing those samples. On iOS however, an app can request a much smaller sample buffer, so there's less lag time between when an app fills that buffer and when the samples actually get played.
- billjings 15y ago
  Android is all around inhospitable to music apps. The link in a sibling post here is just part of the problem - as far as I can tell, Android has no libraries that are useful for serious A/V work. On iOS, in the span of a short morning I can hook up a button or slider to send out MIDI messages over WiFi to my MBP and route it to any device I want; I have no idea how to get the equivalent setup on Android. What if I want to decode an mp3 and process the resulting audio? I can tell you two ways on iOS, I know of a vague direction that might work for Android. You have to dive down into the NDK to do it, too. What about compositing video? Well... Seriously, here is AVFoundation on iOS. This is a high-ish level Obj-C interface for mucking about with AVAssets, which can be audio or video: http://developer.apple.com/library/mac/#documentation/AVFoundation/Reference/AVFoundationFramework/_index.html http://developer.apple.com/library/mac/#documentation/AVFoun... This is just a single library dedicated to a single level of abstraction. Video composition, audio mixing, playback control and monitoring... there's a lot going on just here. You've also got CoreMIDI, AudioQueues, AudioUnits/AUGraphs, MusicPlayer... they're not easy to pick up, but they're there and they can do serious work. Here is what you can do in Java on Android: http://developer.android.com/reference/android/media/package-summary.html http://developer.android.com/reference/android/media/package... You can play encoded media, you can capture a raw input stream or direct it to an encoded file, you can play raw PCM... that's it. Really. To my knowledge, I'm not exaggerating when I say that - I'd be in debt to whoever proved me wrong, so please do! For graphics on Android, there's usually something analogous you can get by with. For audio, though, it's just... not there at all.
jcizzle 15y ago
Pretty close on the iOS stuff: 1. All* rendering takes place on the main thread in iOS. 2. The main thread doesn't always have the highest priority. In fact, its priority level changes throughout an application. 3. There is more than just one reason iOS rendering is so fast. Here are two important ones: a. Animation is actually the basis of the entire rendering system. On desktop Cocoa, the drawing system was a little dated. The mistakes learned from this system and the desire to have fast animation led to the Core Animation framework and the idea of "layers". The ability to quickly composite layers (without moving any data from between the CPU and GPU) and only redraw when necessary is huge. b. The batching together of drawing updates at the end of an event instead of on an as needed basis allows for huge performance gains. * It is possible to draw in a background thread, but is reserved for particular situations (maps, web content, etc.). Table views do not fall into this category.
- danssig 15y ago
  Do you think games will ever take advantage of this on OSX to start giving Apple an edge? Right now I still have to have a Windows machine if I want to do any gaming.
  - jcizzle 15y ago
    When it comes to games, OpenGL is still the best option. The animation system works well for moving around interface elements in two dimensions. The animation system does not work well for 3D or when you are modifying the bitmap content of a layer on the screen. Will OSX ever catch up to Windows for games? Maybe. Some game companies take the approach of writing everything in OpenGL to make it easier to port between systems, writing a layer of native code to support their cross-platform code. However, some studios use DirectX which is windows-only. The popularity of OSX and iOS will only increase the pressure on game developers (and engine developers) to write code that is easier to port.
pace 15y ago
Isn't Google's staff working under NDA? I love the open discussion about Android's weakest point and I appreciate opinions from all side, in particular those from inside Google -- but this uncoordinated communication on G+ addressing problems w/o delivering a solution damages Android's image to some extent.
- wmf 15y ago
  It would be nice if Google could just say "responsiveness: we fixed it" but meanwhile I think these recent discussions are far better than the uninformed trolling that was going on before.
- zyb09 15y ago
  How's that heavily damaging? Google is known to be open about its workings, and I think most people agree that an engineer explaining underlying concepts is a positive thing. Putting up NDAs on every little thing is just silly and annoying.
- marshray 15y ago
  Did you see the part about "I’m interning with the Windows Phone team starting in January"? Still, I don't have experience with iOS devices, but my Nexus S tends to be so laggy at times that apps crash frequently. (I had attributed it to GC).
  - roflharrison 15y ago
    >Still, I don't have experience with iOS devices, but my Nexus S tends to be so laggy at times that apps crash frequently. This sounds more like poorly written apps than an issue from the article. For example if you are scrolling a list view and it slows down to the point of crashing, the application probably isn't caching views or has a memory leak (application authors fault). If your device gets sluggish and you get miscellaneous force closes I would look for applications with background services that are doing more work than they should be.
- jrockway 15y ago
  It's an open source project. Google doesn't make any money from Android. It's just something they do for fun to advance their other business goals.
rayiner 15y ago
This is almost certainly the right answer. Synchronization/priority is the #1 culprit when people complain that a UI is "laggy." It was why BeOS was so renowned for being snappy--all rendering was done in a separate high-priority thread. It's also one of the reasons Linux has always been criticized for a laggy UI: the X server/application/window manager triumvirate isn't so much slow as it is a total mess from a priority point of view. You end up needing priority-shifting schemes UNIX doesn't have (quickly shifting priority from the WM to the app to the X server as an event flows from the X server through the WM to the app).
yellowbkpk 15y ago
The great part about Android being open source is that you can go look at the source to see that the UI thread is not a "normal priority" thread [0]. There are very few things that run at higher priority (and they're listed right there): the threads related to audio and the hardware interaction (power buttons, etc.). Last time I tried it, Android did not let you create a thread with higher priority than the UI thread. [0] http://developer.android.com/reference/android/os/Process.html#THREAD_PRIORITY_DISPLAY http://developer.android.com/reference/android/os/Process.ht...
sssparkkk 15y ago
Interesting to finally see some informed discussion about this going on. In the meantime I've scripted my Galaxy S to turn off syncing when the screen is turned on. It helps a lot to combat lag, as the phone often had the annoying (but understandable) habit of starting a sync when it was awakened by me: resulting in slowness just when I tried to use the device.
therockhead 15y ago
Hmm ... is this still an issue with dual core Android phones ? I have two Android phones, Galaxy S2 and Galaxy Nexus and both are as smooth as butter. Both feel faster than my first gen Ipad.
- exDM69 15y ago
  Yes. A lot of Android's rendering takes place on the CPU and a lot of it is small batches of serial work that isn't very well suited for concurrent execution on multiple cores.
deleted 15y ago
[deleted]
babebridou 15y ago
As I said in the other thread, there are two patterns, one is a Delegate pattern (IOS) where draw method lookup per pixel coordinate is trivial, and the other is a listener pattern, where view layout, composition and superposition is trivial. One is easy 98% of the time and super hard 2% of the time (iOS) and the other is relatively slow all the time but with much more potential for cross-process interactions. In Android, you can have a translucent popups from App#1 appear on top of any sort of screen of App#2. You can't have this on iOS. At all. On the other hand, animations and scrolling are blazing fast on iOS without any need for superior hardware. I honestly believe that this alone explains the "lacking" in performance that Android suffers from: it targets super high-end multi-core devices, with JIT compilers and optimizers that don't exist yet, in order to allow functionalities that are unclear to everyone of us. Shameless plug: I made an app (1) that illustrates what iOS will never be able to do. The question is, will anyone ever need that sort of app on their phone? (1) https://market.android.com/details?id=com.fairyteller.linkpreview https://market.android.com/details?id=com.fairyteller.linkpr...
- saurik 15y ago
  What keeps you from having a translucent popup from App #1 appear on top of any sort of screen from App #2 is not iOS's rendering architecture: it is that you are not allowed to, as one application, do any sort of computation while another one is happening. To be clear, we do this all of the time on jailbroken devices (where we have access to write apps with true multitasking, and can also just add code as required to SpringBoard itself, which is acting as the window manager): you just create a transparent UIView and put it in a new UIWindow; there are seriously no issues doing this. In the end, every UIView is backed by a CoreSurfaceBuffer (I think "Core" got renamed to "IO" at some point, if you look this stuff up), which are managed by a kernel driver that allows processes to pass these buffers (which may be backed by video, not system, memory) to each other, and in the end they mostly composited (with alpha blending) in hardware.
pragmatic 15y ago
Can someone explain what is "laggy" about android? I have a Droid bionic (second Android phone) and a Kindle Fire. What lag should I be suffering?
- usaar333 15y ago
  Can't speak for the bionic, but on a Kindle if you scroll in a webpage, you will notice a very low framerate. It is far less smooth than on, say, an iPad. Other lag is also present in the initial part of scrolling. Android takes a bit longer than iOS to respond to your fingers' movements. Its on the order of milliseconds, but it is noticeable if you compare it to an iOS device.
nkoren 15y ago
Good article! But I have to question the default assumption that iOS isn't laggy. I'm using an old iPhone 3G and it has become laggy as hell over the years. Scrolling on a web page is only ever smooth once a page has finished rendering -- and often not even then. The map application has become so laggy as to be completely unusable; every scroll or keypress takes 20-30 seconds to register (not exaggerating). Installing an app more or less bricks the UI throughout. I'm sure that these problems do not exist on modern iOS hardware -- but on that basis, the only fair comparison is with modern top-of-the-line Android hardware. (In other news, I just ordered my Galaxy Nexus yesterday and am rather looking forward to it. Can you tell?) The trick is that there is effectively only ever one model iPhone / iPad at a time -- so right now it's the 4S, for example, that captures all the mindshare and forms the basis of comparison. Legacy iOS devices simply cannot keep up, and certainly do not maintain the buttery-smooth experience that people identify with iOS. But nobody appreciates this, because legacy iOS devices aren't an active force on the market. Android devices, meanwhile, come in many hardware configurations, some of which are much more analogous to my old laggy 3G than to the latest iOS hotness. This isn't an excuse: it just means that Android has set a harder task for itself than iOS has. But that's no reason not to succeed at that task. 15 years ago, my hand-built BeOS box gave me an unbreakably buttery UI -- even during obnoxious geek demos such as simultaneously playing 30 different videos in 30 different windows -- so there's no reason that ANY computing device, even a very cheap one, should not be able to match that performance today. This article gives a good insight into how Android is failing to do so, and what some of the solutions might be.
- twoodfin 15y ago
  > 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 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.

330 points by andrewmunn 15y ago

sedev 15y ago

The takeaway for me is this: Android and iOS' creators made different tradeoffs in their UI programming. The iOS creators, overall, correctly predicted that a fast, smooth, responsive UI was something that users would care about enough that it was okay to pay a performance cost in other areas in order to make the UI as responsive as it is on iOS devices. Android's creators made a different tradeoff, and the UI on Android devices showed clearly - and continues to show - the problems with that tradeoff.

andrewmunn 15y ago
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.
- YooLi 15y ago
  I don't know about saying "That was never the case...". At the time the decision was made, a blackberry-style device was indeed the target. The problem was when the target shifted to iPhone instead.
- untog 15y ago
  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.
  - msh 15y ago
    I think he meant to say kb devices without touch screens.
daniel_solano 15y ago
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 designed iOS to make rendering in a special, real-time priority thread to ensure responsiveness.
- perssontm 15y ago
  The interesting thing would be an estimate of the amount of work needed to move the android ui-rendering to its separate real-time thread. Would it even be realistically possible?
- yardie 15y ago
  If this is true than it blows a hole in the assumption that Android was designed with a touchscreen in mind.
  - checker 15y ago
    It wasn't: http://news.cnet.com/8301-10784_3-9869123-7.html?tag=mncol;txt http://news.cnet.com/8301-10784_3-9869123-7.html?tag=mncol;t...
interlagos 15y ago
How was the iOS decision more "correct"? Android is clearly succeeding despite the lack of UI refinement, so it's hard to hold one as victorious. There is definitely a different philosophy, though. The Android approach was that it was better to be correct -- if you scroll a page or a webpage, that what scrolls into the viewport needs to be correct, while iOS happily scrolled in a checkerboard. I prefer the stock Android approach (some devices, such as the GS II, sub in the "better to be fast" approach, giving smoother superficial interactivity) so long as there is enough hardware that the result isn't too painful.
- illumin8 15y ago
  The iOS decision was more correct because it has proven itself in the marketplace. Consumers overwhelmingly demand touch interfaces on their smartphones and tablets, as opposed to stylus, trackball, or any other that has come before it. Android started as a platform trying to out-Blackberry RIM. When the iPhone was released in 2007 they switched to a model of trying to out-do iOS.
  - interlagos 15y ago
    That wasn't at all the focus of the comment that I replied to. I get that you're on this "keyboard/trackball" thing (sidenote -- did you know that Android devices still come out with keyboards and trackballs?), however the difference between the two platforms is largely simple architectural differences having nothing to do with form factor.
  - ajross 15y ago
    "Proven itself" how, exactly? Last I checked Android devices were outselling iOS. Now, there's room for argument here about what the proper design is for a mobile OS. But if you're going to support your platform flamage with statements like "Consumers overwhelmingly demand" you need to synchronize the argument with the facts.
    - reidmain 15y ago
      "Proven itself" can mean that iOS grosses more than Android. Last I checked iOS users spend more on apps/services than their Android counterparts.
wvenable 15y ago
Apple is also willing to put a lot of burden on the developers. Having a separate UI thread is more difficult than doing all rendering in the main application thread. Supporting only native code without garbage collection is also more difficult on developers too.
- calloc 15y ago
  Except that all UI stuff is done in the applications main thread ...
gnaffle 15y ago
I'm not so sure that the iOS creators predicted anything. They started off with OS X, which already had a smooth, responsive, GPU backed UI (Cocoa/Quartz Extreme). I don't think that they had to compromise on performance, but they did have to spend extra money on a GPU. Likewise, a good low latency sound system with MIDI support was added to iOS not because Apple correctly predicted that smartphones and tablets would be popular for music production, but because those were features already present in OSX. AFAIK, the Android designers started out making a Blackberry clone, and creating a similar software stack would have been a lot more work at a time when the competitors were all running 2D GUIs with no GPU acceleration or fancy animations.

Legion 15y ago

I don't know if his technical explanation is correct or not, but he is absolutely right about the importance of responsiveness. I was an Android early adopter (G1) and while I could put up with slower HTML rendering (for example), I could not tolerate the poor responsiveness.

davesims 15y ago

“...a lot of the work we have to do today is because of certain choices made years ago... ...having the UI thread handle animations is the biggest problem...An easy solution would of course to create a new UI toolkit but there are many downsides to this also.” What would such a re-write look like, from a practical coding point-of-view? Couldn't this be done in a way that is transparent to the calling code, or would there have to be a fundamental re-write of the SDK, i.e., the UI thread no longer be the main thread?

patrickgzill 15y ago
That jumped out at me as well. I think there would definitely be a way to have most if not all of the underlying API calls set up to do this, without even needing to recompile the application.
- Someone 15y ago
  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.
  - davesims 15y ago
    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 resources, and if there is contention, synchronization of access to drawables should be straightforward.
    - Someone 15y ago
      The post I replied to speculated that it would be possible to change the system's behavior without recompiling apps. 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.

interlagos 15y ago

This 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 difference is evident and jarring. If you're an end-use it quickly disappears and is a non-issue. It just isn't a real problem for end users. 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 interferes with your enjoyment of the device.

MichaelGG 15y ago
Not quite. For instance, on a Galaxy S II, going to the home screen while in the mail app takes ~2 seconds. Doesn't matter how many times I do it, or even if I just do it in a loop, switching between mail and home. It's probably not even Android's direct fault - I wouldn't be surprised if this is Samsung's horrible software shining through - but it's very frustrating, and I don't use other devices to compare it to.
- interlagos 15y ago
  A big part of the delay on the GS II is the Vlingo voice functionality. Did you know (I ask because many people don't know) that if you tap the home button twice it brings up voice mode? The ability to recognize double clicks imposes a certain floor on the responsiveness of that button. That most certainly does bother me, and I've yet to discover how to disable it so it simply reacts immediately.
  - illumin8 15y ago
    Why should it? The iPhone uses a home double-click to pull up the task manager/switcher interface. Yet single clicking the home button still instantly gives you the response you expect.

dshep 15y ago

Finally an answer and seems like a reasonable one. For a time I had both a Nexus One and iPhone 3GS. The Nexus One was faster in just about about everything, but using it just felt like work. The iPhone comparatively was a pleasure to use.

saurik 15y ago

"""It’s because on iOS all UI rendering occurs in a dedicated UI thread with real-time priority. On the other hand, Android follows the traditional PC model of rendering occurring on the main thread with normal priority.""" <- AFAIK this is simply wrong: the events that are later described as blocking rendering are coming in on the main thread, not some special "dedicated" one. The reason things block is because of the way the event loop on that thread is managed (and in fact is directly caused by all of that activity operating on the main thread, which we even often call the "UI thread"), and has nothing to do with threading, and certainly has nothing to do with "real-time priority". """On iOS when an app is installing from the app store and you put your finger on the screen, the installation instantly pauses until all rendering is finished.""" <- This is certainly not true. The update of the display for the installation progress might (...might) stop, as that's happening in the UI (aka, "main") thread of SpringBoard (and the event loop management might ignore incoming events that are not related to the touch event until after the gesture completes), but the installation itself is being managed by a background daemon (installd) and will not stop because someone is touching the screen. The operating system is /not/ doing something hilariously insane here, throwing out all computation on the device because someone is accidentally touching it.

illumin8 15y ago
+1 I think this Saurik guy knows what he's talking about... Now where have I heard that name before? (hint his software runs on over 2 million devices)
- deleted 15y ago
  [deleted]
waqf 15y ago
I'm totally confused. When you say "the events that are later described as blocking rendering are coming in on the main thread, not some special "dedicated" one" are you talking about iOS or Android? I can't make sense of your post either way.
- 15y ago

code_duck 15y ago

I'd be interested to learn what the deal is with sound on Android. I'm a musician and love the software instruments on the iPhone/iPod touch... they're a joy to play. On my relatively modern Android phone (Motorola Droid 2), instruments are so laggy they are absolutely unplayable. A key press results in a sound up to half a second later, sometimes never. The response improved slightly with the upgrade to Gingerbread, but not enough. iOS instruments are responsive enough you could play them in concert if desired... on the other hand, I can't even entertain myself with the Android music apps. Is this just the difference between Java and Obj. C?

anon1385 15y ago
It's a known issue and people have been complaining about it for years now: http://code.google.com/p/android/issues/detail?id=3434 http://code.google.com/p/android/issues/detail?id=3434
charliesome 15y ago
This was on HN a couple of days ago and it turns out that it's down to the sizes of the sample buffers each OS allocates. From what I understand, Android will only give an app a large buffer, so when the app starts filling up that buffed, it may take a little while for the 'playhead' (is there a more technical term?) to get around to playing those samples. On iOS however, an app can request a much smaller sample buffer, so there's less lag time between when an app fills that buffer and when the samples actually get played.
billjings 15y ago
Android is all around inhospitable to music apps. The link in a sibling post here is just part of the problem - as far as I can tell, Android has no libraries that are useful for serious A/V work. On iOS, in the span of a short morning I can hook up a button or slider to send out MIDI messages over WiFi to my MBP and route it to any device I want; I have no idea how to get the equivalent setup on Android. What if I want to decode an mp3 and process the resulting audio? I can tell you two ways on iOS, I know of a vague direction that might work for Android. You have to dive down into the NDK to do it, too. What about compositing video? Well... Seriously, here is AVFoundation on iOS. This is a high-ish level Obj-C interface for mucking about with AVAssets, which can be audio or video: http://developer.apple.com/library/mac/#documentation/AVFoundation/Reference/AVFoundationFramework/_index.html http://developer.apple.com/library/mac/#documentation/AVFoun... This is just a single library dedicated to a single level of abstraction. Video composition, audio mixing, playback control and monitoring... there's a lot going on just here. You've also got CoreMIDI, AudioQueues, AudioUnits/AUGraphs, MusicPlayer... they're not easy to pick up, but they're there and they can do serious work. Here is what you can do in Java on Android: http://developer.android.com/reference/android/media/package-summary.html http://developer.android.com/reference/android/media/package... You can play encoded media, you can capture a raw input stream or direct it to an encoded file, you can play raw PCM... that's it. Really. To my knowledge, I'm not exaggerating when I say that - I'd be in debt to whoever proved me wrong, so please do! For graphics on Android, there's usually something analogous you can get by with. For audio, though, it's just... not there at all.

jcizzle 15y ago

Pretty close on the iOS stuff: 1. All* rendering takes place on the main thread in iOS. 2. The main thread doesn't always have the highest priority. In fact, its priority level changes throughout an application. 3. There is more than just one reason iOS rendering is so fast. Here are two important ones: a. Animation is actually the basis of the entire rendering system. On desktop Cocoa, the drawing system was a little dated. The mistakes learned from this system and the desire to have fast animation led to the Core Animation framework and the idea of "layers". The ability to quickly composite layers (without moving any data from between the CPU and GPU) and only redraw when necessary is huge. b. The batching together of drawing updates at the end of an event instead of on an as needed basis allows for huge performance gains. * It is possible to draw in a background thread, but is reserved for particular situations (maps, web content, etc.). Table views do not fall into this category.

danssig 15y ago
Do you think games will ever take advantage of this on OSX to start giving Apple an edge? Right now I still have to have a Windows machine if I want to do any gaming.
- jcizzle 15y ago
  When it comes to games, OpenGL is still the best option. The animation system works well for moving around interface elements in two dimensions. The animation system does not work well for 3D or when you are modifying the bitmap content of a layer on the screen. Will OSX ever catch up to Windows for games? Maybe. Some game companies take the approach of writing everything in OpenGL to make it easier to port between systems, writing a layer of native code to support their cross-platform code. However, some studios use DirectX which is windows-only. The popularity of OSX and iOS will only increase the pressure on game developers (and engine developers) to write code that is easier to port.

pace 15y ago

Isn't Google's staff working under NDA? I love the open discussion about Android's weakest point and I appreciate opinions from all side, in particular those from inside Google -- but this uncoordinated communication on G+ addressing problems w/o delivering a solution damages Android's image to some extent.

wmf 15y ago
It would be nice if Google could just say "responsiveness: we fixed it" but meanwhile I think these recent discussions are far better than the uninformed trolling that was going on before.
zyb09 15y ago
How's that heavily damaging? Google is known to be open about its workings, and I think most people agree that an engineer explaining underlying concepts is a positive thing. Putting up NDAs on every little thing is just silly and annoying.
marshray 15y ago
Did you see the part about "I’m interning with the Windows Phone team starting in January"? Still, I don't have experience with iOS devices, but my Nexus S tends to be so laggy at times that apps crash frequently. (I had attributed it to GC).
- roflharrison 15y ago
  >Still, I don't have experience with iOS devices, but my Nexus S tends to be so laggy at times that apps crash frequently. This sounds more like poorly written apps than an issue from the article. For example if you are scrolling a list view and it slows down to the point of crashing, the application probably isn't caching views or has a memory leak (application authors fault). If your device gets sluggish and you get miscellaneous force closes I would look for applications with background services that are doing more work than they should be.
jrockway 15y ago
It's an open source project. Google doesn't make any money from Android. It's just something they do for fun to advance their other business goals.

rayiner 15y ago

This is almost certainly the right answer. Synchronization/priority is the #1 culprit when people complain that a UI is "laggy." It was why BeOS was so renowned for being snappy--all rendering was done in a separate high-priority thread. It's also one of the reasons Linux has always been criticized for a laggy UI: the X server/application/window manager triumvirate isn't so much slow as it is a total mess from a priority point of view. You end up needing priority-shifting schemes UNIX doesn't have (quickly shifting priority from the WM to the app to the X server as an event flows from the X server through the WM to the app).

yellowbkpk 15y ago

The great part about Android being open source is that you can go look at the source to see that the UI thread is not a "normal priority" thread [0]. There are very few things that run at higher priority (and they're listed right there): the threads related to audio and the hardware interaction (power buttons, etc.). Last time I tried it, Android did not let you create a thread with higher priority than the UI thread. [0] http://developer.android.com/reference/android/os/Process.html#THREAD_PRIORITY_DISPLAY http://developer.android.com/reference/android/os/Process.ht...

sssparkkk 15y ago

Interesting to finally see some informed discussion about this going on. In the meantime I've scripted my Galaxy S to turn off syncing when the screen is turned on. It helps a lot to combat lag, as the phone often had the annoying (but understandable) habit of starting a sync when it was awakened by me: resulting in slowness just when I tried to use the device.

therockhead 15y ago

Hmm ... is this still an issue with dual core Android phones ? I have two Android phones, Galaxy S2 and Galaxy Nexus and both are as smooth as butter. Both feel faster than my first gen Ipad.

exDM69 15y ago
Yes. A lot of Android's rendering takes place on the CPU and a lot of it is small batches of serial work that isn't very well suited for concurrent execution on multiple cores.

deleted 15y ago

[deleted]

babebridou 15y ago

As I said in the other thread, there are two patterns, one is a Delegate pattern (IOS) where draw method lookup per pixel coordinate is trivial, and the other is a listener pattern, where view layout, composition and superposition is trivial. One is easy 98% of the time and super hard 2% of the time (iOS) and the other is relatively slow all the time but with much more potential for cross-process interactions. In Android, you can have a translucent popups from App#1 appear on top of any sort of screen of App#2. You can't have this on iOS. At all. On the other hand, animations and scrolling are blazing fast on iOS without any need for superior hardware. I honestly believe that this alone explains the "lacking" in performance that Android suffers from: it targets super high-end multi-core devices, with JIT compilers and optimizers that don't exist yet, in order to allow functionalities that are unclear to everyone of us. Shameless plug: I made an app (1) that illustrates what iOS will never be able to do. The question is, will anyone ever need that sort of app on their phone? (1) https://market.android.com/details?id=com.fairyteller.linkpreview https://market.android.com/details?id=com.fairyteller.linkpr...

saurik 15y ago
What keeps you from having a translucent popup from App #1 appear on top of any sort of screen from App #2 is not iOS's rendering architecture: it is that you are not allowed to, as one application, do any sort of computation while another one is happening. To be clear, we do this all of the time on jailbroken devices (where we have access to write apps with true multitasking, and can also just add code as required to SpringBoard itself, which is acting as the window manager): you just create a transparent UIView and put it in a new UIWindow; there are seriously no issues doing this. In the end, every UIView is backed by a CoreSurfaceBuffer (I think "Core" got renamed to "IO" at some point, if you look this stuff up), which are managed by a kernel driver that allows processes to pass these buffers (which may be backed by video, not system, memory) to each other, and in the end they mostly composited (with alpha blending) in hardware.

pragmatic 15y ago

Can someone explain what is "laggy" about android? I have a Droid bionic (second Android phone) and a Kindle Fire. What lag should I be suffering?

usaar333 15y ago
Can't speak for the bionic, but on a Kindle if you scroll in a webpage, you will notice a very low framerate. It is far less smooth than on, say, an iPad. Other lag is also present in the initial part of scrolling. Android takes a bit longer than iOS to respond to your fingers' movements. Its on the order of milliseconds, but it is noticeable if you compare it to an iOS device.

nkoren 15y ago

Good article! But I have to question the default assumption that iOS isn't laggy. I'm using an old iPhone 3G and it has become laggy as hell over the years. Scrolling on a web page is only ever smooth once a page has finished rendering -- and often not even then. The map application has become so laggy as to be completely unusable; every scroll or keypress takes 20-30 seconds to register (not exaggerating). Installing an app more or less bricks the UI throughout. I'm sure that these problems do not exist on modern iOS hardware -- but on that basis, the only fair comparison is with modern top-of-the-line Android hardware. (In other news, I just ordered my Galaxy Nexus yesterday and am rather looking forward to it. Can you tell?) The trick is that there is effectively only ever one model iPhone / iPad at a time -- so right now it's the 4S, for example, that captures all the mindshare and forms the basis of comparison. Legacy iOS devices simply cannot keep up, and certainly do not maintain the buttery-smooth experience that people identify with iOS. But nobody appreciates this, because legacy iOS devices aren't an active force on the market. Android devices, meanwhile, come in many hardware configurations, some of which are much more analogous to my old laggy 3G than to the latest iOS hotness. This isn't an excuse: it just means that Android has set a harder task for itself than iOS has. But that's no reason not to succeed at that task. 15 years ago, my hand-built BeOS box gave me an unbreakably buttery UI -- even during obnoxious geek demos such as simultaneously playing 30 different videos in 30 different windows -- so there's no reason that ANY computing device, even a very cheap one, should not be able to match that performance today. This article gives a good insight into how Android is failing to do so, and what some of the solutions might be.

twoodfin 15y ago
> 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 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.