谱写Kotlin面试指南三步曲-协程篇

前言

随着金三银四的到来，这段时刻陆续开启了面试的热潮，现在Kotlin作为Android日常开发中的首要的言语根底，无疑成为Android面试中常考的一部分，为了检验本身稳固自己的言语根底掌握情况，所以笔者收拾收集了当下网上Kotlin常见的一些问题，但由于篇幅内容过长所以分了三个部分(根底篇，协程篇，Flow篇)，以下是协程篇部分，简略收集了些经典问题，有需求的同学请自行弥补

• 编写Kotlin面试指南三部曲-根底篇

Q1: 什么是并发?

在稳固学习协程的相关知识之前，这是必须要知道的问题

并发程序是具备以下特色的：

• 看起来像是一起履行的多个使命

• 并发使命能够是彻底独立的，也能够具有按特定次序作业的彼此依赖性。

  为什么说是看起来像是一起履行的多个使命呢？打个比方吧，射雕英雄传应该看过吧，周伯通教郭靖一手画圆，一手画方，两只手一起操作，左右互搏，这个是并行；但是呢，我先左手画一笔，右手画一笔，同一时分只需一只手在操作，来回替换，直到完结图案，这个便是并发。

结构化并发

用之前看到过一篇文章来说的话，它是为了防止并发使命而呈现的概念，将这些并发使命放到同一个效果域里，做到一致发动，一致封闭。结构化并发有以下优点：

• 使命需求履行的时分，能够持续跟踪，使命不需求履行的时分，能够撤销，做到随叫随到
• 当使命失利时，能够宣布过错信号表明有过错产生
• 一致处理并发使命，防止使命泄漏

协程便是用于将并发引入 Kotlin 应用程序的结构，并且协程关于结构化并发是彻底支持。

Q2: 关于Kotlin中的协程有什么了解？

每次看到这个问题的时分,看到官方的答复大多数根本是都是这样的：协程视为一种轻量级线程，可用于进步并发代码的功用。这样的一句解说，看到是不是一头雾水。

首先，咱们能够先测验着了解下Kotlin官网说的这段话

能够将协程视为一种轻量级线程。和线程一样，协程能够并行运转，彼此等候和通信。最大的差异是协程十分廉价，几乎是免费的：咱们能够创立不计其数个协程，并且在功用方面付出的费用很少。另一方面，真实的线程的发动和保护本钱很高。一千个线程关于现代机器来说或许是一个严峻的应战。

其实这个答复对笔者来说是挺抽象的，不是特别好了解，所以就从头梳理下，首先咱们从协程的英文名词来拆解下

​ Coroutines = Co + Rountines

这儿Co指的是协作，而Routines代表的是电脑履行的一些例行程式，什么意思呢？便是意味着当这些函数程式彼此协作的时分，咱们就称之为协程。

​

通过上面这张图，笔者用一个例子来便利自己了解，为了更直观的感受协程的魅力，这儿运用了when关键字进行辅助。假定有两个函数它们分别是functionA和functionB

functionA如下代码所示：

fun functionA(case: Int) {
    when (case) {
        1 -> {
            taskA1()
            functionB(1)
        }
        2 -> {
            taskA2()
            functionB(2)
        }
        3 -> {
            taskA3()
            functionB(3)
        }
        4 -> {
            taskA4()
            functionB(4)
        }
    }
}

functionB如下代码所示：

fun functionB(case: Int) {
    when (case) {
        1 -> {
            taskB1()
            functionA(2)
        }
        2 -> {
            taskB2()
            functionA(3)
        }
        3 -> {
            taskB3()
            functionA(4)
        }
        4 -> {
            taskB4()
        }
    }
}

然后，咱们调用functionA，此时会产生什么事呢？

functionA(1)

在这儿，functionA将履行taskA1 并交给functionB操控履行taskB1；然后，functionB将履行taskB1并将操控权交还给functionA履行taskA2等等，如此类推下去，重要的是，functionA与functionB彼此协作。

