November 29, 2014

The Android Evolution, Chapter 1: A Smooth Experience

manu-cornet-bugdroid-cartoon-android-evolution-key-lime-pie-600x202

Welcome to the first chapter in ‘The Android Evolution‘, a series in which we discuss what improvements have been made to Android and what could further be implemented in order to improve our beloved operation system. In the first episode we will discuss how Google has improved Android in terms of offering a smooth and fluid user experience and what changes were made in order to accomplish this goal. Without further ado, let’s dive in now, shall we?

Where’s my GPU?

One of the major flaws Android had to deal with until Honeycomb came along was the lack of GPU acceleration for the UI. This caused people to complain about Android being sluggish and slow, a flaw mostly used when comparing high-end Android devices to Apple’s iPhone. One thing Apple did very well with the production of the first iPhone was making sure the device felt fluid in use. It may not have been the fastest in terms of actual speed but it felt like it was substantially faster than it’s competitors due to a fluid UI operation.

Manufacturers like Samsung managed to work their way around this issue by implementing some rudimentary form of hardware acceleration themselves but still it wasn’t enough to compete with the biggest competitor out there, the iPhone. Google realized this and implemented hardware acceleration for the UI in Honeycomb, an Android version solely made for tablets. Now I’m not saying Honeycomb was the solution to all Android’s problems because at the best it was a sign of good things to come: Honeycomb itself was terribly optimized and in reality more a beta program than a finished and polished version.

Ice Cream Sandwich: Road to perfection

1533 Still, Google had to start somewhere. Because Honeycomb was designated for tablets  only, it became obvious the company was working on a newer Android version for both  phones and tablets, merging the best of both worlds into one new version: Ice Cream  Sandwich. I’ll honestly say I was kind of hesitant to try out Ice Cream Sandwich because I  owned a Honeycomb tablet back then and let’s just say it wasn’t exactly a clear competitor  to the iPad. In some terms it was, yes. Multitasking was superb or at least the UI for it was,  the actual speed of switching between apps was disappointing to say the least, probably  partly due to the slow Tegra2 processor which virtually all Android tablets were running on.

 Boy was I wrong, Ice Cream Sandwich was the best thing that had ever happened to my  tablet. Even the unofficial builds I installed which were labeled pre-beta were smooth as  butter. I also bought the Galaxy Nexus when it came out and even though it had the same  specifications as quite a few older phones it was labeled by me and many other reviewers  as possibly the best phone out there at the moment. Still, Google was not satisfied.

Smooth as butter

In Android 4.1, Jelly Bean, Google went one step further and introduced Project Butter. The name already spoils the contents of Project Butter but for you ignorant folks out there, it consisted of a bunch of optimizations to make Android feel smooth as – you probably guessed it – butter. I’ll try to explain them briefly. There were three major improvements: Vsync, triple buffering and touch responsiveness.

google-project-butter

Vsync locks the amount of frames your phone shows to the maximum refresh rate of your phone’s display. This may sound a little complicated but what it basically means is this: Your display can output a certain number of images per second, usually 60, and Vsync makes sure your phone always outputs this amount of frames. There’s no need to produce 100 frames per second if your display can’t show them and it might cause screen tearing so Vsync takes care of this issue for you. This also works the other way around, so if your phone has trouble keeping up it will no longer visually lag, there will always be 60 frames per second shown on your screen.

Triple buffering allows your CPU, GPU and display to work together better. It’s pretty hard to explain the exact mechanics behind this but a real life comparison should do the trick. Let’s say you’re hosting a party and have to make coffee for your guests. There are multiple ways to do this.

The first way is putting a cup under your coffee machine and then bringing it to your guests one by one. It’s possible but it will take forever. The second way is putting a new cup under the coffee machine before you bring the first cup to a guest so when you come back for a new one, it will be done and ready to be delivered, allowing you to finish this task much quicker. Your coffee machine will run out of coffee and water at one point and thus slow you down because you have to refill everything. Now let’s say you ask one of your guests to refill the machine when it runs empty: This is kind of comparable to triple buffering. In essence, triple buffering just means better cooperation between different parts of your phone.

