协程这个概念已经出来很长时间了，网上对它的定义是非阻塞式的线程框架，讨论最多的也是协程的挂起、恢复以及线程切换，那到底挂起是个什么样的概念，怎么就挂起了，怎么就又恢复了？

带着这些问题，我走上了不归路…

在开始探索协程挂起、恢复之前，需要先了解一下几个重要的名词和概念。

1. Continuation

Continuation在协程中其实只是一个接口，其作用有点类似RxJava中Observer，当请求成功时，触发onNext继续更新UI或者下一步的操作。只不过在协程中，Continuation包装了协程在挂起之后应该继续执行的代码，在编译的过程中，一个完整的协程被分割切块成一个又一个续体。在 await 函数的挂起结束以后，它会调用 continuation 参数的 resumeWith 函数，来恢复执行 await 函数后面的代码。

2. invokeSuspend

invokeSuspend中包含的便是我们协程体中的代码，内部管理了一个状态值，循环触发invokeSuspend的调用，而后根据不同的状态，做协程的挂起和恢复操作。

这两个名词虽然比较抽象，但是对于后面的分析还是比较重要的，还是先以一个简单的例子开始，慢慢理解。

使用launch开启一个协程，在协程体中，加入两个挂起函数，loadDataA和loadDataB，并且在函数前后，log打印出函数的运行轨迹。如下：

Log.d(TAG, "onCreate: start")
lifecycleScope.launch {
    val num = loadDataA()
    loadDataB(num)
}
Log.d(TAG, "onCreate: end") 

private suspend fun loadDataA():Int {
    delay(3000)
    Log.d(TAG, "loadDataA: ")
    return 1
}
​
private suspend fun loadDataB(num:Int) {
    delay(1000)
    Log.d(TAG, "loadDataB: $num")
}

那launch开启协程，内部做了些什么？又是如何处理loadDataA和loadDataB这些挂起函数的？

不妨先在launch处打上断点，Debug看看它的执行路径。

image.png

如上图所示，从onCreate开始，一个lifecycleScope.launch 的执行顺序是

launch->start->invoke->startCoroutineCancellable->resumeWith再到最后invokeSuspend方法，

至于invokeSuspend的作用是什么？这个后面会详细说明。

既然给了大致的执行方向，我们只需要一步一步的跟进，查看内部详细的代码处理。

# Builders.common.kt
    
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开始，在不阻塞当前线程的情况下启动一个新的协程，并将对协程的引用作为Job 返回，CoroutineScope.launch中传入了三个参数，第一个CoroutineContext为协程的上下文，第二个CoroutineStart，协程启动选项。 默认值为CoroutineStart.DEFAULT ，第三个block即协程体中的代码，也就是上面例子中的loadDataA和loadDataB。

接着coroutine.start(start, coroutine, block)使用给定的代码块和启动策略启动此协程。

# AbstractCoroutine.kt
    
public fun <R> start(start: CoroutineStart, receiver: R, block: suspend R.() -> T) {
    initParentJob()
    start(block, receiver, this)
}

在initParentJob()方法之后，调用了start，这个时候你会发现，已经无法再继续跟进去了。

但是在文章一开始Debug的路径显示，在start后，执行到的是CoroutineStart#invoke()

# CoroutineStart.kt
    
@InternalCoroutinesApi
public operator fun <T> invoke(block: suspend () -> T, completion: Continuation<T>): Unit =
    when (this) {
        DEFAULT -> block.startCoroutineCancellable(completion)
        ATOMIC -> block.startCoroutine(completion)
        UNDISPATCHED -> block.startCoroutineUndispatched(completion)
        LAZY -> Unit // will start lazily
    }

在invoke中使用此协程的启动策略将相应的块作为协程启动，这里以DEFAULT为例，startCoroutineCancellable()，而在startCoroutineCancellable中，创建了Continuation，且调用resumeWith来传递请求结果。

# DispatchedContinuation.kt

