Performance in Android — Part 1

If you are reading this post, it is probably because you are finding issues with the performance of your app. As developers we don’t think about the performance until we notice it. But don’t worry, in the following paragraphs you will find some advice that I hope will guide you and help to identify and, hopefully, fix them.

How do I know if I have performance issues?

First of all lets define the consequence of most of your performance problems, “jank”.

As you might know, the system will attempt to redraw your activity every 16 milliseconds to achieve 60 frames per second. This number comes from the device’s hardware, which defines how fast the screen can update itself in a single second. For most devices, this attribute will be 60 hertz: 1.000 ms/60hz = 16.66ms/frame. Voilà! So, during this 16.66 ms windows the application should have everything ready to update the screen.

Lets say that you miss this window because the application takes 24 ms doing some calculation this will result in a dropped frame. If that happens the application will not refresh the screen. Imagine if this happen during an animation, the user will see a laggy animation and you will have jank in your application.

‍

In general, all the applications which suffer performance issues have the same problem, a big piece of work which takes more than 16 milliseconds and blocks the screen from being updated.

Identifying your problems

This can be one of the hardest parts. Obviously there is something wrong with your app, but how can you find out? Lets start classifying the problems that you might face:

• Rendering issues.
• Compute and memory issues.
• Battery issues.

In this post I will focus on the first type and leave the other two for future entries (there is content enough to write a book about that!). Rendering issues are the easiest to identify and fix, but before we start, it’s important to have a brief understanding of the rendering process in Android.

Android rendering pipeline

The Android rendering pipeline is broken up into two key components, CPU and GPU. Each of these components perform different tasks and all of them are related as shown below:

All these operations are executed sequentially, which means that when we invalidate a View, the CPU has to invalidate it, measure the new View, repositioning it in the Layout and process the display list before the GPU can rasterise it and convert the UI objects into pixels on the screen. If you want to understand a bit more how Android creates and draws the UI elements I recommend to take a look at the android developers site. Because these tasks are executed sequentially, it is important to understand that it is not the same to invalidate a view and to rasterise a display list.

Rendering issues

Coming back to the problems that we can find on the CPU side, the most common one comes from unnecessary layouts and invalidation. This means that we are spending too much time invalidating too much of our view hierarchy and needlessly redrawing.

If we take a look now on the GPU side, we might face an overdraw problem, which is when we waste GPU processing time colouring pixels that end up getting coloured over later.

All this CPU and GPU extra time that we are spending drawing unnecessary layouts, redrawing views (if we invalidate them) and overdrawing can move us out of this 16ms windows and creates an undesirable user experience

Facing the overdraw

Identifying an overdraw issue in our apps is as simple as enabling the option “Debug GPU Overdraw” under the developer options screen. This option will open a pop up where we will select “Show overdraw areas”. If you never enabled this option before don’t panic! All the crazy colours that you are seeing on the screen are indicators of the amount of overdraw on the screen.

• True colour: No overdraw.
• Blue: Overdrawn once.
• Green: Overdrawn twice.
• Pink: Overdrawn three times.
• Red: Overdrawn four or more times.

The overdraw appears as a result of applying unnecessary backgrounds to ours Views.