前言
都2023年了,Kotlin協程和Flow大家都用的很熟了吧。Kotlin Flow 的主要作用是簡化異步數據處理的開發,提高代碼的可讀性和可維護性,并提高應用程序的性能和效率。
看一個demo,然后思考2個問題
runBlocking {
flow {
println("wait exe emit 1")
emit(1)
println("wait exe emit 2")
emit(2)
}.collect {
println("collect value : $it")
}
}
執行結果
wait exe emit 1
collect value : 1
wait exe emit 2
collect value : 2
從打印結果可以看出,flow代碼塊中的emit
方法和collect代碼塊中的print
是交替執行的。另外,如果不調用collect方法,是沒有任何打印的。
再來看一個改造的demo
runBlocking {
flow {
emit(1)
emit(2)
}.collect(object :FlowCollector<Int>{
override suspend fun emit(value: Int) {
println(value)
}
})
}
demo2和demo1從執行結果來看是一樣的,區別是把collect方法從lambda變成了接口實現的方式。
接下來,我們就思考并解決如下問題
- flow,collect的執行順序為什么是這樣的?
- 為什么必須調用collect方法才能執行flow代碼塊?
源碼解析
Flow對象的創建
flow{ }的實現
//Creates a _cold_ flow from the given suspendable [block].
public fun <T> flow(@BuilderInference block: suspend
FlowCollector<T>.() -> Unit): Flow<T> = SafeFlow(block)
可以看到flow()
里面需要傳入了FlowCollector的擴展方法,同時會返回一個Flow對象,Flow就是個接口。
這個FlowCollector接口是不是很熟悉,上面demo2中collect參數就是它。
public interface FlowCollector<in T> {
/**
* Collects the value emitted by the upstream.
* This method is not thread-safe and should not be invoked concurrently.
*/
public suspend fun emit(value: T)
}
這個接口的作用是:下游收集上游發出的值
再來看下Flow接口
public interface Flow<out T> {
/**
* Accepts the given [collector] and [emits][FlowCollector.emit] values into it.
* This method should never be implemented or used directly.
*
* The only way to implement the `Flow` interface directly is to extend [AbstractFlow].
* To collect it into a specific collector, either `collector.emitAll(flow)` or `collect { ... }` extension
* should be used. Such limitation ensures that the context preservation property is not violated and prevents most
* of the developer mistakes related to concurrency, inconsistent flow dispatchers and cancellation.
*/
@InternalCoroutinesApi
public suspend fun collect(collector: FlowCollector<T>)
}
它只有一個
collect
方法,作用是:收集上游emit方法發射的數據
大家先記住這2個接口,后面流程都是圍繞這2個接口來完成的。
上面flow方法源碼提到了,會創建一個SafeFlow對象
private class SafeFlow<T>(private val block: suspend FlowCollector<T>.() -> Unit) : AbstractFlow<T>() {
override suspend fun collectSafely(collector: FlowCollector<T>) {
//3.調用block
collector.block()
}
}
public abstract class AbstractFlow<T> : Flow<T>, CancellableFlow<T> {
@InternalCoroutinesApi
//1.調用collect方法
public final override suspend fun collect(collector: FlowCollector<T>) {
val safeCollector = SafeCollector(collector, coroutineContext)
try {
//2.調用抽象方法collectSafely
collectSafely(safeCollector)
} finally {
safeCollector.releaseIntercepted()
}
}
public abstract suspend fun collectSafely(collector: FlowCollector<T>)
}
這段代碼就是我們理清楚文章開頭提出的2個疑問的關鍵所在,下面分析下。
demo中的flow{ }.collect{ }
可以拆成2部分,先創建SafeFlow對象,它是繼承了AbstractFlow這個抽象類,然后調用它的collect方法,關鍵流程就是上面注釋中的3個步驟。
可以看出最后是調用了block(),那這個block又是哪里來的呢?還記得flow{ }的實現嗎?
public fun <T> flow(@BuilderInference block: suspend
FlowCollector<T>.() -> Unit): Flow<T> = SafeFlow(block)
這個block就是flow方法的參數這個block啊,它是FlowCollector的一個擴展函數,這個block其實就是我們flow { }
大括號中的代碼塊啊,這個就是一個lambda表達式的語法而已。
所以,調用collect方法,最終是執行了
flow { }
中的代碼塊。現在能理解為什么必須要調用collect這個收集方法才能觸發上游的數據發射了吧,這也解釋了為什么flow{}是冷流,因為必須要有收集者才能觸發上游的數據發射。
在flow { }
代碼塊中每次調用emit方法,會執行到collect{ }
中的代碼塊,實際上就是執行的FlowCollector這個接口的emit方法啊,只不過collect{ }
用了lambda來簡化而已。
用一張圖來總結