The touch responsiveness part is the easiest to explain but quite possibly the hardest to develop. Google developed a mechanic that predicts where you are most likely to put your finger next on the screen, allowing your phone to get ready for that tap, making the action that is behind it much faster to load. Vsync was also used to improve touch latency by anticipating where your finger will be at the time of the next screen refresh. Last but most certainly not least, your phone runs at lower speeds after a certain period of inactivity in order to save battery life which is a good thing for battery life but it can also cause some unresponsiveness. Jelly Bean uses a feature described as CPU input boost, which makes your phone run faster when you touch the screen, avoiding lag because of your phone running at lower speeds.

There are however certain features such as GPU acceleration which need to be implemented in apps too in order to work properly. At the time Honeycomb was released, GPU acceleration was a new thing and very few apps were coded to properly use this new feature. The consequence was that although Honeycomb supported hardware acceleration, it effectively still wasn’t being used. When Ice Cream Sandwich came out, more and more apps started getting GPU acceleration support, really showcasing the improvements Google made.

The GPU acceleration was also further perfected in newer versions, shapes and text are now being rendered at a higher quality without sacrificing any performance.

Trim that filesystem

Earlier on I spoke about my Galaxy Nexus and what a good phone it was. That’s right, I used the past tense.  After around six months, my phone started slowing down more and more to the point where it was just plainly unusable at times. Apps would randomly crash, booting took minutes, music would randomly stop playing and selecting a new track would result in waiting 20 seconds for it to actually start playing. I could name all the issues I had but the point was that there clearly was something very wrong with my phone. The first thought that came to mind was my software being outdated, so I updated to a newer version but the issues persisted even after a full data reset. Removing apps one by one to see if it had any effect didn’t work, neither did overclocking or changing the CPU governor.

After a little bit of research I discovered I wasn’t the only one having issues with my Galaxy Nexus. Dozens of forum threads describing the exact same issues I had were floating around the internet. It had to do with the internal memory of my phone. This is again something that requires further explanation, but this time it’s not as complicated and no strange comparisons are needed. Phones use flash memory, which is the same type SSDs in computers use. Flash memory is not like a hard drive, the data you store on it is not physically present like on a hard drive where the data is stored on a magnetic disc, basically the same as a CD works. Flash memory uses blocks of memory which can be either filled or empty. When you delete a file from flash memory, it is not immediately deleted. It will show up as empty space on your phone but in reality the data is still there. This means that after a while, you will have used up all the free blocks on your phone so every time there’s a change in data, your phone first needs to erase old blocks in order to overwrite them, resulting in a very slow device.

PCs with SSDs have a solution for this issue called fstrim. Trim is a command telling your device which blocks are no longer in use and can be erased, avoiding the problems mentioned above. While included in the Linux kernel on which Android is based as well, it hadn’t been implemented until Android 4.3 came along. In my opinion, this has been the best improvement Google has made so far because it made my phone perform like it had just come out of the box. It now runs automatically, preferably every night if possible, preventing you from all the issues my phone was suffering from.

 

This has been the first part of ‘The Android Evolution’. We hope you enjoyed and if you have any suggestions or comments about this article or future chapters, please let us know in the comment section down below.


  • Walkop

    Hey guys.

    This is, quite honestly, the first article I’ve read through entirely on Android Guys and been thoroughly impressed with the content. I love the Android history and the description and personal experience you gave of the platforms development over time.

    Fantastic work! Small correction, though: Project Butter was introduced with Android 4.*1*, not 4.2. Of this I am absolutely 100% sure. Otherwise, good solid article.

    Keep up the great original content!

    • Thijs Koot

      Thanks for the feedback. You’re right, it was introduced in Android 4.1, mistake on my part.

  • sexydredlocs

    Great article it actually kept me interested through to the end. Looking forward to the next installment.

  • Pingback: Whasapp Android News ToyMail: Stay connected to the kids you love | Whasapp Android News