Android 17 折叠屏与多窗口适配：视口尺寸和响应式测试清单

2026年6月19日 Screen Size Checker团队 4 分钟阅读

过去做 Android 屏幕适配，很多团队会选几台热门手机，把浏览器缩到一个竖屏宽度，然后就认为页面已经“响应式”了。

这个做法现在风险很高。Android 应用和网页已经不只运行在普通手机上，还会出现在平板、折叠屏、ChromeOS 窗口、桌面式自由缩放窗口、分屏模式以及外接显示器上。到了 Android 17，平台方向更加明确：布局要适配应用实际拿到的窗口空间，而不是适配设计阶段猜测的设备名称。

对 Web 团队、PWA 团队和混合应用团队来说，结论是一样的：屏幕不再是一个固定矩形。真正应该关注的问题不是“用户拿的是什么机型”，而是“当前可用的布局空间有多大、设备像素比（DPR）是多少、当前视口的宽高比是什么”。

这篇文章会把 Android 17 的大屏趋势、折叠屏/多窗口测试重点，以及屏幕尺寸检查器（Screen Size Checker）现有工具串成一个可执行的适配流程。

快速结论

准备 Android 17 适配时，不要只按设备名测试，要按视口尺寸测试。建议至少覆盖这些关键范围：

320-430 CSS 像素（CSS px）的紧凑手机宽度。
600-840 CSS px 的折叠屏主屏和平板竖屏宽度。
840-1199 CSS px 的平板横屏扩展宽度。
一个接近正方形的折叠屏场景，例如 720 x 720。
一个高度很紧的横屏场景，例如 844 x 390。
至少一个可以自由拖拽缩放的桌面式窗口。

实际设备上先用屏幕尺寸检查器（Screen Size Checker）记录视口尺寸、DPR、屏幕分辨率和宽高比，再把高风险尺寸复现在响应式测试器里做布局回归。

Android 17 为什么会改变测试基线

Google 的 Android 17 文档说明：对于以 Android 17（API 级别 37）或更高版本为目标的应用，在最小宽度大于 600dp 的显示区域上，方向、可调整大小和宽高比限制将不再生效。Android 17 还移除了 Android 16 中针对大屏限制的临时豁免选项。具体适用范围和例外以官方文档为准；这条规则直接约束的是原生 Android 应用的 target SDK/API 行为，Web、PWA 和 WebView 场景在这里更多是把它作为大屏和可调整窗口趋势的测试信号。

这件事很重要，因为不少旧的移动端布局其实依赖这些隐含假设：

应用永远是竖屏。
手机视口永远比较窄。
固定最大宽高比可以保护布局。
平板只是更大的手机。
折叠屏只有一种值得适配的视口。

这些假设在大屏和多窗口环境里都不稳。Android 的大屏指导正在把团队推向自适应布局：根据当前可用窗口尺寸调整界面，而不是根据“手机/平板”标签写死分支。它不只影响原生 Android 应用，也会影响 Web 应用、PWA、WebView、结算流程、账号后台、客服页面和在 Android 可调整窗口中打开的响应式网站。

如果你的页面在手机宽度切到平板宽度时会断层，或者横屏高度变紧时按钮、弹窗、底部栏会挤在一起，Android 17 会让这些问题更容易被用户遇到。

Android 17 折叠屏和多窗口为什么要按视口尺寸测试

现代 Android 设备可能呈现出多种差异很大的可用空间：

场景	变化点	为什么要测
竖屏手机	CSS 视口窄、DPR 高、纵向空间长	导航、吸底按钮和表单需要紧凑布局。
横屏手机	宽度增加，但高度明显变小	双列布局可能放得下，但弹窗、底部栏和媒体区容易拥挤。
折叠屏外屏	通常窄而高	文本密集页面、搜索栏和卡片可能比普通手机更吃紧。
折叠屏内屏	更宽，有时接近正方形	单列手机布局可能显得空、拉伸或信息密度过低。
平板竖屏	中等宽度，可读空间增加	侧边栏、详情面板和网格布局开始有价值。
平板横屏	扩展宽度	主从布局、多面板和数据表格通常应该进入可用状态。
分屏模式	应用只拿到物理屏幕的一部分	设备参数不够用，窗口尺寸才是真正输入。
桌面式窗口	宽高可以自由缩放	用户会拖出很多设备预设里没有的中间宽度。

这就是为什么 Android 的窗口尺寸类别关注的是“应用可用的显示区域”。相比“手机”或“平板”这类标签，紧凑（compact）、中等（medium）、扩展（expanded）、大（large）、超大（extra-large）这些宽度类别更接近真实布局决策，因为同一台设备会随着旋转、折叠、展开、分屏和拖拽窗口而切换类别。

