Why Android will always be choppier and laggier than iOS

“One of the things that really stands out using an iPhone is just how smooth it feels compared to using Android,” John Brownlee reports for Cult of Mac. “Where as Android is laggy, with a measurable interim between when you touch the screen and when the OS responds, iOS almost seems to anticipate what you want to do before your finger touches the display.”

“How has Apple managed this incredible feat? A better question might be: ‘How has Google managed to screw up Android’s multitouch so much?'” Brownlee reports. “According to Andrew Munn — a software engineering student and ex-Google intern — Android is so messed up that Google might never be able to match an iPhone or iPad’s performance. Ouch!”

Brownlee reports, “Here’s Munn explaining what this all means, and why Google was stupid enough to design Android this way: ‘Work on Android started before the release of the iPhone, and at the time Android was designed to be a competitor to the Blackberry. The original Android prototype wasn’t a touch screen device. Android’s rendering trade-offs make sense for a keyboard and trackball device. When the iPhone came out, the Android team rushed to release a competitor product, but unfortunately it was too late to rewrite the UI framework.'”

Brownlee reports, “So why hasn’t Google just changed the UI framework? Well, it’s a daunting task that would involve every app on Android Market to be rewritten to support the new framework. That’s at least a year away, and may never happen.”

Read more in the full article here.

[Thanks to MacDailyNews Reader “Opportun” for the heads up.]

