Kotlin协程系列文章：《一、Kotlin协程系列：协程的创立与发动，挂起和恢复》

Kotlin协程系列文章：《二、Kotlin协程系列：协程的线程调度》

在榜首篇文章中咱们剖析了协程发动创立进程发动进程，在本文中，咱们将着重剖析协程中协程调度的逻辑流程。主要是剖析解答如下2个问题：

1. 涉及到协程办法器是怎么将协程代码调度到特定的线程履行？

2. 子协程履行完又是怎么切换回父协程的线程环境？

一、协程的分发器作用

1.1 测验代码

GlobalScope.launch {
    //协程体1
    Log.d(TAG, "before suspend job.")
    withContext(Dispatchers.Main) {
        //协程体2
        Log.d(TAG, "print in Main thread.")
    }
    Log.d(TAG, "after suspend job.")
}

• 此次的协程测验用例中，咱们默许的launch一个协程，咱们简单的将launch需求履行的这外层逻辑为协程体1。
• 在协程体1中，咱们运用withContext将协程切换到主线程履行，打印日志。咱们将这儿边履行的协程逻辑为协程体2。
• 协程体2履行完成后，切回协程体1中履行并打印Log。
• 留意，依据咱们之前《协程的创立与发动》文章中剖析的，Kotlin编译器针对协程体1和协程体2分别生成一个承继与SuspenLamabda的类型，比方：class MainActivity#onCreate$1 : SuspenLambda{...}。咱们在讲协程体时，也一起代指这个类实例。

持续盯梢launch()函数履行逻辑，这次盯梢进程不同与《协程的创立与发动》篇章，咱们会将侧重点放在发动进程中协程调度器是怎么起作用的？接下来见1.2

1.2 CoroutineScope.launch

public fun CoroutineScope.launch(
    context: CoroutineContext = EmptyCoroutineContext,
    start: CoroutineStart = CoroutineStart.DEFAULT,
    block: suspend CoroutineScope.() -> Unit
): Job {
    //1. 见1.2.1
    val newContext = newCoroutineContext(context)
    val coroutine = if (start.isLazy)
        LazyStandaloneCoroutine(newContext, block) else
        StandaloneCoroutine(newContext, active = true)
    //2. 详见1.3
    coroutine.start(start, coroutine, block)
    return coroutine
}

1. 这儿会新建一个CoroutineContext，详见1.2.1
2. 依据之前的剖析，这个里终究会调用到startCoroutineCancellable()办法，详见1.3流程。

1.2.1 newCoroutineContext

public actual fun CoroutineScope.newCoroutineContext(context: CoroutineContext): CoroutineContext {
    val combined = foldCopies(coroutineContext, context, true)
    val debug = if (DEBUG) combined + CoroutineId(COROUTINE_ID.incrementAndGet()) else combined
    return 
    if (combined !== Dispatchers.Default && combined[ContinuationInterceptor] == null)
        debug + Dispatchers.Default
    else 
    	debug
}

1. coroutineContext：coroutineContext是CoroutineScope的成员变量，当此刻为GlobalScope.coroutineContext==EmptyCoroutineContext
2. context：因为调用launch时没有指定Context，所以传到此处也是EmptyCoroutineContext。foldCopies()函数将2个context相加并复制，终究combied==EmptyCoroutineContext。

而在return这最终判别回来的是debug+Dispatchers.Defatult，所以此刻默许的分发器为Dispatchers.Defatult。

这儿涉及到的协程Context运算不做深化剖析，简单能够以为协程重写了“+”运算，使得Context之间能够运用“+”来叠加，没有的Element类型会被添加到Element调集，调集中已有的Element类型会被覆盖。

1.3 startCoroutineCancellable

