lifecycle架构，Transformations的switchMap该怎么理解好

可直接跳过前面的介绍直接看后面关于switchMap的说明，不太理解的可以配合前面的介绍

 

LiveData<T>:

• 内容为T类型数据的容器，可监听内容的变化且具有一定的实时性
• 对外提供监听容器内容变化的接口observe(LifecycleOwner, Observer)
• 会在适当的时期通知监听器
• 适当的时期：激活状态(LifecycleRegistry监听fragment生命周期)
• 外部需MutableLiveData才能改变容器内容

 

MutableLiveData:

• 继承至LiveData
• 提供改变容器内容的接口setValue/postValue

 

MediatorLiveData：

• 继承至MutableLiveData
• 可监听其他容器内容的变化，通过addSource(source:LiveData, Observer)
• addSource还需在激活状态下才会有机会调用addSource中的Observer(激活后，source才会添加Observer作监听器)

 

Transformations.map:

• 容器A监听B内容的变化，变化时将B内容转化为相应的内容并通知A监听器
• 原理是利用MediatorLiveData的addSource对其他容器内容监听，在Observer中再对MediatorLiveData修改内容为转化了的相应的数据，来通知自己的监听器内容发生变化

 

Transformations.switchMap:

• 容器A监听B内容的变化，变化时从B内容获取相应的容器C，添加到A的监听列表里，即现在A同时监听B跟C，而B内容的变化只会(switch)更换A监听列表里的C，C内容的变化才会通知A监听器
• 例子1：B为衣服品牌，C为衣服品牌对应的衣服价格，B与C一一对应关系，那么效果就是A监听的是B对应的C(衣服品牌对应的价格)，衣服品牌变化为B2就监听变化了的品牌B2对应的价格C2，而不再监听之前的C1
• 例子2：业务上可能存在多个B对应一个C，比如B1,B2都是对应同一个C1，那么B1变成B2，A依然还是监听着C1
• 原理跟map类似，自行阅读源码最好