public fun <T> Continuation<T>.resumeCancellableWith(
    result: Result<T>,
    onCancellation: ((cause: Throwable) -> Unit)? = null
): Unit = when (this) {
    is DispatchedContinuation -> resumeCancellableWith(result, onCancellation)
    else -> resumeWith(result)
}

到这里，你可能还是云里雾里，跟进这么多方法，到底有什么用途？不急

我们接着往下看核心部分Continuation，

public interface Continuation<in T> {
    public val context: CoroutineContext
    
    public fun resumeWith(result: Result<T>)
}

Continuation是一个接口，接口内有一个resumeWith方法，在上面launch启动协程中startCoroutineCancellable调用了resumeWith。既然是接口且被调用，那必然是有地方实现了该接口，并且在resumeWith中做了一些事情。

那就来看看实现Continuation接口的地方做了些啥？

Continuation的具体实现是在ContinuationImpl类中，

internal abstract class ContinuationImpl(
    completion: Continuation<Any?>?,
    private val _context: CoroutineContext?
) : BaseContinuationImpl(completion)

而ContinuationImpl继承自BaseContinuationImpl，在BaseContinuationImpl中就可以看到resumeWith的具体实现。

internal abstract class BaseContinuationImpl(
    public val completion: Continuation<Any?>?
) : Continuation<Any?>, CoroutineStackFrame, Serializable {
    
    public final override fun resumeWith(result: Result<Any?>) {
        var current = this
        var param = result
        while (true) {
 
            probeCoroutineResumed(current)
            with(current) {
                val completion = 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 {
                  
                    completion.resumeWith(outcome)
                    return
                }
            }
        }
    }

在resumeWith实现中，最核心的部分是在while循环中，调用invokeSuspend并且对返回的标志判断。

val outcome = invokeSuspend(param)
if (outcome === COROUTINE_SUSPENDED) return
Result.success(outcome)

invokeSuspend这个方法是不是有点熟悉？

其实在文章开头Debug launch时，invokeSuspend是lifecycleScope.launch开启协程内部执行的最后一个方法，invokeSuspend之后即开始执行协程体中的内容。

既然我们已经从上面的分析了解到invokeSuspend是由Continuation的resumeWith而触发，那接下就看看 协程体中的内容是如何执行的？即协程是如何挂起和恢复的？

我们直接将文章开头的案例反编译。

#启动协程 付十一.png

#挂起函数loadDataA

付十一 (1).png

#挂起函数loadDataB

付十一 (2).png

从启动协程launch开始，到执行resumeWith，触发invokeSuspend方法，可以看到在invokeSuspend中有存储了一个变量label，初始值为0。

1. label=0，则进入case 0分支，

case 0:
   ResultKt.throwOnFailure($result);
   var4 = MainActivity.this;
   this.label = 1;
   var10000 = var4.loadDataA(this);
   if (var10000 == var3) {
      return var3;
   }
   break;

执行var4.loadDataA，在loadDataA中同样存在一个label，初始值同样为0，进入loadDataA中的case 0分支，执行delay（）方法，同时将label置为1，并返回COROUTINE_SUSPENDED标志。

# loadDataA
case 0:
   ResultKt.throwOnFailure($result);
   ((<undefinedtype>)$continuation).label = 1;
   if (DelayKt.delay(3000L, (Continuation)$continuation) == var4) {
      return var4;
   }
   break;

标识返回成功后，即var10000=COROUTINE_SUSPENDED，同时var3=COROUTINE_SUSPENDED，if (var10000 == var3) 则直接return，跳出了launch操作，执行协程外的Log.d(TAG, "onCreate: end")，同时也将label置为1，这就是挂起的概念。

2. 挂起后，loadDataA中 Delay完3s将开始恢复协程，触发了loadDataA中的invokeSuspend方法。

$continuation = new ContinuationImpl(var1) {
   // $FF: synthetic field
   Object result;
   int label;

   @Nullable
   public final Object invokeSuspend(@NotNull Object $result) {
      this.result = $result;
      this.label |= Integer.MIN_VALUE;
      return MainActivity.this.loadDataA(this);
   }
};

invokeSuspend中依然是执行MainActivity.this.loadDataA，只不过此时loadDataA中所保存的label的值=1，进入case 1分支，

case 1:
   ResultKt.throwOnFailure($result);
   break;
default:
   throw new IllegalStateException("call to 'resume' before 'invoke' with coroutine");
}

