Fairly or unfairly, Google's Android often gets
knocked for having a lagging or stuttering user
interface when compared to Apple's iOS on iPhone
and iPad. TiPb's previously guessed that this
stemmed from very early architectural decisions
made by Apple, who had a full screen, multi-touch
UI -- albeit it a highly limited one -- in mind from the
outset, as opposed to Google who originally had
Android set up as a BlackBerry, Windows Mobile
Standard, and Nokia competitor that had no need
for high performance, sophisticated UI rendering.
That might turn out to be pretty much the case. In
response to a Google+ post about hardware
acceleration by Android engineer Dianne Hackborn,
ex-Google intern Andrew Munn breaks down why
Android's way of handling graphics and event
processing hinders the OS from offering users a
more fluid, lag-free UI.
Android UI will never be completely smooth
because of the design constraints I discussed at the
beginning:
UI rendering occurs on the main thread of an app
UI rendering has normal priority
The iPhone changed things by introducing a
dedicated thread with high priority for handling UI
rendering, redirecting all power (CPU and GPU) to
handling UI element rendering in realtime based on
touch input. The result? Smooth-as-butter UI
elements, transitions and animations as soon as you
touch the screen -- even on older hardware when
paired with the latest iOS 5 software. The
drawback: everything else, from app downloads to
content rendering will pause so the UI can keep
that high frame rate, high quality redraw pace.
Munn does disclose that he was only an intern with
Google's Android team and never actually got his
hands on the raw Android source code, so this could
be taken as supposition.
Indeed, our own resident Mobile Nations Android
guru, Jerry Hildenbrand from Android Central says
there might be a bit more to it:
The way it stands now, as long as you have free
resources to run multiple UI threads [in Android]
the UI is amazingly smooth -- easily as smooth as
the iPhone or WP7 phones. Problem is that nobody
sets resource management up in a way to keep
them free. A simple customization to the linux
lowmemkiller kernel parameter fixes it, at the
expense of huge memory hogs like Facebook or
HTC applications. One day, when we have Octocore
12NM Cpu's, DDR3 RAM, and huge batteries this
way will prove better. For now, you have to hack at
it.
So Android can be set up to prioritize UI, if that's
what's wanted, but it's not automatic like iOS. That
might annoy user experience snobs, like our friends
on the Iterate podcast but it might be a fine tradeoff
for those with other priorities, like the big screens,
different skins, and high customizability that
Android's design does allow.
But if you ask lots of xda developers this Question they will tell you iphone is just a bunch of wallpapers other than android with lots of apps and stuffs that is rendered by the cpu and Gpu in background and main thread, so iphone has nothing to render other than wallpapers, so when you get an iphone and install 20 or more apps on it then you start experiencing some glitches on the UI.
Source : later!

hmmm....android rocks, ios sucks

Teamandroid#

Team Android

Once Upon A Time, It Was A Man's World

Now...

It's A Droid's World