Garbage collection in Android is another performance bottleneck. ICS "fixes" this by allowing the garbage collector to run on a different thread but imo that's
a kludge.
Garbage collection has never had anything to do with poor UI performances, and everything to do with making poor code stutter. When the GC starts hitting your framerate, it means you are creating far too many objects and far too frequently. Before ICS, android implemented the incremental GC that runs more often but for "negligible" sub-1ms lengths.
If you absolutely need 60fps, make sure the GC never gets to do any work and start monitoring your own memory through buffers, just like you would in any other language.
Garbage Collection very slow on Android with latest stable line http://groups.google.com/group/v8-users/browse_thread/thread...
How can I avoid garbage collection delays in Java games http://stackoverflow.com/questions/2484079/how-can-i-avoid-g...
Avoiding garbage collection for smooth 2d animations Options
http://groups.google.com/group/android-developers/browse_thr...
Image tiling on Android, garbage collector slows down http://stackoverflow.com/questions/7916021/image-tiling-on-a...
Nothing beats primitives and buffers - the performance gap between the two methods is huge, that's true, but it's not a showstopper.
I don't recall gcs in other processes hurting my apps performances though. With that said, if I'm going to write a game, I'll make sure none of the threads in my process will trigger a GC past the loading/splash screen. This means no instanciations of any additional iterators, collections, Strings... The overhead of allocations is almost as bad for the framerate as the GC anyway.