Exceed the Android Speed Limit!
When it comes to goals or benchmarks for app performance, there is really only one. Does your app consistently draw the screen fast enough so that your user sees smooth, fluid motions, transitions, and responses? It turns out that for that user experience, your application has to do all its work in 16 milliseconds or less for every single screen refresh.
How did we come about this number?
Human eyes and 16 ms per refresh
The human brain receives and processes visual information continuously. This allows us some cool tricks. For example, when still images are displayed to follow each other fast enough, we perceive them as motion. A flip book is a good example that’s just at the edge of perception.
- At about 10–12 pages per second, there is clearly motion, but you also retain awareness of individual pages.
- 24 pages per second allows the human eye to see fluid motion, thanks to technologies such as motion blurring, which help you perceive motion when you should just see each individual frame of the animation. 24 images per second is a sweet spot for the film industry, since it’s fast enough to show motion, but cheap enough to produce films on a budget.
- 30 pages per second is sufficient, but not life-like. It is enough for movies, but without fancy cinematic effects, it’s not convincing.
- 60 pages per second is ideal, as most people see this as high-quality, smooth motion.
This measurement of “pages per second” is called “frame rate” or “frames per second” in the computing world. And while it’s important to understand how frame rate leads to smooth motion, it’s not the whole story. The human eye is very discerning when it comes to motion inconsistencies. For example, if your app is running on average at 60 frames per second, and just one frame takes much longer than the preceding ones to display, users will notice a break in smoothness that is generally called “hitching”, “lag” ,“stutter”, or “jank.”
Computer hardware and 16 ms per frame
Most modern mobile devices refresh their display at 60 frames per second. This number is dictated by the device’s hardware, which defines how many times per second the screen can update. (And of course, the hardware is built to successfully play make-believe with the human eye.)
To match the hardware screen’s 60 updates per second, the system software attempts to redraw your current app activity every 16 milliseconds
(1000 ms / 60 frames = 16.666 ms/frame). And therefore, your app has 16 milliseconds, to update each frame.
And that’s 16 milliseconds TOTAL. The system also has to take time to draw, respond to intents, and handle input events, just to name a few. The big picture is that your app is sharing these 16 milliseconds with a lot of other subsystems on Android, so don’t plan on owning all of it.
If your app takes too long and does not finish its calculations in 16 milliseconds, you get what is called a “dropped frame”, and, yes, you already know it. JANK!!
You, your app, and 16 ms per frame
As an app developer, you must keep your app consistently at 60 frames per second, and 16 milliseconds per frame, throughout your user’s experience, to avoid jank.
To get cold, hard data on your app’s rendering performance, use the Profile GPU Rendering tool on your device to discover when and how your app drops frames — we’ll get into the nitty gritty of that in future articles. But if you are in a hurry to make your users happy, you can check out the Android Performance Profiling Tools documentation right now.
For a more entertaining version of this section, watch Why 60 fps, which is part of Android Performance Patterns on YouTube. If you want to jump ahead, check out the Android Performance Course on Udacity. But most importantly, join our Android Performance G+ Community for great tips about, you guessed it, building performant Android apps.
