使用 derivedStateOf 优化高频状态下的 UI 重组

1. 概述

在 Compose 开发中，处理播放进度 、滑动偏移 等高频变化的状态（State）时，若直接在 Composable 顶层观察状态，会导致主函数频繁重组（Recomposition），引发性能抖动、设备发热、界面掉帧等问题。

本文档介绍如何通过 derivedStateOf 构建状态防火墙，过滤高频无效数据，仅在关键业务对象变更时触发 UI 刷新，实现 Compose 界面性能优化。

2. 核心代码示例

推荐写法：高频状态隔离

kotlin 复制代码

// 通过 derivedStateOf 隔离高频状态，仅监听核心业务数据变化
val songInfo by remember {
    derivedStateOf { 
        (playerVM.trackState.value as? PlayingTrackState.CurrentTrack)?.songInfo 
    }
}

3. 工作原理详解

3.1 自动订阅机制 (Read Tracking)

derivedStateOf 闭包内读取 Compose 状态对象时，框架会自动建立订阅关系：

内部监听：trackState.value 每次变化（如播放进度更新），都会触发 derivedStateOf 闭包重新计算；
无感知订阅：无需手动注册/解绑，Compose 自动完成状态依赖管理。

3.2 结果过滤机制 (Filtering)

这是性能优化的核心：derivedStateOf 会通过 equals 对比新计算结果 与旧结果：

结果一致 ：播放进度等高频数据变化，但 songInfo（歌曲ID、封面、标题）未变更 → 拦截更新信号，外部 Composable 不重组；
结果变更 ：切歌导致 songInfo 对象更新 → 向外发送通知，触发 UI 重组。

4. 性能对比分析

特性	传统 collectAsState 观察	derivedStateOf 观察
监听频率	高频（随进度每秒多次更新）	高频（仅内部轻量计算）
UI 重组频率	高频（整个页面强制重刷）	极低（仅切歌等关键场景重刷）
CPU 消耗	较高（重复执行布局、Diffing）	极低（仅做等值判断）
适用场景	进度条、示波器等需实时变化的组件	歌名、封面、静态属性展示组件

5. 关键注意事项（避坑指南）

5.1 严禁「一边锁门，一边开窗」

使用 derivedStateOf 优化时，禁止在 Composable 顶层直接订阅高频状态，否则优化完全失效：

kotlin 复制代码

// ❌ 错误：直接订阅高频状态，会导致整个函数强制重组
val trackState by playerVM.trackState.collectAsStateWithLifecycle()

5.2 必须使用 `.value` 访问状态

在 derivedStateOf 内部，必须直接访问状态对象的 .value 属性，才能让 Compose 正常追踪状态读取，建立订阅关系。

5.3 数据对象需保证引用稳定性

核心数据类（如 SongInfo）必须定义为 data class（自动实现 equals/hashCode）；
禁止每次计算生成内容相同但内存地址不同 的新对象，否则 derivedStateOf 会误判为数据变更，失去过滤效果。

6. 结论

通过 derivedStateOf 包装高频状态访问，相当于在高频数据流（播放/滑动状态）与低频 UI 组件（歌曲详情、页面布局）之间搭建了减震器，有效拦截无效重组。

使用 derivedStateOf 优化高频状态下的 UI 重组