速通 - 协程

协程的概念最核心的点就是一段程序能够被挂起,稍后在挂起的位置恢复,挂起和恢复是由使用者控制的。

数学模型

在一个线程的视角中,我们的程序是按照顺序来执行的,假设我们使用  ~  来描述一段程序的所有指令。

那么协程就是该指令流中的一部分(我们让该协程也运行在当前线程上),我们假设它为   ~ ,此时 0 < i < j < n。

协程中会存在挂起函数,假设挂起函数对应的指令为  ,此时 i < k < j。

协程神奇的地方就在于,当指令从  执行到   的时候,它是顺序的,和正常没有区别。

当指令从  执行到  的时候,也是和正常没有区别。

当指令遇到  的时候,该程序就不往下执行了,而是跑去执行  了,这就是我们上面所描述的该协程挂起了,那么什么时候恢复呢?

等挂起函数的工作做完了,协程就会恢复了,然后通过一些方式来告知当前线程,该执行  到   的指令了。

上图中展示的是协程在当前线程的情况。

因为我们不知道挂起函数要耗时多久,所以,将3号线化成了虚线。

而且,我们应该注意到一个有趣的现象,就是挂起函数将协程代码分成了两块,原本我们在代码里面写的是一个连续的逻辑,但是从协程的角度来看,它们并不连续,理解这一点非常重要。

协程的基础

上面我们画了协程的流程,协程就是一个程序的代码块,为了简单起见,下面我们称呼协程为 Program code block,简称 PCB,非常的 nice。

我们做Android开发的,通常使用的是 kotlinx 封装了好多层之后的函数,里面隐藏了太多的东西,由于过于透明,反而导致难以理解,所以我们从最基础最重要的几个协程方法说起。

协程的创建

创建协程使用 createCoroutine 方法:

  val s = suspend {
        1
    }
    val c = s.createCoroutine(object : Continuation<Int> {
        override fun resumeWith(result: Result<Int>) {
            println("Coroutine End: $result")
        }
        override val context = EmptyCoroutineContext
    })
    c.resume(Unit)

我们先来看看 createCoroutine 的声明:

@SinceKotlin("1.3")
@Suppress("UNCHECKED_CAST")
public fun <T> (suspend () -> T).createCoroutine(
    completion: Continuation<T>
): Continuation<Unit>

其中 suspend()->T 是 createCoroutine 函数的宿主,也就是使用了扩展函数,需要一点 kotlin 的语法知识。我们能在一个 suspend {} 这样一个东西上调用该方法就是因为这种写法了。

上面的程序中,s 变量就是一个协程,可以看看源码:

@kotlin.internal.InlineOnly
@SinceKotlin("1.2")
@Suppress("INVISIBLE_MEMBER", "INVISIBLE_REFERENCE")
public inline fun <R> suspend(noinline block: suspend () -> R): suspend () -> R = block

可以看到它就是一个代码块,我们说一个协程是一个 PCB 也不是瞎说的。

协程里面会涉及到很多高阶函数的东西,这个与协程本身无关,但是会影响理解协程。

继续分析协程的创建代码,我们看到有一个参数completion,它在协程执行完成后调用,实际上就是协程的完成回调。

createCoroutine 返回一个 Continuation,我们像启动协程,就需要使用这个类了。

协程的启动

调用 continuation.resume(Unit) 之后,协程体会立即开始执行。这是为啥呢?

其实是由于,我们的编译器在处理协程代码块的时候,生成了一个类:

里面带$符号的类,就是编译器自动生成的。

当我们调用 Continuation 的方法时,它是一个 SafeContinuation 的实例,但是它只是一个包装类,真正执行逻辑的是里面的 delegate 变量,而这个 delegate 变量就是编译器生成的类的实例了。

至于它是如何传递进去的,有兴趣的可以自行研究,不深入了。

反正就是 resume 方法经过一些方法调用,最后会调用到 invokeSuspend 方法里面,该方法就是储存的协程代码块的逻辑。

而且最妙的地方在于,我们的 PCB,也就是 suspenc {} 被编译器改写成了 switch case 的方式。为啥要这样呢?前面说过了,挂起函数会将 PCB 分成好几个块,所以每一个块的逻辑会对应一个 case,如此这般,这般如此,协程运行时的流程就出来了。

来个例子

fun main() {
    testCreate()
}

fun testCreate() {
    val continuation = suspend {
        println("In Coroutine.")
        5
    }.createCoroutine(object : Continuation<Int> {
        override fun resumeWith(result: Result<Int>) {
            println("Coroutine End: $result")
        }
        override val context = EmptyCoroutineContext
    })

    continuation.resume(Unit)

    println("end")
}

