【Kotlin回顾】25.Kotlin协程—select

敞开生长之旅！这是我参加「日新方案 12 月更文应战」的第36天，点击检查活动概况

select在1.6的版本中还是一个实验性的特性，可是假如select与Deferred、Channel结合运用的话能够明显的提高程序运转的功率以及改善程序的灵活性和可扩展性。今天首要来聊一聊select的运用。

1.select便是挑选「更快」的成果

举个例子，现在要获取用户信息进行展现，有缓存获取和网络恳求获取两种方法，正常情况下缓存获取是最快的可是信息不一定是最新的，网络获取比前者慢可是的确最新的，他们的代码逻辑能够这么写：

fun main() = runBlocking {
    val startTime = System.currentTimeMillis()
    val cacheUserInfo = getCacheUserInfo("张三")
    updateUI(cacheUserInfo)
    println("cache 耗时：${(System.currentTimeMillis() - startTime)}")
    val networkUserInfo = getNetworkUserInfo("李四")
    updateUI(networkUserInfo)
    println("network 耗时：${(System.currentTimeMillis() - startTime)}")
}
/**
 * 从缓存获取用户信息
 */
suspend fun getCacheUserInfo(name: String): User {
    delay(1000)
    return User(name, 20)
}
/**
 * 从网络获取用户信息
 */
suspend fun getNetworkUserInfo(name: String): User {
    delay(1500)
    return User(name, 44)
}
fun updateUI(user: User) {
    println("${user.name}：${user.age}")
}
data class User(
    val name: String,
    val age: Int
)
//输出成果：
//张三：20
//cache 耗时：1011
//李四：44
//network 耗时：2515

上面代码流程是先从缓存中获取信息，再从网络连接中获取信息，首要分为四步：

• 第一步：查询缓存信息；
• 第二步：缓存服务回来信息，更新 UI；
• 第三步：查询网络服务；
• 第四步：网络服务回来信息，更新 UI。

可是上面这段代码是建立在缓存获取信息没有问题或者比网络恳求快的前提下，假如说这儿的缓存呈现了超时的问题那么网络恳求的函数是无法被履行的，由于getCacheUserInfo是一个挂起函数，它在没有被恢复的时分后边的函数是无法被履行的，这儿假定缓存呈现了超时情况，将getCacheUserInfo函数中的delay(1000)改为delay(2000)，那输出的成果如下：

//输出成果
//张三：20
//cache 耗时：2005
//李四：44
//network 耗时：3511

看的出来networkUserInfo终究获取到的时刻也会被延伸，那么假如将getCacheUserInfo()和getNetworkUserInfo()两个函数的履行改为并行的话即便缓存呈现问题用户信息也是能够正常获取的，只不过走的是网络恳求：

fun main() = runBlocking {
    val startTime = System.currentTimeMillis()
    val cacheDeffered = async {
        val cacheUserInfo = getCacheUserInfo("张三")
        updateUI(cacheUserInfo)
        println("cache 耗时：${(System.currentTimeMillis() - startTime)}")
    }
    val networkDeffered = async {
        val networkUserInfo = getNetworkUserInfo("李四")
        updateUI(networkUserInfo)
        println("network 耗时：${(System.currentTimeMillis() - startTime)}")
    }
}
//输出成果：
//李四：44
//network 耗时：1595
//张三：20
//cache 耗时：2085

从成果看的出来并行之后不存在getNetworkUserInfo被阻塞的情况，那么假如我想要的是这两种方法谁最早回来就用谁的数据呢要怎么完结，这儿就进入倒了今天的主体：select。

2.select和async

用select将上面async完结并行的代码进行改造：

fun main() = runBlocking {
    val startTime = System.currentTimeMillis()
    val userInfo = select<User> {
        async { getCacheUserInfo("张三") }
            .onAwait { it } //这儿是要点
        async { getNetworkUserInfo("李四") }
            .onAwait { it } //这儿是要点
    }
    if(userInfo!=null){
        updateUI(userInfo)
        println("select 耗时：${(System.currentTimeMillis() - startTime)}")
    }
}

这儿首要运用 select 这个高阶函数包裹了两次查询的服务，一起传入了泛型参数 User，代表咱们要挑选的数据类型是 User，然后在async后边添加了onAwait { it }，这儿的意图是为了将成果传递给select，select才能将成果回来给变量并在后边更新UI。

至于它的输出成果其实便是依据谁先有呼应就输出谁的成果，比如说缓存获取时刻为delay(1000)网络恳求时刻为delay(1500)得到的成果便是缓存的呼应， 反过来的话得到的成果便是网络恳求的呼应， 所以select的作用便是挑选最快有呼应的哪一个成果进行输出， 这样就避免了等候太长的时刻，得到糟糕的体会。

这儿还存在一个问题，便是假如缓存获取不呈现问题，那么缓存的获取是一定会比网络恳求快的，用了select之后每次获取到的信息都是旧的了，这儿要怎么处理？处理这个问题其实便是加一个标识，这儿我贴上完好代码：

/**
 * 从缓存获取用户信息
 */
suspend fun getCacheUserInfo(name: String): User {
    delay(1000)
    return User(name, 20)
}
/**
 * 从网络获取用户信息
 */
suspend fun getNetworkUserInfo(name: String): User {
    delay(1500)
    return User(name, 44)
}
fun updateUI(user: User) {
    println("${user.name}：${user.age}")
}
data class User(
    val name: String,
    val age: Int,
    val isCache: Boolean = false
)
fun main() = runBlocking {
    val startTime = System.currentTimeMillis()
    val cacheUserInfo = async { getCacheUserInfo("张三") }
    val networkUserInfo = async { getNetworkUserInfo("李四") }
    val userInfo = select<User> {
        cacheUserInfo.onAwait { it?.copy(isCache = true) }
        networkUserInfo.onAwait { it?.copy(isCache = false) }
    }
    if (userInfo != null) {
        updateUI(userInfo)
        println("select 耗时：${(System.currentTimeMillis() - startTime)}")
    }
    if (userInfo != null && userInfo.isCache) {
        val network = networkUserInfo.await()?: return@runBlocking
        updateUI(network)
        println("network 耗时: ${System.currentTimeMillis() - startTime}")
    }
}
//输出成果
//张三：20
//select 耗时：1057
//李四：44
//network 耗时: 1571

经过isCache这个标识，当获取的是缓存数据时要再进行网络数据的恳求，这样缓存中的数据便是注重最新的了。

3.select和channel

前面在channel运用篇讲过，channel能够发送多条数据，假定这儿有这样一个需求，后台下发一个使命，每履行一步都要先在屏幕上展现，再写入本地文件(这两件事能够做成一件，这儿首要为了举例)，只用channel来完结的话大概是这样：

fun main() = runBlocking {
    val startTime = System.currentTimeMillis()
    val channelUI = produce {
        send("UI展现：使命发动")
        delay(100)
        send("UI展现：使命履行")
        delay(100)
        send("UI展现：使命停止")
        delay(100)
    }
    val channelFile = produce {
        send("写入文件：使命发动")
        delay(100)
        send("写入文件：使命履行")
        delay(100)
        send("写入文件：使命停止")
        delay(100)
    }
    channelUI.consumeEach{
        println(it)
    }
    channelFile.consumeEach{
        println(it)
    }
    println("耗时: ${System.currentTimeMillis() - startTime}")
}
//输出成果
//UI展现：使命发动
//UI展现：使命履行
//UI展现：使命停止
//写入文件：使命发动
//写入文件：使命履行
//写入文件：使命停止
//耗时: 686

从输出成果能够看到好像是完结这个需求，可是写入文件的操作是在UI展现完结后才开端履行，那么参加UI展现有很多呢？是不是就意味着写入文件这一操作什么时分履行也不知道了。

假如用select完结会是怎么样的成果呢：

fun main() = runBlocking {
    val startTime = System.currentTimeMillis()
    val channelUI = produce {
        send("UI展现：使命发动")
        delay(100)
        send("UI展现：使命履行")
        delay(100)
        send("UI展现：使命停止")
        delay(100)
    }
    val channelFile = produce {
        send("写入文件：使命发动")
        delay(100)
        send("写入文件：使命履行")
        delay(100)
        send("写入文件：使命停止")
        delay(100)
    }
    //1
    repeat(6) {
        selectChannel(channelUI, channelFile)
    }
    println("耗时: ${System.currentTimeMillis() - startTime}")
}
suspend fun selectChannel(
    channelUI: ReceiveChannel<String>, 
    channelFile: ReceiveChannel<String>
):String = select<String>{
    //2
    channelUI.onReceive{ it.also { println(it) } }
    channelFile.onReceive{ it.also { println(it) } }
}
//输出成果
//UI展现：使命发动
//写入文件：使命发动
//UI展现：使命履行
//写入文件：使命履行
//UI展现：使命停止
//写入文件：使命停止
//耗时: 400

先对上面的几个注释进行阐明：

• 注释1：履行6次，链各个管道中各有3条数据，履行6次的首要意图是将管道中的数据全部消耗掉；
• 注释2：onReceive{} 是 Channel 在 select 傍边的语法，当 Channel 傍边有数据今后，它就会被回调，经过这个 Lambda，咱们也能够将成果传出去

前后两种方法的履行成果比照能够发现，select的完结比Channel的完结耗费的时刻更少，并且他们是交替履行的。那么此刻假如channelUI遇到问题了channelFile是否会履行呢？

fun main() = runBlocking {
    val startTime = System.currentTimeMillis()
    val channelUI = produce<String> {
        delay(100000)
    }
    val channelFile = produce {
        send("写入文件：使命发动")
        delay(100)
        send("写入文件：使命履行")
        delay(100)
        send("写入文件：使命停止")
        delay(100)
    }
    repeat(6) {
        selectChannel(channelUI, channelFile)
    }
    println("耗时: ${System.currentTimeMillis() - startTime}")
}
suspend fun selectChannel(channelUI: ReceiveChannel<String>, channelFile: ReceiveChannel<String>):String = select<String>{
    channelUI.onReceive{ it.also { println(it) } }
    channelFile.onReceive{ it.also { println(it) } }
}
//输出成果
//写入文件：使命发动
//写入文件：使命履行
//写入文件：使命停止
//Exception in thread "main" kotlinx.coroutines.channels.ClosedReceiveChannelException: Channel was closed

能够看到这儿正常的输出了channelFile的数据，这阐明select参加后即便另一个管道没有数据也不会影响整个使命的履行。

在输出成果的一起还爆出了一个过错，这个过错的原因是，channel中只需三个数据，当他们发送完毕后就被封闭了，而第4次调用时由于channel已经被封闭了所以爆出了这个过错，假如把【6】改成【3】这个过错就不会呈现了。可是在这个需求中并不知道详细有多少数据，那要处理这个问题就要运用onReceiveCatching{}了。

fun main() = runBlocking {
    val startTime = System.currentTimeMillis()
    val channelUI = produce<String> {
        delay(100000)
    }
    val channelFile = produce {
        send("写入文件：使命发动")
        delay(100)
        send("写入文件：使命履行")
        delay(100)
        send("写入文件：使命停止")
        delay(100)
    }
    repeat(6) {
        val result = selectChannel(channelUI, channelFile)
    	//打印成果
        println(result)
    }
    println("耗时: ${System.currentTimeMillis() - startTime}")
}
suspend fun selectChannel(channelUI: ReceiveChannel<String>, channelFile: ReceiveChannel<String>):String = select<String>{
    //这儿做了改动
    channelUI.onReceiveCatching{ it.getOrNull() ?: "channelUI is closed!" }
    channelFile.onReceiveCatching{it.getOrNull() ?: "channelFile is closed!"  }
}
//输出成果
//写入文件：使命发动
//写入文件：使命履行
//写入文件：使命停止
//channelFile is closed!
//channelFile is closed!
//channelFile is closed!
//耗时: 442

这时分，即便不知道管道里有多少个数据，咱们也不必担心溃散的问题了。在 onReceiveCatching{} 这个高阶函数傍边，咱们能够运用 it.getOrNull() 来获取管道里的数据，假如获取的成果是 null，就代表管道已经被封闭了。不过，上面的代码仍然还有一个问题，那便是，得到所有成果今后，程序不会立即退出，由于咱们的 channelUI 一直在 delay()。这时分，完结 6 次repeat()调用今后，将 channelUI、channelFile 撤销即可。

//在repeat()后添加即可
channelUI.cancel() 
channelFile.cancel()

4.select和channel、Deffered之间的联络

经过前面的剖析能够发现，当select参加后，它们本来的 API 会多一个 on 前缀。

所以，只需记住了 Deferred、Channel 的 API，你是不需要额定记忆 select 的 API 的，只需要在本来的 API 的前面加上一个 on 就行了。另外还要注意的是，当 select 与 Deferred 结合运用的时分，当并行的 Deferred 比较多的时分，你往往需要在得到一个最快的成果今后，去撤销其他的 Deferred。

比如说，对于 Deferred1、Deferred2、Deferred3、Deferred4、Deferred5，其中 Deferred2 回来的成果最快，这时分，咱们往往会期望撤销其他的 Deferred，以节约资源。那么在这个时分，咱们能够运用相似这样的方法：

fun main() = runBlocking {
    suspend fun <T> fastest(vararg deferreds: Deferred<T>): T = select {
        fun cancelAll() = deferreds.forEach { it.cancel() }
        for (deferred in deferreds) {
            deferred.onAwait {
                cancelAll()
                it
            }
        }
    }
    val deferred1 = async {
        delay(100L)
        println("done1")    // 没时机履行
        "result1"
    }
    val deferred2 = async {
        delay(50L)
        println("done2")
        "result2"
    }
    val deferred3 = async {
        delay(10000L)
        println("done3")    // 没时机履行
        "result3"
    }
    val deferred4 = async {
        delay(2000L)
        println("done4")    // 没时机履行
        "result4"
    }
    val deferred5 = async {
        delay(14000L)
        println("done5")    // 没时机履行
        "result5"
    }
    val result = fastest(deferred1, deferred2, deferred3, deferred4, deferred5)
    println(result)
}
/*
输出成果
done2
result2
*/

5.总结

• select，便是挑选“更快的成果”。
• 当 select 与 async、Channel 调配今后，能够并发履行协程使命，以此大大提高程序的履行功率甚至用户体会，并且还能够改善程序的扩展性、灵活性。
• 关于 select 的 API，不需要去刻意记忆，只需要在 Deferred、Channel 的 API 基础上加上 on 这个前缀即可。