应用的界面应能适应不同的屏幕尺寸、屏幕方向和设备类型。自适应布局会根据可用的屏幕空间自动调整。这些调整包括简单的布局调整（以填满空间）和完全更改布局（以利用额外的空间）。
作为声明式界面工具包，Jetpack Compose 非常适合用来设计和实现可自行调整的布局，以针对各种尺寸以不同方式呈现内容。本文档介绍了一些有关如何使用 Compose 来构建自适应界面的指南。
以显式方式对屏幕级可组合项布局进行大幅调整
使用 Compose 布置整个应用时，应用级和屏幕级可组合项会占用分配给应用进行渲染的所有空间。在应用设计的这个层面上，可能有必要更改屏幕的整体布局以充分利用屏幕空间。
避免根据物理硬件值来确定布局。您可能会想根据固定的有形值来确定布局（设备是平板电脑吗？物理屏幕是否有特定的宽高比？）不过，这些问题的答案对于确定界面可使用的空间可能没什么价值。
在平板电脑上，应用可能会在多窗口模式下运行，这意味着，该应用可能会与另一个应用分屏显示。在 Chrome 操作系统中，应用可能会位于可调整大小的窗口中。甚至可能会有多个物理屏幕，例如可折叠设备。在所有这些情况下，物理屏幕尺寸都与决定如何显示内容无关。
相反，您应该根据分配给应用的实际屏幕区域来决定如何显示，例如 Jetpack WindowManager 库提供的当前窗口指标。如需了解如何在 Compose 应用中使用 WindowManager，请查看 JetNews 示例。
遵循此方法可提高应用的灵活性，因为它将在以上所有场景中都能正常运行。让布局能够自动适应可用的屏幕空间，也可以减少为支持 Chrome 操作系统等平台以及平板电脑和可折叠设备等设备类型而需要进行的特殊处理。
为了适应应用的可用空间，将原始尺寸转换为有意义的 Size 类会很有帮助，如窗口 Size 类中所述。 这会将尺寸分组到标准的大小存储分区中，这些是一些断点，目的是要灵活地针对大多数独特情形优化您的应用，又不至于实现起来太过困难。这些 Size 类参考的是应用的整个窗口，因此请使用这些类来确定影响整个屏幕的布局。您可以将这些 Size 类作为状态进行传递，也可以执行其他逻辑来创建派生状态以传递给嵌套可组合项。
enum class WindowSizeClass { Compact, Medium, Expanded }
@Composable
fun MyApp(windowSizeClass: WindowSizeClass) {
// Perform logic on the size class to decide whether to show
// the top app bar.
val showTopAppBar = windowSizeClass != WindowSizeClass.Compact
// MyScreen knows nothing about window sizes, and performs logic
// based on a Boolean flag.
MyScreen(
showTopAppBar = showTopAppBar,
/* ... */
)
}
这种分层方法会将屏幕尺寸逻辑限制在单个位置，而不是将其分散到应用的多个位置并需要保持同步。这个单一位置会生成状态，您可以将其显式传递给其他可组合项，就像处理任何其他应用状态一样。显式传递状态可以简化个别可组合项，因为它们只是一些接受 Size 类或指定配置以及其他数据的普通可组合函数。
灵活的嵌套可组合项可以重复使用
将可组合项放置在各种不同的位置，可以提高它们的可重用性。如果某个可组合项假定将始终放置在某个特定的位置，并具有特定的尺寸，那么将很难在其他位置或在可用空间不同的情况下重复使用它。这也意味着可重用的个别可组合项应避免隐式依赖于“全局”尺寸信息。
我们来看一个示例：假设用一个嵌套可组合项来实现列表详情布局，该布局可能会显示一个窗格或并排显示两个窗格。
显示典型的列表/详情布局的应用界面截图。1 是列表区域，2 是详情区域。
我们希望将此决策纳入应用的整体布局中，因此我们从屏幕级可组合项传递此决策，如上方所示：
@Composable
fun AdaptivePane(
showOnePane: Boolean,
/* ... */
) {
if (showOnePane) {
OnePane(/* ... */)
} else {
TwoPane(/* ... */)
}
}
如果我们想让一个可组合项根据可用空间单独调整其布局，该怎么办？例如，希望卡片在空间允许的情况下能够显示更多详情。我们希望根据某个可用尺寸执行某种逻辑，但具体是指哪个尺寸？
如上所示，我们应该避免尝试使用设备的实际屏幕尺寸。对于多屏幕设备或者不是全屏显示的应用，这会不准确。
由于该可组合项不是屏幕级可组合项，为了最大限度地提高可重用性，我们也不应该直接使用当前的窗口指标。如果组件在放置时有内边距（例如边衬区），或者有导航栏或应用栏等组件，那么系统为可组合项分配的空间量与应用可使用的总空间量可能会有很大的差距。
因此，我们应使用系统分配给可组合项用于执行渲染的实际宽度。我们可以通过以下两种方法获取该宽度：
如果您想更改内容的显示位置或方式，可以使用一系列修饰符或自定义布局来构建自适应布局。这很简单，只需让某个子项填充所有可用空间，或者为子级布置多个列（如果有足够的空间）。
如果您想更改显示的内容，可以使用 BoxWithConstraints 作为更强大的替代方案。这个可组合项提供的测量约束条件可用来根据可用空间调用不同的可组合项。但是，这样也会带来一些后果，因为 BoxWithConstraints 会将组合推迟到布局阶段（此时已知道这些约束条件），从而导致在布局期间执行更多工作。
@Composable
fun Card(/* ... */) {
BoxWithConstraints {
if (maxWidth < 400.dp) {
Column {
Image(/* ... */)
Title(/* ... */)
}
} else {
Row {
Column {
Title(/* ... */)
Description(/* ... */)
}
Image(/* ... */)
}
}
}
}
确保在不同尺寸下所有数据都可以呈现
如果可以利用额外的屏幕空间，您在大屏幕上向用户显示的内容可以比在小屏幕上多。当实现具有此行为的可组合项时，您可能想要提高效率，根据当前屏幕尺寸来加载数据。
但是，这违背了单向数据流的原则，即可以提升数据并直接提供给可组合项，以实现正确的渲染。应该向可组合项提供足够的数据，确保可组合项在任何尺寸下，都始终具有需要显示的所有内容，即使某些数据有时不会用到。
@Composable
fun Card(
imageUrl: String,
title: String,
description: String
) {
BoxWithConstraints {
if (maxWidth < 400.dp) {
Column {
Image(imageUrl)
Title(title)
}
} else {
Row {
Column {
Title(title)
Description(description)
}
Image(imageUrl)
}
}
}
}
请注意，就 Card 示例而言，我们始终都会将 description 传递给 Card。尽管 description 仅在宽度允许显示它时才会用到，但无论有多少可用宽度，Card 都始终需要 description。
始终传递数据可通过降低自适应布局的有状态程度来使其更简单，并可以避免在不同尺寸之间切换（这可能是由于窗口大小调整、屏幕方向变化或折叠/展开设备造成的）所带来的负面影响。
这一原则还可以在布局发生变化时保留状态。通过提升可能不会在所有尺寸下使用的信息，我们可以在布局尺寸发生变化时保留用户的状态。例如，我们可以提升 showMore 布尔值标志，以便在调整大小会导致布局在隐藏和显示说明之间切换时保留用户的状态：
@Composable
fun Card(
imageUrl: String,
title: String,
description: String
) {
var showMore by remember { mutableStateOf(false) }
BoxWithConstraints {
if (maxWidth < 400.dp) {
Column {
Image(imageUrl)
Title(title)
}
} else {
Row {
Column {
Title(title)
Description(
description = description,
showMore = showMore,
onShowMoreToggled = { newValue ->
showMore = newValue
}
)
}
Image(imageUrl)
}
}
}
}
了解详情
如需详细了解 Compose 中的自定义布局，请参阅下面列出的其他资源。
示例应用
- JetNews：展示了如何设计可调整其界面以充分利用可用空间的应用