This chapter is from the book

The second part of the book covered the full app development process starting with simple ideas and wireframes, turning those into designs, implementing the designs, and tying everything together with beautiful animations. Throughout the process, you relied on users to provide continuous feedback. With all the core work done, most developers consider the process done, but there are a lot of advanced techniques to learn and implement including analyzing and improving the efficiency of your layouts.

Identifying Jank

Unfortunately, development is never as easy as write it once and everything is perfect. In addition to typical bugs that cause the app to crash or misbehave, you’re also going to have performance issues to figure out. When you scroll a view and it seems to stutter or hiccup, dropping frames, the experience is bad. These hiccups are sometimes called “jank,” which is the opposite of smoothness. You want your app to be as fluid as possible, so eliminating jank can significantly improve the feel of your app.

In many cases, you will see jank but not know what is causing it. For instance, the implementation of the custom view which blurs a portion of an image in the woodworking tools app might be smooth on one device and not smooth on another, causing jank each time a new set of tool images comes into view. What’s going on here? If you have difficulty seeing jank, an easy way to help visualize it is by going into the developer options of your phone and turning on Profile GPU rendering (the past few versions of Android have the “On screen as bars” choice so that you don’t have to grab the output from adb). Go back to the app and scroll around for a bit. A graph of the rendering time will be displayed on top of the UI. The X-axis represents rendering over time and the Y-axis represents the amount of time taken for a frame. The horizontal green line is the limit (16 milliseconds); anything above that line means something is taking too long and causing jank. Figure 10.1 shows an example.

You should notice that there are multiple graphs on the screen; one for each “window.” One represents the status bar, one represents the navigation bar, and one represents the visible application. Some devices will show the navigation bar and application graph on top of each other, like in Figure 10.1, but you can discern between them by interacting with the app and watching the graph draw itself. The bars are also made of three colors. The purple at the base is used to indicate the draw time; this is the process of converting your draw commands into what’s called a display list. A display list is a group of OpenGL commands that have been compiled for execution. Once that’s done, the renderer has to execute the display list by communicating with the GPU, represented by the red. At the top of each line is an orange cap. Typically, that cap is small because it represents the amount of time the CPU is waiting for the GPU to acknowledge the commands, which is nearly always fast if you’re not doing any custom GPU work.