【Koltin Flow（五）】SharedFlow及StateFlow

已于 2022-08-05 09:34:49 修改
阅读量953 收藏
点赞数
分类专栏： Kotlin android小菜 文章标签： android kotlin java
于 2022-08-04 20:00:00 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/jinjin10086/article/details/126126581
版权

目录

【Koltin Flow（一）】五种创建flow的方式
【Koltin Flow（二）】Flow操作符之末端操作符
【Koltin Flow（三）】Flow操作符之中间操作符（一）
【Koltin Flow（三）】Flow操作符之中间操作符（二）
【Koltin Flow（三）】Flow操作符之中间操作符（三）
【Koltin Flow（四）】Flow背压
【Koltin Flow（五）】SharedFlow及StateFlow

SharedFlow

简介
相对于Flow而言，SharedFlow为热流，也就是说不管有无接收者，都会发送值。
一、基本使用
代码如下：
            val sharedFlow = MutableSharedFlow<Int>()
            launch {
                sharedFlow.collect {
                    Log.d(TAG.TAG,"SharedFlow $it")
                }
            }

            delay(10)
            sharedFlow.emit(1)
            sharedFlow.emit(100)
            sharedFlow.emit(100)
日志如下：
2022-08-03 10:16:53.366 4955-4981/edu.test.demo D/Test-TAG: SharedFlow 1
2022-08-03 10:16:53.366 4955-4981/edu.test.demo D/Test-TAG: SharedFlow 100
2022-08-03 10:16:53.367 4955-4981/edu.test.demo D/Test-TAG: SharedFlow 100
分析
  • 日志可以看出 基本使用的时候和flow本身没多大区别，发送-接收。
  • 可以看出上面有个delay(10)，如果没有则可能会接收不到值，因为SharedFlow为热流，不管有无接收者，emit都会直接发送值。
二、设置订阅重发
我们看SharedFlow构造的第一个参数replay，此参数用来设置订阅重发的个数。
代码如下：
            val sharedFlow = MutableSharedFlow<Int>(
                replay = 2
            )

            sharedFlow.emit(1)
            sharedFlow.emit(100)
            sharedFlow.emit(100)
			//注释1  在此处加上重发缓存打印
			//Log.d(TAG.TAG,"SharedFlow ${sharedFlow.replayCache}")
            delay(100)

            launch {
                sharedFlow.collect {
                    Log.d(TAG.TAG,"SharedFlow $it")
                }
            }
             //注释2 重置缓存
            //delay(100)
            //sharedFlow.resetReplayCache()
            //Log.d(TAG.TAG,"SharedFlow ${sharedFlow.replayCache}")
            //launch {
              //  sharedFlow.collect {
                //    Log.d(TAG.TAG,"SharedFlow 2 $it")
                //}
            //}
日志如下：
//注释1 处的打印
//2022-08-03 10:23:13.621 5106-5131/edu.test.demo D/Test-TAG: SharedFlow [100, 100]
2022-08-03 10:21:14.906 5043-5070/edu.test.demo D/Test-TAG: SharedFlow 100
2022-08-03 10:21:14.906 5043-5070/edu.test.demo D/Test-TAG: SharedFlow 100
//注释2下的打印
//2022-08-03 10:26:54.917 5233-5260/edu.test.demo D/Test-TAG: SharedFlow []
分析：
  • 可以看到，虽然是发送在前，接收在后，但还是收到了两个值。因为replay重发的值设置为2，可以这样看起来不直观，这样，我们修改下代码，放开注释1出的打印，则日志会多出来【注释1 处的打印】部分的内容，可以很清晰的看出缓存了后两个值。
  • 当然此缓存可以重置，也就是清空之前的缓存，放开注释2处的代码，则可以看出resetReplayCache，之后则清空了缓存，后面的collect接收不到缓存的值。
三、其他两个参数，可参考背压部分的内容
四、shareIn操作符
shareIn操作符是将冷流flow转换为热流SharedFlow，主要参数有三个
1、第一个为作用域。
2、策略，分为三种Eagerly（立即发送）、Lazily（有第一个订阅者之后发送）、
WhileSubscribed()（在第一个订阅者出现之后开始、在最后一个订阅者、消失后结束），可配置二外的参数：
stopTimeoutMillis 为最后一个订阅者小时候保留的时长，单位ms，默认为0。
replayExpirationMillis 为最后一个订阅者消失后，缓存保留的时长，单位ms，默认为Long.MAX_VALUE。
3、缓存重发的个数。
第一种策略
代码如下：
     val sharedFlow = (1..5).asFlow().shareIn(this, SharingStarted.Eagerly,0)
            delay(100)
            sharedFlow.collect {
                Log.d(TAG.TAG,"shareIn $it")
            }