现在咱们运用Kotlin协程就能够十分轻松地完结上述作业，而无需运用例子所示的when, 仅仅便利自己了解。现在，咱们能够暂时的了解为协程便是函数之间的彼此协作，由于这些功用的协作性质，存在着无限的或许性。

• 它能够履行几行 functionA，然后履行几行 functionB，然后再履行几行 functionA，依此类推。当一个线程处于空闲状态并且什么都不做时，这将很有帮助，在这种情况下，它能够履行另一个函数的几行。这样，它就能够充分运用线程，有助于多使命处理

• 支持以同步的办法编写异步代码

  总而言之，协程让多使命处理变得十分简略，能够说协程和线程都是多使命的，但不同的是，线程由操作体系办理，协程由用户办理，由于它拥有能够运用协作履行几行代码的功用。简略来说，协程便是一个根据实践编写的优化结构，运用函数的协作特性使其轻盈而强壮。所以，咱们总是说协程是一个轻量级的线程，这也意味着，它不映射到本机线程，因而不需求在处理器上进行上下文切换，因而协程速度更快。

  或许有些同学现已留意到上面我所说的，”不映射到本机线程“，这是什么意思呢？一般来说,根本上有两种类型的协程

• 无堆叠

• 堆积如山的

  而Kotlin完成的是无仓库的协程，阐明协程没有自己的仓库，因而它们不会映射到本机线程。现在，咱们反过头来了解Kotlin官网说的界说，才真实明白，协程并没有替代线程，它其实更像是一个结构来办理着它们。

​ 综上所述，笔者对协程(Coroutines)有了愈加确切的了解：它是一种更高效和更简略的办法办理并发的结构，其轻量级线程编写在实践线程结构之上，通过运用函数的协作性质来充分运用它。

Q3: 协程比线程更高效的原因是什么？

​ 协程比线程更高效，由于它们是轻量级的，能够挂起和康复而不会产生上下文切换的开销。这意味着它们可用于履行不然会堵塞线程的使命，而不会导致相同的功用丢掉。这句话是什么意思呢？咱们都知道，线程是操作体系办理的，而协程不是被操作体系内核所办理，而彻底是由程序所操控（也便是在用户态履行），这样带来的优点便是功用得到了很大的进步，不会像线程切换那样消耗资源。略微总结下，大致就三个特色：

• 协程是轻量级的，创立一个线程栈大约需求1M左右，而一个协程栈大约只需求几K或许几十K
• 减少了线程切换的本钱，协程能够挂起和康复，它不会产生额外的开销，由程序本身操控
• 不需求多线程的锁机制：由于只需一个线程，也不存在一起写变量抵触，在协程中操控共享资源不加锁，只需求判别状态就好了，所以履行功率比多线程高很多。

Q4: 协程结构中首要组成部分？

协程结构大致有如下部分组成：

• 协程效果域(CoroutineScope)
• 协程上下文(CoroutineContext)
• 协程调度器(CoroutineDispatcher)
• 作业(Job)

以上其实是根据整个协程结构来细化的，假如根据言语层面来说的话，协程中的供给的规范库，一些拦截器，以及十分重要的挂起函数都能够归类到它的组成部分当中，如下图所示

​

Q5: 关于协程效果域CoroutineScope?

咱们能够这么了解, CoroutineScope是一种用于发动协程的盒子。这便是为什么咱们需求它来发动任何协程。由于它是一个盒子，咱们能够一起对盒子里的全部协程履行操作，比方一次性撤销盒子里的全部子协程。

它在咱们实践开发中十分有用，由于咱们需求Activity被毁掉后当即撤销后台使命。一般来说，咱们都是通过考虑Activity、ViewModel等的生命周期而创立的自界说规模效果域Scope。

