修复稳定性问题

当遇到导致性能问题的不稳定的类时，您应该使其稳定。本文档概述了您可以使用的一些技术来实现这一点。

启用强跳过

您应该首先尝试启用强跳过模式。强跳过模式允许具有不稳定参数的可组合项被跳过，并且是修复由稳定性引起的性能问题的最简单方法。

有关更多信息，请参阅强跳过。

使类不可变

您还可以尝试使不稳定的类完全不可变。

  • 不可变：指示一种类型，其中任何属性的值在该类型的实例构造后永远不会改变，并且所有方法都是引用透明的。
    • 确保类的所有属性都是val而不是var，并且是不可变类型。
    • 诸如String、Int和Float之类的基本类型始终是不可变的。
    • 如果这不可能，那么您必须对任何可变属性使用 Compose 状态。
  • 稳定：指示一种可变类型。Compose 运行时不会意识到类型任何公共属性或方法行为何时会产生与先前调用不同的结果。

不可变集合

Compose 认为类不稳定的一个常见原因是集合。如诊断稳定性问题页面中所述，Compose 编译器无法完全确定诸如List、Map和Set之类的集合是否真正不可变，因此将其标记为不稳定。

为了解决这个问题，您可以使用不可变集合。Compose 编译器包括对Kotlinx 不可变集合的支持。这些集合保证是不可变的，Compose 编译器也将其视为不可变。此库仍处于 alpha 阶段，因此 API 可能会有所更改。

再次考虑来自诊断稳定性问题指南的不稳定类

unstable class Snack {
  …
  unstable val tags: Set<String>
  …
}

您可以使用不可变集合使tags稳定。在类中，将tags的类型更改为ImmutableSet<String>

data class Snack{
    …
    val tags: ImmutableSet<String> = persistentSetOf()
    …
}

这样做之后，类的所有参数都将变得不可变，并且 Compose 编译器会将该类标记为稳定。

使用Stable或Immutable进行注释

解决稳定性问题的一种可能途径是使用@Stable或@Immutable注释不稳定的类。

注释类会覆盖编译器否则会推断关于您的类的信息。它类似于Kotlin中的!!运算符。您应该非常小心地使用这些注释。覆盖编译器行为可能会导致您遇到无法预见的错误，例如，当您期望可组合项重新组合时，它不会重新组合。

如果可以在没有注释的情况下使您的类稳定，则您应该努力以这种方式实现稳定性。

以下代码段提供了一个注释为不可变的数据类的最小示例

@Immutable
data class Snack(
…
)

无论您使用@Immutable还是@Stable注释，Compose 编译器都会将Snack类标记为稳定。

集合中的注释类

考虑一个包含类型为List<Snack>的参数的可组合项

restartable scheme("[androidx.compose.ui.UiComposable]") fun HighlightedSnacks(
  …
  unstable snacks: List<Snack>
  …
)

即使您使用@Immutable注释Snack，Compose 编译器仍然会将HighlightedSnacks中的snacks参数标记为不稳定。

在涉及集合类型时，参数面临与类相同的问题，Compose 编译器始终将类型为List的参数标记为不稳定，即使它是稳定类型的集合。

您无法将单个参数标记为稳定，也无法注释可组合项以始终可跳过。有多种前进的道路。

您可以解决不稳定集合问题的方法有很多。以下小节概述了这些不同的方法。

配置文件

如果您乐于遵守代码库中的稳定性约定，则可以通过将kotlin.collections.*添加到稳定性配置文件来选择将 Kotlin 集合视为稳定。

不可变集合

为了编译时不可变性的安全性，您可以使用 kotlinx 不可变集合，而不是List。

@Composable
private fun HighlightedSnacks(
    …
    snacks: ImmutableList<Snack>,
    …
)

包装器

如果您不能使用不可变集合，您可以自己创建。为此，将List包装在一个带注释的稳定类中。根据您的需求，通用包装器可能是最好的选择。

@Immutable
data class SnackCollection(
   val snacks: List<Snack>
)

然后，您可以将其用作可组合项中参数的类型。

@Composable
private fun HighlightedSnacks(
    index: Int,
    snacks: SnackCollection,
    onSnackClick: (Long) -> Unit,
    modifier: Modifier = Modifier
)

解决方案

采用上述任一方法后，Compose 编译器现在将HighlightedSnacks可组合项标记为skippable和restartable。

restartable skippable scheme("[androidx.compose.ui.UiComposable]") fun HighlightedSnacks(
  stable index: Int
  stable snacks: ImmutableList<Snack>
  stable onSnackClick: Function1<Long, Unit>
  stable modifier: Modifier? = @static Companion
)

在重新组合期间，如果HighlightedSnacks的任何输入都没有更改，Compose 现在可以跳过它。

稳定性配置文件

从 Compose 编译器 1.5.5 开始，可以在编译时提供一个要考虑稳定的类的配置文件。这允许将您无法控制的类（例如LocalDateTime等标准库类）视为稳定。

配置文件是一个纯文本文件，每行一个类。支持注释、单一和双重通配符。一个示例配置

// Consider LocalDateTime stable
java.time.LocalDateTime
// Consider my datalayer stable
com.datalayer.*
// Consider my datalayer and all submodules stable
com.datalayer.**
// Consider my generic type stable based off it's first type parameter only
com.example.GenericClass<*,_>

要启用此功能，请将配置文件的路径传递到Compose 编译器 Gradle 插件配置的composeCompiler选项块。

composeCompiler {
  stabilityConfigurationFile = rootProject.layout.projectDirectory.file("stability_config.conf")
}

由于 Compose 编译器会分别在项目的每个模块上运行，因此您可以根据需要为不同的模块提供不同的配置。或者，在项目的根级别创建一个配置，并将该路径传递给每个模块。

多个模块

另一个常见问题涉及多模块架构。如果 Compose 编译器引用的所有非基本类型都明确标记为稳定或位于也使用 Compose 编译器构建的模块中，则它只能推断类是否稳定。

如果您的数据层与 UI 层位于不同的模块中（这是推荐的方法），那么您可能会遇到此问题。

解决方案

要解决此问题，您可以采用以下方法之一

  1. 将类添加到编译器配置文件。
  2. 在您的数据层模块上启用 Compose 编译器，或在适当的地方使用@Stable或@Immutable标记您的类。
    • 这涉及将 Compose 依赖项添加到您的数据层。但是，它只是 Compose 运行时的依赖项，而不是Compose-UI的依赖项。
  3. 在您的 UI 模块中，将您的数据层类包装在 UI 特定的包装器类中。

如果外部库不使用 Compose 编译器，也会出现同样的问题。

并非每个可组合项都应该可跳过

在努力解决稳定性问题时，您不应该尝试使每个可组合项都可跳过。尝试这样做会导致过早优化，从而引入比修复更多的问题。

在许多情况下，可跳过（skippable）并没有实际好处，反而可能导致难以维护的代码。例如

  • 一个很少或根本不重新组合的可组合函数。
  • 一个可组合函数本身只调用可跳过的可组合函数。
  • 一个具有大量参数且参数的 equals 实现代价高昂的可组合函数。在这种情况下，检查任何参数是否发生变化的成本可能会超过廉价重新组合的成本。

当一个可组合函数是可跳过的时，它会增加少量开销，这可能不值得。您甚至可以将您的可组合函数注释为不可重新启动，在您确定可重新启动带来的开销大于其价值的情况下。