日志没有
分析：
  • 我们发现没有日志，原因在哪里呢，因为转换成热流之后策略为Eagerly，立即开始发送，但是100ms之后才有collect，同时replay的个数为0，所以接收不到值，如果我们将replay个数改为2，则可以接收到4和5，和上面的订阅重发是一样的。
第二种策略
代码如下：
    val sharedFlow = (1..5).asFlow().shareIn(this, SharingStarted.Lazily, 2)
            delay(100)
            launch {
                sharedFlow.collect {
                    Log.d(TAG.TAG, "shareIn $it")
                }
            }
            delay(100)
            launch {
                sharedFlow.collect {
                    Log.d(TAG.TAG, "shareIn 2 $it")
                }
            }
日志如下：
2022-08-03 11:09:10.104 6691-6717/edu.test.demo D/Test-TAG: shareIn 1
2022-08-03 11:09:10.104 6691-6717/edu.test.demo D/Test-TAG: shareIn 2
2022-08-03 11:09:10.104 6691-6717/edu.test.demo D/Test-TAG: shareIn 3
2022-08-03 11:09:10.104 6691-6717/edu.test.demo D/Test-TAG: shareIn 4
2022-08-03 11:09:10.104 6691-6717/edu.test.demo D/Test-TAG: shareIn 5
2022-08-03 11:09:10.205 6691-6720/edu.test.demo D/Test-TAG: shareIn 2 4
2022-08-03 11:09:10.205 6691-6720/edu.test.demo D/Test-TAG: shareIn 2 5
分析：
  • 可以看出，第一个collect能接收到全部值，那是因为Lazily是在第一个订阅者出现后才发送值的，但是第二个collect却只接收到了缓存的两个值，那是因为Lazily只管第一个collect，不管后续的collect。
第三种策略
1. 采用默认参数
代码如下：
  var time  = 0L
            time = System.currentTimeMillis()
            val sharedFlow = (1..100).asFlow().onStart {
                Log.d(TAG.TAG,"onStart ${System.currentTimeMillis() - time}")
            }.onCompletion {
                Log.d(TAG.TAG,"onCompletion ${System.currentTimeMillis() - time}")
            }.onEach {
                delay(1000)
            }.shareIn(this, SharingStarted.WhileSubscribed(), 0)

            delay(1000)
            launch {
                Log.d(TAG.TAG, "1 shareIn ${sharedFlow.first()}")
                Log.d(TAG.TAG,"1 接收到第一个值 ${System.currentTimeMillis() - time}")
            }

            delay(3000)
            launch {
                Log.d(TAG.TAG, "2 shareIn ${sharedFlow.first()}")
                Log.d(TAG.TAG,"2 接收到第一个值 ${System.currentTimeMillis() - time}")
            }
日志如下：
2022-08-03 14:00:32.842 8905-8930/edu.test.demo D/Test-TAG: onStart 1029
2022-08-03 14:00:33.844 8905-8930/edu.test.demo D/Test-TAG: 1 shareIn 1
2022-08-03 14:00:33.844 8905-8930/edu.test.demo D/Test-TAG: 1 接收到第一个值 2031
2022-08-03 14:00:33.845 8905-8931/edu.test.demo D/Test-TAG: onCompletion 2032
2022-08-03 14:00:35.839 8905-8931/edu.test.demo D/Test-TAG: onStart 4026
2022-08-03 14:00:36.841 8905-8931/edu.test.demo D/Test-TAG: 2 shareIn 1
2022-08-03 14:00:36.841 8905-8931/edu.test.demo D/Test-TAG: 2 接收到第一个值 5028
2022-08-03 14:00:36.841 8905-8930/edu.test.demo D/Test-TAG: onCompletion 5028
分析：
  • 可以看出 在first之后第一个接收者消失，所以执行了onCompletion，也就是flow结束了，而且接收到第一个值和onCompletion的时间基本是一致的。
  • 在4000ms之后第二个接收者出现，重新执行了onStart ，并且在first之后也执行了onCompletion结束了。