Log.d("MainActivity", "loadDataA: ");
return Boxing.boxInt(1);

case1分支中只做了结果失败时异常的抛出，随后便执行了Log.d("MainActivity", "loadDataA: ");并返回值Int值。

3. 在触发loadDataA中的invokeSuspend时，也触发了launch协程中的invokeSuspend，此时label=1，进入case1分支，

case 1:
   ResultKt.throwOnFailure($result);
   var10000 = $result;
   break;
   ...
default:
   throw new IllegalStateException("call to 'resume' before 'invoke' with coroutine");
}

int num = ((Number)var10000).intValue();
var4 = MainActivity.this;
this.label = 2;
if (var4.loadDataB(num, this) == var3) {
   return var3;
} else {
   return Unit.INSTANCE;
}

同样，对结果做了失败的判断，同时将loadDataA所返回的Int值，赋值给了变量num，开始loadDataB的执行。

4. loadDataB中的处理模式与loadDataA中一致，因为loadDataB之后无挂起函数，则在触发invokeSuspend时，返回的是Unit.INSTANCE，结束协程运行。

总结一下，

什么是挂起？

简单来说就是判断标识为COROUTINE_SUSPENDED时，使用Continuation暂存当前协程的状态，而后直接return出当前协程体。

什么是非阻塞？

挂起是在接口的实现invokeSuspend方法中return出去的，而invokeSuspend之外的函数当然还是会继续执行呀。比如说在一个activity的onCreate的方法中，设置一个Button的onClickListener事件，紧跟其后初始化了一个viewModel，这时在onClick里return，那初始化viewModel难道因为return而不执行吗？当然没有影响。这就是挂起为什么是非阻塞式的。

那恢复又是什么？

协程挂起时，使用了Continuation暂存当前协程的状态，而挂起函数恢复时，会调用Continuation的resumeWith方法，继而触发invokeSuspend，根据Continuation所保存的label值，进入不同的分支，恢复之前挂起协程的状态，并且执行下一个状态。

推荐阅读

「Kotlin篇」多方位处理协程的异常

「Kotlin篇」差异化分析，let，run，with，apply及also

uation所保存的label值，进入不同的分支，恢复之前挂起协程的状态，并且执行下一个状态。

推荐阅读

「Kotlin篇」多方位处理协程的异常

「Kotlin篇」差异化分析，let，run，with，apply及also

最后

分享给大家一份面试题合集。

下面的题目都是在Android交流群大家在面试时遇到的，如果大家有好的题目或者好的见解欢迎分享，楼主将长期维护此帖。
参考解析：郭霖、鸿洋、玉刚、极客时间、腾讯课堂…

内容特点：条理清晰，含图像化表示更加易懂。

内容概要：包括 Handler、Activity相关、Fragment、service、布局优化、AsyncTask相关
、Android 事件分发机制、 Binder、Android 高级必备 ：AMS,WMS,PMS、Glide、 Android 组件化与插件化等面试题和技术栈！
image

Handler 相关知识，面试必问！

常问的点：
Handler Looper Message 关系是什么？
Messagequeue 的数据结构是什么？为什么要用这个数据结构？
如何在子线程中创建 Handler?
Handler post 方法原理？
Android消息机制的原理及源码解析
Android Handler 消息机制

image

Activity 相关

