遵循最佳实践

您可能会遇到常见的 Compose 陷阱。这些错误可能会导致您的代码看起来运行良好，但会损害您的 UI 性能。遵循最佳实践以优化您在 Compose 上的应用。

使用 `remember` 最小化昂贵的计算

可组合函数可能非常频繁地运行，就像动画的每一帧一样频繁。因此，您应该尽可能减少在可组合函数体中进行的计算。

一项重要的技术是使用存储计算结果 remember。这样，计算只运行一次，并且您可以在需要时获取结果。

例如，以下代码显示了一个排序后的姓名列表，但排序方式非常昂贵

@Composable
fun ContactList(
    contacts: List<Contact>,
    comparator: Comparator<Contact>,
    modifier: Modifier = Modifier
) {
    LazyColumn(modifier) {
        // DON’T DO THIS
        items(contacts.sortedWith(comparator)) { contact ->
            // ...
        }
    }
}PerformanceSnippets.kt

每次 ContactsList 重新组合时，整个联系人列表都会重新排序，即使列表没有发生变化。如果用户滚动列表，则每次出现新行时，Composable 都会重新组合。

要解决此问题，请在 LazyColumn 外部对列表进行排序，并使用 remember 存储排序后的列表

@Composable
fun ContactList(
    contacts: List<Contact>,
    comparator: Comparator<Contact>,
    modifier: Modifier = Modifier
) {
    val sortedContacts = remember(contacts, comparator) {
        contacts.sortedWith(comparator)
    }

    LazyColumn(modifier) {
        items(sortedContacts) {
            // ...
        }
    }
}PerformanceSnippets.kt

现在，列表在 ContactList 首次组合时排序一次。如果联系人或比较器发生变化，则会重新生成排序后的列表。否则，可组合函数可以继续使用缓存的排序列表。

使用延迟布局键

延迟布局有效地重用项目，仅在必须时重新生成或重新组合它们。但是，您可以帮助优化延迟布局以进行重新组合。

假设用户操作导致列表中的某个项目移动。例如，假设您显示一个按修改时间排序的笔记列表，最近修改的笔记位于顶部。

@Composable
fun NotesList(notes: List<Note>) {
    LazyColumn {
        items(
            items = notes
        ) { note ->
            NoteRow(note)
        }
    }
}PerformanceSnippets.kt

但是，这段代码存在一个问题。假设底部笔记发生了更改。它现在是最新的笔记，因此它会移到列表顶部，其他所有笔记都会向下移动一个位置。

在没有您的帮助下，Compose 无法意识到未更改的项目只是在列表中移动。相反，Compose 认为旧的“项目 2”已删除，并为项目 3、项目 4 等创建了新的项目。结果是 Compose 重新组合了列表中的每个项目，即使实际上只有一个项目发生了更改。

这里的解决方案是提供项目键。 为每个项目提供一个稳定的键可以让 Compose 避免不必要的重新组合。在这种情况下，Compose 可以确定现在位于位置 3 的项目与以前位于位置 2 的项目是同一个项目。由于该项目的任何数据都没有更改，因此 Compose 无需重新组合它。

@Composable
fun NotesList(notes: List<Note>) {
    LazyColumn {
        items(
            items = notes,
            key = { note ->
                // Return a stable, unique key for the note
                note.id
            }
        ) { note ->
            NoteRow(note)
        }
    }
}PerformanceSnippets.kt

使用 `derivedStateOf` 限制重新组合

在组合中使用状态的一个风险是，如果状态快速变化，您的 UI 可能会比您需要的次数更多地进行重新组合。例如，假设您正在显示一个可滚动的列表。您检查列表的状态以查看列表中第一个可见的项目是哪个

val listState = rememberLazyListState()

LazyColumn(state = listState) {
    // ...
}

val showButton = listState.firstVisibleItemIndex > 0

AnimatedVisibility(visible = showButton) {
    ScrollToTopButton()
}PerformanceSnippets.kt

这里的问题是，如果用户滚动列表，则 listState 会在用户拖动手指时不断变化。这意味着列表会不断重新组合。但是，您实际上并不需要那么频繁地重新组合它——直到新的项目出现在底部时，您才需要重新组合它。因此，这会产生很多额外的计算，从而导致您的 UI 性能下降。

解决方案是使用 派生状态。派生状态允许您告诉 Compose 哪些状态更改实际上应该触发重新组合。在这种情况下，指定您关心第一个可见项目何时更改。当该状态值更改时，UI 需要重新组合，但如果用户尚未滚动到足以将新项目置于顶部的程度，则它不需要重新组合。

val listState = rememberLazyListState()

LazyColumn(state = listState) {
    // ...
}

val showButton by remember {
    derivedStateOf {
        listState.firstVisibleItemIndex > 0
    }
}

AnimatedVisibility(visible = showButton) {
    ScrollToTopButton()
}PerformanceSnippets.kt

尽可能延迟读取

在识别到性能问题后，延迟状态读取可以提供帮助。延迟状态读取将确保 Compose 在重新组合时仅重新运行最少的代码。例如，如果您的 UI 具有在可组合树中较高位置提升的状态，并且您在子可组合函数中读取该状态，则可以将状态读取包装在 lambda 函数中。这样做可以确保仅在实际需要时才进行读取。作为参考，请参阅 Jetsnack 示例应用中的实现。Jetsnack 在其详细信息屏幕上实现了类似于折叠工具栏的效果。要了解此技术为何有效，请参阅博文 Jetpack Compose：调试重新组合。