internal fun <R, T> (suspend (R) -> T).startCoroutineCancellable(
    receiver: R, completion: Continuation<T>,
    onCancellation: ((cause: Throwable) -> Unit)? = null
) =
    runSafely(completion) {
    	//1. 创立SuspendLambda协程体
        createCoroutineUnintercepted(receiver, completion)
            //2. 阻拦：取出分发器，并构建办法器Continuation。详见1.3.1
            .intercepted()
            //3. 调用办法器Continuation的resume办法，详见1.4
            .resumeCancellableWith(Result.success(Unit), onCancellation)
    }

1. 这儿的构建协程体在《协程的创立与发动》一节中现已剖析，不再赘述。
2. 进行阻拦，留意：这儿其实会依据办法器再构建出一个DispatchedContinuation目标，它也是一个续体类型，这是对协程体的一次包装。详见1.3.1末节。
3. 调用阻拦器续体的resumeCancellableWith()开端状况机流转，履行分发流程详见1.4末节。

1.3.1 intercepted()

 public fun intercepted(): Continuation<Any?> =
        intercepted?: (
                //1. 取出阻拦器
                context[ContinuationInterceptor]?
                    //2.构建阻拦器续体
                    .interceptContinuation(this)?: this)
                .also { intercepted = it }

1. 取出当时上下文中的阻拦器类型，依据之前1.2.1末节的剖析，这儿取出来的是Dispatchers.Defatult。
2. interceptContinuation(this)为构建阻拦器续体，留意这儿传入的this是协程体1。 详见1.3.2。

1.3.2 CoroutineDispatcher

//Base class to be extended by all coroutine dispatcher implementations.
public abstract class CoroutineDispatcher :
    AbstractCoroutineContextElement(ContinuationInterceptor), ContinuationInterceptor {
public final override fun <T> interceptContinuation(continuation: Continuation<T>):
        //详见1.4
        Continuation<T> = DispatchedContinuation(this, continuation)
}

直接新建了一个DispatchedContinuation目标实例这儿需求留意传入的构建参数：

1. this：当时Dispatcher，也便是Dispatchers.Defatult。
2. continuation：协程体1。

1.3.3 小结

自此Continuation.intercepted()办法就剖析完毕，终究的结果是：用上下文中的Dispatcher和当时Contination目标也便是协程体1，一起作为构建参数，新建了一个DispatchedContinuation目标。接下来接着1.3中的第三点，调用DispatchedContinuation.resumeCancellableWith()办法开端剖析。

1.4 DispatchedContinuation

internal class DispatchedContinuation<in T>(
    //1. 分发器
    @JvmField val dispatcher: CoroutineDispatcher,
	//2. 留意这儿将Continuation的完成托付给了continuation成员变量。
    @JvmField val continuation: Continuation<T>
) : DispatchedTask<T>(MODE_UNINITIALIZED)
, CoroutineStackFrame,
Continuation<T> by continuation {
    	//3. 复写特点delegate为自己
	    override val delegate: Continuation<T>
        get() = this
    ...
    // We inline it to save an entry on the stack in cases where it shows (unconfined dispatcher)
    // It is used only in Continuation<T>.resumeCancellableWith
    @Suppress("NOTHING_TO_INLINE")
    inline fun resumeCancellableWith(
        result: Result<T>,
        noinline onCancellation: ((cause: Throwable) -> Unit)?
    ) {
        val state = result.toState(onCancellation)
        //默许为true
        if (dispatcher.isDispatchNeeded(context)) {
            _state = state
            resumeMode = MODE_CANCELLABLE
            //4. 详细见
            dispatcher.dispatch(context, this)
        } else {
            executeUnconfined(state, MODE_CANCELLABLE) {
                if (!resumeCancelled(state)) {
                    resumeUndispatchedWith(result)
                }
            }
        }
    }
}

这儿的dispatcher==Dispatchers.Defatult，所以接下来需求解析Dispatchers.Defatult到底是什么东西。详见1.5

