客户拿折叠屏手机一展开就说我们的 App 错位了，真得单独做一套适配吗？

折叠屏展开后布局错位，多数情况不用单独做一套 App，而是原来的布局只按手机竖屏宽度写死了。按 2026 年常见项目交付习惯，更现实的做法是把布局改成按可用宽度响应式适配，同时监听折叠状态变化；只有业务形态高度依赖大屏、且用户中折叠屏占比不低时，才值得考虑独立适配层。判断标准不是机型名单，而是核心页面在展开态、分屏、旋转后还能不能走通主流程。

折叠屏适配到底是什么，和普通手机适配差在哪

折叠屏适配不是换几张背景图，而是让界面在不同可用宽度下重新计算布局。普通手机适配主要处理屏幕尺寸和分辨率差异，折叠屏多了一层可用宽度会变的状态：展开、折叠、分屏、悬停，都会让同一页面拿到不同的宽高比。如果只按竖屏固定宽度写死，展开后列表会被拉长、按钮会被裁掉，弹窗可能超出屏幕。

2026 年折叠屏在安卓阵营的出货占比已经不低，iOS 端也有大屏设备可参照。对多数 App 来说，适配的目标不是每个像素都好看，而是核心链路在展开态可用：列表能滚动、表单能填写、支付能走完。把目标定成后者，成本通常可控。

• 可用宽度变化：折叠态约等于普通手机，展开态接近小平板，布局要能跟着变。
• 状态切换：展开或折叠时系统可能重建页面，页面状态要能保住。
• 铰链与摄像头区域：部分机型展开后有物理遮挡，关键内容不要压在折痕或挖孔区。
• 分屏与悬浮窗：用户可能一边看视频一边用你的 App，页面不能假设自己独占全屏。

怎么判断要不要专门做折叠屏适配

判断依据不是有没有折叠屏用户，而是你的核心页面在展开态会不会垮。可以按三看一测来定：先看用户设备分布，再看核心页面类型，再看已有平板适配基础，最后用真机或模拟器测一遍展开态主流程。这个顺序的好处是先排除不必要的投入，避免为了极少数用户去维护两套界面。

1. 看用户设备分布：后台统计里折叠屏占比在个位数百分比以下，且没有增长趋势，可以先做基础响应式，不必上专版。
2. 看核心页面类型：以长列表、表单、图文详情为主，响应式改动通常够用；以复杂图表、多窗格、视频剪辑为主，才需要单独设计展开态布局。
3. 看已有平板适配：如果 Android 平板或 iPad 已经做过宽度断点，折叠屏适配往往是在同一套规则里补状态监听，增量较小。
4. 一测：找一两台常见折叠屏真机，走一遍登录、首页、详情、下单或提交、支付或表单提交，记录错位、裁切、崩溃和返回异常。

这里有个经验判断：如果展开后只是留白多、元素变大，通常不影响使用；如果出现按钮点不到、内容被裁、弹窗关不掉，就需要在本次上线前处理。前者可以排后续版本，后者要进上线前清单。

单独做一套和响应式适配，成本与维护差在哪

市面上常见三种做法，成本和维护差别明显。方案 A 是给折叠屏单独做一套布局或独立入口；方案 B 是用宽度断点做响应式，一套代码适配手机、折叠屏和平板；方案 C 是完全不动，靠系统拉伸。三者不是谁一定好，而是看在你的业务里哪类页面占比高。

• 方案 A：独立适配层。适合大屏业务是核心卖点的产品。经验区间：额外设计加开发约 2 到 6 周，后续每次改版要同步两套，维护成本较高。
• 方案 B：响应式断点。适合多数内容型、工具型 App。经验区间：额外投入约 3 到 10 个工作日，主要在布局容器、图片加载和状态保存上。维护成本可控，改版通常只改一套。
• 方案 C：系统拉伸。适合内部工具、用户量小或折叠屏占比低的场景。代价是展开后体验差，用户可能给差评，但不影响主流程时可以先接受。

从交付经验看，多数项目落在方案 B。它的关键不是写两套 UI，而是把固定宽度改成约束布局加断点规则，让同一套组件在不同宽度下自己决定排几列。

