Coroutines, gently

Why apps freeze

You have seen this. You tap Save, and the app stops. Not a spinner — actually stops. The button stays pressed, scrolling does nothing, and after a few seconds Android offers to close the app for you.

Nothing has crashed. The app is busy. And "busy" turns out to have a very specific meaning, which is the whole of this lesson.

One worker, one counter

Android draws your screen on a single thread called the main thread. A thread is one line of work, carried out strictly in order, one step after another.

The main thread has a lot to do. Roughly sixty times a second it works out what every pixel should look like and draws it. In between, it handles your taps, your scrolls, and your keyboard.

That is about sixteen milliseconds per frame. If your code takes longer than that on the main thread, a frame is missed. If it takes a second, sixty frames are missed and the screen is visibly frozen. If it takes five seconds, Android decides the app is broken and shows the ANR dialog: Isn't responding — close app?

Meanwhile, plenty of ordinary jobs take far longer than sixteen milliseconds:

So the rule is simple to state and easy to break: never make the main thread wait.

Blocking: the wrong way

1fun main() {
2  println("Order taken")
3  Thread.sleep(2000)
4  println("Serving tea")
5}

Thread.sleep does exactly what the bad barista does. It holds on to the thread and does nothing with it for two seconds. That is called blocking.

In this tiny practice program you just wait, and no harm is done. In an app, that same line freezes the screen — and you can see it happen in Logcat:

1I/Choreographer: Skipped 120 frames! The application
2may be doing too much work on its main thread.

A hundred and twenty skipped frames is two seconds of a dead screen. Users notice at about three.

Suspending: the right way

Here is the same wait, done properly:

delay(2000)

It looks almost identical, and it does something completely different. delay says "wake me in two seconds" and then hands the thread back. During those two seconds the thread is free to draw frames, handle taps, and run other work. When the time is up, your code carries on from exactly where it stopped.

Pausing without holding the thread is called suspending, and a piece of work that can do it is a coroutine.

The three words you need

1. suspend — this function is allowed to pause

1suspend fun boilKettle(): String {
2  delay(2000)
3  return "tea"
4}

suspend is a promise to the reader and a fact for the compiler: this function may stop partway through and continue later.

It comes with one rule: a suspend function can only be called from another suspend function, or from inside a coroutine. That is not bureaucracy. Pausing means somebody has to remember where you got to and come back for you, and only a coroutine does that job.

2. launch — start a coroutine and carry on

1launch {
2  println("Serving " + boilKettle())
3}

launch starts the work and returns immediately. The line after it runs at once, without waiting for the block to finish. That is the barista turning back to the queue.

Work that starts now and finishes later is called asynchronous, and it is worth getting used to the idea that the order your lines are written is no longer the order things finish.

3. runBlocking — the bridge, for practice programs only

Ordinary code cannot call launch or delay out of nowhere, because neither exists outside a coroutine. runBlocking builds one and waits for everything inside to finish:

1fun main() = runBlocking {
2  // suspend functions are allowed in here
3}

1Order taken
2Next customer, please
3Serving tea
4Closing time

What comes later

This has been deliberately gentle, and there is more. Real apps also need to say which thread a piece of work should run on, what happens when the user leaves the screen halfway through, and how a stream of values arriving over time is handled.

Those all have good answers, and you will meet them exactly when you need them rather than now:

• Part 3 starts coroutines from a screen with LaunchedEffect.
• Part 4 gives every ViewModel a viewModelScope, and every Room database function you write will be a suspend function.
• Focus Flow, in Part 5, is a timer built from a loop containing delay(1000) — the exact shape you just typed, ticking once a second while the screen stays perfectly smooth.

For now, three sentences are enough to carry forward: slow work must not sit on the main thread; suspend marks a function that can pause; launch starts work that runs alongside everything else.