史上最详 Android 版 kotlin 协程入门进阶实战（一），androidwifi 开发教程下载

• 讲的太浅，三两句话就带过去了，看完以后就只剩下索然无味

• 讲的太深，从头到尾都是晕乎乎的，最后总结就是三句话：我在哪，我在干嘛，手机真好玩!

• 内容适中，但是用到实际开发中时开始各种突然的翻车，然后挠头：怎么结果跟我想象的不一样啊!

知识的学习过程就像谈恋爱一样，讲究循序渐进。上来就想深入了解的话，那大概率是很容易翻车的。但聊得太浅吧，感情又不到位，后续想深入后很难。没有系统的学习是很难讲学到的知识点融会贯通的，因为笔者的想法是："让读者在更容易吸收kotlin协程知识的同时，能够无缝衔接到实际应用开发中去"。所以接下来对于每一个知识点讲解，笔者将会根据不同的阶段，讲解到不同的深度，至于这个实际的深度是否能够满足读者们的需求，那就只能各位自己去体验了。

文章概览

===================================================================

本文章面向的对象是具有一定的 kotlin 基础和 Android 开发的基础。笔者会以第一视角出发，从零开始创建项目进行讲解。文章主要在于讲解 Kotlin 协程的基本使用、项目应用以及部分协程原理知识。附带会将讲解一些 kotlin 知识、Android Jetpack组件、常用第三方框架的基本使用等(不会深究原理，只是基础使用)。文章主要分为 5 个层次：

1. kotlin 协程的基础用法。

2. kotlin 协程的关键知识点初步讲解。

3. 使用 kotlin 协程开发 Android 的应用。

4. kotlin 协程结合Android Jetpack组件应用。

5. kotlin 协程结合第三方框架的使用，如：Retrofit，OkHttp，coil等。

6. 深入 kotlin 协程原理（如:CoroutineContext、Dispatcher、CoroutineExceptionHandler、Continuation、Scheduler等等）

由于文章涉及到的只是点比较多、内容可能过长，可以根据自己的能力水平和熟悉程度分阶段跳着看。如有讲述的不正确的地方劳烦各位动动小手私信给笔者，万分感谢

文章中使用的主要版本号

==========================================================================

• Android studio 4.1.3

• kotlin： 1.4.32

• kotlinx-coroutines-android:1.4.3

• Retrofit： 2.9.0

• okhttp: 4.9.0

• coil： 1.2.0

• room： 2.2.5

项目创建以及配置

=======================================================================

下面我们就开始进入正题，首先我们使用 Android studio(后面简写为 AS)，创建一个以 kotlin 为开发语言的工程项目KotlinCoroutineDemo，然后我们先在project的build.gradle中引用下面配置

classpath "org.jetbrains.kotlin:kotlin-gradle-plugin:1.4.32"

然后在 app 的build.gradle中引用相关配置

// Kotlin

implementation "org.jetbrains.kotlin:kotlin-stdlib:1.4.32"

// 协程核心库

implementation "org.jetbrains.kotlinx:kotlinx-coroutines-core:1.4.3"

// 协程 Android 支持库

implementation "org.jetbrains.kotlinx:kotlinx-coroutines-android:1.4.3"

}

现在我们就可以愉快的开始我们下一步演示开发了。记得搬好小板凳带上瓜子花生用心看

Kotlin 协程的基础介绍

============================================================================

为了方便我们在此文章把 kotlin 协程简称为协程(Coroutine)。

协程是什么

很多人听到协程的时候第一想法就是协程是什么，笔者在这里也不会去给它下定义，推荐您移步带 kotlin 官方网站去找相关解释。但是我们这里引用官方的一段原话：

• 协程通过将复杂性放入库来简化异步编程。程序的逻辑可以在协程中顺序地表达，而底层库会为我们解决其异步性。该库可以将用户代码的相关部分包装为回调、订阅相关事件、在不同线程（甚至不同机器！）上调度执行，而代码则保持如同顺序执行一样简单。

• 协程是一种并发设计模式，您可以在 Android 平台上使用它来简化异步执行的代码

