最新要闻

广告

手机

iphone11大小尺寸是多少?苹果iPhone11和iPhone13的区别是什么?

iphone11大小尺寸是多少?苹果iPhone11和iPhone13的区别是什么?

警方通报辅警执法直播中被撞飞:犯罪嫌疑人已投案

警方通报辅警执法直播中被撞飞:犯罪嫌疑人已投案

家电

Kotlin协程-从理论到实战

来源:博客园

上一篇文章从理论上对Kotlin协程进行了部分说明,本文将在上一篇的基础上,从实战出发,继续协程之旅。

从源头说起

在Kotlin中,要想使用协程,首先需要使用协程创建器创建,但还有个前提——协程作用域(CoroutineScope)。在早期的Kotlin实现中,协程创建器是一等函数,也就是说我们随时随地可以通过协程创建器创建协程。但在协程正式发布以后,协程创建器需要在协程作用域对象上才能创建了,Kotlin添加了协程作用域来实现结构化并发。什么是结构化并发呢,通俗地说就是正确实施多个协程监控、管理的能力。在实际业务中,我们可能需要创建多个协程对象来完成不同的工作。为了对这些不相关的协程管理起来,Kotlin引入了协程作用域,通过某个协程作用域创建的协程都会被它管理着,在条件满足的时候,执行每个协程的取消工作或者结束自己。


(资料图片)

为了方便我们直接上手,官方提供了MainScopeGlobalScope供我们使用。正如名字那样,他们分别有不同的应用场景,前者比较适合用在UI相关的类中,而后者适用于在整个应用生命周期中都需要存活的类中。当然,对于Android开发者,其实我们有更好的选择——使用ViewModel的Kotlin扩展,它不仅有着全部的协程作用域功能,开箱即用,而且还在onCleared方法中实现了自动取消。

创建协程

有了协程作用域,那我们来创建一个最简单的协程吧。