• Activity规模示例

  假定咱们是在一个Activity中，并且一旦这个Activity被毁掉掉，那么咱们的后台使命也随之被撤销。在Activity中，咱们一般运用lifecycleScope来发动协程

  class MainActivity : AppCompatActivity() {
      override fun onCreate(savedInstanceState: Bundle?) {
          super.onCreate(savedInstanceState)
          lifecycleScope.launch {
              val user = fetchUser()
              // show user
          }
      }
      suspend fun fetchUser(): User {
          return withContext(Dispatchers.IO) {
              // fetch user
              // return user
          }
      }
  }
  

一旦 Activity 被毁掉，假如它正在运转，使命将被撤销，由于咱们现已运用了绑定到Activity 的 LifeCycle 的规模。

• ViewModel规模示例

​ 假定咱们的ViewModel是效果域，一旦ViewModel被毁掉，后台使命就应该被撤销。在ViewModel中，

咱们一般运用viewModelScope来发动协程

class MainViewModel : ViewModel() {
    fun fetch() {
        viewModelScope.launch {
            val user = fetchUser()
            // show user
        }
    }
    suspend fun fetchUser(): User {
        return withContext(Dispatchers.IO) {
            // fetch user
            // return user
        }
    }
}

一旦ViewModel被毁掉，假如使命正在运转，它就会被撤销，由于咱们现已运用了绑定到 ViewModel 的生命周期的规模。

Q6: CoroutinesScope撤销和撤销CoroutinesScope的子撤销有什么差异？

• 一旦CoroutinesScope被撤销了，咱们就不能再从该规模创立新的协程，它不会给出任何过错/反常，仅仅默默地失利了
• 假如撤销了Scopes children的时分，能够再次创立一个新的Children Coroutine并发动它

Q7: 解说协程中的调度程序Dispatcher？

它是在特定线程或线程组上履行协程的必要步骤。并且单个Coroutine 能够运用多个CoroutineDispatcher。什么意思呢？简略来说便是它们作为调度员担任将协程”分派“究竟层线程，它决定着协程内部的代码将在哪个线程上履行。

Android中的规范调度程序

• Dispatchers.Main
• Dispatchers.Main.immediate

​ Dispatchers.Main 和 Dispatchers.Main.immediate 在 Android应用程序的 UI（主）线程上履行代码。有人就会问了，它们都是在UI线程上履行代码，那么它们之间有什么不同么？

​ 咱们做个类比，Dispatchers.Main.immediate 的行为相似于Activity.runOnUiThread(…)，而Dispatchers.Main的行为就相似于Handler(Looper.getMainLooper()).post(…)，也便是说runOnUiThread在UI线程上运转指定的操作，假如当时线程是UI线程的话，该操作会当即履行，不然相关操作会被投递到UI线程的事件队列中去，这便是它与Handler的不同之处。

• Dispatchers.Default

• Dispatchers.IO

  Dispatchers.Default和Dispatchers.IO都能够答应在后台履行使命

  Dispatchers.Default 由线程池支持，最大线程数为 2 或 CPU 核心数。它能够用于核算密集型使命。

  Dispatchers.IO 相似于Default，但最大线程数为 64 或 CPU 核心数。通过调整体系属功用够进一步增加最大线程数。用于 IO 使命，例如大部分时刻都处于等候的作业，而非密集型。

• Dispatchers.unconfined

  简略来说，它仅仅在调用发动函数的线程上履行代码，并且它会当即履行。

Q8: 关于协程中的作业Job?

​ 根据官方文档，Job的界说是这样的:

作业是一个可撤销的事物，其生命周期在其完结时到达顶峰。协程作业是通过发动协程构建器创立的。它运转指定的代码块并在该块完结时完结。

​ 每个协程都与一个作业相关联。每当发动新协程时，它都会回来对作业的引证。协程的作业是可撤销的，撤销它会撤销协程本身。但是假如咱们想处理规模内的全部协程，就不再需求通过单独的作业来完结，咱们能够运用CoroutineScope。