1. 成员变量dispatcher==Dispatchers.Default。
2. 成员变量continucation==协程体1（SuspenLambda类型实例）。一起DispatchedContinuation承继于Continuation接口，它将Continuation接口的完成托付给了成员变量continuation。
3. deleagte为复写了DispatchedTask.delegate特点，将其回来自己。
4. 调用分发器也便是Dispatchers.Defatult的dispatch()办法，留意这儿传入的参数：

• • context：来自Continuation接口的特点，因为托付给了成员变量continuation，所以此context==continuation.context。
  • this：分发器自身Dispatchers.Defatult

自此这个办法的剖析完毕：调用分发器的进行分发，接下来剖析就开端剖析协程办法器CoroutineDispatcher

1.5 DefaultScheduler

//Dispathcer.kt
@JvmStatic
public actual val Default: CoroutineDispatcher = DefaultScheduler
//Dispathcer.kt
// Instance of Dispatchers.Default
internal object DefaultScheduler : SchedulerCoroutineDispatcher(
    CORE_POOL_SIZE, MAX_POOL_SIZE,
    IDLE_WORKER_KEEP_ALIVE_NS, DEFAULT_SCHEDULER_NAME
) {
    ...
}

实践上是承继 SchedulerCoroutineDispatcher类型。详见1.5.1

1.5.1 SchedulerCoroutineDispatcher

internal open class SchedulerCoroutineDispatcher(
    private val corePoolSize: Int = CORE_POOL_SIZE,
    private val maxPoolSize: Int = MAX_POOL_SIZE,
    private val idleWorkerKeepAliveNs: Long = IDLE_WORKER_KEEP_ALIVE_NS,
    private val schedulerName: String = "CoroutineScheduler",
) : ExecutorCoroutineDispatcher() {
    override val executor: Executor
        get() = coroutineScheduler
    // This is variable for test purposes, so that we can reinitialize from clean state
    private var coroutineScheduler = createScheduler()
    private fun createScheduler() =
        //1. 详见1.5.2
        CoroutineScheduler(corePoolSize, maxPoolSize, idleWorkerKeepAliveNs, schedulerName)
    //2. 详见1.5.2
    override fun dispatch(context: CoroutineContext, block: Runnable): Unit 
    = coroutineScheduler.dispatch(block)
    ...
}
//Executors.kt
//2. 实践上是承继ExecutorCoroutineDispatcher
public abstract class ExecutorCoroutineDispatcher: CoroutineDispatcher(), Closeable {
    ...
}

1. 能够看到实践上调用了CoroutineScheduler.dispatch办法。此刻发现，第二个参数是Runnable类型的，而在1.4末节中，咱们知道传入的是this也便是DispatchedContinuation，所以DispatchedContinuation承继的父类中，必定有承继了Runnable接口，而他的run办法的完成也在父类中，这块咱们暂时按下不表，接着看持续盯梢coroutineScheduler.dispatch(block)。

1.5.2 CoroutineScheduler

internal class CoroutineScheduler(
    @JvmField val corePoolSize: Int,
    @JvmField val maxPoolSize: Int,
    @JvmField val idleWorkerKeepAliveNs: Long = IDLE_WORKER_KEEP_ALIVE_NS,
    @JvmField val schedulerName: String = DEFAULT_SCHEDULER_NAME
) : Executor, Closeable {
	... 
    override fun execute(command: Runnable) = dispatch(command)
    fun dispatch(block: Runnable, taskContext: TaskContext = NonBlockingContext, tailDispatch: Boolean = false) {
        trackTask() // this is needed for virtual time support
        val task = createTask(block, taskContext)
        // try to submit the task to the local queue and act depending on the result
        val currentWorker = currentWorker()
        val notAdded = currentWorker.submitToLocalQueue(task, tailDispatch)
        if (notAdded != null) {
            if (!addToGlobalQueue(notAdded)) {
                // Global queue is closed in the last step of close/shutdown -- no more tasks should be accepted
                throw RejectedExecutionException("$schedulerName was terminated")
            }
        }
        val skipUnpark = tailDispatch && currentWorker != null
        // Checking 'task' instead of 'notAdded' is completely okay
        if (task.mode == TASK_NON_BLOCKING) {
            if (skipUnpark) return
            signalCpuWork()
        } else {
            // Increment blocking tasks anyway
            signalBlockingWork(skipUnpark = skipUnpark)
        }
    }
}