该程序的输出如下:

In Coroutine.
Coroutine End: Success(5)
end

套一下我们上面画的图,协程里面没有挂起函数,所以协程是一个整体(该 PCB 只对应 switch 里面的一个 case),所以输出很明显和正常程序没啥区别。

再看第二个例子:

fun main() {
    testCreate()
}

fun testCreate() {
    val continuation = suspend {
        println("In Coroutine.")
        // 这里不同
        delay(3000)
        5
    }.createCoroutine(object : Continuation<Int> {
        override fun resumeWith(result: Result<Int>) {
            println("Coroutine End: $result")
        }
        override val context = EmptyCoroutineContext
    })

    continuation.resume(Unit)

    println("end")
}

与第一个例子不同的地方在于,我们在协程里面写了一个挂起函数 delay,delay 会切到别的线程去执行,我们后面再具体讨论。

可以想一下,现在程序的输出是什么,按照上面的模型来看,应该是:

In Coroutine.
end
Coroutine End: Success(5)

虽然思路是没错,但是由于我们是简单测试,所以 println("end") 执行完之后,程序就结束了,实际上是看不到 Coroutine End: Success(5) 打印出来的,实际输出如下:

In Coroutine.
end

协程的启动2

一般来讲,我们创建协程后就会立即让它开始执行,因此标准库提供了一个一步到位的API——startCoroutine。它与createCoroutine除了返回值类型不同之外,剩下的完全一致:

@SinceKotlin("1.3")
@Suppress("UNCHECKED_CAST")
public fun <T> (suspend () -> T).startCoroutine(
    completion: Continuation<T>
)

挂起函数

上面我们说到,一个挂起函数会将 PCB 挂起(切成2块),而使用 suspend 关键字我们就能创建一个挂起函数:

suspend fun nothing() {}

那么,我们使用这个函数能挂起协程吗?看代码:

fun main() {
    testSuspendFunc()
}

suspend fun nothing() {}

fun testSuspendFunc() {
    val continuation = suspend {
        println("before nothing.")
        nothing()
        println("after nothing.")
        5
    }.createCoroutine(object : Continuation<Int> {
        override fun resumeWith(result: Result<Int>) {
            println("Coroutine End: $result")
        }
        override val context = EmptyCoroutineContext
    })

    continuation.resume(Unit)

    println("end")
}

按照,我们的模型,该输出应该是:

before nothing.
end
after nothing.
Coroutine End: Success(5)

但是不是,实际输出是:

before nothing.
after nothing.
Coroutine End: Success(5)
end

为何会如此呢?很简单,应为编译器知道你只是写了一个假的挂起函数,所以并没有真正的将 PCB 分成两块。

我们看一下编译后的代码就明白了:

可以看到,编译器确实是将 PCB 进行切块了,但是它很鸡贼,它判断了挂起函数的返回值,如果这个函数的返回值不是挂起状态,说明是个冒牌货,那么就 break,然后执行后部分的代码。

我们应该注意到,这个挂起函数的返回值非常的重要。

所以,可以思考一下,我们在协程里面的任意地方添加 Thread.sleep() 函数会影响输出结果吗?假设我们能将 nothing() 的返回值改成COROUTINE_SUSPENDED又会怎样?

挂起协程

协程库里面有很多内置的挂起函数,那么它们是如何做到挂起协程的呢?

有一个基础函数可以做到,suspendCoroutine,它可以获取到它所运行在的协程对象。

@SinceKotlin("1.3")
@InlineOnly
public suspend inline fun <T> suspendCoroutine(crossinline block: (Continuation<T>) -> Unit): T {
    contract { callsInPlace(block, InvocationKind.EXACTLY_ONCE) }
    return suspendCoroutineUninterceptedOrReturn { c: Continuation<T> ->
        val safe = SafeContinuation(c.intercepted())
        block(safe)
        safe.getOrThrow()
    }
}

可以看到这个函数的返回值是 safe.getOrThrow() 。

当我们启动一个协程的时候,改协程的结果状态为 UNDECIDED,然后我们在协程里面调用 suspendCoroutine,该函数会返回 COROUTINE_SUSPENDED ,导致协程逻辑上真正的被切片。

我们实践一下,看一个例子:

suspend fun suspendFunc02() = suspendCoroutine<Int> { _ -> }

fun main() {
    suspend {
        println("a")
        suspendFunc02()
        println("b")
    }.startCoroutine(object : Continuation<Unit> {
        override val context = EmptyCoroutineContext

        override fun resumeWith(result: Result<Unit>) {
            result.getOrThrow()
        }
    })
    println("c")
}