​ 相同的，在日常开发中，咱们能够通过Job供给的一些接口函数来操控协程，首要如下：

• start() 开端

  start()函数很直接，便是用来发动协程，这儿就不过多描绘

• join() 参加

  *join()*函数是一个挂起函数，即它能够从协程或另一个挂起函数中调用。作业堵塞全部线程，直到写入它的协程或上下文完结其作业。只需当协程完结时，才会履行join()函数之后的行。

• cancel() 封闭

  cancel()办法用于撤销协程，而不用等候它完结它的作业。能够说它与join办法正好相反，在某种意义上，*join()办法等候协程完结其悉数作业并堵塞全部其他线程，而cancel()*办法在遇到时杀死协程协程（即中止协程）。

Q9: 关于协程中的SupervisorJob?

关于SupervisorJob其实和协程中的普通Job十分相似，唯一的差异在于假如子协程呈现了反常，不会导致父协程以及其他兄弟协程撤销封闭。

简略举个例子：

val supervisorJob = SupervisorJob()
val scope = CoroutineScope(Dispatchers.IO + supervisorJob)
val job1 = scope.launch { 
              while(isActive) {
                 delay(2000)
              }
           }
val job2 = scope.launch {
              throw Exception()
            }
val job3 = scope.launch { 
              while(isActive) {
                 delay(2000)
              }
           }

能够看到咱们运用SupervisorJob作为效果域，发动了三个协程。第二个协程抛出反常，在此事件期间，其他协程不受影响并持续履行

综上所述，SupervisorJob更适合干一些独立相互不影响的使命，这样一旦某个使命呈现了问题，对其他使命是没有任何影响的，比方说日常开发中一些UI需求，假如我点击的一个按钮呈现了反常，但并不会影响手机状态栏的改写

Q10：简略说说suspend挂起函数？

从字面意思上了解，能够发动、暂停然后康复的函数称为挂起函数。

关于挂起函数要记住的最重要的作业之一是它们只能从另一个挂起函数或在协程中调用。挂起函数仅仅规范的Kotlin函数加上了suspend修饰符，表示它们能够在不堵塞当时线程的情况下挂起协程履行。这意味着咱们正在查看的代码或许会在调用暂停函数时暂停履行，并在稍后从头开端履行，但是需求留意的是，它没有提及与此一起当时线程会产生什么。

日常开发中，咱们经常运用的*delay()函数便是一个典型的挂起函数，咱们测验从协程外部调用delay()*函数，会产生什么呢？直接会抛出如下过错：

由于dely函数本身便是一个挂起函数，咱们需求在一个协程中或许在另一个挂起函数中才能调用*delay()*函数，它在不堵塞线程的情况下将协程推迟给定时刻，并在指定时刻后康复，所以咱们能够这么写：

 GlobalScope.launch(Dispatchers.Main) {
            delay(5000L)
        }
 suspend fun doDelayTask(time: Long) {
        delay(time)
        Log.d("Test","start")
    }

值得留意的是，挂起函数在履行完结之后，协程会从头切回它原先的线程。

具体学习能够看扔物线大佬的视频协程的挂起好难明

Q11: 从另一个挂起函数调用一个挂起函数会产生什么？

咱们现已知道了挂起函数要么在一个协程中调用，要么在另一个挂起函数调用，不然就会报错。当咱们从另一个挂起函数调用一个挂起函数时，第一个函数将挂起履行直到第二个函数完结。这对咱们优点在于能够用来创立易于阅览和调试的异步代码。

Q12: 关于协程中的挂起和堵塞有什么差异?

​ 首先，咱们要理清两个概念：

• 挂起，便是一个稍后会被主动切回来的线程调度操作
• 堵塞，其实是线程中的概念，相当于我线程卡了，或许在主线中进行一些耗时的操作，你必须等候耗时使命结束才能持续履行，这便是咱们人为认知的卡顿

