「挂起」的本质
协程中「挂起」的对象到底是什么？挂起线程，还是挂起函数？都不对，我们挂起的对象是协程。
还记得协程是什么吗？启动一个协程可以使用 launch 或者 async 函数，协程其实就是这两个函数中闭包的代码块。
launch ，async 或者其他函数创建的协程，在执行到某一个 suspend 函数的时候，这个协程会被「suspend」，也就是被挂起。
那此时又是从哪里挂起？从当前线程挂起。换句话说，就是这个协程从正在执行它的线程上脱离。
注意，不是这个协程停下来了！是脱离，当前线程不再管这个协程要去做什么了。
suspend 是有暂停的意思，但我们在协程中应该理解为：当线程执行到协程的 suspend 函数的时候，暂时不继续执行协程代码了。
我们先让时间静止，然后兵分两路，分别看看这两个互相脱离的线程和协程接下来将会发生什么事情：
在挂起点时，线程接着干了啥：
协程的代码块中，线程执行到了 suspend 函数这里的时候，就暂时不再执行剩余的协程代码，跳出协程的代码块。
那线程接下来会做什么呢？
如果它是一个后台线程：
- 要么无事可做，被系统回收
- 要么继续执行别的后台任务
跟 Java 线程池里的线程在工作结束之后是完全一样的：回收或者再利用。
如果这个线程它是 Android 的主线程，那它接下来就会继续回去工作：也就是一秒钟 60 次的界面刷新任务。
关于线程，我们就看完了。接下来，我们来看看协程这一边。
在挂起点时，协程接着干了啥：
线程的代码在到达 suspend 函数的时候被掐断，接下来协程会从这个 suspend 函数开始继续往下执行，不过是在指定的线程。
谁指定的？是 suspend 函数指定的，比如我们这个例子中，函数内部的 withContext 传入的 Dispatchers.IO 所指定的 IO 线程。
Dispatchers 调度器，它可以将协程限制在一个特定的线程执行，或者将它分派到一个线程池，或者让它不受限制地运行。
那我们平日里常用到的调度器有哪些？
常用的 Dispatchers ，有以下三种：
-
Dispatchers.Main：Android 中的主线程 -
Dispatchers.IO：针对磁盘和网络 IO 进行了优化，适合 IO 密集型的任务，比如：读写文件，操作数据库以及网络请求 -
Dispatchers.Default：适合 CPU 密集型的任务，比如计算
回到我们的协程，它从 suspend 函数开始脱离启动它的线程，继续执行在 Dispatchers 所指定的 IO 线程。
紧接着在 suspend 函数执行完成之后，协程为我们做的最爽的事就来了：会自动帮我们把线程再切回来。
这个「切回来」是什么意思？
我们的协程原本是运行在主线程的，当代码遇到 suspend 函数的时候，发生线程切换，根据 Dispatchers 切换到了 IO 线程；
当这个函数执行完毕后，线程又切了回来，「切回来」也就是协程会帮我再 post 一个 Runnable，让我剩下的代码继续回到主线程去执行。
我们从线程和协程的两个角度都分析完成后，终于可以对协程的「挂起」suspend 做一个解释：
协程在执行到有 suspend 标记的函数的时候，会被 suspend 也就是被挂起，而所谓的被挂起，就是切个线程；
不过区别在于，挂起函数在执行完成之后，协程会重新切回它原先的线程。
再简单来讲，在 Kotlin 中所谓的挂起，就是一个稍后会被自动切回来的线程调度操作。
这个「切回来」的动作，在 Kotlin 里叫做 resume，恢复。
通过刚才的分析我们知道：挂起之后是需要恢复。
而恢复这个功能是协程的，如果你不在协程里面调用，恢复这个功能没法实现，所以也就回答了这个问题：为什么挂起函数必须在协程或者另一个挂起函数里被调用。
再细想下这个逻辑：一个挂起函数要么在协程里被调用，要么在另一个挂起函数里被调用，那么它其实直接或者间接地，总是会在一个协程里被调用的。
所以，要求 suspend 函数只能在协程里或者另一个 suspend 函数里被调用，还是为了要让协程能够在 suspend 函数切换线程之后再切回来。
怎么就「挂起」了？
我们了解到了什么是「挂起」后，再接着看看这个「挂起」是怎么做到的。
先随便写一个自定义的 suspend 函数：