Google I/O : Jetpack Compose 中常见的性能问题

前言

Jetpack Compose的应用也逐渐广泛起来，由于声明式UI的特点，Compose在开发的易用性方面有较大优势，但相信很多人对于Compose的性能问题有一些疑问。
这些问题有些是因为Compose还是个新生事物，不够成熟导致的，有些则是因为开发者的使用不当导致的。
本文主要介绍如何编写和配置应用程序以获得最佳性能，并指出了一些要避免的问题。

正确配置应用

如果您的Compose应用性能不佳，则可能意味着存在配置问题。 首先应该检查以下配置项

使用Release模式构建并且使用R8

如果您发现性能问题，请确保尝试在Release模式下运行您的应用。Debug模式对于发现许多问题很有用，但它会带来显着的性能成本，并且很难发现可能影响性能的其他代码的问题。
同时您还应该使用 R8 编译器从您的应用程序中删除不必要的代码。 默认情况下，在Release模式下构建会自动使用 R8 编译器。

使用baseline profile

Compose 作为一个单独的库分发，而不是作为 Android 平台的一部分。这种方法让我们可以经常更新 Compose 并支持较旧的 Android 版本。但是，将 Compose 作为库分发也会产生一定的成本。 Android 平台代码已编译并安装在设备上。另一方面，库需要在应用程序启动时加载，并在需要功能时及时解释(即JIT)。这可能会在启动时减慢应用程序的速度，并且每当它首次使用库功能时。

您可以通过定义baseline profile来提高性能。这些配置文件定义了用户主流程所需的类和方法，并与您应用的 APK 一起分发。在应用程序安装期间，ART 会提前编译该关键代码(即AOT)，以便在应用程序启动时准备好使用。

定义一个好的baseline profile并不总是那么容易，因此 Compose 默认附带一个。因此默认情况下你不需要做任何额外工作。
同时，如果您选择定义自己的配置文件，您可能会生成一个实际上不会提高应用程序性能的配置文件。您应该测试配置文件以验证它是否有帮助。一个很好的方法是为您的应用程序编写 Macrobenchmark 测试，并在您编写和修改baseline profile时检查测试结果。有关如何为 Compose UI 编写 Macrobenchmark 测试的示例，请参阅 Macrobenchmark Compose 示例。

总得来说，使用baseline profile即通过AOT取代JIT，加快Compose首次运行的速度。
在默认情况下Compose已经自带了一个默认的baseline profile，你不需要做什么额外工作就可以支持。
但如果你要自定义baseline profile的话，需要做好测试用例，验证自定义的配置是否有效。

自定义baseline profile比较麻烦，不过根据Google I/O上给出的数据，可以达到20%到30%的启动性能提升，大家可以根据情况决定是否使用

关于Compose的一些最佳实践

在编写Compose代码时你可能会碰到一些常见的错误。这些错误不影响运行，但会损害您的 UI 性能。本节列出了一些最佳实践来帮助您避免它们。

使用remember减少计算

Compose函数可以非常频繁地运行，就像动画的每一帧一样频繁。 出于这个原因，你应该尽可能少地在Compose中做计算。
最常见的就是使用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 时，整个联系人列表都会重新排序，即使列表没有更改。 如果用户滚动列表，只要出现新行，Composable 就会重新组合。
为了解决这个问题，在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 时，列表被排序一次。 如果联系人或比较器更改，则重新生成排序列表。 否则，可组合项可以继续使用缓存的排序列表。
当然：如果可能，最好将计算完全移到Compose之外，比如ViewModel

Lazy Layout使用Key

Lazy Layout使用智能重组，仅在必要时才会发生重组。 同时，我们可以帮助它做出最佳决策。
假设用户操作导致item在列表中移动。 例如，假设您显示按修改时间排序的笔记列表，最近修改的笔记在最上面。

@Composable
fun NotesList(notes: List<Note>) {
    LazyColumn {
        items(
            items = notes
        ) { note ->
            NoteRow(note)
        }
    }
}
复制代码

不过，这段代码存在一定的问题。 假设底部的note发生了变化。 它现在是最近修改的note，所以它应该排在列表的顶部，而其他每个note都向下移动一个位置。

这里的问题是，没有您的帮助，Compose 不会意识到未更改的项目只是在列表中移动。 相反，Compose 认为旧的“第 2 项”被删除并创建了一个新的，依此类推，第 3 项、第 4 项一直如此。 结果是，Compose 会重新组合列表中的每一项，即使其中只有一项实际发生了变化。

解决方案是提供item key。 为每个item提供一个稳定的key可以让 Compose 避免不必要的重组。 在这种情况下，Compose 可以看到现在位于第 3 项和item过去位于第 2 的item相同。由于该项目的数据都没有更改，因此 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 限制重组

在重组中使用状态的一个风险是，如果状态快速变化，你的 UI 可能会比你预期的发生更多的重组。
例如，假设您正在显示一个可滚动的列表。 您检查列表的状态以查看哪个item是列表中的第一个可见item：

