5、LiveData变换：map()与switchMap()操作符、MediatorLiveData的使用、合并多个LiveData源

好，咱们今天聊点实战中特别常用的东西——LiveData的变换操作。说实话，我刚接触LiveData那会儿，觉得它就是个简单的观察者模式封装，没啥大不了的。直到我在一个复杂的搜索页面里，被多个LiveData源的状态管理搞得焦头烂额，才意识到：嗯，这东西要是用不好，代码真的会变成一团乱麻。

今天这一章，我会把LiveData的三种核心变换方式讲透：map()、switchMap()，以及那个低调但强大的MediatorLiveData。你想想看，当你的UI需要同时监听用户输入、网络状态、数据库缓存三个数据源时，怎么优雅地合并它们？这就是我们今天要解决的问题。

5.1 map()：最简单的数据转换

map()操作符，说白了就是把LiveData里的数据从一种形式变成另一种形式。比如你从数据库拿到的User对象，UI只需要显示用户名，这时候用map()就特别合适。

我个人习惯把map()用在那些纯计算、无副作用的场景里。举个例子：

// 原始LiveData
val userLiveData: LiveData<User> = userRepository.getUser()

// 使用map()转换
val userNameLiveData: LiveData<String> = userLiveData.map { user ->
    user.name
}

// 或者用Kotlin的lambda简写
val userNameLiveData2 = userLiveData.map { it.name }

这里有个坑，我曾经踩过：map()是在主线程执行的。如果你在map的lambda里做了耗时操作，比如网络请求或者数据库查询，那UI线程就会被卡住。所以记住，map()只适合做轻量级的转换，比如格式化时间、拼接字符串、提取字段。

5.2 switchMap()：根据输入切换数据源

switchMap()比map()复杂一些，但它的能力也更强。它的核心逻辑是：当上游LiveData的值发生变化时，自动切换到新的LiveData。这特别适合搜索场景——用户每输入一个字符，你就得取消上一次的请求，发起新的搜索。

我记得在做一个电商App的搜索功能时，用户输入关键词，需要实时从服务器获取搜索结果。如果用map()，你会发现每次输入都会触发多个请求，而且旧请求的结果可能覆盖新请求的。这时候switchMap()就派上用场了：

// 用户输入的查询字符串
val queryLiveData: MutableLiveData<String> = MutableLiveData()

// 使用switchMap()切换数据源
val searchResultLiveData: LiveData<List<Product>> = queryLiveData.switchMap { query ->
    // 每次query变化，都会执行这个lambda
    // 返回一个新的LiveData
    repository.searchProducts(query)
}

// 在ViewModel中触发搜索
fun onQueryChanged(query: String) {
    queryLiveData.value = query
}

为什么叫switchMap？因为它会自动取消上一次的观察。当query从"手机"变成"电脑"时，上一次搜索"手机"的LiveData会被自动取消订阅，然后切换到搜索"电脑"的新LiveData。这个机制避免了数据竞争和内存泄漏。

5.3 MediatorLiveData：合并多个数据源

MediatorLiveData是LiveData家族里的"多面手"。它可以同时监听多个LiveData源，然后根据这些源的变化，输出一个统一的结果。说白了，它就是LiveData版的合并操作符。

我举个实际项目中的例子：一个用户详情页面，需要同时展示用户信息、用户订单数、用户积分。这三个数据来自不同的数据源，但UI只需要一个LiveData来驱动渲染。用MediatorLiveData就能优雅地解决：

class UserDetailViewModel : ViewModel() {
    private val userInfoLiveData = userRepository.getUserInfo()
    private val orderCountLiveData = orderRepository.getOrderCount()
    private val pointsLiveData = pointsRepository.getPoints()

    // 合并后的LiveData
    val combinedLiveData = MediatorLiveData<UserDetailUiState>().apply {
        var userInfo: UserInfo? = null
        var orderCount: Int = 0
        var points: Int = 0

        // 添加源并监听变化
        addSource(userInfoLiveData) { info ->
            userInfo = info
            value = UserDetailUiState(
                userInfo = userInfo,
                orderCount = orderCount,
                points = points
            )
        }

        addSource(orderCountLiveData) { count ->
            orderCount = count
            value = UserDetailUiState(
                userInfo = userInfo,
                orderCount = orderCount,
                points = points
            )
        }

        addSource(pointsLiveData) { pts ->
            points = pts
            value = UserDetailUiState(
                userInfo = userInfo,
                orderCount = orderCount,
                points = points
            )
        }
    }
}

// UI状态数据类
data class UserDetailUiState(
    val userInfo: UserInfo? = null,
    val orderCount: Int = 0,
    val points: Int = 0
)

你看，通过addSource()方法，我们把三个LiveData都注册到了MediatorLiveData上。每当任何一个源发生变化，都会触发合并逻辑，生成新的UI状态。这样UI层只需要观察一个LiveData，代码清晰多了。

5.4 三种方式的对比与选择

为了让你更直观地理解什么时候该用哪个，我整理了一个表格：

操作符	适用场景	执行线程	是否支持异步	典型例子
map()	一对一的简单数据转换	主线程	否	提取字段、格式化数据
switchMap()	根据输入切换数据源	主线程（lambda内可异步）	是	搜索、分页、依赖查询
MediatorLiveData	合并多个独立数据源	主线程	否（但可配合异步源）	多数据源合并、状态聚合

简单总结一下我的经验：

• 如果只是改个格式，用map()
• 如果需要根据输入发起新请求，用switchMap()
• 如果需要把多个不相关的数据源捏在一起，用MediatorLiveData

5.5 知识体系结构图

下面这张图帮你理清今天讲的核心逻辑：

5.6 实战中的一些思考

最后，我想分享一点个人体会。很多开发者刚开始用LiveData变换时，容易陷入一个误区：过度使用map()和switchMap()。其实，如果你的业务逻辑比较复杂，比如需要多个数据源做条件判断、需要缓存、需要错误处理，那直接用MediatorLiveData配合状态模式会更清晰。

我记得有一次重构一个订单列表页面，原来的代码用了三层嵌套的switchMap，看得我头皮发麻。后来我用MediatorLiveData把订单数据、用户权限、网络状态三个源合并成一个OrderListUiState，代码瞬间清爽了。所以，工具是死的，人是活的，选择哪种方式，取决于你的业务场景和代码可维护性。

好了，这一章的内容就到这里。LiveData变换是Android架构组件里非常实用的技能，掌握了它们，你的ViewModel代码会变得更加简洁、可测试。下一章我们会继续深入LiveData的进阶用法，敬请期待。

---