折叠屏适配：从市场趋势到技术破局

作者：姚广东 （汽车之家：App 架构团队）

一、折叠屏适配：为何成为互联网行业必答题？

（一）市场爆发：折叠屏从 “小众尝鲜” 到 “大众选择”

近年来，中国折叠屏手机市场呈现高速增长态势。曾经仅在专卖店陈列的折叠屏设备，如今已全面下沉至大众市场，用户群体覆盖商务人士、年轻人士等多个群体。折叠屏不再是小众科技产品，逐渐变成主流终端形态之一。

（二）适配价值：技术与体验的双重刚需

从行业技术来看，做好折叠屏适配，能帮助应用提升跨终端兼容性与通用适配能力，为后续拓展多终端场景打下基础；从用户体验角度来看，折叠屏的特殊屏幕形态（如展开、折叠、分屏等）若缺乏适配，会直接导致界面错乱、影响美观甚至影响使用，而优质的适配效果能显著提升用户留存率与品牌口碑，从而提升产品竞争力。

（三）本文核心：为开发者提供适配思路

在这里，我们将为技术人员提供架构层面的适配技巧与避坑方案，此外，非技术人员也能理解折叠屏适配的必要性与关键方向，助力团队协同推进适配工作。请注意，下面只谈左右折叠与三折叠设备的适配，上下折叠设备因适配问题较少，暂不讨论。还有，交互设计上的动态适配技巧也不在此讨论。

二、先懂 “屏”：折叠屏的屏幕形态与适配范围

要做好适配，首先要明确折叠屏的典型屏幕形态，以汽车之家 App 为例，折叠屏常见的屏幕状态可分为以下几类，不同状态下界面展示逻辑差异显著：

屏幕状态	核心特征
主屏展开	屏幕尺寸较大，适合展示更多内容
折叠副屏	屏幕尺寸与普通直屏手机接近
主屏横屏	屏幕横向显示，屏幕物理形状有些是正方形，有些是长方形
应用内分屏	同一应用内以 Activity 为单位分左右窗口，支持左右双焦点
应用外分屏	不同应用分屏显示（左右或上下），应用宽度可调整
悬浮窗	应用以小窗口形式悬浮于其他界面之上，窗口大小动态变化

这些状态并非独立存在，用户在使用过程中会频繁切换（如从 “主屏展开” 切换为 “应用内分屏”），适配的核心目的就是保证无论状态如何变化，应用界面都能正常展示和操作。

三、适配难关：三大核心难点与解题思路

折叠屏适配的难点，其实是 “软硬件差异导致的兼容性问题”—— 不同厂商系统标准不一、安卓版本碎片化、甚至同一品牌不同型号的适配逻辑都存在差异。以下从 “基础数据校准” 到 “复杂场景适配”，来拆解三大核心难点及应对方案。

（一）基础关：校准屏幕宽度 —— 适配的 “第一块基石”

大型应用中，除了动态布局外，还有很多界面元素的宽度和屏幕宽度相关，因此屏幕宽度是界面布局的重要依据（如 “宽度够不够显示双列内容”），但众多因素会导致应用无法准确获取宽度数据，这是所有适配工作的最基本难题。

1. 两大典型问题：数据延迟与 “假旋转”

   问题 1：宽度变化有延迟

   当用户进行折叠、分屏、切换悬浮窗等操作时，应用通常会通过系统的 onConfigurationChanged 回调函数时机，来触发界面元素调整（比如元素宽度、比例等）。但在部分厂商的设备上，屏幕宽度的更新会 “慢于” 这个回调函数时机 —— 简单说就是 “系统通知应用‘屏幕变了’，但没给新的宽度数据”，导致应用仍用旧宽度渲染界面，出现布局错乱。

   问题 2：“假旋转” 导致宽高不变

   部分折叠屏设备存在 “系统强制横屏，但应用感知不到” 的情况：比如 App 在普通手机上为固定竖屏模式，但在折叠屏设备上，当用户旋转设备后，系统会强制将屏幕转为横屏状态，但应用获取的 “屏幕方向” 仍为竖屏（portrait），宽高也是竖屏的宽高。此时，任何系统 API 均无法获取正确的屏幕宽高与方向信息，比如：

   context.getResources().getDisplayMetrics();
   Resources.getSystem().getDisplayMetrics();
   context.getWindowManager().getDefaultDisplay().getMetrics(outMetrics);
   WindowManager.getCurrentWindowMetrics();
   context.getResources().getConfiguration().orientation;
   getWindowManager().getDefaultDisplay().getRotation();
   

   这相当于应用被 “蒙在鼓里”，界面自然无法正常适配。据实践统计，约半数厂商的双折叠设备存在此问题，三折叠设备暂未发现类似情况。

