您可能会遇到一些常见的 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 ->
// ...
}
}
}
每次重组 ContactsList 时都会重新对整个联系人列表进行排序，即使该列表并没有发生变化。如果用户滚动列表，则每当出现新行时，可组合函数都会执行重组。
如需解决此问题，请在 LazyColumn 外部对列表进行排序，并使用 remember 存储已排序列表：
@Composable
fun ContactList(
contacts: List<Contact>,
comparator: Comparator<Contact>,
modifier: Modifier = Modifier
) {
val sortedContacts = remember(contacts, sortComparator) {
contacts.sortedWith(sortComparator)
}
LazyColumn(modifier) {
items(sortedContacts) {
// ...
}
}
}
现在，列表只会在 ContactList 首次组合时执行一次排序。如果联系人或比较器发生变化，则系统会重新生成经过排序的列表。否则，可组合函数会继续使用缓存中的已排序列表。
使用延迟布局键
延迟布局会尽可能智能化地重用各个项，即仅在必要时才会重新生成或重组这些项。但是，您可以帮助其做出最佳决策。
假设某项用户操作会导致项在列表中移动。例如，假设您显示一个按修改时间排序的备注列表，最近修改的备注位于最顶部。
@Composable
fun NotesList(notes: List<Note>) {
LazyColumn {
items(
items = notes
) { note ->
NoteRow(note)
}
}
}
但这段代码有一个问题。假设底部的备注发生了更改。 它现在是最近修改过的备注，因此会移到列表顶部，而其他备注都会向下移动一个位置。
如果您未提供帮助，则 Compose 并不会意识到未更改的项只在列表中发生了移动。Compose 会认为旧的“项 2”已被删除，并且创建了一个新的“项 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)
}
}
}
使用 derivedStateOf 限制重组
在组合中使用状态的一项风险就是，如果状态快速变化，则界面的重组次数可能会超出您的实际需求。 例如，假设您要显示一个可滚动列表。您可以检查列表状态并确定列表中的哪一项是第一个可见项：
val listState = rememberLazyListState()
LazyColumn(state = listState) {
// ...
}
val showButton = listState.firstVisibleItemIndex > 0
AnimatedVisibility(visible = showButton) {
ScrollToTopButton()
}
问题在于，当用户滚动列表时，listState 会随着用户拖动手指而不断变化。这意味着该列表会不断重组。但是，您实际上并不需要如此频繁地进行重组 - 在底部显示新项之前，并不需要重组。因此，这将完成大量的额外计算，从而导致界面性能较差。
解决方案是使用派生状态。借助派生状态，您可以告知 Compose 哪些状态更改应当实际触发重组。针对本例，请指定需要跟踪第一个可见项发生更改的时间。当该状态值发生更改时，界面需要重组。而如果用户尚未滚动到新项，则不需要重组。
val listState = rememberLazyListState()
LazyColumn(state = listState) {
// ...
}
val showButton by remember {
derivedStateOf {
listState.firstVisibleItemIndex > 0
}
}
AnimatedVisibility(visible = showButton) {
ScrollToTopButton()
}
尽可能延迟读取
发现性能问题后，延后读取状态会有所帮助。延后读取状态可以确保 Compose 在重组时重新运行尽可能少的代码。例如，如果界面的状态在可组合项树中向上提升，而您在可组合子项中读取状态，则可以将状态封装在 lambda 函数中。这种方式可以确保仅在实际需要时才会执行读取操作。您可以了解我们如何将此方法应用于 Jetsnack 示例应用。Jetsnack 在其详情屏幕中实现了类似于工具栏的折叠效果。 如需了解此技术的工作原理，请参阅博文：调试重组。
为了实现这种效果，Title 可组合项需要知晓滚动偏移，以便于使用 Modifier 实现自行偏移。下面列出了未进行优化的简化版 Jetnack 代码：
@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)
) {
// ...
}
}
当滚动状态发生更改时，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)
) {
// ...
}
}
滚动参数现在是一个 lambda。这意味着 Title 仍然可以引用提升的状态，但该值仅在 Title 内部读取，这也是实际需要的。因此，当滚动值发生更改时，最近的重组范围现在是 Title 可组合项 - Compose 不再需要重组整个 Box。
这是一项非常重大的改进，但是您还可以做得更好！如果您触发重组只是为了重新布局或重新绘制可组合项，那么您肯定会充满了疑惑。在本例中，您只是更改了 Title 可组合项的偏移量，而此操作可以在布局阶段完成。
@Composable
private fun Title(snack: Snack, scrollProvider: () -> Int) {
// ...
Column(
modifier = Modifier
.offset { IntOffset(x = 0, y = scrollProvider()) }
) {
// ...
}
}
之前，代码使用 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))
在此代码中，Box 的背景颜色会在两种颜色之间快速切换。因此，其状态也会非常频繁地变化。随后，可组合项会在后台修饰符中读取此状态。因此，该 Box 在每一帧上都需要重组，因为其颜色在每一帧中都会发生变化。
为了改进这段代码，我们可以使用基于 lambda 的修饰符，在本例中为 drawBehind。这将仅在绘制阶段读取颜色状态。因此，Compose 可以完全跳过组合阶段和布局阶段 - 当颜色发生变化时，Compose 会直接进入绘制阶段。
val color by animateColorBetween(Color.Cyan, Color.Magenta)
Box(
Modifier
.fillMaxSize()
.drawBehind {
drawRect(color)
}
)
避免向后写入
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
}
此代码会可组合项末尾处更新计数，也就是上面代码中读取计数后。如果运行此代码，您会看到点击按钮会触发 Compose 执行重组，随后计数器会进入无限增长的循环，状态读取会过期。因此，Compose 会再次安排重组。
您完全可以避免向后写入数据，只需避免在组合中写入状态即可。请尽可能在响应事件时写入状态，并采用 lambda 的形式，如上文中的 onClick 示例所示。