val listState = rememberLazyListState()

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

val showButton = listState.firstVisibleItemIndex > 0

AnimatedVisibility(visible = showButton) {
    ScrollToTopButton()
}
复制代码

这里的问题在于，如果用户滚动列表，listState 会随着用户拖动手指而不断变化。 这意味着该列表不断被重新组合，而showButton的结果也会被不断计算。
但是，您只有在firstVisibleItemIndex发生变化时才需要计算showButton。 所以，这里多了很多额外的计算，会影响您的UI性能

解决方案是使用derivedStateOf。 derivedStateOf告诉Compose只有当我们关心的状态发生变化时，才需要重组。
在这种情况下，当firstVisibleItemIndex发生变化时才需要重组。但如果用户还没有滚动到足以将新item带到顶部的程度，则不需要重新组合。

val listState = rememberLazyListState()

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

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

AnimatedVisibility(visible = showButton) {
    ScrollToTopButton()
}
复制代码

注意，如果把状态都放在ViewModel里，也就不用考虑这个了

尽可能延迟读取State

您应该尽可能推迟读取State。 延迟读取State有助于确保 Compose 在重组时重新运行尽可能少的代码。 例如，如果您的 UI 具有在composable树中高高提升的状态，并且您在子composable中读取状态，则可以将读取的状态包装在 lambda 函数中。 这样做会使读取仅在实际需要时发生。

我们来看一段Jetsnack在列表滚动时实现Title折叠展开的代码，为了达到这个效果，Title composable需要知道滚动偏移量，以便使用修饰符来偏移自己。 在进行优化之前，这是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)
    ) {
        // ...
    }
}
复制代码

当滚动状态发生变化时，Compose 会寻找最近的父重组作用域并使其无效。 在这种情况下，最近的父级是可组合的是Box。 因此 Compose 重组了 Box，并且还重组了 Box 内的任何可组合项。 如果您将代码重构为仅读取您需要的State，那么您可以减少需要重组的元素数量。

@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 composable，因此Compose 不再需要重组整个 Box。

这是一个很好的改进，但我们还可以做得更好。 因为我们所做的只是更改可组合标题的偏移量，这可以在布局阶段完成，而不必经过组合阶段。

Compose的阶段

与大多数其他界面工具包一样，Compose 会通过几个不同的“阶段”来渲染帧。如果我们观察一下 Android View 系统，就会发现它有 3 个主要阶段：测量、布局和绘制。Compose 和它非常相似，但开头多了一个叫做“组合”的重要阶段。

Compose 有 3 个主要阶段：

• 组合：要显示什么样的界面。Compose 运行可组合函数并创建界面说明。
• 布局：要放置界面的位置。该阶段包含两个步骤：测量和放置。对于布局树中的每个节点，布局元素都会根据 2D 坐标来测量并放置自己及其所有子元素。
• 绘制：渲染的方式。界面元素会绘制到画布（通常是设备屏幕）中。

优化状态读取

知道了Compose的3个阶段，Compose 会执行局部状态读取跟踪，因此我们可以在适当阶段读取每个状态，从而尽可能降低需要执行的工作量
如果我们在布局阶段读取状态，就可以跳过组合阶段，如果我们在绘制阶段读取状态，就可以跳过组合和布局

因此我们可以将offset的读取推迟到布局阶段，这样可以避免组合阶段重新执行

@Composable
private fun Title(snack: Snack, scrollProvider: () -> Int) {
    // ...
    Column(
        modifier = Modifier
            .offset { IntOffset(y = scrollProvider()) }
    ) {
      // ...
    }
}
复制代码

之前代码使用了Modifier.offset(x: Dp, y: Dp)，它以偏移量为参数。 通过切换到修饰符的 lambda 版本，您可以确保函数在布局阶段读取滚动状态。 因此，当滚动状态发生变化时，Compose 可以完全跳过组合阶段，直接进入布局阶段。 当您将频繁更改的状态变量传递给modifier时，应尽可能使用modifier的 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))
复制代码

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

为了改善这一点，我们可以使用基于 lambda 的modifier：在本例中为 drawBehind。这意味着仅在绘制阶段读取颜色状态。
因此，Compose 可以完全跳过组合和布局阶段，当颜色发生变化时，Compose 会直接进入绘制阶段。

避免反向写入

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 重组此 Composable，计数器会在无限循环中迅速增加，看到读取的状态已过期，因此会安排另一个重组 .

您可以通过从不在 Composition 中写入状态来完全避免向后写入。 如果可能，请始终响应事件来更新状态，并使用 lambda 表达式，就像前面的 onClick 示例一样。

总结

本文主要介绍如何编写和配置Compose以获得最佳性能，并指出了一些要避免的问题。
想要了解更多的同学可参考Google I/O上相关的分享：Jetpack Compose 中常见的性能问题