Via slashgear
-----
Recent Google engineering intern Andrew Munn has launched into a detailed explanation on Google+
as to why many Android devices are significantly more sluggish and less
responsive in terms of user interface and experience than comparable
iOS and Windows Phone 7 devices. The root of the problem? Inoptimal
priority queuing on Android OS. On one side, iOS has graphics rendering
queued as a real-time priority, thereby letting users self-manage which
priorities are to be rendered in the background. On the flip side,
Android views graphics rendering as a normal priority. As a result,
Android devices tend to become more sluggish when they’re trying to
perform other tasks simultaneously.
The gist of the problem boiled down by Munn:
It’s not GC pauses. It’s not because Android runs
bytecode and iOS runs native code. It’s because on iOS all UI rendering
occurs in a dedicated UI thread with real-time priority. On the other
hand, Android follows the traditional PC model of rendering occurring on
the main thread with normal priority.
Munn also broke it down in real world terms by providing the example
that if you put your finger on the screen of an iPhone or iPad and move
it around when it’s halfway through loading a complex web page like
Facebook, all rendering stops instantaneously. The website will
literally never load until your finger is removed, and this all boils
down to the fact that the “UI thread is intercepting all events and
rendering the UI at real-time priority.”
There are also some other reasons, like inoptimal hardware. The
NVIDIA Tegra 2 CPUs ubiquitous to many Android 3.0 tablets and some
phones suffered from low memory bandwidth and lacked NEON media
instructions, both of which ultimately presented a bottleneck to the
Android user interface and experience. However, Android 4.0 remedies
this by having graphics hardware acceleration, although as long as
graphics aren’t given top priority (a la real-time), platforms like iOS
or Windows Phone 7 are always going to be more fluid.