嵌套调用suspend函数是否会成为性能瓶颈？

问题描述 #

在进行Android/Kotlin开发时，我了解到suspend关键字会将函数转换为状态机，该状态机可从执行线程中移除、暂停，并在未来的某个时间由同一线程或其他线程恢复。
我认为状态机会带来一定的代码和执行时间开销，这当然是必要的，并非真正的问题。
但在我查看的一些现有代码中，发现存在suspend函数调用其他suspend函数的情况，示例如下：

// 协程实现类
override suspend fun doWork(): T { 
    return A().methodA() 
}

class A { 
    suspend fun methodA(): T { 
        return B().methodB() 
    }
}

class B { 
    suspend fun methodB(): T { 
        // 执行网络I/O操作
    }
}

若我的理解正确，这会生成三个可挂起的状态机。仅在doWork()协程实现上使用suspend关键字是否更佳？是否会丢失线程灵活性（我对此存疑）？

回答 #

• 没必要只在最外层标记suspend：嵌套使用suspend是Kotlin协程的常规写法，完全符合设计意图。每个涉及耗时操作（比如示例中的网络I/O）的函数都应该标记为suspend——这是一种语义明确的声明，告诉调用者该函数可能挂起，必须在协程或其他suspend上下文中执行，能大幅提升代码的可读性和安全性。
• 状态机开销远低于预期：Kotlin编译器对suspend函数的状态机生成做了大量优化。嵌套的suspend函数不会生成三个完全独立的冗余状态机，而是在调用链上协同工作，实际性能开销可以忽略不计，远低于I/O操作本身的耗时。
• 线程灵活性不会丢失：协程的线程调度由CoroutineDispatcher决定，和suspend函数的嵌套层级无关。只要整个调用链处于suspend上下文，你依然可以通过withContext在任意节点切换线程，比如在methodB里指定Dispatchers.IO执行网络请求，不会因为嵌套suspend而受限。

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