简单的概括就是我们可以，以同步的方式去编写异步执行的代码。协程是依赖于线程，但是协程挂起时不需要阻塞线程，几乎是无代价的。所以协程像是一种用户态的线程，非常轻量级，一个线程中可以创建 N 个协程。协程的创建是过CoroutineScope创建,协程的启动方式有三种：

1. runBlocking：T 启动一个新的协程并阻塞调用它的线程，直到里面的代码执行完毕,返回值是泛型T，就是你协程体中最后一行是什么类型，最终返回的是什么类型T就是什么类型。

2. launch：Job 启动一个协程但不会阻塞调用线程,必须要在协程作用域(CoroutineScope)中才能调用,返回值是一个 Job。

3. async:Deferred<T> 启动一个协程但不会阻塞调用线程,必须要在协程作用域(CoroutineScope)中才能调用。以Deferred对象的形式返回协程任务。返回值泛型T同runBlocking类似都是协程体最后一行的类型。

等等，好像哪里不对，奇怪的知识点突然有点增多啊。

上面提到协程体中最后一行是什么类型，最终返回的是什么类型T就是什么类型，好像跟我们想的不一样，返回值不应该是用 return 吗，学过kotlin的会知道，在的kotlin高阶函数中，lambda表达式如果你没有显式返回一个值，那它将隐式返回最后一个表达式的值。

那Job、Deferred和协程作用域又是些啥玩意!

不急，慢慢来，我们一个一个的来解释清楚。

什么是 Job 、Deferred 、协程作用域

Job我们可以认为他就是一个协程作业是通过CoroutineScope.launch生成的，同时它运行一个指定的代码块，并在该代码块完成时完成。我们可以通过isActive、isCompleted、isCancelled来获取到Job的当前状态。Job的状态如下图所示，摘自官方文档：

协程的生命周期

| State | [isActive] | [isCompleted] | [isCancelled] |

| --- | --- | --- | --- |

| New (optional initial state) | false | false | false |

| Active (default initial state) | true | false | false |

| Completing (transient state) | true | false | false |

| Cancelling (transient state) | false | false | true |

| Cancelled (final state) | false | true | true |

| Completed (final state) | false | true | false |

我们可以通过下图可以大概了解下一个协程作业从创建到完成或者取消，Job在这里不扩展了，后面我们会在实际使用过程中去讲解。

wait children

+-----+ start +--------+ complete +-------------+ finish +-----------+

| New | -----> | Active | ---------> | Completing | -------> | Completed |

+-----+ +--------+ +-------------+ +-----------+

| cancel / fail |

| +----------------+

| |

V V

+------------+ finish +-----------+

| Cancelling | --------------------------------> | Cancelled |

+------------+ +-----------+

Deferred

Deferred继承自Job，我们可以把它看做一个带有返回值的Job，

public interface Deferred<out T> : Job {

//返回结果值，或者如果延迟被取消，则抛出相应的异常

public suspend fun await(): T

public val onAwait: SelectClause1<T>

public fun getCompleted(): T

public fun getCompletionExceptionOrNull(): Throwable?

}

我们需要重点关注await()方法，可以看到await()方法返回结果是T，说明我们可以通过await()方法获取执行流的返回值，当然如果出现异常或者被取消执行，则会抛出相对应的异常。

什么是作用域

协程作用域(Coroutine Scope)是协程运行的作用范围。launch、async都是CoroutineScope的扩展函数，CoroutineScope定义了新启动的协程作用范围，同时会继承了他的coroutineContext自动传播其所有的 elements和取消操作。换句话说，如果这个作用域销毁了，那么里面的协程也随之失效。就好比变量的作用域，如下面test方法中的money变量

private fun test(){ // scope start

int money = 100;

println(money)

} // scope end

// println(money)

此时money是不能被调用,因为 AS 会提示 Unresolved reference: money。协程作用域也是这样一个作用，可以用来确保里面的协程都有一个作用域的限制。我们开发过程中最常见的场景就内存泄露，协程同样存在这样的问题，后面我们再细细讲解协程作用域CoroutineScope的相关知识，这里只是作为基础点讲解，不继续往下延伸。

Kotlin 协程的基础用法

