协程搬运工-基础

理解Android协程：基础与实践

最新推荐文章于 2025-08-12 09:46:53 发布

原创最新推荐文章于 2025-08-12 09:46:53 发布 · 267 阅读

3 ·

CC 4.0 BY-SA版权

文章标签：

#并发编程 #移动开发 #Android

Andorid进阶专栏收录该内容

311 篇文章

订阅专栏

本文介绍了Android协程的基础知识，包括协程的非阻塞特性、launch与async的使用、runBlocking与suspend函数的影响，以及withContext的协程阻塞行为。通过实例代码解析了协程在并发编程中的应用，强调了结构化并发和作用域构建器的重要性，展示了如何避免内存泄漏。同时，还探讨了协程的轻量级特性和在全局范围内的行为。

协程简介

协程是轻量级的线程，它们在某些coroutiue上下文中与launch构建器一起启动。GlobalScope的生命周期与整个应用程序的生命周期一致。

阻塞与非阻塞

先说结论：

launch不会阻塞线程
async可以阻塞协程也可以不阻塞协程（无法直接运行在线程里，只能运行在协程里）
runBlocking会阻塞线程
suspend会阻塞协程（只能运行在协程里，无法运行在线程里）
withContext会阻塞协程（只能运行在协程里，无法运行在线程里）

launch不会阻塞所在线程

代码

fun main() = runBlocking {
    log("准备启动协程")// ::A
    GlobalScope.launch {
        log("运行协程")//  ::B
        delay(1)
    }
    log("代码运行到协程体之外")//  ::C
    delay(2)
}

日志输出

日志:  准备启动协程
日志:  代码运行到协程体之外
日志:  运行协程

结论

本例代码中C处的日志比B处先执行，所以证明lunch不会阻塞

async可阻塞也可以不阻塞

不使用await

代码

fun main() = runBlocking {
    log("A--进入async方法体内")//A
    val async = GlobalScope.async {
        log("B--开始执行async方法体")//B
        delay(1)
        log("C--async方法体执行完成")//C
    }
    log("D-- async方法体外执行")//D
    delay(2)
}

日志

日志:  A--进入async方法体内
日志:  D-- async方法体外执行
日志:  B--开始执行async方法体
日志:  C--async方法体执行完成

结论

async不会阻塞线程把上一个例子做一些小改动

使用await

代码

fun main() = runBlocking {
    log("A--进入async方法体内")//A
    val async:Deferred<Unit> = GlobalScope.async {
        log("B--开始执行async方法体")//B
        delay(1)
        log("C--async方法体执行完成")//C
    }
    async.await()//加了这样一个调用
    log("D-- async方法体外执行")//D
    delay(2)
}

日志

日志:  A--进入async方法体内
日志:  B--开始执行async方法体
日志:  C--async方法体执行完成
日志:  D-- async方法体外执行

结论

async如果加上了await就会阻塞线程，

runningBlock会阻塞所在线程

代码

fun main() {
    log("A--准备进入runningBlock") //A
    runBlocking {
        log("B--进入runningBlock" )//B
        delay(1)
        log("C--执行完成runningBLock")//C
    }
    log("D--runBlocking代码块外执行")//D
    runBlocking {
        delay(3)
    }
}

执行结果

日志:  A--准备进入runningBlock
日志:  B--进入runningBlock
日志:  C--执行完成runningBLock
日志:  D--runBlocking代码块外执行

结论

本示例中runBlocking代码块中的B和C顺序执行完成后才执行的代码块外面的D，这证明了runningBlock会阻塞线程。

suspend函数会阻塞协程

suspend会阻塞所在的协程，不会阻塞线程，因为suspend无法在线程内部调用

代码

fun main() = runBlocking {
    log("A--调用suspend函数前")
    wait2Second()
    log("B--调用suspend函数后")
    delay(3)
}

suspend fun wait2Second() {
    log("C--调用suspend函数开始")
    delay(2)
    log("D--调用suspend函数结束")
}

日志

日志:  A--调用suspend函数前
日志:  C--调用suspend函数开始
日志:  D--调用suspend函数结束
日志:  B--调用suspend函数后

结论

suspend函数会阻塞协程

withContext是否会阻塞协程

代码

fun main() = runBlocking {
    log("A--执行withContext前")
    withContext(Dispatchers.Default){
        log("B--开始执行withContext")
        delay(1)
        log("C--withContext执行完成")
    }
    log("D--执行withContext后")
    delay(2)
}

日志

日志:  A--执行withContext前
日志:  B--开始执行withContext
日志:  C--withContext执行完成
日志:  D--执行withContext后

结论

withContext会阻塞协程，withContext只能运行在协程，不能运行在线程中。本例中的Default改为Main就会报错，因为Main相当于运行在主线程

等待一个作业

launch方法会返回一个Job对象，Job对象调用了join方法后，会等待launch协程体执行完成再继续后面的任务。

join方法只能在协程体里面调用，不能在线程中调用

代码

fun main() = runBlocking {
    log("A")
    val job = GlobalScope.launch {
        log("B")
        delay(2)
        log("C")
    }
    log("D")
    job.join()
    log(E)
}

日志

日志:  A
日志:  D
日志:  B
日志:  C
日志:  E

结论

join会等待协程体执行完成

结构化并发

使用GlobalScope.launch是很危险的，因为它创建的是一个顶层协程，如果launch方法里执行了耗时任务，而我们的对象过早的被回收就会发生内存泄露。

这种情况的解决办法就是在我们指定的作用域范围内开启协程

举例：

代码

fun main() = runBlocking {
    log(A)
    //这个launch和GlobalScope.launch是不同的，它是运行在runBlocking的作用域内的
    launch {
        log(B)
        delay(2)
        log(C)
    }
    log(D)
}

日志

日志:  A
日志:  D
日志:  B
日志:  C

因为launch方法运行在外部runBlocking作用域内，

作用域构建器（直接抄官方）

除了由不同的构建器提供协程作用域之外，还可以使用 coroutineScope 构建器声明自己的作用域。它会创建一个协程作用域并且在所有已启动子协程执行完毕之前不会结束。

runBlocking 与 coroutineScope 可能看起来很类似，因为它们都会等待其协程体以及所有子协程结束。主要区别在于，runBlocking 方法会阻塞当前线程来等待，而 coroutineScope 只是挂起，会释放底层线程用于其他用途。由于存在这点差异，runBlocking 是常规函数，而 coroutineScope 是挂起函数

代码

fun main() = runBlocking { // this: CoroutineScope
    launch { 
        delay(200L)
        println("Task from runBlocking")
    }
    
    coroutineScope { // 创建一个协程作用域
        launch {
            delay(500L) 
            println("Task from nested launch")
        }
    
        delay(100L)
        println("Task from coroutine scope") // 这一行会在内嵌 launch 之前输出
    }
    
    println("Coroutine scope is over") // 这一行在内嵌 launch 执行完毕后才输出
}