013 Compose 屏幕适配与多尺寸通用方案

今天我想和大家聊聊一个在 Compose 开发中绕不开的话题：屏幕适配。你是不是也曾想过，难道要为手机、小平板、大平板、电视每个尺寸都重写一套页面吗？在我最近的项目 D:\dazhao\androidStudio\FirstComposeApp 里，我新增了一个 AdaptiveLayoutActivity.kt 来探索这个问题。下面我就结合这个例子，分享一下我的实战经验和更通用的解决方案。

1. 先说结论

我的答案是：绝对不能为每个尺寸单独写一套 UI。那样做不仅工作量巨大，后期维护更是一场噩梦。

经过实践，我发现更通用、也更可维护的做法是：

1. 把所有设备归为少量“宽度桶位”：根据屏幕宽度，而不是具体型号，来决定布局。
2. 复用同一份数据模型：业务数据是统一的。
3. 复用同一套业务组件：按钮、卡片、列表项这些“零件”是通用的。
4. 只在最外层切换页面骨架：变化的只是如何排列这些“零件”。

简单来说，变化的不是“所有UI”，而是页面的“骨架”：
- 手机：单列骨架
- 小平板：两栏骨架
- 大平板：三段式骨架
- 电视：居中大留白骨架

而下面这些东西，在所有尺寸下都可以继续复用：
- 列表项
- 详情卡片
- 业务状态
- 事件回调
- 数据结构

2. 项目里的实际案例

为了验证这个想法，我在项目里新增了 AdaptiveLayoutActivity.kt。你可以在 MainActivity 的菜单里找到“多尺寸自适应示例”来体验。

这个示例的核心思想不是做“4套独立的页面”，而是：
- 使用同一份 demoSections() 数据。
- 使用同一组组件，比如 SectionRail(), TaskListCard(), TaskDetailCard() 等。
- 然后，根据当前屏幕的宽度，动态切换到4种不同的页面骨架：
- PhoneAdaptiveLayout()
- SmallTabletAdaptiveLayout()
- LargeTabletAdaptiveLayout()
- TvAdaptiveLayout()

3. 这就是更通用的方案：宽度桶位

在示例中，我定义了一个“宽度桶位”枚举，这是整个方案的核心：

private enum class AdaptiveWindowBucket(
    val minWidth: Dp,
    val title: String,
    val description: String
) {
    PHONE(0.dp, "手机", "单列滚动布局，内容纵向排列"),
    SMALL_TABLET(600.dp, "小平板", "左侧导航 + 右侧内容，两栏布局"),
    LARGE_TABLET(840.dp, "大平板", "导航 + 列表 + 详情，三段式布局"),
    TV(1200.dp, "电视/超大屏", "内容居中、留白更大、交互目标更宽松")
}

这背后的核心思想非常朴素：设备型号千千万，但合理的布局模式就那么几种。所以我们真正要区分的不是“设备”，而是“布局等级”。

4. 为什么这比“每个尺寸一套UI”更合理？

想象一下，如果你真的按设备去写：
- 360dp 手机一套
- 411dp 手机一套
- 600dp 平板一套
- ……

很快你就会发现自己在维护几十个几乎相同的页面，任何业务逻辑的改动都要同步N遍，这简直是开发者的噩梦。

而“桶位方案”只需要回答一个问题：当前屏幕宽度，应该用哪种骨架来排列内容？ 一旦骨架选定，里面所有的内容组件都是复用的，业务逻辑也完全一致。这种清晰的分层让代码的可维护性大大提升。

5. 项目示例里到底复用了什么？

5.1 数据复用

示例里的 LearningSection 和 LearningTask 数据模型，在所有尺寸下都是同一份。这意味着：
- 业务数据源是唯一的。
- 状态管理（比如选中项）也是唯一的。
- 你永远不需要因为切换了布局，而去复制或同步业务逻辑。

5.2 组件复用

TaskListCard(), TaskDetailCard() 这些展示内容的组件，我没有为任何尺寸单独重写。它们在手机、平板、电视里被直接调用。变化的仅仅是外层容器如何摆放它们：是上下堆叠，还是左右并排，或是三段式分布。

5.3 状态复用

整个页面只有一份核心状态：selectedSectionIndex 和 selectedTaskIndex。无论是在紧凑的手机屏幕上，还是在宽阔的电视屏幕上，你操作的都是同一份状态。我认为，保持状态的单一性，是构建可维护自适应UI的关键。

6. 适配时真正应该分层思考

我建议大家以后可以按三层来理解 Compose 的适配策略，这样思路会清晰很多：

第 1 层：业务数据层

• 数据模型 (Data Model)
• UI 状态 (UI State)
• 事件回调 (Event Callbacks)
  这一层与设备尺寸完全无关，是纯粹的商业逻辑。

第 2 层：可复用内容组件层

• 卡片 (Card)
• 列表项 (ListItem)
• 表单块 (FormBlock)
• 详情块 (DetailBlock)
  这一层是构建UI的“乐高积木”，它们本身通常是自适应的（比如使用 fillMaxWidth），因此也不需要为每个尺寸单独编写。

第 3 层：页面骨架层

这一层才是根据屏幕宽度动态切换的：
- 单列骨架 (Single Column)
- 双列骨架 (Two Pane)
- 三列骨架 (Three Pane)
- 居中大屏骨架 (Centered for TV)
真正因屏幕变化而改变的，往往只有这最外层的骨架布局。

