一、前言：阔折叠不是「再加一个尺寸」

先看几个真实的翻车现场。

现场一：首页书架被放大。原实现固定每行两本书，展开到内屏后，列槽没变，封面被等比放大成「巨幅海报」。一行只剩两本，整屏空旷，滑一下还到底了。

现场二：设置页不停返回。「我的」页面用了HdsNavigation，但被强制设成NavigationMode.Stack。展开后本来该左右分栏，结果还是要反复进入详情、再点返回，体验反而比手机更累。

现场三：开合就丢状态。折叠 → 展开时，页面因为布局重建触发了重新请求网络，滚动位置清零，正在编辑的内容没了。

现场四：按机型写死的分支失效。团队写了一长串if 折叠屏的判断，结果横屏的普通手机、分屏、自由窗口拖拽，全都没覆盖到。

根因其实只有一个：

这些代码都在试图「识别设备」，而响应式的本质是「响应窗口约束」。机型识别只对第一台设备有效；窗口约束变化才是折叠屏、横竖屏、多窗口共享的统一模型。

本文要讲的，就是把适配从「机型枚举」迁移到「容器约束」的完整方法。

二、阔折叠到底改变了什么

2.1 Pura X Max 的形态

以 HUAWEI Pura X Max 为例，它是典型的阔折叠形态：

• 外屏5.4 英寸，1848 × 1264 像素；

• 内屏7.7 英寸，2584 × 1828 像素；

• 支持折叠态、展开态、悬停态；

• 外屏比普通直板机更宽、更短；内屏展开后进入大屏布局范围。

关键点在于：这两个屏的「宽」和「短」组合，是普通手机和平板都给不了的。普通手机的竖屏窄、横屏高；平板的大屏接近正方形比例。而阔折叠外屏是一个宽短屏——竖向空间紧张，横向空间宽裕。

2.2 这意味着什么

把这三件事放在一起，就理解了适配的真正难点：

也就是说，你没法用一个固定布局覆盖所有情况。唯一稳定的事实是：窗口可用宽度会变，页面要能跟着连续重排。

这就是为什么「按机型写 if」注定失败——同一台设备的同一种形态，只要进入多窗口或自由拖拽，宽度就是任意值。机型识别在这里完全失灵。

三、核心理念：别识别机型，去测容器

整篇文章最重要的一节。响应式适配的正确心智：

3.1 布局只依赖实际可用容器

• 优先测量页面或业务区域的容器宽高，不读取物理屏幕尺寸决定布局；

• 不写Pura X Max、折叠屏、手机、平板等机型分支；

• 不用横竖屏枚举（orientation）代替宽度判断——横屏、分屏、自由窗口可能得到相同方向、不同宽度；

• 页面嵌在Navigation、Tabs、分栏或弹窗中时，以业务组件最终拿到的空间为准。

为什么强调「业务组件最终拿到的空间」？因为你的页面可能只占窗口的一部分。比如它在一个 Split 右栏里，你读物理屏宽 = 整个屏，但实际可用宽度只是右栏那一份。读物理尺寸必然算错。

3.2 标准用法：onAreaChange + 跨断点才更新

推荐在 ArkUI 根业务容器上使用onAreaChange：