2.进行相关的参数配置
代码如下：
             var time  = 0L
            time = System.currentTimeMillis()
            val sharedFlow = (1..100).asFlow().onStart {
                Log.d(TAG.TAG,"onStart ${System.currentTimeMillis() - time}")
            }.onCompletion {
                Log.d(TAG.TAG,"onCompletion ${System.currentTimeMillis() - time}")
            }.onEach {
                delay(1000)
            }.shareIn(this, SharingStarted.WhileSubscribed(
                stopTimeoutMillis = 500,
                replayExpirationMillis = 2000
            ), replay = 5)

            delay(1*1000)
            launch {
                Log.d(TAG.TAG, "1 shareIn ${sharedFlow.take(5).toList()}")
                Log.d(TAG.TAG,"1 接收到值 ${System.currentTimeMillis() - time}")
            }

            delay(10*1000)
            launch {
                Log.d(TAG.TAG, "2 shareIn ${sharedFlow.take(10).toList()}")
                Log.d(TAG.TAG,"2 接收到值 ${System.currentTimeMillis() - time}")
            }
日志如下（ stopTimeoutMillis = 500,replayExpirationMillis = 2000，replay = 5）：
2022-08-03 14:21:15.245 9591-9616/edu.test.demo D/Test-TAG: onStart 1030
2022-08-03 14:21:20.252 9591-9616/edu.test.demo D/Test-TAG: 1 shareIn [1, 2, 3, 4, 5]
2022-08-03 14:21:20.252 9591-9616/edu.test.demo D/Test-TAG: 1 接收到值 6037
2022-08-03 14:21:20.753 9591-9616/edu.test.demo D/Test-TAG: onCompletion 6538
2022-08-03 14:21:25.243 9591-9622/edu.test.demo D/Test-TAG: onStart 11028
2022-08-03 14:21:35.253 9591-9622/edu.test.demo D/Test-TAG: 2 shareIn [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
2022-08-03 14:21:35.253 9591-9622/edu.test.demo D/Test-TAG: 2 接收到值 21038
2022-08-03 14:21:35.755 9591-9617/edu.test.demo D/Test-TAG: onCompletion 21540
分析：
  • 可以看出，在设置了 stopTimeoutMillis = 500之后，接收到值得时间和onCompletion的时间基本差了500ms，其实就是就是延时结束。
  • 在设置了replayExpirationMillis = 2000之后，第二次开始和接收到值的时间基本就是发送10个值得时间，具体值为1-10，那是因为缓存的值已经失效了，此时这个replay = 5没有多大意义，因为到下次的时候值已经失效了。
日志如下（ stopTimeoutMillis = 500,replayExpirationMillis = Long.MAX_VALUE，replay = 5）：
2022-08-03 14:47:30.144 9697-9724/edu.test.demo D/Test-TAG: onStart 1030
2022-08-03 14:47:35.154 9697-9723/edu.test.demo D/Test-TAG: 1 shareIn [1, 2, 3, 4, 5]
2022-08-03 14:47:35.154 9697-9723/edu.test.demo D/Test-TAG: 1 接收到值 6040
2022-08-03 14:47:35.655 9697-9723/edu.test.demo D/Test-TAG: onCompletion 6541
2022-08-03 14:47:40.141 9697-9726/edu.test.demo D/Test-TAG: onStart 11027
2022-08-03 14:47:45.149 9697-9727/edu.test.demo D/Test-TAG: 2 shareIn [1, 2, 3, 4, 5, 1, 2, 3, 4, 5]
2022-08-03 14:47:45.149 9697-9727/edu.test.demo D/Test-TAG: 2 接收到值 16035
2022-08-03 14:47:45.652 9697-9726/edu.test.demo D/Test-TAG: onCompletion 16538
分析：
  • 首先看区别，第一个接收者基本没变化。
  • 第二个接收者有两点变化，接收到的值变了，不再是1-10，而是两个1-5，而且第二个onStart和接收到值的时间也变了，不再是10个值的时间，而是五个值的时间，原因主要如下：第一replayExpirationMillis值设置为 Long.MAX_VALUE（这也是其默认值）之后，第二个接收者出现时，缓存并未失效，所以出现了前面的12345（因为replay=5，缓存前五个），但是take(10)不够了，所以又出现了onStart，再接收五个，也就是后面的12345，时间也就是接收五个的时间。
  • 如果将第二个接收者的take(10)变成take(5)，缓存就直接够了，就不会出现第二个onStart。
  • 当然这也是因为前面是take(5)，如果改成take(3)，后面也就会出现onStart，数据变成12312，那是因为虽然缓存池为5，但是只缓存了三个值，还需要两个。

StateFlow

简介
和SharedFlow一样，StateFlow也是热流，但是区别在于状态的保存，保存了最新的值，也就是新的接收者会收到最新的值，
和设置了replay = 1的SharedFlow比较类似。
简单使用

######代码如下：

            val stateFlow = MutableStateFlow(0)
            launch {
                stateFlow.collect{
                    Log.d(TAG.TAG,"stateFlow 1 collect $it")
                }
            }
            delay(1000)
            stateFlow.value = 10
            delay(1000)
            stateFlow.value = 10
            delay(1000)
            stateFlow.value = 11
            launch {
                stateFlow.collect{
                    Log.d(TAG.TAG,"stateFlow 2 collect $it")
                }
            }
日志如下：
2022-08-03 15:43:14.618 11669-11705/edu.test.demo D/Test-TAG: stateFlow 1 collect 0
2022-08-03 15:43:15.623 11669-11704/edu.test.demo D/Test-TAG: stateFlow 1 collect 10
2022-08-03 15:43:17.626 11669-11705/edu.test.demo D/Test-TAG: stateFlow 1 collect 11
2022-08-03 15:43:17.626 11669-11705/edu.test.demo D/Test-TAG: stateFlow 2 collect 11
分析：
  • 可以看到接收者1刚开始收到了初始值1，那是因为StateFlow在每个接收者出现时都会接收到最新的值。
  • 接收者1后面又接收到了10，那是动态更新StateFlow的value值触发的，但是注意10发送了两次，但是只接收到了一次，说明StateFlow是天然防抖的，连续发送两次同样的值，只会接收一次，后面又接收到了11和第一个10效果一致，是value值触发的。
  • 接收者2接收到11的道理和接收者1接收到1的道理是一样的。
stateIn操作符
stateIn操作符是将冷流flow转换为热流StateFlow，主要参数有三个
1、第一个为作用域。
2、策略，分为三种Eagerly（立即发送）、Lazily（有第一个订阅者之后发送）、
WhileSubscribed()（在第一个订阅者出现之后开始、在最后一个订阅者、消失后结束），可配置二外的参数：
stopTimeoutMillis 为最后一个订阅者小时候保留的时长，单位ms，默认为0。
replayExpirationMillis 为最后一个订阅者消失后，缓存保留的时长，单位ms，默认为Long.MAX_VALUE。
3、StateFlow的初始值。
策略基本和shareIn是一致的，只是replay固定为1，另外会有一个初始值。
分析一种，其他的和shareIn类比即可，策略为WhileSubscribed()。
代码如下：
			 var time = 0L
            time = System.currentTimeMillis()
            val stateFlow = (1..10).asFlow().onStart {
                Log.d(TAG.TAG,"onStart ${System.currentTimeMillis() - time}")
            }.onCompletion {
                Log.d(TAG.TAG,"onCompletion ${System.currentTimeMillis() - time}")
            }.onEach {
                delay(1000)
            }.stateIn(this, SharingStarted.WhileSubscribed(),0)

            launch {
                Log.d(TAG.TAG, "stateFlow 1 collect ${stateFlow.take(5).toList()}")
                Log.d(TAG.TAG,"接收到值 ${System.currentTimeMillis() - time}")
            }
            delay(10*1000)
            launch {
                Log.d(TAG.TAG, "stateFlow 2 collect ${stateFlow.take(5).toList()}")
                Log.d(TAG.TAG,"接收到值 ${System.currentTimeMillis() - time}")
            }
日志如下：
2022-08-03 15:33:35.204 11353-11379/edu.test.demo D/Test-TAG: onStart 70
2022-08-03 15:33:39.219 11353-11380/edu.test.demo D/Test-TAG: stateFlow 1 collect [0, 1, 2, 3, 4]
2022-08-03 15:33:39.219 11353-11380/edu.test.demo D/Test-TAG: 接收到值 4101
2022-08-03 15:33:39.221 11353-11378/edu.test.demo D/Test-TAG: onCompletion 4102
2022-08-03 15:33:45.145 11353-11378/edu.test.demo D/Test-TAG: onStart 10027
2022-08-03 15:33:49.151 11353-11378/edu.test.demo D/Test-TAG: stateFlow 2 collect [4, 1, 2, 3, 4]
2022-08-03 15:33:49.151 11353-11378/edu.test.demo D/Test-TAG: 接收到值 14033
2022-08-03 15:33:49.151 11353-11380/edu.test.demo D/Test-TAG: onCompletion 14033
分析：
  • 可以看到接收者1接收到的值为01234，因为有一个初始值为0，占了一个位置，开始到接收到值的时间也基本是个值的时间，接收到之后也打印了onCompletion，和接收到值的时间基本一致。
  • 第二个接收者，接收到的值为41234，因为StateFlow缓存了一个最新值4，再接收四个新值，时间和接收者1类似。

总结

  • 本篇主要介绍了SharedFlow和StateFlow的基本使用、以及参数设置相关内容。
  • 本篇也终点介绍了shareIn操作符的使用，以及各种策略参数的设置，stateIn类比shareIn理解。
MakerGaoGao
关注
  • 0
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
StateFlow与SharedFlow(一)
qq_29478349的博客
05-09 1185
简介 因作者语文不好,就不进行繁琐的介绍了.如果照抄其他文章或者官方api也没有意义 可以简单理解为StateFlow和SharedFlow都是Flow的子类. 区别是,Flow是冷流,没有订阅者可以理解为他不保存数据,你在订阅之前的数据无法接收. 而StateFlow和SharedFlow是热流,创建的时候就已经在可以保存数据了. 简单来说StateFlow和SharedFlow都可以监听数据的变化 类似LiveData的使用 下面直接上干货 准备工作: implementation.
SharedFlow vs StateFlow，一篇看懂选择和使用技巧
Androiddddd的博客
12-19 1523
通过本文的介绍，相信读者已经对SharedFlow和StateFlow有了更深入的了解。在实际应用中，提高Android应用的开发效率。如果想要成为架构师或想突破20~30K薪资范畴，那就不要局限在编码，业务，要会选型、扩展，提升编程思维。此外，良好的职业规划也很重要，学习的习惯很重要，但是最重要的还是要能持之以恒，任何不能坚持落实的计划都是空谈。
官方推荐 Flow 取代 LiveData,有必要吗？
最新发布
2401_84009899的博客
05-09 243
这里附上上述的技术体系图相关的几十套腾讯、头条、阿里、美团等公司2021年的面试题，把技术点整理成了视频和PDF（实际上比预期多花了不少精力），包含知识脉络 + 诸多细节，由于篇幅有限，这里以图片的形式给大家展示一部分。当程序员容易，当一个优秀的程序员是需要不断学习的，从初级程序员到高级程序员，从初级架构师到资深架构师，或者走向管理，从技术经理到技术总监，每个阶段都需要掌握不同的能力。早早确定自己的职业方向，才能在工作和能力提升中甩开同龄人。
Kotlin-Flow常用封装类：StateFlow的使用
m0_64420071的博客
08-02 1396
如果大家的项目的语言是Kotlin，并且小组成员都会Flow。那么我推荐你们使用StateFlow替代LiveData。
Kotlin 学习笔记（六）—— Flow 数据流学习实践指北（二）StateFlow 与 SharedFlow
修之竹的博客
02-20 1214
最后总结一下 Flow 第二小节的内容吧：1）热流有无消费者都可发送数据，生产者和消费者的关系可以是一对多；2）SharedFlow 可构建热流，可设置 replay 重播数据量及 extraBufferCapacity 缓冲区大小，以及 onBufferOverflow 缓冲区满的策略；3）emit与tryEmit发送方法的异同，前者是挂起函数，注意在使用默认构造的 SharedFlow 时不要使用tryEmit；
你应该知道的 Flow 的 shareIn 和 stateIn 操作符
小金子的专栏
06-04 2974
前言 Flow 的 shareIn 和 stateIn 操作符可以转化一个 Cold Flow 到 Hot Flow：它可以把从上游 Cold Flow 中收到的数据广播给所有的订阅者(collectors/subscriber). 它通常用来提升性能, 甚至内部有缓存机制. 知识点普及：Cold Flow 一被订阅或者被观察的时候, 就会产生数据. 通常订阅者可以观察到所有的数据. 而 Hot Flow 是不管有没有订阅者订阅, 它都保持活跃, 并且可能发射数据. 在这个博客中, 你可以通过例子熟悉 s.
Android开发，使用eventbus、livedata、observe、stateflow、sharedflow进行数据发送
09-06
Android开发，通过使用eventbus、livedata、observe、stateflow、sharedflow进行数据发送，并且封装了livedataBus、BaseObservable、ShareFlowBus和StateFlowBus
计数器的搭建和stateflow工作过程范例
07-20
计数器的搭建和stateflow工作过程，熟悉多路示波器使用，脉冲触发使用，常量设置以及条件状态转移使用。
Stateflow教程,stateflow教程 pdf,matlab
09-10
matlab simulink 状态图教程 状态图建立，状态图的调试
Simulink的Stateflow教程
03-29
Simulink的Stateflow教程
Flow Charts in Stateflow.zip_stateflow
07-15
Stateflow中的流程图，适合初学者参考学习
Flow/SharedFlow/StateFlow
xiangxiongfly
08-29 862
Flow/SharedFlow/StateFlow LiveData特点 LiveData具有感知生命周期，避免内存泄漏 LiveData只能主线程更新数据，postValue本质调用setValue LiveData功能有限，不适合处理复杂数据 频繁请求数据容易数据丢失 Flow Flow是Kotlin协程与响应式编程模型结合的产物 Flow功能强大，支持线程切换、背压 Flow默认是冷流，只有调用collect订阅后，才会开始执行发射数据流的代码，有懒加载的特点 SharedFlow Flow
Kotlin上的反应式流-SharedFlow和StateFlow
eclipse_xu
11-15 4184
点击上方蓝字关注我，知识会给你力量在本教程中，你将学习Kotlin中的反应式流，并使用两种类型的流——SharedFlow和StateFlow，构建一个应用程序。事件流已经成为Androi...
不做跟风党，LiveData，StateFlow，SharedFlow 的使用场景对比
Flywith24 写文章的地方
09-14 1713
Android 常用的分层架构Android 中加载 UI 数据不是一件轻松的事，开发者经常需要处理各种边界情况。如各种生命周期和因为「配置更改」导致的 Activity 的销毁与重建。「...
Kotlin Flow场景化学习
AndroidKt
01-17 2162
目录结构 何为Kotlin Flow？ Flow，直接翻译就是“流”，如何理解呢？生活中，我们有水流，人流，车流等；开发中，我们有字节流，视频流等。参考这些内容，我们就很好理解”流“的概念，连续的内容输出形成“流”。Android技术层面上，使用过RxJava的朋友对生产者-消费者模式以及数据流的概念如数家珍，而Kotlin Flow是以协程为基础进行连续内容输出的开发库，实现与RxJava相似的功能，但是与Android结合更紧密，因为它是“亲儿子”。 为何需要Kotlin Flow？ RxJava相
ViewModel中的StateFlow和SharedFlow，使用建议以及单元测试
weixin_47933729的博客
01-17 407
StateFlow和SharedFlow都是kotlin中的数据流，官方概念简介如下： StateFlow：一个状态容器式可观察数据流，可以向其收集器发出当前状态和新状态。是热数据流。 SharedFlow：StateFlow是StateFlow的可配置性极高的泛化数据流（StateFlow继承于SharedFlow）
kotlin协程Flow的StateFlow和SharedFlow(十二)
Mr_Tony的专栏
08-11 3110
一、前言 有时候我们需要实时监听一个状态变化或者持续不断接收数据，Flow提供了StateFlow和SharedFlow以供我们使用 二、使用方式 略 三、参考链接 StateFlow https://kotlin.github.io/kotlinx.coroutines/kotlinx-coroutines-core/kotlinx.coroutines.flow/-state-flow/ StateFlow 和 SharedFlow https://developer.android.googl
从 LiveData 迁移到 Kotlin 数据流
Android开发者
06-28 351
LiveData 的历史要追溯到 2017 年。彼时，观察者模式有效简化了开发，但诸如 RxJava 一类的库对新手而言有些太过复杂。为此，架构组件团队打造了LiveData: 一个专用...
Kotlin StateFlow&SharedFlow（二）
qq_46515305的博客
04-13 2543
StateFlow hold flow, 没有消费者进行消费的时候，生产者也可以生产数据（生产者在没有消费者订阅之前生产数据可能会丢失数据）。 class MainViewModel : ViewModel() { private val _stateFlow = MutableStateFlow(0) val stateFlow = _stateFlow.asStateFlow() fun incrementCounter() { _stateFlow.val
StateFlow 和 sharedFLow的区别
06-12
StateFlow 和 SharedFlow 都是 Kotlin 中的 Flow 类型，不同之处在于它们的行为和使用方式略有不同。 StateFlow 是一种具有单一状态值的流，它提供了一个可观察的状态，只要状态发生变化，StateFlow 就会发出新值。...

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值