关于jetpack:Jetpack架构演化初步运用flow附加经典案例

Jetpack 架构演变：初步使用 flow，附加经典案例

在 jetpack 体系中 livedata 的角色纯纯粹粹是个桥接器，DataSource 中获取到数据，而后由 viewmodel 停止逻辑处理，最初被 livedata.postValue 到 view 层，唯一的价值是绑定了 lifecycle，只在页面活泼（start）的时候承受数据
官网的一篇介绍能够参考：从 LiveData 迁徙到 Kotlin 数据流 – 掘金
对于初学者来说使用 lieveData 的益处是足够简略和绝对平安
引入 flow 次要因为以下几点：

具备更敌对的 API，学习成本较低
跟 Kotlin 协程、LiveData 分离更严密，Flow 可能转换成 LiveData，在 ViewModel 中间接使用
分离协程的作用域，当协程被勾销时，Flow 也会被勾销，防止内存走漏
flow 库从属于 kotlin，livedata 属于 Android，托付 Android 平台的限度对于将来跨平台开展无利

【flow 是个冷数据流】

所谓冷流，即上游无消费行为时，上游不会产生数据，只需上游开始生产，上游才开始产生数据。
而所谓热流，即无论上游是否有消费行为，上游都会本人产生数据。
下边通过一个经典场景粗疏描绘下 flow（单纯的 flow，而 stateFlow 会在后续章节中解说）的使用
案例：一个菜谱利用 app 中，我想在一个页面展现一个列表（recyclerview），此列表的每个 item 是个子列表，子列表顺次为
打算菜谱列表；
珍藏菜谱列表；
依据食材抉择的菜谱列表；
依据食材获取用户偏好的菜谱列表；

四个子列表需要四个接口来获取，组装好起初刷新最初的列表
其中每个列表都有可能是空，是 emptylist 的话这行就不浮现了，因为四个接口数据量大小不同，所以不会同一时间返回，同时又要保障这四个子列表按请求的次序来展现。
思路：
设计数据结构，最外层的 data：

data class ContainerData(val title : String , val list: List)

复制代码
其中 Recipe 实体是每个菜谱

data class Recipe(val id: String,

               val name: String,
               val cover: String,
               val type: Int,
               val ingredients: List? = mutableListOf(),
               val minutes: Int,
               val pantryItemCount : Int )

复制代码
模仿四个恳求为:

val plannlist = Request.getPlannlist()
val favouritelist= Request.getFavouritelist()

… 以此类推
假如依照请求四个恳求返回秩序不同，同时请求在列表中按次序浮现，假如实现？
计划一：能够等待四个恳求都返回后而后组装数据，刷新列表
能够利用协程的 await 办法：

val dataList = MutableLiveData()

viewModelScope.launch {
// planner
val plannerDefer = async {Request.getPlannlist() }
// favourite
val favouriteDefer = async {Request.getFavouritelist() }
val plannerData = plannerDefer.await()
val favouriteData = favouriteDefer.await()

.... 省略后两个接口
val list = listof(Container("planner" , plannerData)，Container("favourite" , favouriteData)，...
)
dataList.postValue(list)
}

复制代码
await() 办法是挂起协程，四个接口异步恳求（非次序），等最初一个数据恳求返回后才会执行下边的步骤
而后组装数据利用 liveData 发送，在 view 中渲染

viewModel.dataList.observe(viewLifecycleOwner) {mAdapter.submitList(it)

}

复制代码
此种形式简略，并且无效处理了按次序排列四个列表的需要，缺点是体验差，假设有一个接口极慢，其余几个就会等待它，用户看着 loading 不断发愣么。
计划二：接口间不再相互等待，哪个接口先回来就渲染哪个，问题就是如何保障次序？
有的同学会有计划：先定制一个空数据 list

val list = listOf(Container("planner", emptylist()),
Container("favourite", emptylist()),
...
)

复制代码
而后先用 adapter 去渲染 list，哪个接口回来就去之前的列表查找交换，而后 adapter 刷新对应的数据，当然能够，不过会产生一部分逻辑胶水代码，查找遍历的操作。
此时咱们能够借助 flow 来实现了
1 结构一个 planner 数据流

val plannerFlow = flow {val plannList = Request.getPlanlist()

emit(ContainerData("Planner", plannList))

}.onStart {emit(ContainerData("", emptylist()))
}

复制代码
注意是个 val 变量，不要写成 fun plannerFlow() 办法，不然每次调用开拓新栈的时候新建个 flow，并且会不断保存在内存中，直到协程勾销
其中 onStart 会在发送正式数据之前发送，作为预加载。
而后咱们就能够结构正式恳求了

viewModelScope.launch {combine(plannerFlow , favouriteFlow , xxxFlow ,xxxFlow) { planner , favourites , xxx , xxx  ->
            mutableListOf(planner , favourites , xxx,xxx)
  }.collect {datalist.postValue(it)
     }
 }

复制代码
combine 的官网正文为

Returns a Flow whose values are generated with transform function by combining the most recently emitted values by each flow.

复制代码
combine 操作符能够连接两个不同的 Flow，一旦产生数据就会触发组合后的 flow 的流动，同时它是有序的。