34 Comments

  1. Sounds like the early days of Windows, when it was “DOS” with a graphical interface thrown on top to mimic the Mac OS. So, Android is a non-touch mobile OS (designed for physical keyboard) with a touch-screen interface bolted on top.

    1. yes – this situation is windows all over again…

      kill android now – that is the answer –
      Samsung and HTC – are nothing without Android.
      Apple buys Samsung and owns the Galaxy line – sounds better.

      mark it as illegal pirated software (claiming it as freeware ain’t good enough – slam Google now Oracle) and anyone using or selling it will be imprisoned for 7 years and/or fined 750,00 USD.

    2. @ken1w: Yes, the Android mess is very much like Microsoft’s purchase of QDOS (Quick and Dirty Disk Operating System) from Seattle Computer Products and its subsequent damage to the computer community.

      Android @ Wikipedia

      ‘Android’ was created by Android Inc., who sold it to Google in 2005. The OS is a hodgepodge of code including Linux, C, Java, Webkit, and JavaScript (aka ECMAScript). As with Microsoft’s inability to innovate upon the fundamentals of QDOS (such as its incredibly crappy memory management), it appears that Google is incapable of innovating upon the fundamentals of Android. The result is clunky crudware that is in many ways just as damaging to the computer community as MS-DOS.

      Conclusion: Android proves that we continue to be in the Stone Age of Computing. Unga Bunga! Oogle Boogle Google! 😯

  2. Its always painful to when someone with little to no software development knowledge or experience tries and explain something like this. Wild assertions are usually made and this one delivered in spades.

    Some reality:

    Androids applications will not need to be rewritten, that is the point of an API – to provide a consistent ‘interface’ for software without worrying about underlying code changes having an effect on software calling the API higher up on the stack. APIs were invented to address problems specifically like this (among other things)

    Android applications are not native code executable binaries, they are Davlik bytecode packages and the Davlik virtual machine handles all memory management, threading, object lifetime and object disposal during the lifetime of an Android App.

    Google can change the thread priority of the UI without breaking existing applications. That is not to say that it would be easy, or some overnight change, I’m just pointing out that yes it indeed can be done and existing software would be just fine.

    I bring up Davlik because it offers yet another area where Google could make threading changes. Davlik at some point takes any threading calls the app makes and ‘thunks’ those down to the Android Native API threading interface. Even if a dev were trying to do something off the wall with thread priority in their app they are constrained by the runtime. So its not even a question of ‘some applications’ might work and others not. A change in the runtime is universal across all bytecode that is loaded on the VM.

    Its long been known that ByteCode does indeed incur a performance hit vs. native code. There is a compilation step that needs to be performed when processing bytecode by the JIT that just does not exist with a native code binary that is compiled to the native machine code of the cpu it is running on.

    The arguments for Native Code or ByteCode are numerous and it is not really a question of which method is ‘right’ or ‘wrong’, more like a big list of pros and cons for each one.

    Even if they introduced a new Graphics API for laughs they could still simply provide an intermediate layer that converts the existing API calls into the new ones… how do you think MS has handled many of their compatibility issues on windows over the years while still introducing new frameworks?

    It sounds like Google does not see this as a big enough issue to address , or they are spread thin .. mixed up priorities maybe… Could be any number of reasons but it surely is not the cooked up craziness this article claims it is.

      1. Thanks man.

        I should have been clear, the cooked up craziness I was referring to was the claim (I believe cultofmac made it) that this issue cannot be fixed without Google dumping the entire Android market and forcing devs to rewrite every app.

        I read Andrew’s posts and I absolutely agree about the thread priority of the UI rendering as being the cause, it makes perfect sense.

        My first experience with Android was on a very underpowered device and as I was playing with it the entire UI froze for a moment and I remember thinking “WTF this thing can’t multi-thread!”

        My current phone (droid incredible w/ custom ROM) runs very smooth but I stripped it down to the bone and only run the few things I need on it.

        1. My current phone (iPhone 4 with stock ROM) runs very smooth and I’ve got 50 Apps on it including dozens of Apps I don’t need (and several that are not available on Android).

    1. A friend of mine has an Android 7″ mini tablet. I didn’t take note of which brand or make as it wasnt prominently displayed and he had a sleeve on it which may have covered the logo. It’s a generic tablet running Gingerbread, not Kindle Fire or Nook Tablet.

      The thing that impressed me most was the usability – he could do emails on it, read ebooks and pretty much do anything my iPad could. So this notion of having to sand down your fingers is complete nonsense. Apps opened fluidly without jaggedness or lag, or none that was noticeable to me. In fact I would race him in replying to emails on my iPhone and we were neck and neck, so there’s no speed disadvantage there.

      The one thing he could do and I couldn’t was to utilize a file system to attach files to mail, something the iPhone and iPad cannot do without outside assistance through an app. What’s more he could reply to mail and attach files which to this day the iPad is unable to do.

      All this knocking of Android blinds us to the fact that Google has made great strides in improving the usability of Android and at the same time adding polish. The gap is smaller than you think.

      1. Once you hit the $200+ range the hardware starts getting decent.

        Ive tried a few $70-100 ones with resistive digitizers and found them unusable.

        Once you get into the price range of a decent android tablet the ipad is usually a stone throw away and you know you are getting the best so thats the route im going.

        When the right android tablet materializes ill prob buy one to play with.

      2. The gap is much bigger than you think, try one yourself. My feeling is that honeycomb is completely crap, I don’t want to open the task manager each 5 minutes. Couple that with delayed input, crap ware everywhere, inconsistent user interfaces. Once you start a third-party native app (game) it’s halfway decent, but the OS is terrible.

        1. I’d rather have a limited set of features that work exactly as they should and are smooth and stable.

          Sure, you can always throw on experimental features, but the issue is that you lose the polish…

    2. There is a limit to how many under the hood improvements can be made without having to deprecate existing APIs and replace em with better ones.

      New APIs would require developers to re-write their apps. Not a road easily traveled. Companies like MS, Adobe, Quark took years to move their code base from MacOS classic into OSX.

      Essentially once an Operation System is out, it gets really hard to really change.

      1. I agree.

        You can run the risk too of killing your own platform if you can’t paint a pretty picture as to why a dev should rewrite their code or provide a compelling reason.

        MS did a lot of damage with. Net to their developers and i know a couple of guys who quit windows development over that “upgrade”

  3. “When the iPhone came out, the Android team rushed to release a competitor product, …”

    You mean when Eric T. Mole first saw the iPhone in a privileged view when he was on Apple’s Board, BEFORE not AFTER the iPhone came out but before. Schmidt betrayed Apple & Steve Jobs.

    1. It shouldn’t. Usually you only get stuck altering when you introduce code that relies on specific functionality not common on a majority of handsets like netflix with its DRM.

      They def could improve android in that regard. Comparitively speaking the iOS side is cake with only a few models to code for.

      1. yeah, I intended it as more of a rhetorical comment. I am an iOS developer and it is just one more reason why I can’t visualize developing for Android.

        I don’t doubt that we will see more form factors from Apple that we will need to deal with, but I have the feeling that the SDK will make it far simpler even if there are more devices.

    1. Cut And Paste from above:

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

Reader Feedback

This site uses Akismet to reduce spam. Learn how your comment data is processed.