1. 该类承继了Executor类，并且它的构建参数可看到是线程池的参数，所以能够知道这个其实是Kotlin协程完成的一个线程池，详细就不跟进去了。
2. execute()进程也是dispatch进程：将使命投递到使命队列，然后通知线程去取使命履行，自此完成了线程切换动作。
3. 而在新线程里履行的Runnable为1.4中的调用代码：dispatcher.dispatch(context, this)中的this，也便是DispatchedContinuation。DispatchedContinuation.kt并没有完成run办法，那么一定是他承继的父类完成了Runnable接口并完成，所以需求接着看它承继的父类：DispatchedTask类。

1.6 DispatchedTask.run()

internal abstract class DispatchedTask<in T>(
    @JvmField public var resumeMode: Int
) : SchedulerTask() {
	...
    internal abstract val delegate: Continuation<T>
    @Suppress("UNCHECKED_CAST")
    internal open fun <T> getSuccessfulResult(state: Any?): T =
        state as T
    internal open fun getExceptionalResult(state: Any?): Throwable? =
        (state as? CompletedExceptionally)?.cause
    public final override fun run() {
        assert { resumeMode != MODE_UNINITIALIZED } // should have been set before dispatching
        val taskContext = this.taskContext
        var fatalException: Throwable? = null
        try {
            val delegate = delegate as DispatchedContinuation<T>
            //1. 取出代理商的续体
            val continuation = delegate.continuation
            withContinuationContext(continuation, delegate.countOrElement) {
                val context = continuation.context
                val state = takeState() // NOTE: Must take state in any case, even if cancelled
                val exception = getExceptionalResult(state)
                val job = if (exception == null && resumeMode.isCancellableMode) context[Job] else null
                if (job != null && !job.isActive) {
                    val cause = job.getCancellationException()
                    cancelCompletedResult(state, cause)
                    continuation.resumeWithStackTrace(cause)
                } else {
                    if (exception != null) {
                        continuation.resumeWithException(exception)
                    } else {
                        //1. 被包装的续体的resume办法，真正的开端动身其协程状况机代码。
                        continuation.resume(getSuccessfulResult(state))
                    }
                }
            }
        } catch (e: Throwable) {
            // This instead of runCatching to have nicer stacktrace and debug experience
            fatalException = e
        } finally {
            val result = runCatching { taskContext.afterTask() }
            handleFatalException(fatalException, result.exceptionOrNull())
        }
    }
}

1. 将delegate转为DispatchedContinuation，应该留意1.4 末节中DispatchedContinuation承继DispatchTask时，便对此delegate进行了复写：

override val delegate: Continuation

get() = this

而此delegate.continucation便是当初newDispatchedContinuation(this)时传入的this，此this便是Kotlin编译器一开端为协程体生成的SuspendLambda类型目标。详细能够回看1.3末节。

2. 调用了continuation.resume()办法触发了协程的状况机从而开端履行协程事务逻辑代码，结合之前1.5.2的剖析能够知道，这个办法的调用现已是被dispatch到特定线程，完成线程切换后履行的。所以协程状况机的代码也是跑在新线程上的。

1.7 总结

至此，协程的线程调度剖析完毕，关键有如下几个关键：