@State private layoutMode: number = 0; private updateLayout(widthVp: number): void { const nextMode: number = resolveLayoutMode(widthVp); if (nextMode !== this.layoutMode) { this.layoutMode = nextMode; } } build() { Column() { // 页面内容 } .width('100%') .height('100%') .onAreaChange((_oldArea: Area, newArea: Area) => { this.updateLayout(Number(newArea.width)); }) }

两个关键纪律：

1. 只在跨越断点时更新状态，避免每次细微尺寸变化都触发无意义重绘；

2. 只保存轻量派生值（列数、布局模式等），不把原始宽高长期存成状态，除非绘制确实需要连续数值。

3.3 折叠状态什么时候才读

普通页面重排不需要监听FoldStatus。只有以下硬件能力差异场景才该读取折叠/悬停状态：

• 相机来源、位置、方向或可用性变化；

• 悬停态专属的上下分区交互；

• 双屏协同、背屏预览等硬件能力；

• 无法由窗口约束表达的设备功能。

即便用了折叠状态，视觉布局仍应优先由当前窗口约束决定。折叠状态管的是「硬件能力」，不是「列数怎么排」。

一句话记住分工：窗口约束管布局，折叠状态管硬件能力，方向枚举谁都不该单独管布局。

四、真实案例一：首页书架（重复布局连续重排）

4.1 问题

首页书架是这个 App 第一个适配的页面。原实现固定每行两本，展开后列槽和封面被过度放大，整屏空旷。

4.2 策略

这类「重复卡片」页面，宽屏的常用策略是增加列数、保持卡片合理尺寸，而不是把固定列数等比放大。最终方案按书架容器的实际宽度动态显示 2 / 3 / 4 列：

4.3 把布局计算提成纯函数

「宽度 → 列数」这种纯计算，要从组件里剥离出来，提成纯函数：

export function resolveColumnCount(widthVp: number): number { if (widthVp >= 600) { return 4; } if (widthVp >= 480) { return 3; } return 2; }

纯函数的好处：

• 可测试：断点边界、极端宽度、0 或非法值都能覆盖；

• 可复用：同类页面共享一致的语义断点；

• 不污染 UI：组件不堆积判断逻辑。

4.4 实现连续重排时的纪律

• 保留原有 Repository、Scroller、NavPathStack和业务状态对象；

• 只改变布局派生值（列数），不在尺寸回调里调用加载、保存或路由；

• 重复项使用稳定 key；重分组后仍保持业务顺序；

• 不满一行时补等宽空槽，或用合适的 Grid 对齐策略；

• 大集合使用 Grid/List 的懒加载，避免一次构建全部子节点。

这次适配验证了一个可复用结论：

折叠屏适配的主问题是窗口约束变化，不是识别设备型号。书架的 2/3/4 列完全由容器宽度驱动，没有任何机型判断，因此横屏、分屏、自由窗口、未来新形态全都自动适配。

五、真实案例二：我的（列表 + 详情分栏）

这是更复杂的一类页面，也是踩坑最密集的场景。

5.1 问题

「我的」页面原本用HdsNavigation，但被强制设成NavigationMode.Stack。展开后仍需反复进入详情和返回。这类「设置类列表 + 详情」页面，宽屏的正确策略是中大宽度时分栏。

5.2 别手写双栏，复用官方导航容器

不要在HdsNavigation外面再手写一套 Row 双栏，也不需要为普通列表详情场景引入FoldSplitContainer。直接复用官方导航容器的自适应能力：

写法很简单——优先用HdsNavigation.mode(NavigationMode.Auto)，再通过navBarWidthRange、minContentWidth表达左右区域的最小舒适宽度，让系统自己决定 Stack/Split：

不要在组件外再手写一套 Row 双栏，也不需要为普通列表详情场景引入FoldSplitContainer。

5.3 导航语义：Push vs Replace，这是分栏的灵魂

很多人以为「分栏就是左右两栏」，于是照搬单栏的 Push 逻辑。结果：在 Split 模式下点左侧每个条目都 Push 进右栏，点五次右栏叠了五层，返回键在历史菜单项之间倒退——这是分栏最常见的翻车。

正确的导航语义：

还有一条容易被忽略：底部一级 TabBar 的显隐，必须由 Navigation 的实际 Stack/Split 模式决定，不能只依赖NavDestination.onShown/onHidden。因为分栏详情仍属于一级页，应保留 TabBar；只有单栏全屏详情才隐藏。只监听 onShown/onHidden 会在分栏替换详情时闪烁或错误隐藏一级导航。

onNavigationModeChange返回的是系统根据最终容器约束解析出的实际模式，适合用于默认详情、选中态和外层导航显隐的联动。但布局断点本身继续交给HdsNavigation.Auto，避免同时维护两套 600vp 判断。

口诀：单栏 Push 留栈，分栏 Replace 换内容；分栏详情还是一级页，TabBar 不能只看 onShown/onHidden。

5.4 侧栏信息密度：分栏左栏不是手机的等比缩窄

这是一个非常关键的认知，也是视觉质感的分水岭。

Split 左栏不是把手机设置卡片等比缩窄，而是一个独立的信息密度档位：

为什么？因为左栏窄、要塞标题和尾部控件，还要保持选中态。如果照搬手机的全宽 Cell，标题、副标题、图标、尾部控件会严重争抢空间、互相截断。

左右宽度必须从真实内容反推

别直接拿系统常见的「240vp 左栏、360vp 详情」起手。真实运行时主标题、副标题、图标和尾部控件会严重争抢空间。这个项目的实际演进路径：

1. 起手用 240vp 左栏 + 360vp 详情 → 争抢严重；

2. 只去掉图标 → 仍不够；

3. 最终采用280–320vp 左栏 + 至少 320vp 详情，同时去掉 Split 的图标和副标题。

两侧最小宽度之和仍为 600vp，因此没有改变单栏/分栏的总体门槛。

系统默认分栏宽度只能作为起点，最终配比和侧栏密度必须通过真实内容与设备截图校准。

5.5 条目与尾部控件

• 只有真正拥有详情页的条目才切换右栏；

• 枚举设置用Select，并在尾部显示当前值；

• 布尔设置用真正的 Switch，状态由checked驱动，通过onCheckedChange持久化；

• 导入、导出等一次性命令保持原地执行；

• 不要用「状态文字 + 整行点击」模拟 Switch——语义不清，还容易和子控件事件重复触发。

六、三条不可妥协的强制原则

把前面散落的原则收拢成三条硬约束。

6.1 布局只依赖实际可用容器

• 测量业务容器宽高，不读物理屏；

• 不写机型分支；

• 不用 orientation 代替宽度判断；

• 嵌套场景以组件最终拿到的空间为准。

6.2 折叠状态只用于硬件能力差异

普通重排不读FoldStatus。只有相机、悬停分区、双屏协同等硬件能力才需要，且视觉布局仍以窗口约束为准。

6.3 开合必须保持任务连续

折叠、展开、旋转、窗口缩放只改变布局，绝不能：

• 重新请求网络或重读数据库；

• 重置滚动位置、选中项、输入内容、编辑状态；

• 清空导航栈或返回首页；

• 关闭当前弹层或打断进行中的操作；

• 因布局重建产生重复提交。

布局状态和业务状态必须分离。响应式状态只保存列数、布局模式等轻量派生值；业务对象、控制器在开合时应保持同一实例。

七、六步标准适配流程

把适配做成可重复的工程流程。

第一步：盘点固定假设

检查目标页面是否存在：

• 固定列数、固定宽高或按屏幕百分比无限拉伸；

• 只为窄手机设计的 Row/Column；

• 固定底部按钮导致短屏遮挡；

• 用设备类型、分辨率或 orientation 选布局；

• 全屏弹窗在宽屏上被不自然拉长；

• 旋转或开合时重新加载数据。

同时检查 Loading、空态、错误态、弹层和极端数据量，不只检查正常内容态——非正常态往往比正常态更容易溢出。

第二步：确定布局策略

根据内容特征选最小必要变化：

不要为了「利用大屏」而增加操作步骤或改变核心使用习惯。

第三步：设计断点

• 先用真实内容的最小舒适宽度推导断点，再参考系统常用断点；

• 断点必须用 vp，并集中为语义常量；

• 相邻模式要有明确职责，避免断点附近反复跳变；

• 同一页面的 Loading、内容态、占位态必须共用相同断点。

提醒：首页书架的 480/600vp 是书架场景的结论，不是全应用无条件复用的全局断点。其他页面按自身内容测算，但同类页面应复用一致语义。

第四步：提取纯布局计算

把「宽度 → 布局模式」「数据 → 行列分组」提成纯函数（见第四章）。纯函数便于覆盖断点边界、极端数据量和顺序稳定性。

第五步：实现连续重排

保留 Repository / Scroller / NavPathStack / 业务状态，只改布局派生值。详见第四章的纪律。

第六步：处理短屏与安全区

阔折叠外屏偏短，宽度适配通过 ≠ 页面可用：

• 主操作按钮必须可见，或能通过滚动到达；

• 键盘弹出后，输入框和确认操作不能被遮挡；

• 沉浸式页面继续遵守状态栏、导航区、挖孔避让；

• 悬浮 TabBar 上方保留足够滚动尾部空间；

• 不锁定方向，避免折叠设备出现兼容模式或黑边。

八、常见错误清单（对照自检）

把所有踩过的坑列成清单，写代码前先过一遍：

• ❌ 按型号写if PuraXMax—— 无法覆盖后续设备、横屏、多窗口。

• ❌ 直接读取物理屏幕宽度 —— 组件实际可能只拿到窗口或分栏的一部分。

• ❌ 只处理展开态 —— 外屏偏短同样可能遮挡操作。

• ❌ 宽屏仍固定两列并放大卡片 —— 浪费空间，破坏内容尺度。

• ❌ 宽屏无脑增加列数 —— 卡片可能过小，要从最小舒适宽度推导。

• ❌ 在尺寸回调中重新加载数据 —— 开合时产生闪烁、竞态、状态丢失。

• ❌ 只验证正常数据态 —— Loading、空态、键盘、弹窗更容易溢出。

• ❌ 只按 orientation 切布局 —— 分屏和自由窗口会产生错误判断。

• ❌ 为折叠屏锁定方向 —— 触发兼容显示、黑边、无法利用窗口。

• ❌ 分栏仍用 Push 堆叠每个左侧选择 —— 返回键会在历史菜单项间倒退。

• ❌ 只在onShown/onHidden隐藏 TabBar —— 分栏替换详情时容易闪烁或错误隐藏一级导航。

• ❌ 分栏没有默认详情或选中态 —— 右侧空白，左右缺对应关系。

• ❌ 侧栏复用手机全宽 Cell 且保留图标 —— 标题、副标题、尾部控件争抢狭窄宽度并截断。

• ❌ 只去掉侧栏图标但仍用 240vp + 双行文本 —— 释放空间不足以消除截断。

• ❌ 用状态文字或整行点击模拟布尔设置 —— 不符合 Switch 心智，还可能重复触发。

九、测试与验收矩阵

适配不能只靠肉眼，要有可执行的测试矩阵。

9.1 纯逻辑测试

每个断点至少测试：断点前 1vp、断点值、断点后 1vp、0 或非法宽度的安全默认值。

重复布局还要覆盖：0 / 1 / 刚好满行 / 满行+1、多个完整行与不完整末行、原顺序不变、key 稳定、Loading 槽位数与内容列数一致。

列表 + 详情还要覆盖：

• 空栈进入 Split 时只初始化一次默认详情；

• Stack 用 Push，Split 用 Replace；

• 左侧选中态与右侧详情始终一致；

• Stack 详情隐藏 TabBar，Split 详情保留 TabBar；

• 左栏最小宽度 + 详情最小宽度与分栏门槛一致。

9.2 页面状态

所有宽度档位至少验证：Loading、空态、错误与重试、正常数据、极少与较多数据、弹窗/菜单/输入/键盘、明色/深色、大字体或系统显示缩放。

9.3 窗口变化

• 普通手机竖屏与横屏；

• Pura X Max 折叠态；

• 折叠 → 展开 → 折叠；

• 展开态旋转；

• 悬停态；

• 多窗口或连续拖动窗口宽度；

• 变化过程中保持滚动、选中、输入和导航状态。

9.4 工程验证

至少执行构建，要求CompileArkTS、PackageHap和最终BUILD SUCCESSFUL：

DEVECO_SDK_HOME=/Applications/DevEco-Studio.app/Contents/sdk \ /Applications/DevEco-Studio.app/Contents/tools/hvigor/bin/hvigorw assembleHap --no-daemon

视觉与开合连续性必须在 Pura X Max 模拟器、云真机或实体机上补充验证——构建通过 ≠ 体验通过。

十、页面适配完成清单（可直接当 PR Checklist）

• 已检查当前页面全部状态（含 Loading / 空态 / 错误态）。

• 布局由业务容器宽度驱动，没有机型特判。

• 断点有内容尺度依据，并集中定义为语义常量。

• Loading、空态、错误态与正常态共用布局规则。

• 开合不重新加载数据，不丢失滚动、输入、选择和导航。

• 列表 + 详情分栏已定义默认详情、持续选中态及 Push/Replace 语义。

• Split 左栏已按真实内容验证宽度、图标、副标题、行高和尾部控件。

• 分栏与单栏下的一级导航、返回键行为分别正确。

• 短屏、键盘、安全区、悬浮导航均可操作。

• 断点和数据分组逻辑有单元测试。

• 普通手机与 Pura X Max 折叠/展开已回归。

• HAP 构建成功。

十一、写在最后

阔折叠响应式适配的分水岭，不在「会不会写onAreaChange」，而在有没有把心智从「识别设备」迁移到「响应约束」：

折叠屏适配的主问题是窗口约束变化，不是识别设备型号。
布局只依赖业务容器实际拿到的空间，不读物理屏、不写机型、不用 orientation 代替宽度。
重复布局增加列数，列表详情切分栏，分栏左栏是独立密度档位不是手机等比缩窄。
单栏 Push 留栈，分栏 Replace 换内容；分栏详情还是一级页，TabBar 不能只看 onShown/onHidden。
开合只改变布局——业务对象、控制器、滚动位置、编辑状态全程保持同一实例。
断点从真实内容的最小舒适宽度推导，提成纯函数，覆盖边界与极端值。
系统默认分栏宽度只是起点，最终配比和侧栏密度必须靠真实内容与设备截图校准。

记住这套方法的最简表达：窗口约束管布局，折叠状态管硬件能力，方向枚举谁都不该单独管布局。

一旦你接受了「不识别机型」这个前提，阔折叠就不再是「又一个要特判的设备」，而是「又一个窗口约束变化的场景」——它和横屏、分屏、自由窗口共享同一套适配逻辑。这套逻辑写一次，未来的新形态就自动覆盖了。这才是响应式适配真正省力的地方。

官方参考资料

• HUAWEI Pura X Max 规格参数

• Pura X Max 阔折叠手机应用开发

• HarmonyOS 设备兼容要求

• HarmonyOS 多设备设计与场景最佳实践

• HarmonyOS 窗口沉浸式开发

• HarmonyOS 应用 UX 体验标准概述

官方资料的共同要求可以归纳为：按窗口变化及时重排、展开态提高信息利用率、短屏保证关键操作可达、开合过程保持任务连续。

本文基于一个真实阅读类 App 的阔折叠适配工程指南整理，核心方法可复用于任何 HarmonyOS 响应式页面。若你正在做折叠屏、横屏或多窗口适配，可以直接按「六步流程 + 完成清单」起步，把布局从机型特判迁移到容器约束驱动。