选择响应式断点前，先测视口尺寸、DPR 和宽高比

做响应式 QA 时，下面这些数据比设备宣传页里的硬件参数更有用：

数据	含义	用途
屏幕分辨率	显示屏上的物理像素	用于判断硬件清晰度、图片素材密度和渲染质量。
视口尺寸	页面或应用界面实际可用的 CSS 像素区域	响应式 CSS、布局断点和组件重排的主要依据。
设备像素比（DPR）	一个 CSS 像素对应多少物理像素	解释为什么同为 1080px 的设备会对应不同的 CSS 视口宽度。
宽高比	宽度和高度的比例关系	用来发现媒体裁切、布局拉伸、面板比例异常等问题。
方向与窗口形态	竖屏、横屏，或由窗口尺寸决定的形状	暴露高度、导航、键盘、弹窗和媒体区的隐含假设。

常见误区是把屏幕分辨率当成断点来源。一个物理宽度 1440px 的屏幕，受 DPR、浏览器 UI、显示缩放和系统设置影响，实际视口可能只有 360-430 CSS px。折叠屏还会多一层复杂性：同一台设备的外屏和内屏可能分别落在完全不同的视口范围里。

正确顺序是先看视口行为，再用分辨率和 DPR 解释图片清晰度、Canvas 渲染和像素密度问题。

需要注意，Android 文档里的 600dp 是原生应用布局和平台限制语境中的阈值；本文建议的 600、840 等 CSS px 测试宽度用于 Web 响应式 QA。二者都在提醒团队关注可用空间，但不能简单当作一一等价的单位换算。

Android 折叠屏与多窗口视口尺寸测试矩阵

下面这个矩阵可以作为 Android 17 适配的基础测试清单。它不能替代真机测试，但能帮你避免只测一个普通 Android 手机宽度。

测试组	建议覆盖的宽度范围	重点检查
紧凑手机	320-374 CSS px	长文案、结算表单、导航溢出、固定宽度卡片。
常见 Android 手机	375-430 CSS px	默认移动端布局、触控目标、吸底操作区。
手机横屏	640-932 CSS px 宽度，并搭配紧凑高度	顶部栏高度、弹窗、媒体内容、底部面板、键盘遮挡。
折叠屏外屏	320-430 CSS px，并带较高宽高比	密集表单、文本换行、窄卡片、搜索框。
折叠屏内屏	600-840 CSS px，包含接近正方形的比例	空白区域、卡片拉伸、双栏/双面板切换阈值。
平板竖屏	600-839 CSS px	中等宽度布局、侧边导航、正文行长。
平板横屏	840-1199 CSS px	扩展布局、数据表格、主从详情页。
桌面式窗口	500-1600 CSS px，可自由拖拽	布局过渡、容器查询、表格横向溢出。
分屏模式	半屏宽度和三分之二宽度	物理屏幕很大但窗口变窄时，核心流程是否仍可完成。

如果只能选少量宽度，至少测试 360、390、412、600、768、840、1024，再加一个自由缩放的中间宽度，例如 540 或 720。高度要单独测，尤其是横屏和分屏场景。

用响应式测试器复现 Android 17 高风险尺寸

Screen Size Checker 现有工具已经覆盖了这套流程需要的关键环节。建议按下面顺序使用。

1. 先测真实设备

在要测试的 Android 设备或浏览器上打开屏幕尺寸检查器，记录：

视口尺寸
屏幕分辨率
设备像素比（DPR）
宽高比
浏览器和操作系统信息

这样拿到的是页面真正看到的数据，而不是设备宣传页上的标称分辨率。

2. 对照常见 Android 设备范围

使用 Android 视口尺寸表，对比 Pixel、Galaxy、折叠屏、小米、OPPO、vivo、荣耀等常见 Android 设备的参考尺寸。

看折叠屏时，重点关注外屏和主屏分别列出的条目。目标不是精确适配某一款机型，而是看清你的设计需要承受哪些宽度、DPR 和宽高比范围。

3. 用响应式测试器复现高风险尺寸

使用响应式测试器预览手机、平板、桌面和自定义视口。重点检查：

媒体查询是否在预期宽度触发
固定宽度组件是否溢出
卡片、表格、导航栏、抽屉和弹窗是否能正常重排
设计在“没有设备名称”的中间宽度下是否仍然可用

为了应对 Android 17，不要只停在手机预设。请额外添加 600px 和 840px 附近的自定义宽度，因为很多自适应布局会在这两个区域切换结构。

4. 测形状变化，不只测宽度变化

折叠屏和多窗口模式会产生不规则的窗口比例。页面里如果有视频、图表、仪表盘、商品图、相机预览或固定比例卡片，可以使用宽高比计算器辅助判断。

