android kotlin 协程简单入门

Posted 2023-03-02 史大拿

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了android kotlin 协程简单入门相关的知识，希望对你有一定的参考价值。

android kotlin 协程(一)

config:

system: macOS
android studio: 2022.1.1 Electric Eel
gradle: gradle-7.5-bin.zip
android build gradle: 7.1.0
Kotlin coroutine core: 1.6.4

前言:最近系统的学习了一遍协程, 计划通过10篇左右blog来记录一下我对协程的理解, 从最简单的 runBlocking开始; 到最后 suspend和continuation的关系等等

tips:前面几篇全都是协程的基本使用,没有源码,等后面对协程有个基本理解之后,才会简单的分析一下源码!

学习我这个系列的协程, 只需要记住一点, suspend函数永远不会阻塞main线程执行! 永远是异步的!

看完本篇你将会学到哪些知识:

runBlocking()
CoroutineScope#launch()
CoroutineScope#async()
Job的常用方法
协程状态[isActive,isCancelled,isCompleted]

runBlocking

定义: runBlocking 会阻塞线程来等待自己子协程执行完, 并且对于不是子协程的作用域,也会尽量的去执行,

首先来了解一下什么是自己的子协程

通常我们通过

CoroutineScope.launch
CoroutineScope.async

来开启一个协程,因为当前是在CoroutineScope作用域中,所以直接launch / async 即可

这段代码可以看出,runBlocking 会等待子协程全部执行完,然后在结束任务,因为协程都是异步的,

所以会先执行协程之外的代码,然后再执行协程中的代码

可以在协程中添加一些睡眠操作再来测试一下

可以看出,还是可以正常的执行完所有代码

现在解释完了定义中的前半句话: runBlocking 会阻塞线程来等待自己子协程执行完, 并且对于不是子协程的作用域,也会尽量的去执行,

再来看一下后半句话:

可以看出,通过自定义coroutine 和 GlobalScope,来创建的协程照样可以执行出来

那么在他们之中稍微添加一点逻辑会怎么样?

可以看出,一旦添加了一点逻辑, runBlocking是不会等待非子协程的作用域

如果想让runBlocking等待非子协程执行完,那么只需要调用Job.#join() 即可

例如这样:

join()方法目前可以理解为: 等待当前协程执行完在往下执行其他代码,

一旦调用了join()方法,那么协程就变成了同步的,那么这块代码一共执行需要4s

因为协程1并没有join, 所以协程1还是异步的,

协程2调用了join,所以在执行协程2的过程中,协程1也在执行.

所以协程1,与协程2的执行时间为2s

tips: 在开发中不建议使用runBlocking,因为会阻塞主线程,阻塞主线程的时间,用来子协程的执行…

开启协程两种不同的方式

在上面代码中我们提到了,开启协程有2种方式

CoroutineScope#launch
CoroutineScope#async

先来看相同点:

相同点就是无论是哪种方式,都会执行里面的代码

那么这两种方式有什么区别呢?

launch无法返回数据, async可以返回结果

返回的结果通过 Deferred#await() 来获取,并且调用Deferred#await()的时候,会等待async 执行完成之后在往下执行,就和Job#join一样,不过await()有返回结果

使用await的时候有一个注意点:

那么也可以看到,launch 与 async 的返回值也有所不同:

launch 返回 Job
async 返回Deferred

其实本质上来说,async 返回的也是Job,不过只是Job的子类Deferred而已,Deferred只是对返回值等一些操作的封装

那么Job是用来干什么的呢?

Job是用来管理协程的生命周期的, 例如刚才提到的 Job.join() 就可以让协程 “立即执行”

launch 和 async 捕获异常的方式也不同,这个等下一篇专门聊异常的时候在详细讲解

Job.cancel 取消协程

协程比线程好用的一点就是协程可以自己管理生命周期, 而线程则不可以

这里需要注意的是,如果协程体中还在执行,但是外部已经取消了,那么则会throw异常出来

JobCancellationException

fun main() = runBlocking<Unit> 
    println("main start")

    val job = launch 
        try 
            (0..100).forEachIndexed  index, _ ->
                delay(1000)
                println("launch $index")
            
         catch (e: Exception) 
            println("协程被取消了 $e")
        
    

    // 协程执行完成监听
    job.invokeOnCompletion 
        println("协程执行完毕$it")
    

    delay(5500)

    // 取消协程
    job.cancel()

    println("main end")

Job#invokeOnCompletion: 协程完成回调

运行结果:

main start
launch 0
launch 1
launch 2
launch 3
launch 4
main end
协程被取消了 kotlinx.coroutines.JobCancellationException: StandaloneCoroutine was cancelled; job="coroutine#2":StandaloneCoroutineCancelling@76a4d6c
协程执行完毕kotlinx.coroutines.JobCancellationException: StandaloneCoroutine was cancelled; job="coroutine#2":StandaloneCoroutineCancelled@76a4d6c

coroutine的3种状态

coroutine的三种状态都是通过Job来管理的:

isActive 是否是活跃状态
isCancelled 是否取消
isCompleted 是否完成

先来看看正常流程执行的代码:

我们知道协程始终是异步执行的,在执行printlnJob的时候,协程体中的代码还没有真正的执行

所以此时处于活跃状态,并且协程没有被执行完

如果我们在协程执行完成的回调中调用

那么此时,协程体中的代码已经执行完了,那么此时就是非活跃状态

还剩一个Job#isCancelled 这个方法比较简单,简单的说就是是否调用了Job.cancel()

但是这里有一个特别奇怪的点,明明已经调用Job#cancel() 来取消协程,并且协程体中的代码也没执行,但是为什么还显示协程没有执行完呢?

因为Job#cancel() 并不是suspend函数,不是suspend函数就没有恢复功能,这行文字可能看的有一点迷惑,先不用管什么挂起于恢复,现在只需要知道

我们调用cancel() 的时候会紧跟着一个,Job#join() 即可

或者直接调用Job.cancelAndJoin() 即可

挂起恢复,这4个字我理解了10天左右,不可能通过本篇就讲清楚,现在只需要会调用这些api,即可!!

那么问题就来了,这个状态有什么用呢?

先来看一段代码:

可以惊奇的发现,这段代码无论如何都cancel不掉.好像是失效了一样

那么解决这个问题,就可以检测协程是否是活跃状态,例如这样

Job也提供了一个方法: Job#ensureActive()

ensureActive() 本质也是通过isActive判断,不同的是,当取消的时候可以捕获到取消的异常,然后来处理对应的事件

图片地址

回顾一下本篇:

本篇我们讲解了runBlocking, 这个函数会帮我们阻塞主线程, 阻塞住线程的时候会等待内部的子协程全部执行完

还聊了最基础的如何开启一个协程, launch / async 以及他们的相同点和不同点

最后引出了协程生命周期管理者Job, 讲解了Job常用的方法,以及job的3种状态

方法名	作用	补充
join()	立即恢复协程体执行	等待协程体执行完成,在执行后续代码
cancel()	取消协程	,如果取消时,协程体还在执行,这throw JobCancellationException,这个异常不会上报,会自行处理
invokeOnCompletion()	协程体执行完成回调
isActive	协程体是否是活跃状态
isCancelled	协程体是否被取消
isCompleted	协程体是否执行完成