Tracking jank

To ensure smooth operation of your app, you should aim to target 60fps (16ms/frame). If your app doesn't meet the required frame rendering time, the system is forced to skip frames and users perceive this as the app stuttering. This unsmooth interaction due to missing screen frames is known as jank. For more information on this experience, see Slow rendering.

Relationship between slow frames, frozen frames, and ANRs

Slow frames, frozen frames, and ANRs are all different forms of jank that your app may encounter. See the table below to understand the difference.

	Slow frames	Frozen frames	ANRs
Rendering time	Between 16ms and 700ms	Between 700ms and 5s	Greater than 5s
Visible user impact area	RecyclerView scroll behaving abruptly On screens with complex animations not animating properly	During application startup Moving from one screen to another (for example, screen transitioning)	While your activity is in the foreground, your app has not responded to an input event or BroadcastReceiver (such as key press or screen touch events) within five seconds. While you do not have an activity in the foreground, your BroadcastReceiver hasn't finished executing within a considerable amount of time.

Tracking slow frames and frozen frames separately

When an app is starting up or transitioning to a different screen, it's normal for the initial frame to take longer than 16ms to draw because the app must inflate views, lay out the screen, and perform the initial draw from scratch.

Best practices for prioritizing and resolving jank

Keep the following best practices in mind when looking to resolve jank in your app:

Identify and resolve the most easily reproducible instances of jank.
Prioritize ANRs. While slow or frozen frames might make an app appear sluggish, ANRs cause the app to hang.
Slow rendering is hard to reproduce, but you can start by killing 700ms frozen frames. This is most common while the app is starting up or changing screens.

App Startup