1. 创立SuspendLambda时，他的协程上下文目标来自于comletion.context，默许便是Dispatcher.Default。
2. SuspendLambda发动时调用了intercept()进行一层包装，得到DispatchedContinuation，后续协程发动是发动的DispatchedContinuation协程。
3. DispatchedContinuation承继于Runnable接口，协程发动时将自己投递到分发器dispatcher履行run办法，从而到达了线程切换作用。
4. 在DispatchedContinuation的run办法中，调用SuspendLambda.resume()发动状况机。在新线程履行协程状况机代码。

这一末节中，介绍了怎么将协程调度到意图线程履行，接下来剖析怎么做到随意切换线程后，然后再恢复到本来线程的。

二、协程中的线程切换

在榜首末节中，咱们搞清楚了协程发动时，协程调度器是怎么在其间起作用的。这一末节旨在剖析在协程用分发器切换线程履行新的挂起函数后，是怎么切换会本来线程持续履行剩下的逻辑的。

为此，咱们需求将1.1的测验代码反编译出来实践代码从而剖析。

2.1 反编译代码

2.1.1 MainActivity$onCreate$1

final class MainActivity$onCreate$1 extends SuspendLambda implements Function2<CoroutineScope, Continuation<? super Unit>, Object> {
    ...
    @Override // kotlin.coroutines.jvm.internal.BaseContinuationImpl
    public final Object invokeSuspend(Object $result) {
        Object coroutine_suspended = IntrinsicsKt.getCOROUTINE_SUSPENDED();
        switch (this.label) {
            case 0:
                ResultKt.throwOnFailure($result);
                Log.d(MainActivity.TAG, LiveLiterals$MainActivityKt.INSTANCE.m4147xf96cab04());
                this.label = 1;
                //1. 新建编译器主动生成的承继于SuspendLambda的类型。
                AnonymousClass1 anonymousClass1 = new AnonymousClass1(null);
                //2. 调用withContext
            	Object res = BuildersKt.withContext(Dispatchers.getIO(), anonymousClass1, this);
                if (res != coroutine_suspended) {
                    break;
                } else {
                    //挂起
                    return coroutine_suspended;
                }
            case 1:
                ResultKt.throwOnFailure($result);
                break;
            default:
                throw new IllegalStateException("call to 'resume' before 'invoke' with coroutine");
        }
        Log.d(MainActivity.TAG, LiveLiterals$MainActivityKt.INSTANCE.m4148xe0c1b328());
        return Unit.INSTANCE;
    }
}

1. 依据之前的文章剖析，这儿suspend lambda 的类型都主动生成承继于SuspendLambda的类型。详见2.1.2。

2. 将anonymousClass1传入withContext，并且留意这儿传入了this==MainActivity$onCreate$1，详见2.2。

2.1.2 AnonymousClass1

/* compiled from: MainActivity.kt */
public static final class AnonymousClass1 extends SuspendLambda implements Function2<CoroutineScope, Continuation<? super Integer>, Object> {
    int label
    ...
    @Override // kotlin.coroutines.jvm.internal.BaseContinuationImpl
    public final Object invokeSuspend(Object obj) {
        IntrinsicsKt.getCOROUTINE_SUSPENDED();
        switch (this.label) {
            case 0:
                ResultKt.throwOnFailure(obj);
                return Boxing.boxInt(Log.d(MainActivity.TAG, LiveLiterals$MainActivityKt.INSTANCE.m4146x7c0f011f()));
            default:
                throw new IllegalStateException("call to 'resume' before 'invoke' with coroutine");
        }
    }
}

2.2 withContext