============================================================================

现在我们开始使用协程，首先我们在MainActivity的 xml 布局中新建一个Button按钮然后设置好点击事件，然后创建一个start()方法，通过Button的点击事件执行。现在我们开始在start方法中使用协程。

刚才我们上面提到启动协程有三种方式，接下来我们先看看如何通过runBlocking、launch和async启动协程，我们直接在 start 方法中使用，但是由于我们的launch和async启动，只能在协程的作用域下启动，那我们又该怎么办呢？

运行第一个协程

在 Android 中有一个名为GlobalScope全局顶级协程，这个协程是在整个应用程序生命周期内运行的。我们就以此协程来使用launch和async启动，代码如下：

import android.os.Bundle

import android.util.Log

import android.view.View

import android.widget.Button

import android.widget.LinearLayout

import androidx.appcompat.app.AppCompatActivity

import androidx.constraintlayout.widget.Group

import androidx.viewpager.widget.ViewPager

import kotlinx.coroutines.*

import java.lang.NullPointerException

class MainActivity : AppCompatActivity() {

private lateinit var btn:Button

override fun onCreate(savedInstanceState: Bundle?) {

super.onCreate(savedInstanceState)

setContentView(R.layout.activity_main)

btn = findViewById(R.id.btn)

btn.setOnClickListener {

start()

}

}

private fun start(){

runBlocking {

Log.d("runBlocking", "启动一个协程")

}

GlobalScope.launch{

Log.d("launch", "启动一个协程")

}

GlobalScope.async{

Log.d("async", "启动一个协程")

}

}

}

然后运行 app，点击按钮执行start()方法。我们就可以在控制台上看到如下输出：

D/runBlocking: 启动一个协程

D/launch: 启动一个协程

D/async: 启动一个协程

哇

，so easy。协程原来这么简单，那我们接着继续往下走。上面提到过三种启动方式分别会的得到各自的返回信息。我们现在增加三个变量然后分别用协程进行赋值，同时进行输出：

private fun start(){

val runBlockingJob = runBlocking {

Log.d("runBlocking", "启动一个协程")

}

Log.d("runBlockingJob", "$runBlockingJob")

val launchJob = GlobalScope.launch{

Log.d("launch", "启动一个协程")

}

Log.d("launchJob", "$launchJob")

val asyncJob = GlobalScope.async{

Log.d("async", "启动一个协程")

"我是返回值"

}

Log.d("asyncJob", "$asyncJob")

}

然后运行，我们可以在控制台上看到如下输出：

D/runBlocking: 启动一个协程

D/runBlockingJob: 41

D/launchJob: StandaloneCoroutine{Active}@3b8b871

D/launch: 启动一个协程

D/async: 启动一个协程

D/asyncJob: DeferredCoroutine{Active}@63f265

也有可能是

D/runBlocking: 启动一个协程

D/runBlockingJob: 41

D/launchJob: StandaloneCoroutine{Active}@1344515

D/asyncJob: DeferredCoroutine{Active}@38c002a

D/async: 启动一个协程

D/launch: 启动一个协程

还有可能是

D/runBlocking: 启动一个协程

D/runBlockingJob: 41

D/launch: 启动一个协程

D/launchJob: StandaloneCoroutine{Active}@b94e973

D/async: 启动一个协程

D/ asyncJob: DeferredCoroutine{Active}@f7aa030

嗯哼，什么情况

怎么后面 4 条日志顺序还是随机的。没有看懂的童鞋，说明你没有仔细看上面的文字。

知识点来了，赶紧拿出你的小本本记下来，我们一个一个的来分析。

我们在上面提到过runBlocking启动的是一个新的协程并阻塞调用它的线程，我们对比输出日志可以看到前两条runBlocking的相关输出日志的位置顺序是不会变化的，这就证明我们之前所说的runBlocking会阻塞调用它的线程，直到`runBloc

《Android学习笔记总结+最新移动架构视频+大厂安卓面试真题+项目实战源码讲义》
浏览器打开：qq.cn.hn/FTe 免费领取

king`运行结束才继续往下执行。

