A few Google+ posts by a Google Engineer and by a former Google intern and soon-to-be Microsoft intern correct poor “facts” and shed some light on why Android’s user interface isn’t as smooth as iOS‘s. The reason may not be what you think it is.
Dianne Hackborn, an engineer at Google, hopped on Google Plus to set straight some of the misinformation that’s been floating around about Android.
She says that some form of hardware acceleration has always been utilized by Android, since Android 1.0. This includes window compositing, menu transitions and pop-ups, the notification bar’s animation, and some others.
However, prior to Android 3.0 – “Honeycomb,” the tablet-targeted OS – drawing inside of a window was usually software based, and hardware acceleration wasn’t needed to get 60fps frame rates. Honeycomb changed things to add more prevalent hardware acceleration options to developers. Android’s newest version, 4.0 or “Ice Cream Sandwich,” hasn’t made drastic changes except that hardware acceleration is on by default now.
A key fact of the debate of Android performance has been the use of hardware acceleration. Hackborn describes why using it isn’t really as ideal as people think it is:
Hardware accelerated drawing is not all full of win. For example on the PVR drivers of devices like the Nexus S and Galaxy Nexus, simply starting to use OpenGL in a process eats about 8MB of RAM. Given that our process overhead is about 2MB, this is pretty huge. That RAM takes away from other things, such as the number of background processes that can be kept running, potentially slowing down things like app switching.
Overall, Hackborn sets quite a few facts straight in her long post. Be sure to check it out.
Andrew Munn, a former Google intern and soon-to-be Microsoft intern, took Hackborn’s facts and aimed to explain why Android doesn’t provide as smooth of a user interface as iOS, WebOS, or even Windows Phone 7.
RedmondPie summarizes Munn pretty well:
UI rendering processes in iOS occur with dedicated threads with real-time priority whereas on Android, UI rendering processes occur along with the main thread with normal priority. Whenever an iOS devices detects touch, it stops other processes and focuses all attention to rendering the UI. Android devices don’t do this, instead general processing and UI rendering occurs concurrently which results in choppy UI.
Munn states in his disclaimer that he has tried to do as much research as he can, but he did not work on the Android framework, nor has he gone through Android’s rendering source code.
If you’re more interested, be sure to check out the original posts linked below. They contain quite a bit of valuable information, especially considering that Android’s lack of smoothness is one of its biggest criticisms.