public suspend fun <T> withContext(
    context: CoroutineContext,
    block: suspend CoroutineScope.() -> T
): T {
    contract {
        callsInPlace(block, InvocationKind.EXACTLY_ONCE)
    }
    //1. 获取当时协程, 留意这儿的uCont便是当时续体，也便是MainActivity$onCreate$1
    return suspendCoroutineUninterceptedOrReturn sc@ { uCont ->
        //2. 核算获的新的协程上下文
        val oldContext = uCont.context
        val newContext = oldContext + context
        //3. 快速判别：新上下文和旧上下文共同的情况快速处理。
        // always check for cancellation of new context
        newContext.ensureActive()
        // FAST PATH #1 -- new context is the same as the old one
        if (newContext === oldContext) {
            val coroutine = ScopeCoroutine(newContext, uCont)
            return@sc coroutine.startUndispatchedOrReturn(coroutine, block)
        }
        // FAST PATH #2 -- the new dispatcher is the same as the old one (something else changed)
        // `equals` is used by design (see equals implementation is wrapper context like ExecutorCoroutineDispatcher)
        if (newContext[ContinuationInterceptor] == oldContext[ContinuationInterceptor]) {
            val coroutine = UndispatchedCoroutine(newContext, uCont)
            // There are changes in the context, so this thread needs to be updated
            withCoroutineContext(newContext, null) {
                return@sc coroutine.startUndispatchedOrReturn(coroutine, block)
            }
        }
        // SLOW PATH -- use new dispatcher
        //4. 新建一个DispatchedCoroutine
        val coroutine = DispatchedCoroutine(newContext, uCont)
        //5. 发动协程
        block.startCoroutineCancellable(coroutine, coroutine)
        coroutine.getResult()
    }
}

1. suspendCoroutineUninterceptedOrReturn这个函数直接步进是看不到完成的，它的完成是由Kotlin编译器生成的，它的作用是用来获取当时续体的，并且经过uCont回来，这儿便是MainActivity$onCreate$1。

2. 将旧协程上下文和新的上下文一起。核算得到终究的上下文。这儿的context==Dispatchers.getIO()。

3. 快速判别，不用看。

4. 新建一个DispatchedCoroutine，留意这儿传入了新的协程上下文和当时续体目标。

5. 调用startCoroutineCancellable()发动协程。这儿的同1.3.2末节剖析一样，详见 2.2.1

2.2.1 startCoroutineCancellable

internal fun <R, T> (suspend (R) -> T).startCoroutineCancellable(
    receiver: R, completion: Continuation<T>,
    onCancellation: ((cause: Throwable) -> Unit)? = null
) =
    runSafely(completion) {
    	//1. 创立SuspendLambda协程体
        createCoroutineUnintercepted(receiver, completion)
            //2. 阻拦：取出分发器，并构建办法器Continuation。详见1.3.1
            .intercepted()
            //3. 调用办法器Continuation的resume办法，详见1.4
            .resumeCancellableWith(Result.success(Unit), onCancellation)
    }

此办法在之前1.3末节现已剖析过，针对此此次调用，其间的改动是协程上下文中的分发器现已被设置为Dispatchers.Main。

1. 创立了SuspendLambda目标，此目标的CoroutineContext为completion.context。而其间的ContinuationInterceptor类型Element便是咱们之前传入的Dispatchers.Main。

2. 创立一个DispatchedContinuation。

3. 将协程SuspendLambda的状况机逻辑经过Dispatcher.Main调度到主线程履行，调度进程参考榜首下节。分发逻辑详见2.7末节。

4. 当SuspendLambda的状况机invokeSuspend()逻辑履行完成后，会回来到BaseContinuationImpl.resumeWith()，咱们需求接此办法剖析，来得到协程在切换到主线程履行后，又是怎么切回协程体1的履行线程的，详见2.3。

2.3 resumeWith

