Kotlin协程学习之路【一】

协程介绍

本质上，协程像是轻量级的线程

在我们编程的过程中 难免会出现异步编程和一些回调函数，这就很容易出现callback hell 回调地狱 ，也就是说可能出现大量嵌套代码，这种代码在视觉效果以及逻辑维护上都堪称地狱级代码，很容易给程序员带来困扰。

在这之前大家可能接触比较多的是像Rxjava这种用于处理异步编程的框架，有各种操作符以及流式调用等特点方便进行异步编程，而协程在这方面和Rxjava这种框架不同，协程做到了让代码看起来更直白更具有逻辑性，至于怎么让代码看起来更通俗易懂，可以看看接下来我在学习协程中个人的一些理解和总结

---

创建协程

举两个简单的创建方法 runBlocking { } 以及 GlobalScope.launch { }

runBlocking { }

runBlocking创建了一个协程，并且会阻塞当前线程，等待作用域也就是{}内的代码以及所有子协程结束，并且runBlocking 是有返回值的，但是由于会阻塞线程，所以用的情况不多，在这里做一个入门讲解

GlobalScope.launch { }

通过这个方法创建出来的协程是一个顶层的协程，它的生命周期跟application是一样的，没有返回值，也不可以取消，并且不会阻塞当前线程，这一点和runBlocking { } 正好相反

通过下面一段代码让大家了解一下用法

// 简单的输出一句Hello World
GlobalScope.launch {  
    print("Hello World")
}

---

launch和Job

launch是以不阻塞的方式去启动一个新的协程，需要在协程的范围内去调用，比如上面提到runBlocking couroutineScope，并且会返回一个Job用来控制任务的开始取消等操作

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的构造方法，有三个参数

• context：可以传入一个调度器Dispatchers来控制协程启动选项，默认的参数是CoroutineStart.DEFAULT也就是按当前的上下文环境去启动，如果我们想在IO线程中启动，可以传入Dispatchers.IO 还有像Dispatchers.Main就是在主线程中去启动
• start：如果我们想去控制协程的启动时机，可以通过start传入一个CoroutineStart，默认的CoroutineStart是立即启动，如果想要延时启动可以传入CoroutineStart.LAZY, 然后在需要启动的时候调用Job的join方法
• block：让协程在传入的协程范围内去运行

构建launch的方法讲完之后就讲一下Job的作用，Job有几个常用的方法，像是join cancel cancelAndJoin

• join：启动协程任务并且会以一个非阻塞的方式去等待这个Job完成

• cancel：取消任务

• cancelAndJoin：综合上面两个方法，实际上内部就是先调用了cancel再调用join,也就是说会等待协程内的任务完成之后，再继续往下执行代码，如果是cancel的话，那么调用的时候协程内的任务就会直接中断

  以上两种cancel，举个在安卓中的实际场景，比如一个草稿箱功能 ，用户在点击退出之后弹出一个loading框，这个时候可以用cancelAndJoin等待上传完成之后再dissmiss，如果用户选择直接退出，那么可以用cancel

  另外被取消的协程，会抛出一个CancellationException异常，表示协程被正常取消，如果你没有捕获错误的话，不会打印到控制台/日志

• isActive：这是一个判断当前协程是否还存活的标记，可以在任务中根据这个属性决定任务是否继续

在协程中如果你想要在任务结束之后做一些操作，那么你可以用try{}finally{}这样的操作把任务逻辑写在try中，在finally中释放资源

---

作用域构建器

除了由不同的构建器提供协程作用域之外，还可以使用 coroutineScope 构建器声明自己的作用域。它会创建一个协程作用域并且在所有已启动子协程执行完毕之前不会结束。coroutineScope 是非阻塞式的，是挂起函数，而runBlocking 是阻塞式，属于常规的函数，但是两者都会等待各自作用域中的所有子协程结束

关于上面说的runBlocking { }是阻塞式，coroutineScope是非阻塞式，可以通过下面一段代码来体现

import kotlinx.coroutines.*

fun main() = runBlocking { 
    // 用launch启动一个子协程
    launch { 
        delay(200L)
        println("Task from runBlocking")
    }
    
    // 创建一个协程作用域
    coroutineScope { 
        launch {
            delay(500L) 
            println("Task from nested launch")
        }
    
        delay(100L)
        println("Task from coroutine scope") // 这一行会在内嵌 launch 之前输出
    }
    
    println("Coroutine scope is over") // 这一行在内嵌 launch 执行完毕后才输出
}


最终的输出结果：x
Task from coroutine scope 
Task from runBlocking 
Task from nested launch 
Coroutine scope is over

 这一段代码取自kotlin官方文档，用来说明runBlocking { }和coroutineScope的阻塞以及非阻塞式区别，有的人可能会觉得有点疑惑，代码上看起来coroutineScope后面的打印总是会在最后才输出，看起来似乎coroutineScope才是阻塞式的
 然而并不是这样，Task from runBlocking这一段先打印相信大家可以明白，接着代码运行到了coroutineScope作用域里，作用域中有子协程，相信大家也能明白作用域中打印的顺序，那么问题来了，为什么Coroutine scope is over总是在最后打印。
 其实是因为上面所提到的阻塞和非阻塞式特点，coroutineScope作用域会以非阻塞式的等待所有子协程完成，所以内部第一个launch在运行到delay的时候并没有阻塞住线程，而是继续运行下去，所以会先打印延时比较短的Task from coroutine scope，之后delay时间到了协程切回去打印了Task from nested launch，而由于coroutineScope是在runBlocking 当中，所以当couroutineScope没有结束之前，runBlocking会阻塞当前线程等待，所以在coroutineScope内部delay没有结束，没有打印完成之前，最后一句println并不会被执行到。

---

这篇文章就暂时讲这么多知识点，接下来我也会根据自己在学习协程过程的一些疑惑以及总结陆续写后续的相关文章