文章目录
- 一、withContext、async和launch对比
- 1. withContext
- 2. async
- 3. launch
- 总结对比
- 任务启动:
- 适用情境:
- 二、为何说 withContext是顺序执行
- 1. 挂起协程但不创建新协程
- 2. 顺序流程的保证
- 3. 用例场景的体现
- 结论
withContext、async和launch是Kotlin协程库中用来管理并发和异步任务的三个不同的构建器。它们适用于不同的场景,具有不同的功能和用法。以下是它们之间的主要区别:
一、withContext、async和launch对比
1. withContext
功能:用于切换协程的执行上下文(例如从主线程切换到IO线程),不会创建新的并发任务。
返回值:返回协程代码块中最后一个表达式的结果。
执行方式:顺序执行,不会启动新的协程,当前协程挂起直至withContext代码块执行完成。
用法场景:适用于需要在指定上下文中执行任务的场景,特别是密集型计算或IO操作。
线性顺序:withContext是顺序执行的,代码在withContext调用时会被挂起,直到其内代码块执行完毕。
import kotlinx.coroutines.*fun main() = runBlocking {val result = withContext(Dispatchers.IO) {// 在IO线程中执行performIoOperation()}println("Result: $result")
}suspend fun performIoOperation(): String {delay(1000L) // 模拟耗时操作return "Completed"
}
2. async
功能:用于并发地启动一个新的协程,并适合需要返回结果的任务。
返回值:返回一个Deferred对象,通过调用await()获取结果。
执行方式:并行执行。多个async可以同时启动并发任务。
用法场景:适合需要并行计算的场景,尤其是需要合并多个异步操作的结果。
非阻塞:async本身不阻塞当前线程,await会让调用者等待结果。
示例1:
val deferred: Deferred<ResultType> = async {// 执行一些并发任务someComputation()
}
val result = deferred.await()
示例2:
import kotlinx.coroutines.*fun main() = runBlocking {val deferredOne = async { performTask1() }val deferredTwo = async { performTask2() }println("Task One Result: ${deferredOne.await()}")println("Task Two Result: ${deferredTwo.await()}")
}suspend fun performTask1(): String {delay(1000L) // 模拟耗时任务return "Result One"
}suspend fun performTask2(): String {delay(2000L) // 模拟耗时任务return "Result Two"
}
3. launch
功能:用于启动一个新的协程,不会返回结果(不适用于需要直接返回结果的场景)。
返回值:返回一个Job对象,表示协程的生命周期,可以用来取消任务。
执行方式:并行执行。多个launch同时启动,并发地处理任务。
用法场景:适合处理不关心返回结果的异步任务,比如更新UI、发送网络请求等。
示例:
launch {// 执行一些与返回结果无关的异步任务performSomeAction()
}
总结对比
任务启动:
withContext:不启动新协程,仅切换上下文,协程挂起直至块完成。
async:启动新协程,适合需要结果的并发任务。
launch:也启动新协程,但不关注返回值,更关注任务的执行及生命周期管理。
适用情境:
- withContext适合需要在线性代码中切换执行环境的场景。
- async在需要合并多个异步结果的情况下很有用,例如发起多个网络请求并等待它们的结果。
- launch适合对任务完成后无需直接处理结果的场景,如不计返回值的操作。
在协程使用中,选择合适的构建器依据实际需求,如执行主线上下文切换、需要并发结果处理或者单纯启动并行任务。通过理解withContext、async和launch的区别,可以更有效地设计异步任务的执行逻辑。
二、为何说 withContext是顺序执行
在Kotlin的协程中,说withContext是顺序执行的,是因为它的执行模型以及在协程中的角色使得它与其上下文中的代码保持了执行的顺序性。以下几点阐述了这种顺序执行特性:
1. 挂起协程但不创建新协程
不创建并发任务:与async不同,withContext并不会启动一个新的协程,而是挂起当前正在执行的协程,然后在指定的协程上下文中继续执行。在withContext完成之前,协程会被挂起。
立即执行并返回结果:当代码调用withContext时,程序流会直接切换到新上下文中执行指定代码块,执行完成后返回最后一个表达式的结果。在这一过程中,代码流是线性的。
2. 顺序流程的保证
线性逻辑顺序:withContext调用是阻塞当前协程的——注意,这是一种挂起执行,不是传统意义上的线程阻塞——这意味着在withContext代码块结束之前,后续代码不会被执行。这保证了执行顺序与代码编写顺序一致。
协程的挂起和恢复流程:因为协程在挂起时释放了线程,其它协程任务可以在该线程上执行,但对当前协程来说,它会等待withContext中任务的完成,并从那里继续执行后续的代码。
3. 用例场景的体现
在业务逻辑中,withContext设计用于在不同的上下文中处理顺序性任务,而不是用于引入并行或并发的复杂性。例如:
import kotlinx.coroutines.*fun main() = runBlocking {println("Main thread: ${Thread.currentThread().name}")val result = withContext(Dispatchers.IO) {println("Inside withContext, thread: ${Thread.currentThread().name}")performIoOperation()}println("Back to main thread, result: $result")
}suspend fun performIoOperation(): String {delay(1000L) // 模拟IO操作return "IO Result"
}
在此代码中:
println(“Main thread: ${Thread.currentThread().name}”)在主线程中执行。
当withContext被调用时,当前协程被挂起,指定代码在IO上下文中执行。
一旦withContext完成,控制权返回到协程,它再继续执行后面的代码println(“Back to main thread, result: $result”)。
结论
因此,使用withContext时,虽然它可以修改协程所执行的上下文(比如切到其它线程),它在逻辑上是顺序执行的,确保其内的操作完成后才能继续后续执行。这种顺序性使其非常适合在协程中处理需要在指定调度器上完成的同步操作。