public final override fun resumeWith(result: Result<Any?>) {
        // This loop unrolls recursion in current.resumeWith(param) to make saner and shorter stack traces on resume
        var current = this
        var param = result
        while (true) {
            // Invoke "resume" debug probe on every resumed continuation, so that a debugging library infrastructure
            // can precisely track what part of suspended callstack was already resumed
            probeCoroutineResumed(current)
            with(current) {
                val completion = completion!! // fail fast when trying to resume continuation without completion
                val outcome: Result<Any?> =
                    try {
                        val outcome = invokeSuspend(param)
                        if (outcome === COROUTINE_SUSPENDED) return
                        Result.success(outcome)
                    } catch (exception: Throwable) {
                        Result.failure(exception)
                    }
                releaseIntercepted() // this state machine instance is terminating
                if (completion is BaseContinuationImpl) {
                    // unrolling recursion via loop
                    current = completion
                    param = outcome
                } else {
                    //1. 进入此判别
                    // top-level completion reached -- invoke and return
                    completion.resumeWith(outcome)
                    return
                }
            }
        }
    }

当状况机履行完后， 后进入到completion的类型判别，由2.2和2.2.1能够知道，当初传入的completion是DispatchedCoroutine类型，所以加入到else分支，调用了DispatchedCoroutine.resumeWith()，接下来剖析此办法。

在此之前，咱们需求看下DispatchedCoroutine的承继联系，详见2.4.1。假如想直接盯梢流程，能够直接看2.4.2。

2.4 DispatchedCoroutine

2.4.1 DispatchedCoroutine 的承继联系

internal class DispatchedCoroutine<in T>(
    context: CoroutineContext,
    uCont: Continuation<T>
) : ScopeCoroutine<T>(context, uCont) {
}

承继于ScopeCoroutine

internal open class ScopeCoroutine<in T>(
    context: CoroutineContext,
    @JvmField val uCont: Continuation<T> // unintercepted continuation
) : AbstractCoroutine<T>(context, true, true), CoroutineStackFrame {
}

承继于AbstractCoroutine

public abstract class AbstractCoroutine<in T>(
    parentContext: CoroutineContext,
    initParentJob: Boolean,
    active: Boolean
) : JobSupport(active), Job, Continuation<T>, CoroutineScope {
}

2.5 协程线程的恢复

2.5.1 AbstractCoroutine.resumeWith()

    public final override fun resumeWith(result: Result<T>) {
        val state = makeCompletingOnce(result.toState())
        if (state === COMPLETING_WAITING_CHILDREN) return
        afterResume(state)
    }

调用了afterResume办法，此办法在DispatchedCoroutine类型有详细完成。见2.5.2

2.5.2 afterResume

//DispatchedCoroutine
override fun afterResume(state: Any?) {
        if (tryResume()) return // completed before getResult invocation -- bail out
        // Resume in a cancellable way because we have to switch back to the original dispatcher
        uCont.intercepted().resumeCancellableWith(recoverResult(state, uCont))
}

1. 取出当时续体uCont，这个续体依据之前的剖析：2.2末节，能够知道它等于MainActivity$onCreate$1。

2. intercepted()：取出其分发阻拦器

3. resumeCancellableWith：运用办法阻拦器协程体，将uCont续体的状况机逻辑调度到相对应的线程环境履行，这儿便是之前的Dispatcher.Default。留意其注释：“将其切换到原先的分发器”。2⃣而这一进程其实和1.3末节的进程共同。

4. 恢复到Dispatcher.Default持续履行状况机时，因为label现已被更新，所以会往下持续履行，打印最终一句log。

2.6 总结

1. withContext(Dispatcher.Main)发动的协程时，获得当时协程续体uCount也便是MainActivity$onCreate$1，会核算出新的协程context，然后用它们创立一个DispatchedCoroutine。

2. AnonymousClass1协程发动时，用DispatchedCoroutine作为completion参数，然后发动，此刻会调度主线程履行协程。

3. 当协程履行完成后，AnonymousClass1.resumeWith()办法会调用completion.resumeWith()。

4. DispatchedCoroutine.resumeWith()办法会调用uCount.intercepted().resumeCancellableWith()，使得父协程进行调度并接着履行状况机逻辑。

2.7 Dispatchers.Main

    @JvmStatic
    public actual val Main: MainCoroutineDispatcher get() 
