Ughh! Android & microstutter!

[random_guy#WN]

Just got the HTC One today...First off, I love the hardware. I have haven't been this marveled by a phone (hardware) since the release of the iPhone 4.

But what's up with Android and the microstutter? HTC did a fantastic job with the software. The default HTC apps are extremely fluid and do not stutter at all. However, Sense has been like this since I had the Evo long ago. Comparing app for app to the iPhone 4S, just about all the non-HTC apps stutters a bit...Facebook, Google+, YouTube, Yelp, etc...

I admit that I am a bit OCD, but I am a bit disappointed that after all the hardware advancement we still have apps microstuttering. Was anyone else on the same boat but eventually got over it because the rest of the phone is so fantastic? (I know I just got it so I will obviously give it a little more time).

 

[BigHonu]

I came from an iPhone and do admit that the animations are not quite as fluid. 'Microstutter' seems to sum up what I see pretty well.

Still, it hasn't affected how I use the phone. All the apps work as they should. I honestly don't notice it anymore unless I've been using an iPod or similar previously.

Posted via Android Central App

 

[Grizzly_Atoms]

Coming in as a 5 year iOS user I will agree that the scrolling and app performance at times is not quite up to the iOS level, but the tradeoff for the bigger screen and more freedom is worth it for me. I was wondering whether Apple owns some proprietary patents that Android has to work around and this is the result...?

 

[zkSharks]

Android made a huge leap with 4.0-4.2 as they started incorporating hardware acceleration into the UI, meaning that the primary Android UI is rendered with the GPU rather than the CPU. With Android, there's typically more going on in the background than there is on iOS. As a result, when you throw in a manufacturer overlay (even a fairly well-performing one) such as Sense, add in some third-party apps doing their multi-tasking and background service actions, it adds up.

Apple has the advantage of complete hardware and software control, which is something that Google does not have. Apple can write iOS to function extremely well on their hardware, while Google is building an operating system that runs on many different hardware platforms. Enabling near-perfect hardware-dependent accelerated rendering that works on these different platforms isn't nearly as easy. It's improving, though, and it's improving quickly. For instance, the new Hangouts app definitely had some of that aptly-named 'microstutter' with the slide-out drawer. They released an update a day or two ago that has all but removed it for me, and I'm running it on a Galaxy Nexus ? hardly the superphones that the One and S4 are.

Here's a bit more detail on Project Butter and what Google has done to improve Android's performance, courtesy of Engadget:

Project Butter lets the CPU and graphics run in parallel, rather than crash into each other, and has a big impact on both real and perceived speed: the entire interface runs at 60 frames per second on sufficiently fast hardware. Graphics are now triple-buffered to keep scrolling and transitions humming along, and the processor will swing into full gear the moment you touch the screen to keep input lag to a minimum.

 

[mrbootcrm]

Coming in as a 5 year iOS user I will agree that the scrolling and app performance at times is not quite up to the iOS level, but the tradeoff for the bigger screen and more freedom is worth it for me. I was wondering whether Apple owns some proprietary patents that Android has to work around and this is the result...?

I'm pretty sure it has something to do with app developers having to make their app compatible with many different hardware specs. It's kinda like how Windows programs can seem less fluid than Mac. This is why the native HTC apps are butter smooth. Because they were written for the One and no other phones.

 

[zkSharks]

I'm pretty sure it has something to do with app developers having to make their app compatible with many different hardware specs. It's kinda like how Windows programs can seem less fluid than Mac. This is why the native HTC apps are butter smooth. Because they were written for the One and no other phones.

That's true in some ways and not in others. For standard app development, everything you need to use to build the app is provided through Android's built-in SDK and APIs. This means that you develop the app for Android, not for the specific hardware it runs on. This makes simple app development relatively easy; the hardest part is accounting for different screen types, but Google has made advances in that area as well, such as with the Fragments UX approach. It allows you to build your UI as fragments, which are then displayed in different ways depending on device specs. On a tablet, a list may be displayed alongside a 'detail view'. Selecting a list item changes said detail view. On a phone, the list takes up the full Activity (app window), and selecting a list item causes the detail view to appear. The following image illustrates this:

Even when you're talking about apps that manipulate audio/video, or require complex graphics rendering (such as with most mobile games), Android provides ways of performing these tasks with hardware acceleration regardless of the hardware that the app ends up installed on. However, there's a caveat. While the apps that HTC built for the One may not require hardware-specific coding (with the exception of the IR and camera applications), they were still built and tested on the One. This means that HTC made sure they ran well enough on the One before shipping.

To some people this is just splitting hairs, so to speak, but the important distinction is between writing hardware-specific code and writing code that runs well on said hardware. My guess is that HTC's bundled apps lie more in the domain of code that runs well on the One, with occasional hardware-specific code (as I mentioned for the IR/Camera stuff).