更新时间：2026年10月09日

折叠屏 UI 适配不能只把手机稿拉宽。先按应用当前可用窗口决定单栏或多栏，再看折叠姿态与铰链是否影响内容，最后确认展开、折叠和分屏后选中对象、输入草稿及阅读位置都能延续。先掌握响应式设计的断点与多设备处理，再补折叠屏特有的姿态和任务连续性。

窗口尺寸和设备姿态，是两组判断

展开的设备也可能处在分屏窗口中，应用实际得到的空间并不宽；半折状态的屏幕则可能有水平或垂直的分隔关系。因此不能写成“检测到折叠屏就双栏”，也不能只按某一个机型的分辨率制作固定稿。

Android 官方折叠屏说明把折叠特征、铰链方向、遮挡及分隔关系作为布局依据。设计上可对应两步：先判断当前窗口容不容得下内容，再判断关键对象能不能跨越折叠或铰链区域。折痕不一定遮挡内容，双屏设备的铰链也不能当作一条普通网格线处理。

交付时给出布局切换的内容条件，而非只有设备名单。例如列表必须容得下工单编号、标题和状态，详情必须能够阅读正文与回复；两者无法同时满足时就退回单栏。具体断点由设计与研发在目标设备和实际内容上验证。

用同一张工单，画出单栏和双栏

案例任务是客服处理工单 TK-204：“设备连接失败”。窄窗口先显示工单列表，进入详情后看到问题描述、历史沟通与回复框；宽窗口左侧保留列表，右侧显示当前工单。展开带来的价值是少一次返回，而不是让详情页左右留白变多。

首次进入双栏且没有选中工单时，可以显示选择提示，不必自动打开列表第一项并制造“已阅读”的错觉。已经选中 TK-204 后再展开，则直接在右侧继续显示它，左侧同步标明选中对象。

把这几种布局放在同一 Pixso 文件中，列表项、详情头部和回复区使用一致组件；变化的是区域关系，不是每个尺寸重新设计一套控件。若文字尺寸和布局单位还不清楚，可结合Android UI 尺寸与适配补齐基础。

工单标题、金额、操作按钮不应被遮挡区域截断。垂直分隔适合让列表与详情各处一侧；如果一侧空间太窄，不必强行维持双栏。横向半折时，也不能机械地把页面从中间切开，上下部分应各自完成有意义的任务。

对于本例，若支持桌面姿态，可尝试上方展示工单内容、下方放回复编辑与发送操作；但要确认屏幕键盘出现后下方仍可用。客服需要对照上下文输入长回复时，也可能更适合回到可滚动详情。姿态提供机会，不代表每个姿态都必须新增专属模式。

铰链附近即使没有像素遮挡，也可能不适合放最频繁的操作。把“发送”“关闭工单”等关键按钮放在完整可触达区域，并检查握持和键盘变化后的相对位置，不用一张展开静态图代替所有条件。

用户在 TK-204 里输入了一半回复，此时折叠设备。合理的结果是继续看到同一工单和同一份未发送草稿，而不是跳回列表首页。需要明确保存的状态包括选中工单、筛选条件、列表滚动位置、详情阅读位置、回复文字及附件上传状态。

Android 的 UI 状态保存文档强调配置变化和进程重建后的状态恢复，尤其是输入与导航相关状态。设计交付要写清“恢复什么、回到哪里”；实现方案由研发按状态类型选择。不要把设计稿中的连线当作已经验证了运行时恢复。

导航也随布局关系变化：窄屏详情的返回键回到原筛选结果和滚动位置；双栏中关闭详情，是否保留列表选中态需要约定；折叠发生在弹窗打开时，是保留弹窗还是转为整页编辑，也应沿用户当前任务判断，不能默认丢弃输入。

只测试完全展开和完全折叠会漏掉真实操作。用户可能边看另一款应用边回复，或拖动分屏分隔条改变宽度。Android 多窗口文档说明应用窗口可以被重新调整；设计稿应允许布局根据可用区域变化，而非假设始终占满物理屏幕。

回复框获得焦点后，键盘不能遮住当前输入行与发送结果；详情内容仍需能滚动查看。图片附件预览、错误提示和底部操作区也要分别检查，不要让它们都争抢剩余高度。缩小窗口时，较次要的辅助信息可以收起，但当前任务不能消失。

用以下连续任务验收：在窄屏筛选“待处理”，滚动并打开 TK-204，输入未发送回复，展开设备进入双栏，再进入分屏缩窄窗口，最后返回列表。每次变化后核对当前工单、草稿、选中态和列表位置。

在 Pixso 原型旁注明每次转换应保留与可变化的内容，让研发据此做设备验证。另补一条包含加载失败或草稿保存失败的路径：布局适配不能掩盖数据问题。最终判断不是所有尺寸看起来相同，而是用户不必因为屏幕变化重新开始工作。