​ 两个概念，它们最大的差异便是协程中的挂起是非堵塞式的，仅仅它能用看起来堵塞的代码写出非堵塞的操作，简略来说便是能够主动来回的切线程，从而不会形成主线程的堵塞

​ 他们会形成什么影响呢？咱们试着直接从主线程中下载一百张图片然后显示界面列表中，这一看便是耗时操作吧，咱们必须拿到图片后去再改写界面UI，在图形化 GUI 体系中 , 一般都在主线程中更新 UI , 主线程中都有一个无限循环 , 不断改写界面，所以咱们也叫做UI线程，这时分主线程中履行了耗时操作，就会影响到界面改写，呈现掉帧，甚至直接ANR了；那假如咱们将下载操作运用协程挂起了呢，在这段等候的时刻内是不会影响UI改写操作的，直到拿到成果再主动切换到UI线程去改写界面数据

具体学习能够看扔物线大佬的视频究竟什么是「非堵塞式」挂起？

Q13: 发动协程的launch() 和 async() 有什么差异？在某些情况下应该运用哪个？

launch() 和 async() 之间的首要差异在于 :

• launch() 将创立一个新的协程并当即发动它
• async() 将创立一个新的协程但不会发动它直到某些东西在成果Deferred 上调用 await()

​ 一般来说，当咱们想让协程在后台运转而不堵塞主线程时，应该运用launch() ，而当咱们需求等候协程的成果再持续时，应该运用 async() ，不够具体？launch 更多是用来建议一个无需成果的耗时使命（如批量文件删去、创立），这个作业不需求回来成果。async 函数则是更进一步，用于异步履行耗时使命，并且需求回来值（如网络请求、数据库读写、文件读写），在履行结束通过await() 函数获取回来值。

​ 怎么挑选这两个函数就看咱们自己事务的需求啦，比方仅仅需求切换协程履行耗时使命，就用launch函数。假如想把原来的回调式的异步使命用协程的办法完成，就用async函数。

Q14: 区分 Kotlin 中的 launch / join 和 async / await

• launch/join：

​ launch用于发动和中止协程。假如launch 中的代码抛出反常，它会被视为线程中的未捕获反常，一般会在JVM程序中写入 stderr 并导致 Android 应用程序溃散。join 用于在传播其反常之前等候发动的协程完结。另一方面，溃散的子协程会用匹配的反常撤销其父协程。

• async/await：

​ async 关键字用于发动核算回来成果的协程。咱们必须对成果运用 await，它由Deferred 的实例表示。异步代码中未捕获的反常保存在生成的 Deferred中，不会传输到其他任何地方。它们在处理之前不会被履行。

Q15: 协程中的 GlobalScope 以及为什么要防止它？

一般，不鼓舞运用GlobalScope。知道为什么吗？能够看下Kotlin官方关于大局效果域的中界说：

“大局效果域用于发动在整个应用程序生命周期内运转且不会过早撤销的顶级协程。”

GlobalScope 创立大局协程，这些协程不是某个特定规模的子级。因而，开发人员有责任跟踪全部此类大局协程并在完结作业后毁掉它们。这种手动保护协程生命周期的负担或许会导致开发人员付出额外的尽力。此外，假如处理不当，很或许会导致内存泄漏。所以在日常开发中应防止运用GlobalScope。

但是，正如咱们所见，全部协程都必须在某个协程规模内创立。那么，引荐的办法是什么？

正如Kotlin 的CoroutineScope 文档中说到的那样，获取规模的独立实例的最佳办法是CoroutineScope 和 MainScope 工厂。

Q16: 假如协程内部抛出反常会怎么样?

假如在协程中抛出反常，则协程将被撤销。协程的全部子程序也将被撤销，并且这些协程中的任何未完结的作业都将丢掉。

Q17: CoroutineScope.launch {} 中的反常怎么作业？

​ 假定咱们从一个CoroutineScope效果域中发动了 3 个协程