2. 解题方案：二次触发 + 根布局宽度

   针对上述问题，无需复杂的技术重构，关键在于 “绕过系统差异”：

   应对 “配置变化有延迟”：

   二次触发回调方案：在系统 onConfigurationChanged 回调后，通过延迟二次触发该回调（例如延迟 100ms 可以适配绝大多数设备），此过程涉及递归调用，需谨慎处理。

   应对 “假旋转”：

   结合延迟调用的同时，通过获取根布局宽度替代系统 API 获取宽度。需避坑：getCurrentWindowMetrics().getBounds().width() 在部分机型上兼容性差，建议使用 getDecorView().getWidth()，该方法兼容性好，可以准确获取真实布局宽度。

（二）进阶关：适配分屏功能 —— 从 “单窗口” 到 “多窗口” 的跨越

分屏是折叠屏的核心优势（如 “边看帖子边看评论”），但也是适配的重灾区。分屏分为 “应用内分屏”（同一应用分窗）和 “应用外分屏”（不同应用分窗），其中应用内分屏因涉及系统级能力，适配难度最高。

1. 先搞懂：分屏方案的 “两大阵营” 当前行业内应用内分屏方案主要有两种：国内厂商主导的 EasyGo 和谷歌推出的 AE，不同厂商对两种方案的兼容策略差异大，直接影响适配策略：

   小米、oppo、三星：不再支持 EasyGo，强制要求 App 用 AE（仅兼容历史适配过 EasyGo 的老 App）；部分低版本设备双方案并存时优先 EasyGo，高版本则优先 AE。

   华为、vivo、荣耀：优先支持 EasyGo 方案。 若要覆盖六大主流厂商的折叠屏设备，必须同时兼容两种方案，这是适配分屏的前提。

2. 方案对比：EasyGo 与 AE 的核心差异 两种方案均支持 “购物模式”（如左列表右详情）和 “导航模式”（如左菜单右内容），但在灵活度上存在明显区别，非技术人员可重点关注 “功能支持范围”，技术人员需针对性处理差异点：

   功能场景	EasyGo 方案	AE 方案	对适配的影响
   简单购物模式	支持	支持	-
   简单导航模式	支持	支持	-
   任意页面开启购物模式	支持	不支持	AE 方案需要穷举需要购物模式的 “页面对” 配置，不支持 * 号匹配任意页面的方式
   隐式 Intent 调用	支持	不支持	AE 方案需将隐式 Intent 转为显式 Intent，否则无法触发分屏
   分屏页面动态切换全屏	支持	不支持	AE 方案要求 “启动新页面” 实现全屏，复杂场景（如视频续播）需额外处理逻辑
   购物模式透明主题	不支持	支持	EasyGo 不支持，可能是由于系统无法区分页面的透过情况，为了避免透明主题的页面被分屏后透出黑底的问题。AE 方案确实有此问题，部分透明主题的页面需要修改主题来适配

   总体来看，EasyGo 方案更灵活，AE 方案需在 App 层面做更多兼容处理，才能保证不同厂商设备上的体验一致性。

3. 关键问题：H5/RN 页面如何适配分屏？

   很多应用包含 H5（网页）和 RN（React Native）页面，这些页面通常共用独立的 Activity 容器，需确保其分屏能力与原生页面一致（如部分 H5 页面需显示在左半屏（PrimaryPage），部分 RN 页面不参与分屏（FullPage））。 解决方案通俗来说就是 “换壳”：通过定义 Activity 容器的子类（分别对应 “左半屏”“全屏” 等场景），再结合全局路由拦截 —— 当打开 H5/RN 页面时，根据页面路由匹配对应的容器子类，或者说页面内容不变，换了能支持分屏配置的不同的壳子，最终实现分屏行为的细粒度控制。

4. 分屏衍生问题：这些 “小坑” 需避开 分屏会打破传统 “单窗口” 的应用逻辑，引发一系列新问题，需结合业务场景针对性解决：

   1. 双页面同时 “前台运行”：分屏后左右页面对用户都可见，通常是只有一个界面有焦点，但也有设备是同时处于活跃状态（resumed）的，导致 PV 上报冲突（同一用户同时上报两个页面的访问量）、视频播放紊乱（两个视频同时播放）等问题，分屏的目的之一就是要做到 “边看边播”，不能简单的强制关掉双焦点的特性，要站在用户的角度，处理好这个问题。
   2. 双页面同时可见，只有一个页面有焦点：分屏后失去焦点的页面，仍然对用户可见，要避免执行 WebView 的 onPause，否则 H5 页面无法执行 JS 刷新宽度。
   3. 栈顶 Activity 判定异常：通常 APP 有自己的 Activity 堆栈管理，有些业务场景存在判断 “栈顶 Activity” 触发业务逻辑的情况（如登录弹窗），分屏时 “栈顶 Activity” 的判断会出现异常，需重新调整业务逻辑（如 “优先响应用户当前操作的页面”）。
   4. 系统回调不完整：部分设备在屏幕解锁时，仅触发 Activity 的 onConfigurationChanged 回调，而不触发 android.content.ComponentCallbacks 接口的同名方法，可采用其他手段监听配置变化（比如监听 View.OnLayoutChangeListener），补全回调逻辑。
   5. UA 字段缺失：部分折叠屏展开时，H5 页面获取的 UA 信息缺失 “Mobile” 标识，导致依赖 UA 判断的功能（如企业微信跳转）异常，需手动补充 UA 标识。（系统主动缺失 “Mobile” 标识，可能是认为大屏时，让 H5 像 PC 一样展示更合适？）

