Jetpack Compose 性能优化实战：5 个方向让你的 App 流畅如丝

前言：Compose 已成 Android 开发主流

Jetpack Compose 自 2021 年正式发布以来，已经成为 Android 现代 UI 开发的标准方案。越来越多的团队将存量代码迁移至 Compose，或直接用 Compose 从零构建新应用。然而，随着 Compose UI 复杂度不断提升，性能问题也开始浮出水面：列表滑动卡顿、动画掉帧、冷启动耗时……

本文从实战角度出发，梳理 Compose 性能优化最常见的 5 个方向，每个方向附带可直接复用的代码片段，帮助你快速定位并解决性能瓶颈。

一、理解重组（Recomposition）：从根源防止无效渲染

Compose 的核心机制是响应式重组——状态变化时，框架自动重新执行相关 Composable。但如果重组范围控制不当，就会导致大量不必要的 UI 重建，造成明显卡顿。

常见错误：在父级 Composable 里创建 lambda 或 List，每次重组都产生新对象，导致子组件被强制重组。

// ❌ 错误写法：每次父组件重组都会创建新 List
@Composable
fun ParentScreen(viewModel: MyViewModel) {
    val items = listOf("A", "B", "C")  // 每次重组都是新对象
    ItemList(items = items)
}

// ✅ 正确写法：从 ViewModel 稳定来源获取
@Composable
fun ParentScreen(viewModel: MyViewModel) {
    val items by viewModel.items.collectAsStateWithLifecycle()
    ItemList(items = items)
}

使用 @Stable 和 @Immutable 注解帮助 Compose 编译器识别稳定类型，跳过不必要的重组：

@Immutable
data class UserProfile(
    val id: Long,
    val name: String,
    val avatarUrl: String
)

二、LazyList 优化：让列表滑动丝滑如油

LazyColumn / LazyRow 是 Compose 中最常用的列表组件，也是性能问题的重灾区。以下几点是高频踩坑点：

• key 参数必须指定：为每个 item 提供稳定唯一的 key，避免全量重组。

• 避免在 item lambda 内做耗时计算：使用 remember 缓存派生数据。

• 图片加载使用异步库：Coil / Glide for Compose，避免主线程解码图片。

• itemsIndexed 谨慎使用：如果只需 item 不需要 index，用 items 即可。

LazyColumn {
    items(
        items = articleList,
        key = { article -> article.id }  // ✅ 提供稳定 key
    ) { article ->
        val formattedDate = remember(article.id) {
            // ✅ 缓存耗时格式化操作
            SimpleDateFormat("yyyy-MM-dd", Locale.getDefault())
                .format(Date(article.timestamp))
        }
        ArticleCard(article = article, date = formattedDate)
    }
}

对于超长列表（>1000 项），建议结合 Paging 3 使用 collectAsLazyPagingItems()，实现分页加载，进一步降低内存压力。

三、使用 derivedStateOf 避免过度重组

当某个状态需要基于其他状态派生计算，且计算成本较高时，应使用 derivedStateOf 包裹，确保只有在派生结果真正变化时才触发重组。

@Composable
fun ScrollToTopButton(listState: LazyListState) {
    // ❌ 错误：每次 firstVisibleItemIndex 变化都重组
    val showButton = listState.firstVisibleItemIndex > 0

    // ✅ 正确：只有布尔值从 false→true 或 true→false 时才重组
    val showButton by remember {
        derivedStateOf { listState.firstVisibleItemIndex > 0 }
    }

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

这个优化在列表滚动场景尤其明显，可以将按钮区域的重组次数从"每帧"降低到"仅切换阈值时"。

四、借助 Android Studio 工具定量分析

性能优化不能只凭感觉，Android Studio 提供了强大的 Compose 专属工具链：

• Layout Inspector：实时查看 Compose 树结构，标注哪些组件正在重组（绿色高亮闪烁）。

• Composition Tracing：在 Systrace / Perfetto 中记录 Composable 函数调用，精确定位热点。需在 build.gradle 中启用：composeOptions { kotlinCompilerExtensionVersion = "1.5.x" }。

• Recomposition Counts：Layout Inspector 的 Recomposition 面板可直观看到每个节点的重组次数和跳过次数。

// build.gradle (app)
android {
    buildFeatures {
        compose = true
    }
    composeOptions {
        kotlinCompilerExtensionVersion = "1.5.14"
    }
}

dependencies {
    // 启用 Composition Tracing
    implementation "androidx.compose.runtime:runtime-tracing:1.0.0-beta01"
}

建议在优化前后各跑一次 Systrace，用数据说话，而不是凭肉眼感知"好像快了一点"。

五、实战建议与常见误区总结

经过大量项目实践，以下几点是最值得反复强调的：

• 不要过早优化：先用 Layout Inspector 确认存在重组问题，再针对性优化，避免增加不必要的代码复杂度。

• ViewModel + StateFlow 是标准搭档：状态统一从 ViewModel 的 StateFlow 流入 UI，配合 collectAsStateWithLifecycle() 自动感知生命周期，既安全又高效。

• remember 不是万能的：过度使用 remember 会增加内存占用，只对真正昂贵的计算使用。

• Modifier 顺序影响性能：Modifier.clip().background() 与 Modifier.background().clip() 产生不同的绘制层级，前者开销更小。

• 避免在 Composable 顶层创建协程 scope：使用 rememberCoroutineScope() 绑定生命周期，防止内存泄漏。

Jetpack Compose 的性能优化是一个系统工程，没有银弹。理解重组机制是基础，善用官方工具是手段，最终目标是让用户感受到流畅自然的交互体验。随着 Compose 编译器的持续演进（Strong Skipping Mode 等新特性），未来的优化空间还会进一步扩大。