接下来我们再继续往下看，我们看到后面四条日志是无序的，但是launchJob始终在asyncJob前面。而launch和async协程体内的日志输出是无序的。每执行一次看到的顺序都有可能跟之前的不一样。我们前面提到过launch和async都是启动一个协程但不会阻塞调用线程，所以launchJob始终在asyncJob前面（2 个协程之间不是很明显，你们自己在尝试的时候，可以同时启动 5 个甚至更多协程去看日志输出）

而launch和async协程体内的日志是无序的，这是因为协程采用的是并发设计模式，所以launch和async的协程体内的 log 日志输出是无序方式，这就解释了launch和async都是启动一个协程但不会阻塞调用线程，同时也解释了 log 日志之间输出顺序之间的关系（这里描述是不严谨的，后面会补充）。

难道就这样结束了吗？那你想的可就太简单了。刚才我们提到协程采用的是并发设计模式，多个协程并发执行的。那如果这个时候，我们把启动协程放在同一协程作用域下启动的是顺序又该是怎么样的呢？ 大家可以先思考一下这个问题，回头我们再来看这个问题。

runBlocking 的返回值

现在我们回到之前的话题，我们看到输出的日志信息中runBlockingJob的输出结果是 41，为什么是这么一个数值，其实他默认返回是一个该协程作业的当前状态

我们通过runBlocking方法可以看到，其返回值是调用了joinBlocking方法，而在joinBlocking方法中

我们看到joinBlocking方法返回了一个 state 强转成泛型T类型。我们现在大概知道runBlocking返回的是个什么东西了。如果在runBlocking协程最后一行增加一个返回值：

val runBlockingJob = runBlocking {

Log.d("Coroutine", "runBlocking 启动一个协程")

"我是 runBlockingJob 协程的返回值"

}

我们将会看到如下输出：

D/Coroutine: runBlocking 启动一个协程

D/runBlockingJob: 我是 runBlockingJob 协程的返回值

runBlocking它的设计目的是将常规的阻塞代码连接到一起，主要用于main函数和测试中。根据本文章的目标我们后续将不再往下扩展。

继续往下走，我们看到launchJob输出的是一个StandaloneCoroutine对象，为什么会是一个StandaloneCoroutine对象呢，不是说好的返回一个 Job 吗？

别慌，稳住！继续往下看

launch 函数

我们看到launch函数中有 3 个参数context、start和block，同时都带有默认值，虽然我们不知道这三个参数是干什么用的，但是我们可以看名知其意，不妨先大胆的猜测一下，我们这里先跳过，后面再针对这三个参数做一些基本讲解。我们看到launch方法最终返回的是一个coroutine对象，由于我们没有传入值其最后返回的是一个StandaloneCoroutine对象，跟我们输出的日志结果一致。那为什么笔者会说launch返回的是一个 Job 呢。我们再继续看看StandaloneCoroutine又是一个什么鬼，通过查找继承关系我们可以看到，StandaloneCoroutine就是一个 Job，现在就一目了然了。

private open class StandaloneCoroutine(...) : AbstractCoroutine<Unit>(parentContext, active){

//此处省略.....

}

public abstract class AbstractCoroutine<in T>(...) : JobSupport(active), Job, Continuation<T>, CoroutineScope {

//此处省略.....

}

async 函数

同理我们也看看async函数，和launch拥有同样的 3 个参数context、start和block，默认值都是一样的,最终返回的是也是一个coroutine对象。只是async返回的DeferredCoroutine对象。

private open class DeferredCoroutine<T>(...) : AbstractCoroutine<T>(parentContext, active), Deferred<T>, SelectClause1<T> {

//此处省略.....

}

同样的都是继承 AbstractCoroutine<Unit>类,但是DeferredCoroutine同时也继承Deferred<T>接口。这么看来DeferredCoroutine就是一个Deferred<T>，一个携带有返回值Job。那么问题来了，我们要怎么获取到这个Deferred<T>携带的返回值T呢。

我们在一开始的时候提到需要重点关注Deferred的await()方法，我们可以通过返回Deferred对象，调用await()方法来获取返回值，我们看到await()前面有个suspend关键字，这又是个额啥玩意。