What I find amazing is how even a few milliseconds delay can make the difference between something seeming smooth and something seeming intolerably slow and laggy. The appearance of user responsiveness is crucially important.It says people's tolerance has gone way down :P On my new phone I've noticed the home-screen animations can get a little choppy when I go 'back' to home and scroll around, speeding up after a bit (I assume when everything is loaded). However, I don't really care that much.
The thing I find most interesting about the walled garden metaphor in mobile development is that what came before it was prison visitation, not freedom. The grim days of flip-phones running crap Java ports of Pac-Man that you paid $4.99 to rent for a month? Those were like six years ago.Hah! I actually emailed my carrier at the time (US Cellular) about potentially writing some apps for the phone I had at the time. It was my first phone with a color screen and ran BREW apps.
Youtube buffers frequently, and for no apparent reason decaches and stutters when going to & from windowed to full-screen.What's worse is that it depends on the video you're watching. Some load slowly, while others load right away even at 1080p.
Java has never done graphics particularly efficiently sadly.That's not really true. Java's Swing GUI framework was slow, but if you're doing raw 2d graphics it's fine (so is OpenGL with jogl). Android doesn't use Swing, so that's a non-issue. Also android converts java into another bytecode format before it runs.
Anyway you guys are right nobody writes an app with worker threads from the start, it just makes everything a pain in the ass to debug.Um… I do. Actually, the major java program I wrote was a space-invaders style video game where each sprite had it's own thread. I had no idea what I was doing, but I was a big fan of threads :)
Anyway you guys are right nobody writes an app with worker threads from the start, it just makes everything a pain in the ass to debug.Oh, also I've only written one single program for android. It was a counter. You ran the program and it showed a counter that counted up every 10ms. I used a worker thread to do the counting and updated the UI using (I just looked up the source) android.os.Handler way to inject stuff into the UI thread.
When user input and background processing are going on at the same time, iPhones give a higher priority and more processor cycles to the user input, Android gives more to the background processing.That's not exactly true. It sounds like this Andrew Munn guy was just blowing smoke out his ass. You can make stuff go fast with any threading model provided you're really careful. It sounds like the guys who wrote the browser on iOS were, while the android browser developers made other trade-offs (using an OpenGL display list rather then Tiles)
However, I believe the rewrite must happen, despite the downsides. As an aspiring product manager, I find Android’s lagginess absolutely unacceptable. It should be priority #1 for the Android team.I mean, a college kid who worked on this project as an intern is saying Google needs to do a comparability breaking rewrite (likely the old API would be there, but like windows with tons of cruft, it would just end up as bloat so old apps would work, while new ones wouldn't be backwards compatible) in order to get a few extra frames that Moore's law might handle anyway.
« Older Amalgamation, an animation by Micaël Reynaud... | Keeping wildlife, an amphibiou... Newer »
This thread has been archived and is closed to new comments
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.
Good read, thanks.
posted by Blazecock Pileon at 2:42 PM on December 6, 2011 [1 favorite]