一个在 390 x 844 下看起来正常的布局，到了 720 x 720 或 840 x 600 时可能会暴露图片裁切、卡片拉伸、侧栏高度不足等问题。

5. 涉及视觉决策时，对比可用屏幕空间

当产品、设计和 QA 对“是否应该切到双栏布局”意见不一致时，可以使用屏幕尺寸对比工具比较物理尺寸和可用区域。

这样可以把“感觉像平板”变成更具体的讨论：宽度是多少、高度是多少、面积变化多大、比例是否适合双面板。

Android 17 适配前的 CSS 与 QA 检查清单

上线前可以用这份清单检查 Android 手机、折叠屏、平板和桌面式窗口中的核心流程：

同时测试 600 CSS px 以下和 600 CSS px 以上的布局。
至少测试一个 840 CSS px 或更宽的扩展布局。
手动拖拽窗口，不要只依赖设备预设。
竖屏和横屏分开测。
测一个高度很紧的场景，而不只是测窄宽度。
避免假设手机永远是竖屏。
避免用“是否平板”这类设备名逻辑决定布局，优先使用可用窗口尺寸。
使用流式网格、弹性间距和基于内容的断点。
可复用组件优先考虑容器查询，避免组件被放进窄面板时失控。
扩展布局里为长文本设置合理的 max-width，避免行长过长。
表格要在溢出前支持横向滚动、堆叠或减少列数。
在紧凑高度下检查弹窗、抽屉、吸底栏、Cookie 横幅和浮动按钮。
宽高比变化时，确认媒体、图表和预览区域不会被拉伸或裁切。
原生或混合应用要验证旋转、折叠、展开和窗口缩放后 UI 状态是否保留。

目标不是为每一台 Android 设备单独做一套设计，而是让组件能响应它实际拿到的空间。

一次轻量的 Android 17 适配回归

大多数团队可以用一轮 QA 完成下面这套快速检查：

在真实 Android 手机上打开页面，用屏幕尺寸检查器记录视口。
在响应式测试器中按 360、390、412、600、768、840、1024 CSS px 测核心流程。
增加一个接近正方形的折叠屏比例，例如 720 x 720。
增加一个高度紧凑的横屏比例，例如 844 x 390。
覆盖流程里的关键步骤：导航、搜索、表单填写、结算或提交、错误状态和成功确认。
对有争议的折叠屏或平板断点，用 Android 视口尺寸表交叉确认。
记录问题时写真实视口、DPR 和宽高比，不要只写设备名。

最后一步很关键。“Galaxy Fold 上坏了”不如“结算摘要在 692 x 717 CSS px、DPR 3 时重叠”有价值。后者能让设计师和开发者直接复现问题。

如果要快速开始，可以先打开响应式测试器，把上面的 360、390、412、600、768、840、1024、720 x 720 和 844 x 390 建成一组回归尺寸。

资料与延伸阅读

常见问题

Android 17 适配只和原生 Android 应用有关吗？

不是。Android 17 的平台行为直接影响原生应用，但同样的设备趋势也会影响 Web 应用、PWA、WebView，以及用户在 Android 平板、折叠屏和桌面式窗口中打开的响应式网站。只要你的 UI 依赖固定手机宽度的视口，就应该重新测试。

Android 折叠屏应该测试哪些视口尺寸？

外屏和展开后的主屏都要测。实践中建议覆盖 320-430 CSS px 的窄手机宽度、600-840 CSS px 的中等宽度、至少一个横屏高度紧凑场景，以及至少一个接近正方形的场景。然后再对照最新的 Android 视口尺寸表。

响应式设计更应该看屏幕分辨率还是视口尺寸？

布局适配通常优先看视口尺寸，因为 CSS 媒体查询和大多数网页布局决策都基于 CSS 像素。屏幕分辨率和 DPR 仍然重要，但主要用于图片清晰度、Canvas 渲染和密度适配。

没有每一台折叠屏设备，怎么测试 Android 多窗口？

先用支持自定义视口的响应式测试器覆盖关键宽度和高度，再在至少一台真实 Android 设备或模拟器上验证核心流程。多窗口测试的重点是改变应用可用窗口尺寸，而不是穷举所有设备名。

Android 17 多窗口适配要测试哪些尺寸？

建议至少测试 360、390、412、600、768、840、1024 CSS px，再加一个接近正方形的 720 x 720 和一个高度紧凑的 844 x 390。这样能覆盖常见手机、折叠屏主屏、平板竖屏、平板横屏、分屏和桌面式窗口的高风险断点。

需要为每一款折叠屏单独写布局吗？

通常不需要。更稳妥的做法是让组件根据可用宽度、高度和宽高比自适应。设备尺寸表用于理解真实取值范围，最终断点应围绕内容和任务流来设计，而不是围绕具体机型写分支。