为了实现此效果，Title 可组合函数需要滚动偏移量才能使用 Modifier 自身进行偏移。以下是优化前 Jetsnack 代码的简化版本

@Composable
fun SnackDetail() {
    // ...

    Box(Modifier.fillMaxSize()) { // Recomposition Scope Start
        val scroll = rememberScrollState(0)
        // ...
        Title(snack, scroll.value)
        // ...
    } // Recomposition Scope End
}

@Composable
private fun Title(snack: Snack, scroll: Int) {
    // ...
    val offset = with(LocalDensity.current) { scroll.toDp() }

    Column(
        modifier = Modifier
            .offset(y = offset)
    ) {
        // ...
    }
}PerformanceSnippets.kt

当滚动状态发生变化时，Compose 会使最近的父级重新组合范围失效。在这种情况下，最近的范围是 SnackDetail 可组合函数。请注意，Box 是一个内联函数，因此不是重新组合范围。因此，Compose 会重新组合 SnackDetail 和 SnackDetail 内部的任何可组合函数。如果更改代码以仅在实际使用状态的地方读取状态，则可以减少需要重新组合的元素数量。

@Composable
fun SnackDetail() {
    // ...

    Box(Modifier.fillMaxSize()) { // Recomposition Scope Start
        val scroll = rememberScrollState(0)
        // ...
        Title(snack) { scroll.value }
        // ...
    } // Recomposition Scope End
}

@Composable
private fun Title(snack: Snack, scrollProvider: () -> Int) {
    // ...
    val offset = with(LocalDensity.current) { scrollProvider().toDp() }
    Column(
        modifier = Modifier
            .offset(y = offset)
    ) {
        // ...
    }
}PerformanceSnippets.kt

滚动参数现在是一个 lambda。这意味着 Title 仍然可以引用提升的状态，但该值仅在 Title 内部读取，即在实际需要的地方读取。结果，当滚动值发生变化时，最近的重新组合范围现在是 Title 可组合函数——Compose 不再需要重新组合整个 Box。

这是一个很好的改进，但您可以做得更好！如果您只是为了重新布局或重绘可组合函数而导致重新组合，那么您应该对此表示怀疑。在这种情况下，您所做的只是更改 Title 可组合函数的偏移量，这可以在布局阶段完成。

@Composable
private fun Title(snack: Snack, scrollProvider: () -> Int) {
    // ...
    Column(
        modifier = Modifier
            .offset { IntOffset(x = 0, y = scrollProvider()) }
    ) {
        // ...
    }
}PerformanceSnippets.kt

以前，代码使用 Modifier.offset(x: Dp, y: Dp)，它将偏移量作为参数。通过切换到修饰符的 lambda 版本，您可以确保该函数在布局阶段读取滚动状态。结果，当滚动状态发生变化时，Compose 可以完全跳过组合阶段，直接进入布局阶段。当您将频繁变化的状态变量传递给修饰符时，应尽可能使用修饰符的 lambda 版本。

这是此方法的另一个示例。此代码尚未优化

// Here, assume animateColorBetween() is a function that swaps between
// two colors
val color by animateColorBetween(Color.Cyan, Color.Magenta)

Box(
    Modifier
        .fillMaxSize()
        .background(color)
)PerformanceSnippets.kt

在这里，框的背景颜色在两种颜色之间快速切换。因此，此状态变化非常频繁。然后，可组合函数在背景修饰符中读取此状态。结果，框必须在每一帧上重新组合，因为颜色在每一帧上都在变化。

要改进这一点，请使用基于 lambda 的修饰符——在本例中，使用 drawBehind。这意味着颜色状态仅在绘制阶段读取。结果，Compose 可以完全跳过组合和布局阶段——当颜色发生变化时，Compose 直接进入绘制阶段。

val color by animateColorBetween(Color.Cyan, Color.Magenta)
Box(
    Modifier
        .fillMaxSize()
        .drawBehind {
            drawRect(color)
        }
)PerformanceSnippets.kt

避免向后写入

Compose 的一个核心假设是您永远不会写入已经读取的状态。当您这样做时，这称为向后写入，它会导致每一帧都发生重新组合，并且会无限循环。

以下可组合函数显示了此类错误的示例。

@Composable
fun BadComposable() {
    var count by remember { mutableStateOf(0) }

    // Causes recomposition on click
    Button(onClick = { count++ }, Modifier.wrapContentSize()) {
        Text("Recompose")
    }

    Text("$count")
    count++ // Backwards write, writing to state after it has been read</b>
}PerformanceSnippets.kt

此代码在读取前一行上的计数后，在可组合函数的末尾更新了计数。如果运行此代码，您会发现单击按钮后（这会导致重新组合），计数器会以无限循环的速度快速增加，因为 Compose 会重新组合此可组合函数，看到一个过时的状态读取，因此会安排另一次重新组合。

您可以通过永远不在组合中写入状态来完全避免向后写入。如果可能，请始终响应事件并在 lambda 中写入状态，如前面的 onClick 示例中所示。

其他资源

应用性能指南：了解提高 Android 性能的最佳实践、库和工具。
检查性能：检查应用性能。
基准测试：对应用性能进行基准测试。
应用启动：优化应用启动。
基线配置文件：了解基线配置文件。

为您推荐

注意：当 JavaScript 关闭时，会显示链接文本
状态和 Jetpack Compose
图形修饰符
Compose 思维