使用Transformations.switchMap的优势？对比两种LiveData实现方式

两种实现方式 #

方式一：基于Transformations.switchMap的实现 #

MutableLiveData<Integer> userIdLiveData = ...;
LiveData<User> user = Transformations.switchMap(userIdLiveData, id -> repository.getUserById(id));

void setUserId(int userId) {
    // 为何不手动在此查询？
    userIdLiveData.setValue(userId);
}

方式二：直接赋值的实现 #

LiveData<User> user;

void setUserId(int userId) {
    user = repository.getUserById(userId);
}

核心优势解析 #

• 自动维护观察者订阅关系
  直接赋值的方式每次调用setUserId都会生成新的LiveData<User>实例，原来的观察者如果还绑定着旧实例，就接收不到新数据的更新，必须手动重新订阅，很容易出现界面不刷新的问题。而switchMap返回的是同一个LiveData实例，它会自动切换内部数据源，把新查询返回的LiveData的更新转发给外部观察者，观察者只需订阅一次就能持续接收数据。

• 降低内存泄漏风险
  直接赋值时，旧的LiveData<User>如果还有未取消的订阅，很容易引发内存泄漏。switchMap会在切换数据源时自动取消对旧数据源的订阅，从根源上减少这类问题的发生。

• 实现响应式数据流联动
  switchMap让userIdLiveData和user形成了响应式依赖：只要userIdLiveData的值变化，user就会自动触发新查询并更新数据。这种逻辑完全贴合LiveData的响应式设计，代码更简洁清晰，不用手动触发查询和订阅操作。

• 配置变更后自动保留状态
  当屏幕旋转等配置变更导致Activity/Fragment重建时，直接赋值的方式需要重新调用setUserId获取新的LiveData，否则界面拿不到数据。而switchMap返回的user和ViewModel中的userIdLiveData绑定，ViewModel会在配置变更时保留，重建后的界面能直接拿到最新数据，无需额外处理。

内容的提问来源于stack exchange，提问作者diwasip777