这个程序的输出是:

a
c

为何后面没有输出b呢?是因为协程一直被挂起,没有人恢复它。所以我们想写一个自己的挂起函数,还需要考虑如何恢复协程。

那么如何恢复呢?suspendCoroutine 提供了一个参数,它可以操作我们的协程对象:

suspend fun suspendFunc02() = suspendCoroutine<Int> { c -> 
    c.resume(996)
}

问题在于,这样直接写行吗?我们上面贴过 suspendCoroutine 的逻辑,它会先执行 block,也就是我们写的 c.resume(996) 这行代码,然后再  getOrThrow 获取返回值。

巧就巧在,resume 方法会改变 result 的值为 996,从而导致 getOrThrow 的返回值变成 996,也就是说协程不会挂起。

所以,这样写之后,会输出:

a
b
c

做一个实验

现在我们已经掌握了协程的所有基本操作方法(创建,启动,挂起,恢复),是时候写代码了。

我们希望做这样的一个功能:

fun testSuspend() {
    val suspend = Suspend {
        for (i in 1..5) {
            g(i)
        }
    }

    println(suspend.c())
    println(suspend.c())
    println(suspend.c())
    println(suspend.c())
    println(suspend.c())
}

我们创建的 Suspend 类接受一个 block,然后这个 block 有一个 g 方法可供调用者使用。

每次调用 g 方法,Suspend 类就应该延迟生成一个数字,然后调用其 c 方法的时候,才会真正的生成并输出该数字。这个功能其实就是模拟的 python 的 generator 了。

想要做到这样,显然需要在执行 g 方法的时候,挂起当前协程,然后等待 c 方法调用的时候,再恢复协程,理解了这个,写起代码来不是很简单。

class Suspend(block: suspend Scope.() -> Unit):Scope {

    private var continuation: Continuation<Unit>? = null
    private var num:Int = 0

    init {
        val coroutineBlock: suspend Scope.() -> Unit =
            { block() }
        coroutineBlock.startCoroutine( this, object : Continuation<Unit> {
            override fun resumeWith(result: Result<Unit>) {
            }
            override val context = EmptyCoroutineContext
        })
    }

    fun c() :Int{
        val result = num
        continuation?.resume(Unit)
        return result
    }

    override suspend fun g(value:Int) : Unit {
        return suspendCoroutine { continuation ->
            this.continuation = continuation
            this.num = value
        }
    }
}

init 创建协程,g 挂起协程,c 恢复协程,没啥好说的,当然kotlin的高阶函数不在该文章的讨论范围之内。

yield 函数

yield 函数是一个比较典型的例子,有助于我们理解其他的挂起函数。

看 yield 的一个例子:

fun main() {
    val singleDispatcher = newSingleThreadContext("Single")
    
    runBlocking {
        val job = launch {
            launch {
                withContext(singleDispatcher) {
                    repeat(3) {
                        println("Task1")
                        yield()
                    }
                }
            }

            launch {
                withContext(singleDispatcher) {
                    repeat(3) {
                        println("Task2")
                        yield()
                    }
                }
            }
        }

        job.join()
    }
}

该程序的输出为:

Task1
Task2
Task1
Task2
Task1
Task2

为啥会交替执行呢?

我们看看 yield 的代码:

别的先不看,我们看它的返回值是 COROUTINE_SUSPENDED,这说明它会将我们写的 repeat 函数拆分为 3 个部分:

两个子协程都运行在单线程池上,协程1在上,所以协程 1 的 repeat1 先放到线程池队列里面,然后是协程2 的 repeat 1。

再看 yield 的逻辑,追踪一下发现它只是往线程池里面 post 了一个 runnable,而 runnable 会调用 resume,resume 会导致程序执行下一个切片的片段,也就是 repeat 2,如下图:

然后,由于 task 2 的 repeat 1 也会 post,所以就形成了一个交替执行的效果:

这样的行为,让 yield 看起来拥有了让出协程执行权的能力,非常的牛逼。

官方框架

Kotlin协程的官方框架kotlin.coroutines是一套独立于标准库之外的以生产为目的的框架,框架本身提供了丰富的API来支撑生产环境中异步程序的设计和实现。

也就是说,关于协程,我们虽然掌握了根本,但是这些根本操作却有N多种组合方法,创造出各种各种的使用方法。但是万变不离其宗,掌握了根本,其他的无非就是一个花心思去深入的一个过程。

就像打游戏,我的世界,萌新只会”挖三填一“,大佬能够造出摩天大厦。

所以关于协程其他的东西,暂时不介绍了,希望各位能够自行学习。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值