在这儿，Coroutine3抛出一个运用launch {} 构建器的反常

然后Coroutine3会被撤销

这个撤销操作终究会被传输到CoroutineScope，那么它也将撤销封闭

咱们都知道，假如CoroutineScope被撤销的话，那么它的全部子协程也会被撤销

​ 并且这个时分反常也会传播到反常处理程序当中，咱们能够增加自界说的反常处理程序，默许情况下协程会供给一个反常处理程序，这个默许的反常处理程序会导致应用程序溃散。

​

Q18: CoroutineScope.async {} 中的反常怎么作业？

相同的假定咱们从一个CoroutineScope发动了 3 个协程

在这儿，Coroutine3 抛出一个运用 async {} 构建器的反常

然后Coroutine3相同会被撤销

这个撤销操作终究会被传输到CoroutineScope，那么它也将撤销封闭

​ 咱们都知道，假如CoroutineScope被撤销的话，那么它的全部子协程也会被撤销

但是和launch不同的是，它抛出的反常不会委托给协程反常处理程序。相反，只需咱们调用*Deferred.await()*函数，反常就会被从头抛出，在这种情况下不会调用协程反常处理程序。

Q19: 平常运用协程时有碰到哪些过错？

这个问题需求结合实践项目中论述，一般来说，每个人所遇到的问题不尽相同，所以也会有不同的想法；

这儿笔者仅仅罗列出日常开发中一些运用协程呈现的常见过错：

• 咱们在发动协程的时分没有运用正确的上下文,导致协程在不应该撤销的时分被撤销，或许无法访问咱们需求的数据
• 没有运用结构化并发办法，这或许导致竞争条件和其他一些问题
• 运用try/catch来捕获协程的反常

Q20: 运用 Kotlin 协程时有哪些好的做法能够遵循？

一般来说咱们运用协程时分有一些良好的做法，当然，具体要开发者在实践开发中自行领会。下面简略罗列下:

• 将协程用于短期后台使命
• 将协程用于能够并行履行的使命
• 将协程用于需求在与 UI 线程不同的线程上履行的使命
• 不要将协程用于需求履行的使命在 UI 线程上
• 不要对需求同步履行的使命运用协程

Q21: Kotlin协程比Rxjava/RxKotlin好在哪里?

​ 就现在日常开发来说，一些比较新的项目都采用协程而不再运用Rxjava/Kotlin来处理异步问题，原因有两点：

• 协程作为一个线程办理结构，它编写代码愈加简练，关于现已了解面向对象编程和并发/多线程/异步的同学来说，它们十分直观，一起协程现已供给了并发和结构化并发的简略完成，易于保护和扩展，有用进步编码功率；反观Rxjava /RxKotlin，作为响应式编程结构，相同能够优化代码以进步应用程序的响应能力，十分简略扩展，但由于过度运用它而很难保护，并且由于它的复杂性不是那么好上手，使得代码十分复杂，更难调试，那开发同学假如不是特别了解Rxjava的话，就要花更多时刻去解决问题，由于它不会回来过错，并且唯一的调试办法十分原始。
• 其次便是在功用方面，Coroutines 比 RxJava更高效，由于它运用更少的资源来履行相同的使命，一起履行速度更快。RxJava运用更多的内存并需求更多的 CPU时刻，这转化为更高的电池消耗和用户或许的UI中断。

这个问题是有针对性的，并不是说Rxjava不好，就办法数而言，RxJava比彻底根据协程的解决方案更大、更强壮。没有谁好谁坏，全部以本身实践项目出发。比较具体的对比它们之间的不同能够看笔者的另一篇文章Kotlin 协程能彻底替代 RxJava 吗

结语

引荐小鱼人爱编程大佬的协程系列文章，作者写的很具体，关于协程的了解仍是十分到位的，以及一些原理分析运用也十分简略易懂，小伙伴们必定不容错过