= MainDispatcherLoader.dispatcher

直接详见2.7.1

2.7.1 MainDispatcherLoader

internal object MainDispatcherLoader {
    private val FAST_SERVICE_LOADER_ENABLED = systemProp(FAST_SERVICE_LOADER_PROPERTY_NAME, true)
    @JvmField
    val dispatcher: MainCoroutineDispatcher = loadMainDispatcher()
    private fun loadMainDispatcher(): MainCoroutineDispatcher {
        return try {
            val factories = if (FAST_SERVICE_LOADER_ENABLED) {
                FastServiceLoader.loadMainDispatcherFactory()
            } else {
                // We are explicitly using the
                // `ServiceLoader.load(MyClass::class.java, MyClass::class.java.classLoader).iterator()`
                // form of the ServiceLoader call to enable R8 optimization when compiled on Android.
                // 1.获得MainDispatcherFactory的完成类
                ServiceLoader.load(
                        MainDispatcherFactory::class.java,
                        MainDispatcherFactory::class.java.classLoader
                ).iterator().asSequence().toList()
            }
            @Suppress("ConstantConditionIf")
            factories.maxByOrNull { it.loadPriority }?.tryCreateDispatcher(factories)
                ?: createMissingDispatcher()
        } catch (e: Throwable) {
            // Service loader can throw an exception as well
            createMissingDispatcher(e)
        }
    }
}

1. 经过ServiceLoad机制获取MainDispatcherFactory的完成类，而在源码里边，其完成类为AndroidDispatcherFactory
2. 调用tryCreateDispatcher()创立分发器，详见2.7.2。

2.7.2 AndroidDispatcherFactory

internal class AndroidDispatcherFactory : MainDispatcherFactory {
    override fun createDispatcher(allFactories: List<MainDispatcherFactory>) =
        HandlerContext(Looper.getMainLooper().asHandler(async = true))
    override fun hintOnError(): String = "For tests Dispatchers.setMain from kotlinx-coroutines-test module can be used"
    override val loadPriority: Int
        get() = Int.MAX_VALUE / 2
}

依据createDispatcher分发，主线程分发器的完成类为HandlerContext类型，传入用MainLooper构建的Handler。详见2.7.3。

2.7.3 HandlerContext

internal class HandlerContext private constructor(
    private val handler: Handler,
    private val name: String?,
    private val invokeImmediately: Boolean
) : HandlerDispatcher(), Delay {
    /**
     * Creates [CoroutineDispatcher] for the given Android [handler].
     *
     * @param handler a handler.
     * @param name an optional name for debugging.
     */
    constructor(
        handler: Handler,
        name: String? = null
    ) : this(handler, name, false)
    @Volatile
    private var _immediate: HandlerContext? = if (invokeImmediately) this else null
    override val immediate: HandlerContext = _immediate ?:
        HandlerContext(handler, name, true).also { _immediate = it }
    override fun isDispatchNeeded(context: CoroutineContext): Boolean {
        return !invokeImmediately || Looper.myLooper() != handler.looper
    }
    override fun dispatch(context: CoroutineContext, block: Runnable) {
        if (!handler.post(block)) {
            cancelOnRejection(context, block)
        }
    }
    override fun scheduleResumeAfterDelay(timeMillis: Long, continuation: CancellableContinuation<Unit>) {
        val block = Runnable {
            with(continuation) { resumeUndispatched(Unit) }
        }
        if (handler.postDelayed(block, timeMillis.coerceAtMost(MAX_DELAY))) {
            continuation.invokeOnCancellation { handler.removeCallbacks(block) }
        } else {
            cancelOnRejection(continuation.context, block)
        }
    }
   ...
}

HandlerContext承继于HandlerDispatcher，而他的dispatch办法，能够看到，便是将block丢到设置MainLooper的handler履行。所以续体将会在主线程履行状况机，到达切换到主线程履行协程的意图。