启动模式以及使用场景?
onNewIntent()和onConfigurationChanged()
onSaveInstanceState()和onRestoreInstanceState()
Activity 到底是如何启动的
启动模式以及使用场景
onSaveInstanceState以及onRestoreInstanceState使用
onConfigurationChanged使用以及问题解决
Activity 启动流程解析

image

Fragment

Fragment 生命周期和 Activity 对比
Fragment 之间如何进行通信
Fragment的startActivityForResult
Fragment重叠问题
Fragment 初探
Fragment 重叠， 如何通信
Fragment生命周期

image

Service 相关

进程保活
Service的运行线程（生命周期方法全部在主线程）
Service启动方式以及如何停止
ServiceConnection里面的回调方法运行在哪个线程？
startService 和 bingService区别
进程保活一般套路
关于进程保活你需要知道的一切

image

Android布局优化之ViewStub、include、merge

什么情况下使用 ViewStub、include、merge？
他们的原理是什么？
ViewStub、include、merge概念解析
Android布局优化之ViewStub、include、merge使用与源码分析

image

BroadcastReceiver 相关

注册方式，优先级
广播类型，区别
广播的使用场景，原理
Android广播动态静态注册
常见使用以及流程解析
广播源码解析

image

AsyncTask相关

AsyncTask是串行还是并行执行？
AsyncTask随着安卓版本的变迁
AsyncTask完全解析
串行还是并行

image

Android 事件分发机制

onTouch和onTouchEvent区别，调用顺序
dispatchTouchEvent， onTouchEvent， onInterceptTouchEvent 方法顺序以及使用场景
滑动冲突，如何解决
事件分发机制
事件分发解析
dispatchTouchEvent， onTouchEvent， onInterceptTouchEvent方法的使用场景解析

image

Android View 绘制流程

简述 View 绘制流程
onMeasure， onlayout， ondraw方法中需要注意的点
如何进行自定义 View
view 重绘机制

  • Android LayoutInflater原理分析，带你一步步深入了解View(一)

  • Android视图状态及重绘流程分析，带你一步步深入了解View(二)

  • Android视图状态及重绘流程分析，带你一步步深入了解View(三)

  • Android自定义View的实现方法，带你一步步深入了解View(四)

    image

Android Window、Activity、DecorView以及ViewRoot

Window、Activity、DecorView以及ViewRoot之间的关系

image

Android 的核心 Binder 多进程 AIDL

常见的 IPC 机制以及使用场景
为什么安卓要用 binder 进行跨进程传输
多进程带来的问题

  • AIDL 使用浅析

  • binder 原理解析

  • binder 最底层解析

  • 多进程通信方式以及带来的问题

  • 多进程通信方式对比

    image

Android 高级必备 ：AMS,WMS,PMS

AMS,WMS,PMS 创建过程

  • AMS,WMS,PMS全解析

  • AMS启动流程

  • WindowManagerService启动过程解析

  • PMS 启动流程解析

    image

Android ANR

为什么会发生 ANR？
如何定位 ANR？
如何避免 ANR？
什么是 ANR
如何避免以及分析方法
Android 性能优化之 ANR 详解

image

Android 内存相关

注意：内存泄漏和内存溢出是 2 个概念

什么情况下会内存泄漏？
如何防止内存泄漏？

  • 内存泄漏和溢出的区别

  • OOM 概念以及安卓内存管理机制

  • 内存泄漏的可能性

  • 防止内存泄漏的方法

    image

Android 屏幕适配

屏幕适配相关名词解析
现在流行的屏幕适配方式

  • 屏幕适配名词以及概念解析

  • 今日头条技术适配方案

    image

Android 缓存机制

LruCache使用极其原理

  • Android缓存机制

  • LruCache使用极其原理述

    image

Android 性能优化

如何进行 内存 cpu 耗电 的定位以及优化
性能优化经常使用的方法
如何避免 UI 卡顿

  • 性能优化全解析，工具使用

  • 性能优化最佳实践

  • 知乎高赞文章

    image

