本质上,协程像是轻量级的线程
callback hell 回调地狱
,也就是说可能出现大量嵌套代码,这种代码在视觉效果以及逻辑维护上都堪称地狱级代码,很容易给程序员带来困扰。Rxjava
这种用于处理异步编程的框架,有各种操作符以及流式调用等特点方便进行异步编程,而协程在这方面和Rxjava
这种框架不同,协程做到了让代码看起来更直白更具有逻辑性,至于怎么让代码看起来更通俗易懂,可以看看接下来我在学习协程中个人的一些理解和总结举两个简单的创建方法 runBlocking { }
以及 GlobalScope.launch { }
runBlocking { }
runBlocking
创建了一个协程,并且会阻塞当前线程,等待作用域也就是{}
内的代码以及所有子协程结束,并且runBlocking
是有返回值的,但是由于会阻塞线程,所以用的情况不多,在这里做一个入门讲解
GlobalScope.launch { }
通过这个方法创建出来的协程是一个顶层的协程,它的生命周期跟
application
是一样的,没有返回值,也不可以取消,并且不会阻塞当前线程,这一点和runBlocking { }
正好相反
通过下面一段代码让大家了解一下用法
// 简单的输出一句Hello World GlobalScope.launch { print("Hello World") } 复制代码
launch
和Job
launch
是以不阻塞的方式去启动一个新的协程,需要在协程的范围内去调用,比如上面提到runBlocking
couroutineScope
,并且会返回一个Job
用来控制任务的开始取消等操作
public fun CoroutineScope.launch( context: CoroutineContext = EmptyCoroutineContext, start: CoroutineStart = CoroutineStart.DEFAULT, block: suspend CoroutineScope.() -> Unit ): Job { val newContext = newCoroutineContext(context) val coroutine = if (start.isLazy) LazyStandaloneCoroutine(newContext, block) else StandaloneCoroutine(newContext, active = true) coroutine.start(start, coroutine, block) return coroutine } 复制代码
launch
的构造方法,有三个参数context
:可以传入一个调度器Dispatchers
来控制协程启动选项,默认的参数是CoroutineStart.DEFAULT
也就是按当前的上下文环境去启动,如果我们想在IO线程中启动,可以传入Dispatchers.IO
还有像Dispatchers.Main
就是在主线程中去启动start
:如果我们想去控制协程的启动时机,可以通过start
传入一个CoroutineStart
,默认的CoroutineStart
是立即启动,如果想要延时启动可以传入CoroutineStart.LAZY
, 然后在需要启动的时候调用Job
的join
方法block
:让协程在传入的协程范围内去运行launch
的方法讲完之后就讲一下Job
的作用,Job
有几个常用的方法,像是join
cancel
cancelAndJoin
join
:启动协程任务并且会以一个非阻塞的方式去等待这个Job
完成
cancel
:取消任务
cancelAndJoin
:综合上面两个方法,实际上内部就是先调用了cancel
再调用join
,也就是说会等待协程内的任务完成之后,再继续往下执行代码,如果是cancel
的话,那么调用的时候协程内的任务就会直接中断
以上两种cancel,举个在安卓中的实际场景,比如一个草稿箱功能 ,用户在点击退出之后弹出一个loading框,这个时候可以用
cancelAndJoin
等待上传完成之后再dissmiss,如果用户选择直接退出,那么可以用cancel
另外被取消的协程,会抛出一个
CancellationException
异常,表示协程被正常取消,如果你没有捕获错误的话,不会打印到控制台/日志
isActive
:这是一个判断当前协程是否还存活的标记,可以在任务中根据这个属性决定任务是否继续
try{}finally{}
这样的操作把任务逻辑写在try
中,在finally
中释放资源除了由不同的构建器提供协程作用域之外,还可以使用
coroutineScope
构建器声明自己的作用域。它会创建一个协程作用域并且在所有已启动子协程执行完毕之前不会结束。coroutineScope
是非阻塞式的,是挂起函数,而runBlocking
是阻塞式,属于常规的函数,但是两者都会等待各自作用域中的所有子协程结束
runBlocking { }
是阻塞式,coroutineScope
是非阻塞式,可以通过下面一段代码来体现import kotlinx.coroutines.* fun main() = runBlocking { // 用launch启动一个子协程 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 执行完毕后才输出 } 最终的输出结果:x Task from coroutine scope Task from runBlocking Task from nested launch Coroutine scope is over 复制代码
runBlocking { }
和coroutineScope
的阻塞以及非阻塞式区别,有的人可能会觉得有点疑惑,代码上看起来coroutineScope
后面的打印总是会在最后才输出,看起来似乎coroutineScope
才是阻塞式的Task from runBlocking
这一段先打印相信大家可以明白,接着代码运行到了coroutineScope
作用域里,作用域中有子协程,相信大家也能明白作用域中打印的顺序,那么问题来了,为什么Coroutine scope is over
总是在最后打印。coroutineScope
作用域会以非阻塞式的等待所有子协程完成,所以内部第一个launch
在运行到delay
的时候并没有阻塞住线程,而是继续运行下去,所以会先打印延时比较短的Task from coroutine scope
,之后delay
时间到了协程切回去打印了Task from nested launch
,而由于coroutineScope
是在runBlocking
当中,所以当couroutineScope
没有结束之前,runBlocking
会阻塞当前线程等待,所以在coroutineScope
内部delay
没有结束,没有打印完成之前,最后一句println
并不会被执行到。