Jank & the frame budget

You have about 16 milliseconds

A screen refreshing at 60 frames per second gives your app roughly 16ms to produce each frame — measure, layout, draw, all of it. On a 90Hz or 120Hz display that budget shrinks further, to about 11ms or 8ms. Miss it and the screen shows the same frame twice: a dropped frame the walker actually feels as a stutter. That stutter has a name: jank.

All of this work happens on the main thread — the same thread that handles touch input and runs your Compose code. Block it with something slow (a big computation, a synchronous disk read, a database query) and every frame due during that block gets janked, not just one.

One of the most common causes of jank in a Compose app isn't a slow computation at all — it's a composable recomposing far more often than it needs to, redoing layout and draw work every time some unrelated state ticks, like a live GPS position updating 10 times a second and dragging a whole screen along with it.

Don't guess where the time is going. Android Studio's Layout Inspector shows you recomposition counts per composable, and a system trace (Perfetto) shows exactly which frames blew the budget and why. Measure first, then fix.