Why is it important to keep heavy work off the main thread in a mobile app, and what kinds of work belong on a background thread?
technical-conceptual · Junior level · software-engineering
What the interviewer is really asking
Assesses whether the candidate understands that the UI thread renders frames and handles input, so blocking it causes visible jank or ANRs, and can identify what work to move off it.
What to say
- Explain that the main (UI) thread is responsible for rendering each frame and handling touch input, and it has roughly a 16ms budget per frame at 60fps (about 8ms at 120fps) before frames get dropped.
- Name concrete work that belongs on a background thread: network calls, disk and database reads/writes, JSON parsing, image decoding, and crypto, then post the result back to the UI thread to update state.
- Mention the symptoms you're preventing: dropped frames and stutter (jank), an unresponsive UI, and on Android an ANR if the main thread is blocked too long.
What to avoid
- Claiming background threads always make the app faster, ignoring that thread coordination and updating UI from the wrong thread cause their own bugs.
- Saying you'd just 'add more threads' without explaining what work actually blocks the frame budget.
- Forgetting that UI updates themselves must come back to the main thread, so you can't touch views directly from a background coroutine or queue.
Example answers
Strong: The main thread draws frames and handles taps, and it only has about 16ms per frame at 60fps. If I do a network call or decode a large image on it, that work blows the budget, frames drop, and the screen stutters. So I run I/O, parsing, and image decoding on a background dispatcher or executor and only switch back to the main thread to update the UI.
Weak: You should always use background threads because threads make things faster. I'd put as much as possible on other threads so the app runs in parallel and stays quick.