导入库
api 'org.jetbrains.kotlinx:kotlinx-coroutines-android:1.1.0'
api 'org.jetbrains.kotlinx:kotlinx-coroutines-core-common:1.1.0'
随笔
GlobalScope
GlobalScope为是全局的，生命周期是app的生命周期。
全局协程类似于守护线程.在 [GlobalScope]作用范围内启动的活跃的协程,
不会保持应用程序的整个进程存活. 它们的行为就象守护线程一样.不会保活进程.
GlobalScope.launch 时, 我们创建了一个顶级的协程. 虽然它是轻量的, 但它运行时还是会消耗一些内存资源.
由GlobalScope启动的协程
（ GlobalScope.launch { }/GlobalScope.async { }）
任务总是在子线程执行
runBlocking
runBlocking { }
任务执行在当前启动线程，并且会阻塞当前线程
在主线程启动则任务在主线程执行，在子线程启动任务则在子线程执行
Job
job.cancel() // 取消 job
job.join() // 等待 job 结束
Job.cancelAndJoin()//取消作业并暂停调用协同程序，直到取消的作业完成
由于有些协程不会等待子协程执行，所以可以调用子协程的join方法，
告诉父协程，请等待我执行完毕，例如：
fun main() = runBlocking {
val job = GlobalScope.launch {
// 启动新的协程, 并保存它的执行任务的引用
//由于是全局协程，所以runBlocking 不会等待他执行完成
delay(1000L)
println("World!")
}
println("Hello,")
job.join() // 等待, 直到子协程执行完毕
}
fun main() =runBlocking {
launch{//由于属于子协程，不需要手动join，runBlocking 会等待他完成
delay(2000L)
println("World!") // 后打印
}
println("Hello,")//先打印,打印完成仍会等待launch执行
}
//嵌套coroutineScope/runBlocking，会自动等待子协程执行完成，再执行后面的
fun main() =runBlocking {
coroutineScope {//新的作用域，注意区分launch，runBlocking 会等待它执行完成再执行后面的代码
delay(200L)
println("Hello,")//等待之后，先打印
}
println("World!") // 后打印，等待launch执行完再执行
}
coroutineScope
[runBlocking] 和 [coroutineScope] 之间的主要区别是,
[coroutineScope]在等待子协程运行时, 不会阻塞当前线程
coroutineScope {
// 创建新的协程作用范围
launch {
delay(500L)
println("World!")//后打印
}
println("Hello,") // 先打印，打印完等待launch执行完成之后才结束
}
launch和async
launch和async区别
launch里面的代码会立即执行
async的代码需要手动执行（使用await()）
suspend
专门修饰协程方法，例如
fun main() = runBlocking {
launch { doWorld() }
println("Hello,")
}
// 这是你的第一个挂起函数
suspend fun doWorld() {
delay(1000L)
println("World!")
}
但是如果抽取出来的函数包含一个协程构建器, 并且这个构建器需要在当前作用范围上调用, 那么怎么办?
这种情况下, 对于被抽取出来的函数来说只有 `suspend` 修饰符是不够的.
有一种解决办法是把 `doWorld` 变成 `CoroutineScope` 的扩展函数, 但这种办法有时候并不适用,
因为它会使得 API 难于理解. 理想的解决办法是, 要么明确地把 `CoroutineScope` 作为一个类的域变量,
再让这个类包含我们抽取的函数, 或者让外层类实现 `CoroutineScope` 接口, 于是就可以隐含的实现这个目的.
最后一种办法就是, 可以使用 [CoroutineScope(coroutineContext)],
但这种方法从结构上来说并不安全, 因为你不再能够控制当前方法运行时所属的作用范围.
只有私有 API 才能够使用这个构建器.
协程的取消
协程的取消是 *协作式的*. 协程的代码必须与外接配合, 才能够被取消.
`kotlinx.coroutines` 库中的所有挂起函数都是 *可取消的*.
这些函数会检查协程是否被取消, 并在被取消时出 [CancellationException]异常.
但是, 如果一个协程正在进行计算, 并且没有检查取消状态, 那么它是不可被取消的
//可以取消（唯一的不同就是判断条件）
runBlocking {
val startTime = System.currentTimeMillis()
val job = launch(Dispatchers.Default) {
var nextPrintTime = startTime
var i = 0
repeat (1000) { // 一个执行计算的循环，只是为了占用 CPU
// 每秒打印消息两次
if (System.currentTimeMillis() >= nextPrintTime) {
println("job: I'm sleeping ${i++} ...")
nextPrintTime += 500L
}
}
}
delay(1300L) // 等待一段时间
println("main: I'm tired of waiting!")
job.cancelAndJoin() // 取消一个作业并且等待它结束
println("main: Now I can quit.")
}
//无法取消（唯一的不同就是判断条件）
runBlocking {
val startTime = System.currentTimeMillis()
val job = launch(Dispatchers.Default) {
var nextPrintTime = startTime
var i = 0
while (i<1000) { // 一个执行计算的循环，只是为了占用 CPU
// 每秒打印消息两次
if (System.currentTimeMillis() >= nextPrintTime) {
println("job: I'm sleeping ${i++} ...")
nextPrintTime += 500L
}
}
}
delay(1300L) // 等待一段时间
println("main: I'm tired of waiting!")
job.cancelAndJoin() // 取消一个作业并且等待它结束
println("main: Now I can quit.")
}
withContext
可以使用 [withContext] 函数和 [NonCancellable] 上下文,
把相应的代码包装在 `withContext(NonCancellable) {...}`
withTimeout
//到达超时后自动取消
fun main() = runBlocking {
//sampleStart
withTimeout(1300L) {
repeat(1000) { i ->
println("I'm sleeping $i ...")
delay(500L)
}
}
//sampleEnd
}
withTimeoutOrNull
使用 [withTimeoutOrNull]函数, 它与 [withTimeout] 函数类似,
但在超时发生时, 它会返回 `null`, 而不是抛出异常:
async
在概念上，[async]就类似于 [launch]。
它启动了一个单独的协程，这是一个轻量级的线程并与其它所有的协程一起并发的工作。
不同之处在于 `launch` 返回一个 [Job] 并且不附带任何结果值，
而 `async` 返回一个 [Deferred] —— 一个轻量级的非阻塞 future， 这代表了一个将会在稍后提供结果的 promise。
你可以使用 `.await()` 在一个延期的值上得到它的最终结果， 但是 `Deferred` 也是一个 `Job`，
所以如果需要的话，你可以取消它。
val one = async(start = CoroutineStart.LAZY) { doSomethingUsefulOne() }
使用了CoroutineStart.LAZY需要手动调用start(),然后再使用await()
协程调度器
Unconfined : I'm working in thread main
Default : I'm working in thread DefaultDispatcher-worker-1
newSingleThreadContext: I'm working in thread MyOwnThread
main runBlocking : I'm working in thread main
当调用 `launch { …… }` 时不传参数，它从启动了它的 [CoroutineScope] 中承袭了上下文（以及调度器）。
在这个案例中，它从 `main` 线程中的 `runBlocking` 主协程承袭了上下文。
[Dispatchers.Unconfined]是一个特殊的调度器且似乎也运行在 `main` 线程中，但实际上， 它是一种不同的机制，这会在后文中讲到。
该默认调度器，当协程在 [GlobalScope]中启动的时候使用， 它代表 [Dispatchers.Default]使用了共享的后台线程池
所以 `GlobalScope.launch { …… }` 也可以使用相同的调度器—— `launch(Dispatchers.Default) { …… }`
[newSingleThreadContext]为协程的运行启动了一个线程。 一个专用的线程是一种非常昂贵的资源。
在真实的应用程序中两者都必须被释放，当不再需要的时候，使用 [close] 函数，或存储在一个顶层变量中使它在整个应用程序中被重用
CoroutineScope
创建一个新的作用域
重点，在安卓中使用这个创建的才不会阻塞主线程，用runBlock会阻塞主线
CoroutineScope(context: CoroutineContext): CoroutineScope
例如：CoroutineScope(Dispatchers.Main)