（三）高阶关：横屏适配 —— 从 “手机逻辑” 到 “多设备逻辑”

横屏是折叠屏的常见使用场景，但不同设备（PAD、三折叠屏）的横屏逻辑差异大，需结合设备特性定制方案。

1. PAD 横屏适配：从 “自研方案” 到 “兼容系统”

早在 2018 年，汽车之家就完成了 PAD 设备的横屏适配，通过自研 PAD 适配框架，对 App 内所有页面的横屏效果，统一执行左右留白策略，避免横屏铺满时图片、组件拉伸失真，影响观感。作为过渡方案，同时支持部分页面自定义 “横屏铺满”，为后续标准化布局留有余地。

但近年来，部分新型平板新增 “系统级横屏留白” 功能，与 App 自研的留白策略冲突（表现为留白间距叠加、系统兼容性问题引发界面抖动）。解决方案是 “针对性停用”：通过识别设备型号，对支持系统留白的平板，关闭 App 自研的留白功能，优先使用系统策略。

2. 三折叠横屏适配：融合三种设备的适配逻辑

三折叠设备是适配难度最高的形态，需同时兼容手机、折叠屏、PAD 的适配逻辑： 当三折屏全展开时，系统默认启用 “三屏分屏模式”，App 横屏后系统会自动对左右区域做高斯模糊处理，避免内容过度分散；

当关闭 “三屏分屏” 功能时，自动切换为汽车之家 PAD 适配方案，页面左右呈现留白效果，保证与 PAD 端体验一致。

从硬件特性看，三折叠也属于折叠屏设备，但汽车之家的 PAD 适配方案在普通折叠屏上默认不生效，要做到三折全展开时，当作 PAD 处理，技术关键是 “动态识别屏幕状态”：通过判断 screenLayout 是否大于 Configuration.SCREENLAYOUT_SIZE_LARGE，识别三折全展开状态，触发 PAD 适配样式；当设备切换为双折状态时，自动禁用 PAD 样式，回归折叠屏适配逻辑。

四、通用适配原则：让方案更具扩展性

无论是技术还是非技术人员，都可参考以下原则，提升适配效率与兼容性，避免 “重复踩坑”：

（一）用 “屏幕宽度断点” 替代 “状态判断”

不要根据屏幕状态去适配，比如折叠起来要怎样显示，展开后要怎样显示，分屏后要怎样…… 原因在于各厂商缺乏统一的状态 API，且现有状态 API 存在系统版本碎片化问题，无法兼容低版本设备。 核心策略是按屏幕宽度断点：业务只需判断当前屏幕宽度是否达到预设断点，即可自动选择布局方式（比如动态选择单列流、多列流、左右分栏（如左直播右评论）等布局方式），无论屏幕处于何种状态，都能适配。以汽车之家的断点规范为例：

1. 单屏布局：屏幕宽度＜580dp（如折叠副屏、小悬浮窗）
2. 双屏布局：屏幕宽度＞580dp（如主屏展开、应用内分屏）
3. 三屏布局：屏幕宽度＞900dp（如三折叠全展开）
4. 多屏布局：屏幕宽度＞1500dp（如连接外部大屏）

（二）分批次迭代：避免 “一刀切” 上线

大型 App 的各模块由不同业务团队负责，分屏适配需求、排期节奏差异大，若强制 “所有模块同时上线适配”，易导致体验不一致或 Bug 集中爆发。

我们要从用户体验出发，统筹协调各业务排期，基于 “厂商兼容效果” 和 “最小化用户影响”，分批次上线适配方案 —— 先覆盖适配效果较好的厂商，再逐步拓展至其他厂商，后续通过持续迭代优化细节。

五、总结与行业期望

（一）适配核心：直面差异，灵活兼容

说了很多，本质是 “应对软硬件差异的解决方案”—— 从校准屏幕宽度的基础工作，到分屏、横屏的复杂场景，核心思路都是 “绕过不兼容点，找到通用逻辑”。声明一点，本文旨在总结折叠屏适配经验，无意对各厂商产品优劣进行评价，且厂商排序无先后之分。

（二）对行业的期望：统一标准，降低成本

当前折叠屏适配的最大痛点是 “厂商标准不统一”，希望后续厂商能在分屏功能上进一步优化，例如分屏场景下，希望支持指定页面的展示位置（Primary/Secondary）跟随唤起源页面（如半透明弹窗），减少应用的兼容成本。

（三）未来趋势：适配问题终将逐步解决

随着折叠屏市场的持续成熟，以及厂商对开发者生态的重视，相信当前的适配难题会逐步得到解决。对于互联网行业从业者而言，提前布局折叠屏适配，不仅能提升当前用户体验，更能为后续多终端场景（如折叠屏平板、可穿戴设备）积累技术与经验，抢占市场先机。