Android MVC、MVP、MVVM

好几种我该选择哪个？优劣点

任玉刚的文章：设计模式选择

image

Android Gradle 知识

这俩篇官方文章基础的够用了
必须贴一下官方文档：配置构建
Gradle 提示与诀窍

Gradle插件 了解就好
Gradle 自定义插件方式
全面理解Gradle - 执行时序

  • Gradle系列一

  • Gradle系列二

  • Gradle系列三

    image

RxJava

使用过程，特点，原理解析
RxJava 名词以及如何使用
Rxjava 观察者模式原理解析
Rxjava订阅流程，线程切换，源码分析 系列

image

OKHTTP 和 Retrofit

OKHTTP完整解析
Retrofit使用流程，机制详解
从 HTTP 到 Retrofit
Retrofit是如何工作的

image

最流行图片加载库： Glide

郭神系列 Glide 分析
Android图片加载框架最全解析（一），Glide的基本用法
Android图片加载框架最全解析（二），从源码的角度理解Glide的执行流程
Android图片加载框架最全解析（三），深入探究Glide的缓存机制
Android图片加载框架最全解析（四），玩转Glide的回调与监听
Android图片加载框架最全解析（五），Glide强大的图片变换功能
Android图片加载框架最全解析（六），探究Glide的自定义模块功能
Android图片加载框架最全解析（七），实现带进度的Glide图片加载功能
Android图片加载框架最全解析（八），带你全面了解Glide 4的用法

image

Android 组件化与插件化

为什么要用组件化？
组件之间如何通信？
组件之间如何跳转？
Android 插件化和热修复知识梳理
为什么要用组件化

  • Android彻底组件化方案实践
  • Android彻底组件化demo发布
  • Android彻底组件化-代码和资源隔离
  • Android彻底组件化—UI跳转升级改造
  • Android彻底组件化—如何使用Arouter

插件化框架历史
深入理解Android插件化技术
Android 插件化和热修复知识梳理

由于篇幅限制，文档的详解资料太全面，细节内容太多，所以只把部分知识点截图出来粗略的介绍，每个小节点里面都有更细化的内容！

好啦，这份资料就给大家介绍到这了，有需要详细文档的小伙伴，可以微信扫下方二维码免费领取哈~

# kotlin # android # java
Logo
开源鸿蒙跨平台开发者社区

开源鸿蒙跨平台开发社区汇聚开发者与厂商，共建“一次开发，多端部署”的开源生态，致力于降低跨端开发门槛，推动万物智联创新。

更多推荐

Flutter-OH 核心概念：Package（包）与 Plugin（插件）的区别详解（含FFI Plugin）

层级关系：Package是Flutter-OH可复用模块的统称，包含纯Dart包、传统Plugin（ArkTS交互）、FFI Plugin（C/C++交互）；核心差异：纯Dart Package无鸿蒙原生代码；传统Plugin通过Channel调用鸿蒙ArkTS代码；FFI Plugin通过ffi直连鸿蒙C/C++二进制；选型关键：根据是否需要鸿蒙原生能力、原生能力类型（系统API/高性能计算）选

avatar 开源鸿蒙跨平台开发者社区
cover

《Flutter for OpenHarmony：星轨天气的粒子化气象宇宙可视化系统》

avatar 开源鸿蒙跨平台开发者社区

Flutter-OH 核心概念：Package（包）与 Plugin（插件）的区别详解

核心差异：Flutter-OH Package是纯Dart代码的复用模块，不涉及鸿蒙原生；Flutter-OH Plugin包含鸿蒙原生（ArkTS）代码，用于Flutter-OH调用鸿蒙系统/硬件/分布式能力。开发选择：仅需Dart就能实现的功能用Package，需要访问鸿蒙原生API（如硬件、分布式能力、系统功能）用Plugin。技能要求：开发Flutter-OH Package只需Dart，

avatar 开源鸿蒙跨平台开发者社区