And this is somehow further evidence of Google's incompetence (and/or lack of taste) rather than just the obvious result of a bunch of engineering tradeoffs that, if you look at Android marketshare and Google's resultant influence on the future of the web, seem to have worked out quite well for them.

[1] http://code.google.com/p/android/issues/detail?id=6914#c1

The side effect of having all that extra CPU is that, when not running the core Android UI (e.g. a game written mostly in native code), a lot more power is available to developers.

If you allocate objects in a user interface loop, you will force a periodic garbage collection, creating little "hiccups" in the user experience. The concurrent collector introduced in Gingerbread helps, but unnecessary work should always be avoided. http://developer.android.com/guide/practices/design/performa...

Why should I avoid garbage collection? When Dalvik does a GC, most of the time your game will have to wait until the garbage collection is complete. It will often take in the order of 100 milliseconds to complete. Doesn’t sound like much but in your game loop this is huge – causing a horrible stutter or lack of responsiveness. http://fanitis.com/2011/02/09/android-game-performance-garba...

Garbage collection and async operations frequently block UI rendering. http://www.satine.org/archives/2011/01/01/the-care-and-feedi...

Android Garbage Collector Slow Down http://stackoverflow.com/questions/6742314/android-garbage-c...

I'm performance tuning interactive games in Java for the Android platform. Once in a while there is a hiccup in drawing and interaction for garbage collection. Usually it's less than one tenth of a second, but sometimes it can be as large as 200ms on very slow devices. http://stackoverflow.com/questions/2484079/how-can-i-avoid-g...

iOS/Obj C does not do automatic garbage collection specifically for this reason (and battery life).