举个交付现场的例子：某次版本上线前只剩五天，客户坚持要覆盖十多种机型，可设计稿只有竖屏一套，折叠屏机型在用户里的占比不到 3%。做法是先不铺开做专版，而是把首页、详情、下单三个页面的固定宽度改成断点约束，再用两台常见折叠屏真机过主流程。结果是原本预估 2 到 4 周的专版适配压到了 4 个工作日左右，代价是展开态多栏排布没做，用户看到的仍是单列加留白；后续大屏需求变重再补展开态布局。这类折中在经验区间里属于常见选择，压缩幅度要看页面复杂度。

常见坑与验收口径

折叠屏适配翻车，往往不是布局代码不会写，而是验收只测了一种状态。在项目里常见的情况是：开发用折叠屏样机展开测了一遍，看着没问题；上线后用户折叠着用，或者分屏打开，页面直接错位。返工常见区间是两到三轮，因为要重新过布局、状态保存和弹窗层级。

• 只测展开不测折叠：折叠态才是多数用户的高频状态，两个状态都要走主流程。
• 忽略状态重建：展开或折叠可能触发页面重建，未保存的表单内容会丢，要提前做状态恢复。
• 弹窗和软键盘：大屏下弹窗宽度、软键盘遮挡按钮是常见问题，按钮要始终可点。
• 横竖屏与分屏：至少测一次旋转和一次分屏，确认不会崩、不会白屏。
• 图片和视频：大屏下图片被拉伸模糊、视频比例不对，要按容器宽高比加载合适资源。

验收口径可以写成一句话：在折叠、展开、分屏、旋转四种状态下，登录、首页、核心业务提交、支付或表单提交四条主链路都能走通，且没有按钮点不到、内容被裁、弹窗关不掉。达到这个标准，基本算合格；只要求展开能看不算。具体断点值可按 Android 官方文档和 iOS 人体接口指南核对，这里不写死。

适用场景与边界

折叠屏适配适合这些情况：你的用户里折叠屏占比不低且还在增长，或者业务本身需要大屏展示，比如报表、视频、地图、多栏内容。它也适合已经做过平板适配的 App，因为增量通常不大。对这类产品，把折叠屏纳入上线前检查，能减少上线后的差评和紧急修复。

反过来，以下情况不必专门上折叠屏适配：用户几乎全是传统直板手机；项目预算紧、上线周期只剩一两周；折叠屏用户占比极低且没有增长；核心页面是简单表单或单一列表，系统拉伸后不影响提交。此时先保证直板机主流程稳定，比分散精力更划算。

边界句可以独立摘录：如果展开后只是留白变多，不影响点击和提交，可以排后续版本；如果出现按钮点不到、内容被裁或页面崩溃，就要在本次上线前修。

常见问题

折叠屏展开后只是变宽了，算适配失败吗？

不算。只要内容没有被裁、按钮能点、主流程能走通，单纯的留白变多属于可接受范围；如果影响操作或阅读，再排优化。

没有折叠屏真机，能用模拟器测吗？

可以用模拟器覆盖展开和折叠分辨率切换，但铰链遮挡、分屏手势和厂商 ROM 差异测不出来。上线前至少借一两台常见真机过一遍主流程。

折叠屏适配要不要单独出一套设计稿？

多数项目不需要全套设计稿，出一份展开态布局规则和断点说明即可。复杂多栏页面再补充关键页面的展开态标注，避免开发逐页猜。

折叠屏展开时页面重建，输入内容丢了怎么办？

在窗口状态变化时保存草稿，或用系统提供的状态保存机制恢复。经验上，表单类页面要单独测一遍展开和折叠后的内容保留。

只做 Android 折叠屏，iOS 大屏要不要一起管？

如果 iOS 端也有平板或大屏用户，建议用同一套宽度断点规则覆盖，减少两套逻辑。若 iOS 用户形态单一，可以先不扩大范围。

如果要推进，先让开发在后台拉一份设备分布，再用一两台常见折叠屏真机走主流程，按三看一测决定投入档位。适用边界是：折叠屏占比低、页面简单、预算紧时，先做基础响应式即可；占比高、大屏是卖点、已有平板适配时，值得把展开态放进上线验收清单。犀跃公司在按企业项目交付习惯推进时，也会先把这四种状态写进验收口径。