在无并行性的Android(Kotlin)中，何时及为何使用协程替代线程？

Great question—this is such a common point of confusion when making the switch from threads to coroutines, especially when you're working within a single-threaded context like Android's main thread. Let's break down exactly when and why coroutines are still the better choice, even without parallelism:

1. Avoid Callback Hell with Sequential Async Code #

Even in a single-threaded environment, you'll often need to run sequential asynchronous operations (like fetching data from a local database, processing it, then updating the UI). With threads, this usually means nesting callbacks or juggling Handler posts, which quickly turns into unreadable "callback hell."

Coroutines let you write this code as if it were synchronous, using suspend functions that pause execution without blocking the thread:

lifecycleScope.launch {
    // Fetch data from local storage (suspend function, no block)
    val userProfile = localDatabase.getUserProfile()
    // Process the data (another suspend function)
    val formattedProfile = formatProfileForUI(userProfile)
    // Update UI directly—we're still on the main thread!
    profileTextView.text = formattedProfile
}

Compare this to thread-based code, where you'd have to manually post results back to the main thread with Handler or runOnUiThread(), leading to messy, nested logic.

2. Suspend Instead of Block to Keep the UI Responsive #

On Android's main thread, blocking operations (like Thread.sleep()) will freeze the UI, causing jank or ANRs. Coroutines use suspension instead of blocking: when a suspend function like delay() is called, it lets the main thread go back to handling user input, rendering, and other critical tasks.

Take this example:

// Coroutine approach: UI stays responsive during the delay
lifecycleScope.launch(Dispatchers.Main) {
    delay(2000) // Suspend execution, main thread is free to work
    statusTextView.text = "Operation complete!"
}

// Thread approach: Blocks the main thread, UI freezes
Thread.sleep(2000) // UI is unresponsive for 2 seconds
statusTextView.text = "Operation complete!"

Even in a single thread, suspension keeps your app smooth—something threads can't do without switching contexts.

3. Built-In Lifecycle Management to Prevent Leaks #

Android components (like Activities and Fragments) have short lifecycles. Threads require manual cleanup to avoid memory leaks: you have to track flags, call interrupt(), and handle InterruptedException, which is error-prone.

Coroutines solve this with structured concurrency. Scopes like lifecycleScope or viewModelScope automatically cancel all running coroutines when the component is destroyed:

// Coroutine: Auto-cancels when Activity is destroyed
lifecycleScope.launch {
    while (isActive) {
        refreshLatestData() // Suspend function
        delay(10000)
    }
}

// Thread: Manual cleanup required, easy to mess up
private var isRunning = true
private val refreshThread = Thread {
    while (isRunning) {
        refreshLatestData()
        try {
            Thread.sleep(10000)
        } catch (e: InterruptedException) {
            // Handle interrupt, which adds more boilerplate
        }
    }
}

override fun onDestroy() {
    super.onDestroy()
    isRunning = false
    refreshThread.interrupt()
}

No more forgotten thread interrupts or leaked background tasks—coroutines handle this for you.

4. Consistent Code Style for Future Changes #

Even if you're not using parallelism now, your code might need it later. Coroutines let you switch between single-threaded and parallel execution with just a change of dispatcher, without rewriting your core logic.

For example, if you later decide to process data in parallel, you can update your coroutine to use Dispatchers.IO while keeping the same sequential-looking code:

lifecycleScope.launch {
    // Now runs in parallel on IO thread pool
    val userProfile = withContext(Dispatchers.IO) {
        remoteApi.fetchUserProfile()
    }
    val formattedProfile = formatProfileForUI(userProfile)
    profileTextView.text = formattedProfile
}

With threads, you'd have to refactor to use thread pools, manage task submission, and handle thread synchronization—all much more work.

Bonus: Minimal Overhead #

Even in a single thread, coroutines are far lighter than threads. A thread takes megabytes of memory for its stack, while a coroutine only uses a few kilobytes. You can create thousands of coroutines without worrying about memory issues, which is impossible with threads.

内容的提问来源于stack exchange，提问作者Ritt