前文介绍了kotlin相关的一个基础知识
可以参考链接kotlin简介回顾
纠错
在前篇中我们说kotlin的启动都是基于上下文启动的,这话其实不对 ,协程的启动时基于CoroutineScope,就是协程域
位于package kotlinx.coroutines
其中提供了大量的扩展方法 用于启动协程
协程启动模式 CoroutineStart枚举类
共计4个参数 分别是:
DEFAULT
LAZY
ATOMIC
UNDISPATCHED
协程调度器 Dispatchers单利
Default
Main
IO
Unconfined
为了配合下面的知识我们先拿出每个调度器的 isDispatchNeeded 默认为true
这里我们先不看这个参数的含义,后面会说
这里我们简单说下
override fun isDispatchNeeded(context: CoroutineContext): Boolean = false
目前只是出现在了最后一个参数 也就是UNCONFINED中
DEFAULT
根据上下文立即调度协程执行。
如果调度器的CoroutineDispatcher.isDispatchNeeded 返回true,那么协程将稍后被调度执行,而协程构建器将继续运行
如果调度器的
CoroutineDispatcher.isDispatchNeeded=true 那么协程构建器会继续运行 而协程代码将稍后运行
我们来看看参数运行情况:
默认启动方式 并使用调度器为
运行结果:
runBlocking----main
runBlocking–CANCLE–main
不难发现我们先运行了构建器所在位置 而协程代码将被延后了
如果我们使用了
Dispatchers.Unconfined,
那么协程将被先运行结果如下
launch----main
runBlocking----main
runBlocking–CANCLE–main
这也是我们协程更细粒度的控制
对于DEFAULT 启动模式后面还有一句话就是:能被随时取消
当然这肯定基于 我们的协程延后才能实现 如果协程提前运行了 肯定无法取消
也就是我们的携程构建器先运行的话 协程将直接被取消
这里就不做异常的说明
LAZY
惰性的,启动由我们指定start开始 才会执行
我们来看下exp:
val job = launch(start = CoroutineStart.LAZY) {
println("launch----${Thread.currentThread().name}")
delay(100)
println("launch--delay--${Thread.currentThread().name}")
}
job.start()
println("runBlocking----${Thread.currentThread().name}")
job.cancel()
println("runBlocking--CANCLE--${Thread.currentThread().name}")
输出依然:
runBlocking----main
runBlocking–CANCLE–main
我们改变下代码:
val job = launch(Dispatchers.Unconfined, start = CoroutineStart.LAZY) {
println("launch----${Thread.currentThread().name}")
delay(100)
println("launch--delay--${Thread.currentThread().name}")
}
println ("runBlocking----${Thread.currentThread().name}-1")
job.start()
println("runBlocking----${Thread.currentThread().name}-2")
job.cancel()
println("runBlocking--CANCLE--${Thread.currentThread().name}-3")
}
也就是将isDisp…=false的情况
那么和DEFAULT就差不多了 不过依然要等start后会立刻切回到协程执行
ATOMIC
val job = launch( start = CoroutineStart.ATOMIC) {
println("launch----${Thread.currentThread().name}")
delay(100)
println("launch--delay--${Thread.currentThread().name}")
}
println("runBlocking----${Thread.currentThread().name}-2")
job.cancel()
println("runBlocking--CANCLE--${Thread.currentThread().name}-3")
这个不做过多解释 和DEFAULT 差不多 但是唯一的差别就是 启动协程后到第一个挂起点 之间的携程代码 是不可被cancle的
UNDISPATCHED
这个就和isDispaterNeed=false 一样 先执行协程 直到第一个挂起点
总结一下:对于上面 启动模式如果都在调度器为true的情况下除了undispated 都是优先执行我们协程构建器的代码 再运行协程代码
还有就是如果协程后执行的 能被提前取消
下面我们看下调度器
不难从上面的代码中我们发现 如果未指定调度器 以及我们的各种启动模式均运行在主线程
1.不适用调度器
运行在Main线程中
2.default调度器下:
使用的并非父线程 而是新建线程 并且复用较高
最重要的一点就是同一个协程 挂起前 和挂起后并不是同一个线程!
注意 并不是挂起生成了不同的线程 而是调度器去生成的
IO调度器也一样
不同的是IO调度器更适合长时间运行任务 可以看到线程的复用机制较低 而default 偏高
而Unconfined
我们发现其第一次挂起前运行在父协程所在线程 之后运行在默认线程池
总结下 :调度器决定我们的携程运行在哪个线程
启动模式决定我们的协程运行先后顺序
最后用图来表示本文的结束:
