Kotlin Flow數據流的3種使用場景詳解

Posted on by

一 Flow使用註意事項

多個Flow不能放到一個lifecycleScope.launch裡去collect{}，因為進入collect{}相當於一個死循環，下一行代碼永遠不會執行；如果就想寫到一個lifecycleScope.launch{}裡去，可以在內部再開啟launch{}子協程去執行。

示例，下面是錯誤寫法：

  //NOTE: 下面的示例是錯誤寫法
  lifecycleScope.launch { 
        mFlowModel.caseFlow1
            .flowWithLifecycle(lifecycle, Lifecycle.State.STARTED)
            .collect {}

        mFlowModel.caseFlow2
            .flowWithLifecycle(lifecycle, Lifecycle.State.STARTED)
            .collect {}
  }

正確寫法：

  lifecycleScope.launch {
        launch {
            mFlowModel.caseFlow1
                .flowWithLifecycle(lifecycle, Lifecycle.State.STARTED)
                .collect {}
       }

        launch {
            mFlowModel.caseFlow2
                .flowWithLifecycle(lifecycle, Lifecycle.State.STARTED)
                .collect {}
        }
    }

當然，直接啟動多個 lifecycleScope.launch也是可以的。

二 幾種使用場景

2.1、處理復雜、耗時邏輯

一般在處理復雜邏輯、耗時操作時，我們會將其放到子線程中去處理，避免在主線程中處理導致卡頓。而Flow可以方便地進行線程切換，所以處理復雜邏輯、耗時操作時，可以考慮使用Flow來進行處理，下面來看一個例子：

假設我們想讀取本地Assets目錄下的person.json文件，並將其解析出來，json文件中的內容

// assets目錄下person.json
{
	"name": "小馬快跑",
	"age": 18,
	"interest": "money! lots of money!"
}

下面通過Flow的方式實現在IO線程中讀取json文件，並最終在主線程中輸出結果：

/**
 * 通過Flow方式，獲取本地文件
 */
 private fun getFileInfo() {
      lifecycleScope.launch {
            flow {
                //解析本地json文件，並生成對應字符串
                val configStr = getAssetJsonInfo(requireContext(), "person.json")
                //最後將得到的實體類發送到下遊
                emit(configStr)
            }
                .map { json ->
                    Gson().fromJson(json, PersonModel::class.java) //通過Gson將字符串轉為實體類
                }
                .flowOn(Dispatchers.IO) //在flowOn之上的所有操作都是在IO線程中進行的
                .onStart { log("onStart") }
                .filterNotNull()
                .onCompletion { log("onCompletion") }
                .catch { ex -> log("catch:${ex.message}") }
                .collect {
                    log("collect parse result:$it")
                }
        }
  }

/**
 * 讀取Assets下的json文件
 */
private fun getAssetJsonInfo(context: Context, fileName: String): String {
        val strBuilder = StringBuilder()
        var input: InputStream? = null
        var inputReader: InputStreamReader? = null
        var reader: BufferedReader? = null
        try {
            input = context.assets.open(fileName, AssetManager.ACCESS_BUFFER)
            inputReader = InputStreamReader(input, StandardCharsets.UTF_8)
            reader = BufferedReader(inputReader)
            var line: String?
            while ((reader.readLine().also { line = it }) != null) {
                strBuilder.append(line)
            }
        } catch (ex: Exception) {
            ex.printStackTrace()
        } finally {
            try {
                input?.close()
                inputReader?.close()
                reader?.close()
            } catch (e: IOException) {
                e.printStackTrace()
            }
        }
    return strBuilder.toString()
}

執行結果：

11:11:32.178  E  onStart
11:11:32.197  E  collect parse result:PersonModel(name=小馬快跑, age=18, interest=money! lots of money!)
11:11:32.198  E  onCompletion

可以看到在collect{}中得到瞭正確的數據，這裡註意一下flowOn()的作用域是在自身之上的操作，上述例子中flowOn(Dispatchers.IO) 意味著在flowOn之上的所有操作都是在IO線程中進行的。

2.2、存在依賴關系的接口請求

如果最終展示依賴多個接口且接口之間是有依賴關系的，之前我們可能會在第一個接口請求成功的回調裡繼續調用第二個接口，以此類推，這樣雖然能實現，但是會導致回調層級很深，也就是所謂的回調地獄；此時可以使用Flow的flatMapConcat將多個接口串聯起來。

lifecycleScope.launch {
     lifecycle.repeatOnLifecycle(Lifecycle.State.STARTED) {
                 //將兩個flow串聯起來 先搜索目的地，然後到達目的地
                mFlowModel.getSearchFlow()
                    .flatMapConcat {
                        //第二個flow依賴第一個的結果
                        mFlowModel.goDestinationFlow(it)
                    }.collect {
                        mTvCallbackFlow.text = it ?: "error"
                    }
     }
}

2.3、組合多個接口的數據

有這樣一種場景：數據的最終展示依賴多個接口請求到的數據，有兩種實現方式：

  • 一個個串行去請求接口，拿到數據後最終拼到一起；
  • 所有接口並行去請求，拿到數據後最終拼到一起。

串行請求雖然可以，但是效率並不高；更優的方式是采用接口並行，可以使用Flow的zip操作符，如下要獲取電費、水費、網費的總花銷，對應的花費需要各自請求自己的接口，最終把數據進行合並統計：

  //ViewModel中
  //分別請求電費、水費、網費，Flow之間是並行關系
  suspend fun requestElectricCost(): Flow<ExpendModel> =
        flow {
            delay(500)
            emit(ExpendModel("電費", 10f, 500))
        }.flowOn(Dispatchers.IO)

  suspend fun requestWaterCost(): Flow<ExpendModel> =
        flow {
            delay(1000)
            emit(ExpendModel("水費", 20f, 1000))
        }.flowOn(Dispatchers.IO)

  suspend fun requestInternetCost(): Flow<ExpendModel> =
        flow {
            delay(2000)
            emit(ExpendModel("網費", 30f, 2000))
        }.flowOn(Dispatchers.IO)

  data class ExpendModel(val type: String, val cost: Float, val apiTime: Int) {
    fun info(): String {
        return "${type}: ${cost}, 接口請求耗時約$apiTime ms"
    }
}
    //UI層
    mBtnZip.setOnClickListener {
        lifecycleScope.launch {
            val electricFlow = mFlowModel.requestElectricCost()
            val waterFlow = mFlowModel.requestWaterCost()
            val internetFlow = mFlowModel.requestInternetCost()

            val builder = StringBuilder()
            var totalCost = 0f
            val startTime = System.currentTimeMillis()
            //NOTE:註意這裡可以多個zip操作符來合並Flow，且多個Flow之間是並行關系
            electricFlow.zip(waterFlow) { electric, water ->
                totalCost = electric.cost + water.cost
                builder.append("${electric.info()},\n").append("${water.info()},\n")
            }.zip(internetFlow) { two, internet ->
                totalCost += internet.cost
                two.append(internet.info()).append(",\n\n總花費：$totalCost")
            }.collect {
                mTvZipResult.text = it.append("，總耗時：${System.currentTimeMillis() - startTime} ms")
            }
        }
    }

執行結果：

電費: 10.0, 接口請求耗時約500 ms,
水費: 20.0, 接口請求耗時約1000 ms,
網費: 30.0, 接口請求耗時約2000 ms,
                 
總花費：60.0，總耗時：2012 ms

可以看到不但得到瞭所有接口的數據，而且總耗時基本等於耗時最長的接口的時間，說明zip操作符合並的多個Flow內部接口請求是並行的。

到此這篇關於Kotlin Flow數據流的3種使用場景詳解的文章就介紹到這瞭,更多相關Kotlin Flow數據流內容請搜索WalkonNet以前的文章或繼續瀏覽下面的相關文章希望大傢以後多多支持WalkonNet！

推薦閱讀：