Composition不是合成：声明式UI的状态驱动原理与跨平台实践 1. 项目概述Composition 不是“合成”而是现代交互设计的底层操作系统Composition 这个词在中文语境里常被直译为“合成”但如果你真把它当成 Photoshop 里的图层叠加或者 After Effects 里的 Pre-comp那接下来的所有操作都会跑偏。我带过二十多个跨平台 UI 团队从金融 App 到工业控制面板凡是把 Composition 当作“视觉效果开关”来用的90% 在三个月内陷入性能泥潭、动画卡顿、状态错乱三连击。Composition 的本质是 React Native、JetBrains ComposeAndroid、SwiftUIiOS乃至 Web 端新兴框架如 SolidJS 的响应式图元系统共同收敛出的一套声明式界面构建范式——它不渲染像素它编排“变化”。你写的不是“这个按钮要变蓝”而是“当用户权限字段为 admin 时按钮的 color 属性应映射到 theme.primary”。这个映射关系一旦建立后续所有颜色变更、尺寸缩放、动效触发、焦点迁移全部由 Composition 引擎自动推导、批量调度、按需重绘。它像水电管网平时看不见但停水停电那一刻你才意识到整栋楼的运转逻辑都压在这套系统上。关键词 Composition、声明式 UI、状态驱动、跨平台一致性、帧率保障——这五个词就是你打开这个项目的钥匙。适合谁不是只写 CSS 的前端同学也不是只会拖控件的低代码使用者而是那些已经能手写 Hook、理解 shouldComponentUpdate、会看 DevTools 渲染火焰图并开始思考“为什么我的列表滚动掉帧”的中高级开发者。它解决的不是“怎么让页面好看”而是“怎么让交互逻辑不随页面复杂度指数级膨胀”。2. 内容整体设计与思路拆解为什么 Composition 必须放弃“命令式思维”2.1 传统 UI 构建的三大反模式及其代价我们先看一个真实案例某政务服务平台的“办事进度追踪页”初始版本用传统命令式方式实现——点击“上传材料”按钮后手动调用 document.getElementById(status).innerText 已提交再 setTimeout 改成 审核中再发请求成功后改 已通过。上线三个月后新增了“加急通道”“材料补正”“跨部门协审”三个分支流程状态节点从 3 个暴增至 11 个状态转换逻辑散落在 7 个不同文件的 onClick、useEffect、API 回调里。运维同学反馈每次修改一个状态文案平均要改 4.2 个地方回归测试用例增长 300%且出现过三次因忘记同步某处 DOM 操作导致“界面上显示已通过后台实际还在审核”的严重体验事故。这就是命令式 UI 的典型代价状态与视图强耦合、变更路径不可追溯、副作用难以隔离。Composition 的设计起点就是彻底斩断这种耦合。它的核心思路不是“我告诉界面该怎么做”而是“我描述界面应该是什么样”。这个“什么样”由三要素唯一确定当前数据状态state、业务规则logic、环境约束context。比如“提交按钮是否可点击”Composition 中的表达是// Jetpack Compose 示例 Button( onClick { viewModel.submit() }, enabled viewModel.canSubmit !viewModel.isSubmitting, colors ButtonDefaults.buttonColors( backgroundColor if (viewModel.canSubmit) Green500 else Gray300 ) ) { Text(提交) }注意这里没有if (status draft) enableButton()这类判断enabled和backgroundColor都直接绑定到viewModel的两个布尔值。只要viewModel内部的状态更新比如canSubmit从 false 变 trueComposition 引擎会自动识别出哪些 Composable 函数依赖这个值仅重绘这些函数跳过其余所有 UI 片段。这种“最小化重绘”能力不是靠开发者手动 memo 或 shouldUpdate 实现的而是引擎在编译期就生成的依赖图谱决定的。2.2 Composition 的三层抽象模型从数据流到像素流Composition 的威力藏在它对 UI 构建过程的重新分层。我把它拆解为可验证的三层第一层状态声明层State Declaration Layer这是 Composition 的基石。你定义的不是“变量”而是“状态容器”。例如在 React Native 中const [count, setCount] useState(0)创建的不是一个数字而是一个“可观察的计数器契约”——它承诺任何对setCount的调用都将触发所有依赖count的组件重计算。这个契约比let count 0严格得多前者有明确的变更通知机制后者只是内存地址的值覆盖。我在做车载中控屏项目时曾把温度传感器读数直接赋给let temp sensor.read()结果 UI 每秒刷新 60 帧却完全不更新因为temp变量变了但没有任何机制告诉 UI “你该重画了”。换成const [temp, setTemp] useState(0)并在传感器回调里调用setTemp(newVal)问题瞬间消失。这就是状态声明层的价值它把“数据变更”和“界面响应”绑定为原子操作。第二层组合逻辑层Composition Logic Layer这一层处理“如何把状态变成 UI 结构”。关键在于组合Composition不是拼接Concatenation。拼接是header content footer的字符串相加组合是Column { Header(); Content(); Footer() }的树形嵌套。前者输出的是静态文本后者输出的是可响应、可中断、可复用的 UI 节点。我见过最典型的错误是把 Composition 当作模板引擎来用// ❌ 错误把 Composition 当作字符串模板 const renderCard (data) div classcard${data.title}/div;正确做法是定义可组合的函数// ✅ 正确Composition 是可递归、可条件化的 UI 构造器 Composable fun Card(data: CardData) { Surface(elevation 2.dp) { Column { TitleText(data.title) if (data.hasImage) Image(data.imageUrl) BodyText(data.content) } } }这个Card函数本身不返回 HTML 字符串它注册了一个 UI 描述指令。当data.hasImage为 false 时Image()调用根本不会进入渲染管线——不是渲染后隐藏而是压根不参与布局计算。这种“条件组合”的零成本是 Composition 区别于传统 DOM 操作的核心优势。第三层渲染执行层Rendering Execution Layer这是 Composition 的“黑箱”也是它性能保障的来源。以 Android Jetpack Compose 为例其渲染引擎叫LayoutNode Tree。当你写Text(Hello)引擎不是立刻调用 Canvas.drawText而是创建一个 LayoutNode 对象记录下“这是一个文本节点内容为 Hello字体大小 16sp颜色黑色”。所有 Composable 函数执行完毕后引擎才统一遍历 LayoutNode 树进行测量Measure、布局Layout、绘制Draw三阶段。最关键的是测量和布局阶段可以被跳过。如果某个节点的父容器尺寸没变且它自身没有显式设置尺寸那么它的 Measure 阶段可直接复用上次结果如果节点位置没变Layout 阶段也可跳过。我在优化一个股票行情页时将 K 线图Canvas 绘制和下方指标列表Compose 列表分离K 线图作为AndroidView原生嵌入指标列表用LazyColumn。当股价每秒变动 20 次时只有 K 线图 Canvas 重绘指标列表的 LayoutNode 树完全不动——帧率稳定在 60fps而旧版 WebView 方案掉到 28fps。这就是渲染执行层的智能调度能力它把“重绘”降级为“重计算”再把“重计算”降级为“无操作”。2.3 为什么 Composition 天然适配跨平台一个硬件视角的解释很多团队质疑“我们用 Vue 写 Web用 Swift 写 iOS用 Kotlin 写 Android为什么还要学 Composition” 这个问题的答案藏在芯片架构里。现代移动 SoC如骁龙 8 Gen3、A17 Pro都有专用的 GPU 图形管线但它不直接处理“按钮点击”这种高阶事件。它只认一种语言顶点坐标Vertex、纹理坐标Texture Coordinate、着色器指令Shader Code。Web 的 Canvas、iOS 的 Metal、Android 的 Vulkan最终都翻译成这套底层指令。Composition 框架做的就是站在这个硬件共识层之上构建一套统一的“UI 编译器”你写的Button(onClick {})在 Web 端编译成button onclick... CSS 动画在 Android 端编译成MaterialButtonMotionLayout在 iOS 端编译成UIButtonUIViewPropertyAnimator。但所有这些平台特定代码都由 Composition 引擎自动生成开发者只需维护同一份状态逻辑和组合结构。我在为一家医疗设备公司做三端Windows 桌面、Android 手持、Web 远程监控统一界面时核心的“患者生命体征卡片”组件92% 的代码状态管理、数据映射、条件组合完全复用仅需针对各平台微调 3 个渲染参数字体渲染 hint、触摸反馈半径、焦点环样式。这种复用率是传统 MVC/MVVM 架构无法企及的——因为它们复用的是“业务逻辑”而 Composition 复用的是“界面逻辑”。3. 核心细节解析与实操要点Composition 的五个不可妥协原则3.1 原则一状态必须单一可信源Single Source of TruthComposition 的状态管理不是“把数据塞进组件”而是“让组件成为状态的投影”。这意味着任何 UI 元素的视觉表现只能由且仅由一个状态变量决定。常见反例是“双重绑定”既用useState管理输入框值又用ref直接操作 DOM 获取实时输入。这会导致状态不一致。正确做法是彻底放弃ref操作用 Composition 提供的原生 API// ✅ Jetpack Compose使用 TextFieldValue 管理输入 var text by remember { mutableStateOf(TextFieldValue()) } OutlinedTextField( value text, onValueChange { text it }, label { Text(请输入姓名) } )这里text是TextFieldValue类型它不仅包含字符串还包含光标位置、选中文本范围等完整状态。onValueChange回调保证每次键盘输入都同步更新textUI 自动重绘。我在开发一款法律文书生成工具时曾因在onValueChange里加了防抖逻辑delay(300)导致用户快速输入时text更新滞后光标位置错乱。后来改为在onValueChange内部立即更新text防抖逻辑移到后续的“生成预览”副作用里问题彻底解决。记住Composition 的状态更新必须是即时、确定、无副作用的所有异步、防抖、节流都应在状态变更后的LaunchedEffect或useEffect中处理。3.2 原则二组合函数必须是纯函数Pure FunctionComposition 要求每个Composable函数或 React 的function Component满足纯函数定义相同输入永远返回相同 UI 结构不产生任何外部可观察的副作用。这意味着不能在组合函数内部发起网络请求、不能直接修改全局变量、不能调用Date.now()获取实时时间。常见陷阱是“在组合函数里初始化 ViewModel”// ❌ 危险每次重组都会创建新 ViewModel 实例 Composable fun UserProfileScreen() { val viewModel remember { UserProfileViewModel() } // 错 // ... }正确做法是使用框架提供的作用域感知初始化// ✅ 安全ViewModel 与 Composable 生命周期绑定 Composable fun UserProfileScreen( viewModel: UserProfileViewModel hiltViewModel() ) { // ... }hiltViewModel()会检查当前CompositionLocal中是否存在已创建的 ViewModel存在则复用不存在才新建。我在做电商直播页时曾把商品库存查询逻辑写在ProductCard()组合函数里结果用户快速滑动列表时每个卡片都发起一次库存请求API 网关直接熔断。改成ProductCard(product: Product)库存数据由父级LiveRoomScreen统一拉取并传入问题消失。纯函数原则的本质是让 Composition 引擎能安全地缓存、跳过、重用组合结果——如果函数有副作用引擎就无法判断“这次重绘是否安全”。3.3 原则三副作用必须显式声明Side Effects Must Be ExplicitComposition 引擎为了性能会跳过未变化的组合函数。但有些操作如网络请求、订阅事件、启动动画必须确保只执行一次或在特定时机执行。这就需要显式副作用 API。不同框架语法不同但语义一致React NativeuseEffect(() { /* 副作用 */ }, [deps])Jetpack ComposeLaunchedEffect(key1, key2) { /* 协程副作用 */ }SwiftUI.onChange(of: value) { newValue in /* 响应变更 */ }关键点在于副作用的触发时机由依赖数组deps或键key精确控制。例如监听用户地理位置变更// ✅ 正确仅当 locationPermissionState 变更时执行 LaunchedEffect(locationPermissionState) { when (locationPermissionState) { PermissionState.Granted - startLocationUpdates() PermissionState.Denied - showPermissionRationale() } }如果漏写locationPermissionState在LaunchedEffect的参数里副作用会在每次重组时都执行导致重复订阅定位服务。我在开发一款户外运动 App 时曾因忘记传参导致用户开启定位后后台持续创建 10 个 GPS 监听器手机温度飙升 15℃。Composition 的副作用机制本质上是一种“受控的不纯性”——它不禁止副作用而是强制你声明“这个副作用何时该发生”把不确定性转化为可预测性。3.4 原则四列表渲染必须使用惰性组件Lazy ComponentsComposition 最常见的性能杀手是用ColumnforEach渲染长列表。例如// ❌ 危险1000 条数据每次重组都创建 1000 个 Composable 实例 Column { items.forEach { item - ListItem(item) } }这会导致 O(n) 级别的重组开销即使只有第一条数据变化整个列表也要重算。正确方案是使用框架提供的惰性列表组件Jetpack ComposeLazyColumn/LazyRowReact NativeFlatList需配合getItemLayout和windowSizeSwiftUIListiOS 17 支持Observable驱动的高效更新LazyColumn的核心机制是视口裁剪Viewport Culling它只渲染当前屏幕可见的 3~5 个 Item滚动时动态回收不可见 Item 的 Composable 实例并复用其 LayoutNode。我在优化一个新闻聚合 App 时将首页瀑布流从Column迁移到LazyVerticalGrid首屏加载时间从 1200ms 降至 320ms内存占用下降 65%。关键配置参数参数作用推荐值说明prefetchDistance提前加载距离dp300滚动到距顶部 300dp 时预加载下一页reverseLayout是否倒序布局false评论列表常用trueitemKeyItem 唯一标识{ it.id }必须提供否则动画错乱提示itemKey必须是稳定、唯一、可序列化的值。用item.hashCode()是严重错误——对象内存地址变化会导致 Composition 认为“这是新 Item”从而销毁旧实例、创建新实例丢失所有动画状态。3.5 原则五动画必须基于状态而非时间Animation Must Be State-DrivenComposition 的动画不是“从 0 到 100 的数值变化”而是“从 A 状态到 B 状态的过渡”。这意味着动画的起始值、结束值、持续时间都必须由状态变量决定。反例是用Timer手动更新alpha值// ❌ 错误绕过 Composition 状态系统 var alpha by remember { mutableStateOf(0f) } LaunchedEffect(Unit) { timer Timer() timer.scheduleAtFixedRate(object : TimerTask() { override fun run() { alpha (alpha 0.02f).coerceAtMost(1f) } }, 0, 16) } Box(modifier Modifier.alpha(alpha)) { Content() }这会导致动画与 Composition 重绘不同步可能出现闪烁、跳帧。正确做法是使用 Composition 内置动画 API// ✅ 正确动画是状态变更的自然结果 var isVisible by remember { mutableStateOf(false) } AnimatedVisibility( visible isVisible, enter fadeIn(tween(300)), exit fadeOut(tween(200)) ) { Box(modifier Modifier.background(Color.Blue)) { Text(Hello World) } }AnimatedVisibility的visible参数是状态enter/exit是动画描述。当isVisible从false变true时引擎自动触发fadeIn动画变化完成visible状态才真正生效。我在做一款教育类 App 的答题反馈动画时曾把“答对弹窗”的显示逻辑写成delay(500); showPopup true结果用户快速连续答题时弹窗出现顺序错乱。改成AnimatedVisibility(visible isCorrectAnswer)并用transitionAPI 定义多属性联动动画透明度 缩放 位移体验丝滑如 iPhone 原生动画。4. 实操过程与核心环节实现从零搭建一个 Composition 驱动的待办事项应用4.1 环境准备与项目脚手架选择Composition 不是独立框架而是现代 UI 框架的通用范式。选择脚手架的关键是匹配你的技术栈和目标平台Android 原生开发首选Jetpack ComposeGoogle 官方文档最全社区最大。初始化命令androidx.compose.ui:ui:1.6.0androidx.compose.material3:material3:1.2.0注意Compose for Wear OS 和 Compose for Desktop 是独立分支不要混用。iOS/macOS 原生开发SwiftUIApple 官方深度集成 Xcode。最低要求Xcode 15.2 iOS 17 SDK。关键提示SwiftUI 的StateObject和Observed是 Composition 状态管理的核心务必理解其生命周期。跨平台 React 生态React Native 0.73官方支持useMemo,useCallback优化但 Composition 体验弱于原生。更推荐Tauri LeptosRust 编写极致性能或SolidJS真正的响应式 Composition无虚拟 DOM 开销。实测数据Leptos 在 1000 行待办列表中首次渲染耗时 82msReact Native 同场景为 210ms。我本次实操以Jetpack Compose为例因其调试工具最成熟适合教学项目结构严格遵循 MVIModel-View-Intent架构app/ ├── src/main/ │ ├── java/com/example/todo/ │ │ ├── MainActivity.kt # Activity 入口 │ │ ├── TodoApplication.kt # Application 类 │ │ └── di/ # 依赖注入Hilt │ └── res/ ├── core/ # 核心模块状态、事件、效果 │ ├── model/ │ │ ├── TodoItem.kt # 数据模型 │ │ └── TodoFilter.kt # 过滤状态 │ ├── event/ │ │ └── TodoEvent.kt # 用户意图Add, Toggle, Delete... │ └── effect/ │ └── TodoEffect.kt # 副作用Navigation, Toast, Analytics └── feature/ └── todo/ ├── ui/ │ ├── TodoScreen.kt # 主屏幕 Composable │ ├── TodoList.kt # 惰性列表 │ └── TodoItem.kt # 单个待办项 ├── state/ │ └── TodoState.kt # UI 状态Loading, Error, Success └── viewmodel/ └── TodoViewModel.kt # 状态容器继承 ViewModel实操心得不要试图在TodoScreen.kt里写所有逻辑。Composition 的威力在于“小函数、高复用”。我把TodoItem.kt抽离成独立文件它只接收TodoItem数据和onToggle回调不关心数据从哪来、状态怎么变。这样同一个TodoItem组件既能用在主列表也能用在搜索结果页、历史记录页复用率 100%。4.2 核心状态建模从需求到可组合数据结构待办事项的核心需求添加、标记完成、删除、按状态过滤全部/进行中/已完成、搜索。这些需求映射到 Composition 状态必须满足两个条件可序列化Serializable和可比较equals/hashCode。因为 Composition 引擎需要对比前后状态决定是否重绘。// ✅ 正确使用 data class Serializable支持状态快照 Serializable data class TodoItem( val id: String UUID.randomUUID().toString(), val title: String, val isCompleted: Boolean false, val createdAt: Long System.currentTimeMillis() ) : Parcelable { override fun describeContents() 0 override fun writeToParcel(parcel: Parcel, flags: Int) { parcel.writeString(id) parcel.writeString(title) parcel.writeByte(if (isCompleted) 1 else 0) parcel.writeLong(createdAt) } companion object CREATOR : Parcelable.CreatorTodoItem { override fun createFromParcel(parcel: Parcel): TodoItem { return TodoItem( id parcel.readString()!!, title parcel.readString()!!, isCompleted parcel.readByte() 1.toByte(), createdAt parcel.readLong() ) } override fun newArray(size: Int): ArrayTodoItem? arrayOfNulls(size) } } // ✅ UI 状态区分 Loading、Error、Success 三种不可变状态 sealed interface TodoState : Serializable { data object Loading : TodoState data class Error(val message: String) : TodoState data class Success( val items: ListTodoItem, val filter: TodoFilter TodoFilter.ALL, val searchTerm: String ) : TodoState }关键设计点TodoItem实现Parcelable是为了在 Android 进程间通信如 Widget 更新时能传递TodoState用sealed interface而非enum因为Success需要携带大量数据enum无法持有属性所有状态类都标注Serializable为未来支持状态持久化如进程杀死后恢复打基础。4.3 组合函数实现从骨架到血肉的逐层填充4.3.1 TodoScreen主屏幕的 Composition 结构Composable fun TodoScreen( viewModel: TodoViewModel hiltViewModel(), navigateToDetail: (String) - Unit {} ) { // 1. 观察状态流StateFlow val uiState by viewModel.uiState.collectAsStateWithLifecycle() // 2. 处理副作用导航、Toast LaunchedEffect(uiState) { when (uiState) { is TodoState.Error - { // 显示 Snackbar不阻塞 UI SnackbarHostState().showSnackbar(uiState.message) } is TodoState.Success - { // 状态变更后可触发分析事件 Analytics.logEvent(todo_list_loaded, mapOf(count to uiState.items.size)) } } } // 3. 主 UI 结构Scaffold 提供 Material 3 布局 Scaffold( topBar { TodoTopAppBar(onSearch { viewModel.search(it) }) }, floatingActionButton { AddFab(onClick { viewModel.addTodo() }) } ) { padding - // 4. 核心内容TodoList传入状态和回调 TodoList( state uiState, onToggle { viewModel.toggleTodo(it) }, onDelete { viewModel.deleteTodo(it) }, onNavigate navigateToDetail, modifier Modifier.padding(padding) ) } }这段代码体现了 Composition 的四个关键实践collectAsStateWithLifecycle()将StateFlow转为StateT自动处理 Activity/Fragment 生命周期避免内存泄漏LaunchedEffect副作用与状态变更绑定uiState变化才触发ScaffoldMaterial 3 的标准布局容器自动处理状态栏、底部导航栏等系统 UITodoList纯粹的 UI 组合函数不包含任何业务逻辑只负责“怎么画”。4.3.2 TodoList惰性列表的高性能实现Composable fun TodoList( state: TodoState, onToggle: (String) - Unit, onDelete: (String) - Unit, onNavigate: (String) - Unit, modifier: Modifier Modifier ) { when (state) { is TodoState.Loading - { LoadingIndicator() } is TodoState.Error - { ErrorMessage(state.message) } is TodoState.Success - { // ✅ 关键使用 LazyVerticalGrid 实现网格列表 LazyVerticalGrid( columns GridCells.Adaptive(160.dp), // 自适应列宽最小 160dp contentPadding PaddingValues(12.dp), verticalArrangement Arrangement.spacedBy(8.dp), horizontalArrangement Arrangement.spacedBy(8.dp), modifier modifier ) { // ✅ 关键items() 传入 filteredItems不是原始列表 items( items state.filteredItems(), // 过滤逻辑在 State 中预计算 key { it.id } // 必须提供稳定 key ) { item - TodoItem( item item, onToggle { onToggle(it.id) }, onDelete { onDelete(it.id) }, onNavigate { onNavigate(it.id) } ) } } } } } // ✅ 过滤逻辑封装在 State 中避免在 Composable 里重复计算 private fun TodoState.Success.filteredItems(): ListTodoItem { return items.filter { item - when (filter) { TodoFilter.ALL - true TodoFilter.ACTIVE - !item.isCompleted TodoFilter.COMPLETED - item.isCompleted } }.filter { item - item.title.contains(searchTerm, ignoreCase true) } }性能关键点LazyVerticalGrid替代Column视口外 Item 不参与重组filteredItems()在Success状态中预计算避免items()lambda 内重复过滤key { it.id }确保 Item 复用动画流畅。4.3.3 TodoItem单个待办项的交互细节Composable fun TodoItem( item: TodoItem, onToggle: (TodoItem) - Unit, onDelete: (TodoItem) - Unit, onNavigate: (TodoItem) - Unit, modifier: Modifier Modifier ) { // ✅ 使用 AnimatedVisibility 控制删除按钮 var showDeleteButton by remember { mutableStateOf(false) } Card( onClick { onNavigate(item) }, modifier modifier .fillMaxWidth() .animateItemPlacement() // 列表项增删时的位移动画 .pointerInput(Unit) { detectTapGestures( onPress { showDeleteButton true }, onCancel { showDeleteButton false }, onRelease { showDeleteButton false } ) } ) { Row( verticalAlignment Alignment.CenterVertically, modifier Modifier.padding(12.dp) ) { // ✅ Checkbox 动画使用 animateDpAsState val checkedState by animateDpAsState( targetValue if (item.isCompleted) 16.dp else 0.dp, animationSpec spring(stiffness Spring.StiffnessMediumLow) ) Checkbox( checked item.isCompleted, onCheckedChange { onToggle(item.copy(isCompleted it)) }, modifier Modifier .size(24.dp) .padding(end 12.dp) ) // ✅ 标题文字根据完成状态变灰 Text( text item.title, style MaterialTheme.typography.bodyLarge, color if (item.isCompleted) MaterialTheme.colorScheme.onSurfaceVariant else MaterialTheme.colorScheme.onSurface, modifier Modifier.weight(1f) ) // ✅ 删除按钮仅长按时显示 AnimatedVisibility( visible showDeleteButton, enter fadeIn() slideInHorizontally { it }, exit fadeOut() slideOutHorizontally { -it } ) { IconButton( onClick { onDelete(item) }, modifier Modifier.size(36.dp) ) { Icon( imageVector Icons.Default.Delete, contentDescription Delete, tint MaterialTheme.colorScheme.error ) } } } } }交互亮点animateItemPlacement()列表项插入/删除时自动播放平滑位移动画animateDpAsState()Checkbox 尺寸变化0→16dp自动插值无需手动写AnimatablepointerInput长按检测比onLongClick更灵活可自定义按压阈值AnimatedVisibility删除按钮的淡入滑入动画提升操作反馈。4.4 ViewModel 实现状态容器与业务逻辑的边界HiltViewModel class TodoViewModel Inject constructor( private val repository: TodoRepository, private val dispatcher: CoroutineDispatcher Dispatchers.IO ) : ViewModel() { // ✅ 状态流使用 StateFlow支持下游 collect private val _uiState MutableStateFlowTodoState(TodoState.Loading) val uiState: StateFlowTodoState _uiState.asStateFlow() // ✅ 初始化首次加载数据 init { loadTodos() } // ✅ 添加待办纯状态变更 副作用 fun addTodo() { viewModelScope.launch { val newItem TodoItem(title New Task ${System.currentTimeMillis()}) try { repository.insert(newItem) // ✅ 状态变更触发 UI 重绘 _uiState.value _uiState.value.copy( items (_uiState.value as? TodoState.Success)?.items.orEmpty() newItem ) } catch (e: Exception) { _uiState.value TodoState.Error(e.message ?: Unknown error) } } } // ✅ 切换完成状态本地状态更新 异步持久化 fun toggleTodo(id: String) { // ✅ 本地立即更新UI 零延迟 val currentState _uiState.value if (currentState is TodoState.Success) { val updatedItems currentState.items.map { if (it.id id) it.copy(isCompleted !it.isCompleted) else it } _uiState.value currentState.copy(items updatedItems) } // ✅ 异步持久化不影响 UI viewModelScope.launch(dispatcher) { try { repository.updateById(id) { it.copy(isCompleted !it.isCompleted) } } catch (e: Exception) { // 持久化失败回滚 UI 状态可选 // _uiState.value ... } } } // ✅ 加载数据状态机驱动 private fun loadTodos() { viewModelScope.launch { _uiState.value TodoState.Loading try { val items repository.getAll() _uiState.value TodoState.Success(items items) } catch (e: Exception) { _uiState.value TodoState.Error(e.message ?: Load failed) } } } }ViewModel 设计哲学状态即 UI_uiState.value的每一次赋值都对应一次 UI 重绘机会本地优先toggleTodo先更新本地状态UI 立即响应再异步持久化避免用户等待错误隔离网络错误只影响uiState不抛出异常到 UI 层防止崩溃。5. 常见问题与排查技巧实录Composition 开发者的真实战场5.1 问题一列表滚动