I find that piece pretty interesting: "The "choppiness" and "lagginess" you are mentioning are more often related to heavy
garbage collection than drawing performance.".
Wasn't that supposed to be a thing of the past with modern garbage collectors?
I also thought so, but maybe not with mobile devices with limited memory? I always thought thought it was strange to disallow GC in ObjC on iOS, but they might have tried it with less than stellar results.
I stopped experiencing this once my device was upgraded to Android 2.2. It's much smoother. I'm not sure if this is because of the JIT or some other new feature, but I'm guessing you've used older versions of Android.
I sometimes wonder how much more elegant our solutions to computing problems would become if transistors per integrated circuit stopped increasing exponentially.
It's the downside of all GCs, and I've yet to see one that alleviates it.
It does seem likely that it is GC issues and not whether the GPU is used or not: The visual choppiness is completely inconsistent, lending itself more to brief thread stops for GCs than to any sort of CPU starvation.
On the bright side, it is far less common on 2.2 than before. It still is by no means a deal breaker, but pretty much every user of both the iPhone and Android makes note of the much more consistent smoothness of the former.
I bet Android has a lot of room to improve not just by improving garbage collection but by decreasing garbage creation. The compiler can do a lot of optimizations to reuse objects instead of allocating new ones. I don't know what the state of the Android JIT is, but Sun's JIT took many years to incorporate some basic-seeming optimizations.
One thing that could be done in the meantime is to rewrite performance-sensitive Android UI code in a way that eliminates object allocation. In Java this would result in horrifying code, but it might be worth it, and they wouldn't necessarily have to use Java.
Windows phone 7 seems super smooth and has a gc. But Microsoft has modified to gc behavior to limit interruptions. There is no reason the gc needs to be firing during ui scrolls. Google should be able to do the same. From http://blogs.msdn.com/b/abhinaba/archive/2010/07/29/windows-... :
1. GC is not run on some timer. So if a process is not allocating any memory and there is no low-memory situation then GC will never be fired irrespective of how long the application is running
2. The phone is never woken up by the CLR to run GC. GC is always in response to an active request OR allocation failure OR low memory notification.
3. In the same lines there is no GC thread or background GC on WP7
Android's GC is very aggressive. Further, pretty much everything is an object, so it's constantly being worked.
I would save judgement on Windows Mobile 7 until it really is running various apps and doing active day to day work. A fresh Android phone is very smooth. Once you have it checking all of your accounts, have twitter and facebook feeds and dropbox running, rdio in the background, etc, the demands on the GC are much higher.
Wasn't that supposed to be a thing of the past with modern garbage collectors?