协程上下文Coroutine Context:
在上一次的理论中提到了协程上下文Coroutine Context,其实所有的协程构建器(coroutine builder)如launch和async都会接收一个可选的CoroutineContext参数,该参数可用于显式指定新协程所运行的分发器以及其它上下文元素。咱们来看一下程序:
也就是我们可以指定其它的上下文分发器,接下来再来看一下async():
协程分发器:
首先咱们先编写个例子:
而launch它不是第一个参数是可以接收一个协程上下文么?所以咱们手动指定一下:
呃,不是要接收的是一个协程上下文类型么?咋传的是一个分发器呢?其实它也是一个上下文:
它的类型是一个Unconfined,那它是不是协程上下文类型呢,看一下它的层次继承体系既可:
嗯,接下来继续编写代码:
最后再来修改,对于协程我们知道它是运行在指定线程里面的,那能否指定某个线程来作为协程的分发器呢?答案是可以的,这里可以将线程池设置成协程的分发器,如下:
看下错误提示:
这里需要的是一个协程上下文类型,而很明显线程池用的是Java的方式不可能是Kotlin需要的协程上下文类型的,所以此时扩展方法则又会发生效能了:
所以代码修改如下:
也就是看一下每一个协程线程的运行情况,运行:
下面对于上面的程序进行一个解析:
1、当通过launch来启动协程并且不指定协程分发器时,它会继续启动它的那个CoroutineScope的上下文与分发器。对于该示例来说,它会继承runBlocing的上下文,而runBlocking则是运行在main线程当中。
2、Dispatchers.Unconfined是一种很特殊的协程分发器,它在该示例中也是运行在main线程中,但实际上,其运行机制与不指定协程分发器时是完全不同的。【在日常的开发中使用较少】
注意了!!如之前我们所解读的对于这个Unconfied的协程分发器它是不会局限于某一个特定的线程的:
那目前由于这个launch就是运行在main()线程当中,而输了也如预期是在main线程,不就是局限于某个线程,跟官方说的有点出入?其实不是这样的,这里只能说是凑巧而已,如果修改一下代码则运行结果又不一样了,如下:
也就是符合官网的解释了,不会局限于某个特定的线程了,那再来修改一下:
关于这块的原理剖析放下次继续。