7. 示例里4档布局分别适合什么场景？

手机 (<600dp)

• 适合纵向单列滚动，使用 LazyColumn。
• 核心是让内容完整、清晰地展示，不要试图在狭小空间内硬塞并列信息。

小平板 (600dp ~ 839dp)

• 适合两栏布局。
• 通常是左边导航栏，右边内容详情区。
• 开始利用宽度优势，提升信息密度。

大平板 (840dp ~ 1199dp)

• 适合三段式布局。
• 经典模式：左边分类导航，中间列表，右边详情预览。
• 充分利用宽度，一屏内展示更多上下文信息，减少页面跳转。

电视/超大屏 (>=1200dp)

• 核心不是铺满，而是控制。
• 一定要用 widthIn(max = xxx.dp) 限制内容最大宽度，避免元素被拉伸得面目全非。
• 设计上需要更大的留白、更大的点击区域、更清晰的视觉层级，以适应远距离观看和遥控器操作。

8. 这类方案为什么比 XML 时代更舒服？

不得不说，Compose 做这种动态布局切换真是太顺手了。因为你可以在 Kotlin 代码里直接响应尺寸变化。看看示例里的核心代码，多么简洁：

BoxWithConstraints(modifier = Modifier.fillMaxSize()) {
    val windowBucket = remember(maxWidth) { classifyWindow(maxWidth) }

    when (windowBucket) {
        AdaptiveWindowBucket.PHONE -> PhoneAdaptiveLayout(...)
        AdaptiveWindowBucket.SMALL_TABLET -> SmallTabletAdaptiveLayout(...)
        AdaptiveWindowBucket.LARGE_TABLET -> LargeTabletAdaptiveLayout(...)
        AdaptiveWindowBucket.TV -> TvAdaptiveLayout(...)
    }
}

这种写法的优势很明显：
- 逻辑集中：尺寸判断和布局选择写在一起，一目了然。
- 告别繁琐：不需要创建一堆 layout-sw600dp, layout-sw840dp 这样的XML目录。
- 灵活直观：页面之间的切换关系完全由代码逻辑控制，非常灵活。

9. 真正通用的适配策略是什么？

根据我的经验，我建议大家优先采用下面这套策略：

策略 1：先用流式布局解决 80% 的问题

优先使用 Compose 内置的弹性布局能力：
- fillMaxWidth(), weight()
- widthIn(), heightIn()
- padding(), aspectRatio()
- LazyColumn, LazyRow 的自动换行或自适应

很多页面仅仅依靠这些，就足以在手机和平板之间良好适配了。

策略 2：只在必要时切换骨架

不要一开始就想着为所有尺寸做差异化设计。先让你的页面具备良好的“流式弹性”。然后通过测试，再判断是否真的需要从单列变为双列，或从双列变为三列。

策略 3：把断点控制在 3 到 4 档

在实际项目中，下面这套断点已经能覆盖绝大多数场景了：
- < 600dp：手机
- 600dp ~ 839dp：小平板（小两栏）
- 840dp ~ 1199dp：大平板（大三栏/详情并列）
- >= 1200dp：电视/超大屏（居中约束）

策略 4：大屏设计的核心是“约束”，而非“填充”

面对电视或超宽屏，最常见的问题不是“内容放不下”，而是“内容被拉得太宽，导致阅读体验糟糕”。所以，大屏设计的要点往往是：
- 将主要内容区域居中。
- 使用 widthIn(max = xxx.dp) 严格控制最大宽度。
- 主动增大留白和点击区域，提升可用性。

10. 什么时候才需要更明显的差异化布局？

并不是所有尺寸变化都需要切换骨架。只有在以下情况，才值得你去做更明显的布局切换：
- 导航形态发生根本变化：例如从手机底部的 BottomNavigation 变为平板的永久性侧边 Navigation Rail。
- 信息密度与组合方式变化：例如从手机上的垂直列表详情，变为平板上列表与详情的并排展示。
- 交互方式变化：例如在电视上，需要引入焦点导航和更大的交互热区。

如果仅仅是字体大小、间距或卡片宽度的微调，那属于“自适应”的范畴，完全可以通过 Modifier 参数化解决，不算“重写UI”。

11. 你应该怎么继续练习？

如果你觉得这个思路有用，我建议你基于这个示例继续做3个练习，巩固一下：

1. 丰富数据：给 AdaptiveLayoutActivity.kt 增加更真实的设置项数据，看看数据变化如何自动反映到所有布局中。
2. 改造真实页面：把项目里现有的 SettingsScreen 改造成一个“手机单列 / 平板双列”的真实设置页面。
3. 实践约束布局：给 LoginActivity 的登录表单加上 widthIn(max = 480.dp) 修饰符，亲自体验一下如何防止表单在大屏上被过度拉宽。

12. 一句话总结

经过这一番探索，我的结论是：更通用、更可维护的 Compose 适配方案，绝不是“给每个尺寸写一套UI”。

真正的策略是：用少量宽度断点决定页面骨架，同时复用同一份业务状态和同一套内容组件。

这样做，既能优雅覆盖从手机到电视的各种尺寸，又能让你的代码库保持简洁和可维护，彻底告别复制粘贴的地狱。