Jetpack Compose 性能优化实战：5个高频坑与解决方案

Jetpack Compose 已经成为 Android 原生 UI 开发的主流方案，但很多开发者在实际项目落地时都踩过同一批坑：动画卡顿、状态管理混乱、性能优化无从下手。本文基于真实项目经验，整理出 Compose 开发中最高频的性能问题及解决方案，并附上可直接复用的代码片段。

一、搞清楚 Recomposition 的触发机制

Compose 性能问题十有八九出在不必要的重组（Recomposition）上。很多开发者误以为只要用了 remember 就够了，实际上 Compose 的重组粒度取决于 Composable 函数读取了哪些 State。

最常见的反模式是把整个复杂对象作为 State 传入：

// ❌ 错误：整个 UserInfo 变化都会触发 ProfileCard 重组
@Composable
fun ProfileCard(userInfo: UserInfo) {
    Text(userInfo.name)
    Text(userInfo.email)
}

// ✅ 正确：只传需要的字段，减少重组范围
@Composable
fun ProfileCard(name: String, email: String) {
    Text(name)
    Text(email)
}

另一个高频问题是 Lambda 引用不稳定。每次父组件重组时，传入的 Lambda 都会产生新实例，导致子组件被强制重组：

// ❌ 每次重组都创建新 Lambda
LazyColumn {
    items(list) { item ->
        ItemCard(item, onClick = { viewModel.onItemClick(item) })
    }
}

// ✅ 用 remember 缓存 Lambda（Kotlin 1.9+ 可用 rememberUpdatedState）
val onItemClick = remember { { item: Item -> viewModel.onItemClick(item) } }

调试工具推荐：在 Android Studio 开启 Layout Inspector → Recomposition Counts，能直观看到每个节点的重组次数，快速定位热点。

二、LazyColumn 的正确打开方式

LazyColumn 是 Compose 里最容易出性能问题的组件，核心原则是：给每个 item 提供稳定唯一的 key。

// ❌ 没有 key，列表增删时会全量重组
LazyColumn {
    items(messageList) { msg ->
        MessageItem(msg)
    }
}

// ✅ 提供 key，Compose 可以精准复用已有组件
LazyColumn {
    items(
        items = messageList,
        key = { msg -> msg.id }  // 必须是唯一稳定值
    ) { msg ->
        MessageItem(msg)
    }
}

另一个坑点：在 item 内部做复杂计算。LazyColumn 滚动时会频繁调用 item 的 Composable，应把耗时逻辑移到 ViewModel 或用 remember(key) 缓存：

@Composable
fun MessageItem(msg: Message) {
    // ❌ 每次重组都计算
    val formattedTime = SimpleDateFormat("HH:mm").format(msg.timestamp)
    
    // ✅ key 不变就不重算
    val formattedTime = remember(msg.timestamp) {
        SimpleDateFormat("HH:mm", Locale.getDefault()).format(msg.timestamp)
    }
    
    Text(formattedTime)
}

对于图片加载，务必配合 contentScale 和固定尺寸，避免 Coil/Glide 加载完成后触发重新布局：

AsyncImage(
    model = msg.avatarUrl,
    contentDescription = null,
    modifier = Modifier.size(40.dp),  // 固定尺寸！
    contentScale = ContentScale.Crop
)

三、状态提升与 ViewModel 的配合

Compose 推崇"状态提升（State Hoisting）"，但很多人做过头了——把所有状态都塞进 ViewModel，导致 UI 层完全依赖 ViewModel 才能预览，测试也变得复杂。

实用原则：局部 UI 状态留在 Composable，业务状态交给 ViewModel。

// 局部 UI 状态（展开/折叠）不需要进 ViewModel
@Composable
fun ExpandableCard(title: String, content: String) {
    var expanded by remember { mutableStateOf(false) }
    
    Card(onClick = { expanded = !expanded }) {
        Column {
            Text(title)
            AnimatedVisibility(visible = expanded) {
                Text(content)
            }
        }
    }
}

// 业务数据从 ViewModel 的 StateFlow 收集
@Composable
fun ArticleScreen(viewModel: ArticleViewModel = hiltViewModel()) {
    val uiState by viewModel.uiState.collectAsStateWithLifecycle()
    
    when (uiState) {
        is Loading -> LoadingIndicator()
        is Success -> ArticleList((uiState as Success).articles)
        is Error -> ErrorView((uiState as Error).message)
    }
}

注意：使用 collectAsStateWithLifecycle() 而非 collectAsState()，前者在 Activity 进入后台时会自动停止收集，节省资源。

四、动画性能：用 derivedStateOf 避免过度重组

滚动联动动画是 Compose 的高频需求，但如果直接监听 lazyListState.firstVisibleItemScrollOffset，会在每一帧都触发重组：

val listState = rememberLazyListState()

// ❌ 每像素都重组
val showFab = listState.firstVisibleItemIndex > 0

// ✅ 只有结果变化时才重组
val showFab by remember {
    derivedStateOf { listState.firstVisibleItemIndex > 0 }
}

AnimatedVisibility(visible = showFab) {
    FloatingActionButton(onClick = { /* scroll to top */ }) {
        Icon(Icons.Default.ArrowUpward, contentDescription = "回到顶部")
    }
}

derivedStateOf 的核心价值：将高频 State 变化转换为低频结果变化，是处理滚动、拖拽等连续手势的必备工具。

五、实战踩坑记录

以下是真实项目中遇到的几个典型问题：

• 坑1：Dialog 内容闪烁。根因是 Dialog 的内容 Composable 和触发状态在同一层，点击按钮时状态先变 false 再销毁，导致闪一帧空内容。解决方案：用 AnimatedVisibility 替代直接条件渲染，或用 DialogProperties(dismissOnBackPress = true) 配合独立的 showDialog 状态管理。

• 坑2：TextField 输入卡顿。在低端机上 TextField 每次输入都卡，排查发现是 onValueChange 里做了字符串格式化操作（手机号分段显示），格式化逻辑本身是 O(n) 但触发了整个父组件重组。解决：把格式化逻辑移入 remember(value) { ... }，并把 TextField 封装成独立组件隔离重组影响。

• 坑3：BottomSheet 内 LazyColumn 高度异常。BottomSheet 默认有高度约束，内部 LazyColumn 需要加 .weight(1f) 或指定 fillMaxHeight(0.9f)，否则在某些机型上会只显示一行。

• 坑4：Dark Mode 切换时动画丢失。系统深色模式切换会重建 Activity（除非在 Manifest 配置了 uiMode），导致 Compose 状态丢失。解决：在 AndroidManifest 的 Activity 节点加 android:configChanges="uiMode" 并在 ViewModel 里持久化关键状态。

Jetpack Compose 的学习曲线主要在于理解其响应式模型和重组机制，一旦建立起正确的心智模型，开发效率会有质的提升。建议结合 Android Studio 的 Profiler 和 Layout Inspector 实际测量，而不是凭感觉优化。