Kotlin 協程：通道與流

Question

我最近在學習和閱讀很多關於Flow和 Kotlin 協程的內容。 但是我仍然對什么時候應該使用Flow以及什么時候應該使用Channel感到困惑。

一開始看起來更簡單。 使用熱數據流？ Channel 。 冷的？ Flows 。 如果您需要從多個地方收聽數據流，情況也是如此； 如果是這種情況， Channel是首選。 還有很多例子和問題。

但是最近引入了FlowChannels ，以及大量鼓勵使用Flow的方法和類，這些方法和類有助於將Channels轉換為Flows等等。 隨着每個 Kotlin 版本中出現所有這些新東西，我越來越困惑。 所以問題是：

什么時候應該使用Channel ，什么時候應該使用Flow ？

Answer 1

對於迄今為止最好的工具是Channel許多用例， Flow已成為新的最佳工具。

作為一個具體的例子， callbackFlow現在是從 3rd-party API 的回調接收數據的最佳方法。 這在 GUI 設置中特別有效。 它將回調、通道和關聯的接收協程都耦合在同一個獨立的Flow實例中。 僅在收集流時注冊回調。 取消流程會自動傳播到關閉通道和取消注冊回調。 您只需要提供一次回調注銷代碼。

您應該將Channel視為Flow在其實現中使用的較低級別的原語。 只有在您意識到Flow不符合您的要求后才考慮直接使用它。

Answer 2

在我看來，這里有一個很好的解釋（Roman Elizarov）冷流，熱通道：

通道非常適合對本質上很熱的數據源、無需應用程序請求而存在的數據源進行建模：傳入網絡連接、事件流等。通道，就像期貨一樣，是同步原語。 當您需要將數據從一個協程發送到相同或不同進程中的另一個協程時，您應該使用通道

但是如果我們不需要並發或同步，而只需要非阻塞的數據流呢？ 直到最近我們才擁有一個類型，所以歡迎 Kotlin Flow類型......

與通道不同，流本質上不涉及任何並發性。 它們是非阻塞的，但是是順序的。 流的目標是讓異步數據流成為異步操作的掛起函數——方便、安全、易於學習和易於使用。