The truth about Android & iOS UI performance(blog.crazybob.org)
blog.crazybob.org
The truth about Android & iOS UI performance
http://blog.crazybob.org/2011/12/truth-about-android-ios-ui-performance.html
1 comments
In the apps I've written, it's not common for timer and/or I/O events to come into the run loop during an animation. Hardware acceleration will make a much bigger difference. Romain measured a 1000X performance improvement in one case: http://atnan.com/blog/2011/11/10/ios-vs-android-ics-hardware...
I/O in the main thread and GC are also common culprits. StrictMode is helping with the first. The latter was improved in Android 2.3 with the concurrent garbage collector. There are still more improvements that can be had there, but like I said, HW acceleration is the biggest win. When apps start optimizing for HW acceleration, allocations will likely decrease (because the apps won't be re-drawing on every frame), and GC overhead will become even less of an issue.
I/O in the main thread and GC are also common culprits. StrictMode is helping with the first. The latter was improved in Android 2.3 with the concurrent garbage collector. There are still more improvements that can be had there, but like I said, HW acceleration is the biggest win. When apps start optimizing for HW acceleration, allocations will likely decrease (because the apps won't be re-drawing on every frame), and GC overhead will become even less of an issue.
Hardware acceleration is a huge boost, but the main remaining problem with Android is stutter. This is where run loops really help.
As you say, I/O in the main thread and GC are central causes. Both are problems that Apple doesn't have, because of run loops and manual memory management respectively.
Also, the focus on multithreading the heck out of everything is not the way to go. There is real, substantial overhead to having multiple threads. Run loops are such a powerful tool precisely because they let you keep everything on the main thread (avoiding context switch overhead) while giving you an easy way to prioritize UI when needed (event tracking mode).
As you say, I/O in the main thread and GC are central causes. Both are problems that Apple doesn't have, because of run loops and manual memory management respectively.
Also, the focus on multithreading the heck out of everything is not the way to go. There is real, substantial overhead to having multiple threads. Run loops are such a powerful tool precisely because they let you keep everything on the main thread (avoiding context switch overhead) while giving you an easy way to prioritize UI when needed (event tracking mode).
In addition, when scrolling, iOS's main thread goes into a "tracking" mode where it filters out certain types of events that might result in redrawing or other performance degradations
He calls it tracking mode; the full name is a "run loop mode"—specifically, UIEventTrackingMode. When you're scrolling or zooming or transitioning a view, the main thread restricts which actions are performed: timers do not fire, sockets are disabled, and many other tweaks. This is why animations on iOS are so smooth (in my opinion).