viewModelScope.launch{    //这里就是协程代码啦啦啦啦    delay(2000)    System.out.println("Hello World")}

launch创建并启动了一个协程,协程启动两秒后,在控制抬打印了Hello World,然后协程就结束了(协程是有完整生命周期的)。这个协程完成的工作有限,我们可以使用线程完成相同的功能:

thread {            Thread.sleep(2000)            System.out.println("Hello World")        }

我们可以看到,除去构建函数,两段代码唯一的区别就是延迟函数——delayThread.sleep.从功能上看他们都是让后面的代码延迟执行,但是效果却是不一样的,前者不会阻塞线程。这段代码其实是放在主线程里面执行的,但是它不会影响到UI的绘制,而后者假如把它放在主线程执行的话,应用会出现两秒的无响应。Kotlin把这种不会阻塞当前线程执行的函数称之为挂起函数,挂起函数可以在挂起点断开与当前线程的联系,让线程空闲下来完成其他的操作,当条件满足后,挂起函数重新在挂起点恢复,接着往下执行后面的代码。

还有个小问题没有解决,在上一篇文章中,我曾经说过,挂起函数只能在挂起函数中执行,既然delay是挂起函数,那么反推,我们的代码块也应该是个挂起函数,而这个挂起函数就是所谓的协程体。

让协程跨线程工作

如果你看到上面的代码,然后转手在协程体里面写个网络请求的话,你会发现,你的应用崩溃了,这是怎么回事呢?因为协程虽然不会阻塞主线程,但是主线程是不允许进行网络请求的。如果这时你就急着下了协程没啥用的结论,那么你就肤浅了。让我们稍微改一改上面的代码,让它运行在子线程吧。

viewModelScope.launch (Dispatchers.IO){    //这里就是协程代码啦啦啦啦    delay(2000)    System.out.println("Hello World")}

很好,现在协程体里面的网络请求可以顺利执行了,但是很快有读者就会发现新问题了——我怎么把网络请求的结果传回主线程呢,难不成还搞个Handler,那和直接使用线程有什么区别,辣鸡协程。嘿,别急,这个协程其实也为客官处理好了。让我们再次改造一下代码:

viewModelScope.launch (Dispatchers.IO){    //这里就是协程代码啦啦啦啦,这里是在子线程执行的代码哦    //假装这个是网络请求吧    delay(2000)    withContext(Dispatchers.Main) {        //哦豁豁,这里竟然运行在主线程哦        System.out.println("Hello World")    }}

很好,我们可以愉快地使用协程处理网络请求了,那么这些魔法是怎么发生的呢,停下脚步,我们来重新审视一下上面的代码。

首先,相比于最开始的代码,我们的代码里多了两个对象,一个方法调用。首先我们来看那两个对象,从名字中我们不难猜到它就是调度线程的。Kotlin提供了四个常用的实现

  • Default,它是标准协程构建者默认使用的调度器,使用共享的线程池工作,适用于计算型的任务;

  • Main,它是代表UI线程的调度器,通常来说只有一个线程,使用这个调度器就可以直接在协程中操作UI;

  • Unconfined,它没有限定线程范围,它在哪个线程中被调用就会在哪个线程里执行完初始的代码,直到遇到挂起函数,随后它会使用挂起函数指定的调度器恢复,这个过程可以一直持续下去。

  • IO,是用来承载阻塞的IO操作的,如文件读写,网络连接等,是我们比较常用的调度器。

所以那两个调度器对象是让协程切换工作环境的魔法。接下来还有一个方法调用没有解释。withContext的作用是将当前的协程调度器切换到指定的调度器上,用这个调度器接着执行构建块中的代码。同时它也是一个挂起函数。提到挂起函数,我们就该想到,它是可恢复的。所以当这个挂起函数的代码块执行完成之后,它会自动恢复成原来的调度器,接着往下执行。

用协程串联两个异步操作

在项目开发中,还有一种常见的应用场景,客户端需要先请求一些配置信息,然后利用配置信息再请求真正的内容信息。这个过程描述起来是串行的,但是代码写起来却是割裂的,需要在第一个网络请求的回调中处理和发起第二个请求,然后在第二个回调中获取真正需要展示的数据,可能这个过程还会加个存库,或者触发另外请求的工作,那么完了,这代码没法看了。这放在以前,这种情况通常会使用RxJava,但是RxJava的代码可读性也还是差点意思。那么Kotlin协程可以写成什么样呢?

viewModelScope.launch(Dispatchers.IO) {            val retrofit=Retrofit.Builder().build()            val apiUser=retrofit.create(APIUser::class.java)            val user=api.current()            val detail=api.userDetail(user.id)            withContext(Dispatchers.Main) {                userLiveData.value=detail            }        }

这和我们写一般的同步代码一摸一样,没有回调,也不需要付出其他代价,这个过程甚至可以一直加下去。其实我觉得这个才是协程的真正威力。

让多个协程一起工作

我们继续复杂化使用场景——我在做一个多端使用的笔记App,现在用户打开了某一个已存在的笔记,为了让用户能快速浏览到上一次的操作信息,一方面我需要从文件中读取上一次操作的结果,另一方面我要拉取远程的操作结果,然后对两个结果合并,决定最终的展示数据。考虑到这两个操作其实是并行的,上面我们让协程串联起来的思路已经不适用了,因为协程里面的操作都是串行的。既然一个协程解决不了,我们再加一个协程可不可以呢?看着好像是可以,但是,协程操作的结果我们怎么获取到呢?查阅API,我找到了另一个协程构建器async。它会返回一个协程对象,然后通过await方法获取到协程的计算结果。思路来了,我们马上动手

val fileResult=viewModelScope.async(Dispatchers.IO) {             //假装是读文件的代码吧             1         } val networkResult=viewModelScope.async(Dispatchers.IO) {     //也是假装是网络请求的代码     2 } val fResult=fileResult.await()val rResult=networkResult.await()val result=if(fResult>rResult){    fResult}else{    networkResult}

然后你就会发现报错了,await是挂起函数。看来两个协程还完成不了,要三个,所以,让我们创建第三个协程吧

//前面的两个协程不变 viewModelScope.launch {     val fResult=fileResult.await()     val rResult=networkResult.await()     val result=if(fResult>rResult){         fResult     }else{         networkResult     }}

这就是协程间通信的基本写法啦,从这个基础之上,甚至还能衍生出更复杂的版本,但是万变不离其宗,都可以参考这种思路完成。

协程的取消

正如之前提到的一样,协程有着类似于线程的完整生命周期,包括创建,激活,完成中(取消中),已完成(已取消),刚才我们的示例都是正常状态,协程完成工作后会自动结束,但协程的另一条取消流程我们还没有提到。协程有自己的取消API——cancel可供使用,我们只需要保存好协程创建者返回的协程对象就行了。当然更常见的还是文章开篇提到的使用协程作用域取消。这个操作会取消所有的协程。

总结

本篇文章从协程创建开始,讲到了怎样用协程写出异步代码,怎么让多个协程共同工作,虽然覆盖了很大一部分使用场景,但是依然还有遗漏。由于篇幅限制,遗漏部分将在下一篇博文中继续讲解,希望大家持续关注。

青山不改,绿水长流,咱们下期见!

关键词: