本原创文章帖发布在华为开发者联盟社区，欢迎开发者前往访问评论交流，更多与该内容相关讨论，请点击原帖查看：

跨平台框架释放阔屏潜能：CPF-RN在Pura X Max阔折叠UI的适配实践-华为开发者话题 | 华为开发者联盟

折叠、悬停、分屏等多形态窗口给React Native应用带来了新的适配挑战。本文基于 CPF-RN结合华为Pura X Max折叠设备，讲解断点、栅格分栏、平行视界、悬停布局、避让区、交互归一、自适应弹窗等整套响应式适配实践。通过维护一套RN业务代码，即可适配折叠屏多种形态，避免重复开发，保障开合切换过程中页面状态连续不丢失。配套示例工程已在AtomGit开源。

 

前言

Pura X Max 采用折叠形态：合上是一块外屏，展开是一块内屏，两块屏幕规格各异。对开发者来说，真正的变化在于：屏幕不再是固定尺寸，而是随形态伸缩的"弹性区间"，页面需从静态布局走向动态重组。

和直板机相比，折叠态的外屏更宽、更矮，展开后的内屏显示面积显著增大。折叠态系统默认不支持横竖屏旋转，展开态则跟随传感器自动旋转——应用需要针对不同的窗口尺寸与方向，做响应式的页面布局适配。

除折叠、展开两种基础形态之外，设备还支持介于两者之间的悬停态——半开半合，可平稳放置于桌面，常用于视频通话、播放视频等免手持场景，此时需要对折痕区域避让，并对上下两个界面重新布局。开合之间，应用还需要守住用户操作和页面状态的连续性，不能出现一折叠，页面就"断片"的问题。

图 1 ｜ 基于 RNOH 的自适应页面在不同屏幕尺寸下的表现

对RN开发者而言，现实挑战十分明确：窗口一会儿小一会儿大，页面跟着重排的代价有多大？手头的JS业务代码，哪些能直接跑在新形态上，哪些需要改造？

CPF-RN支持将React Native应用直接运行在HarmonyOS平台。借助TurboModule与Fabric，折叠状态、窗口避让区、系统手势等原生系统能力被桥接至JavaScript层，为RN应用提供断点、栅格、分栏、折叠状态识别、安全避让、多输入交互归一等开箱即用组件。开发者仅需维护一套业务代码，即可跟随折叠、分屏、悬停等窗口形态的变化，自动完成页面布局重组。

一、折叠屏成了 RN 应用的新考题

折叠形态正加速进入主流设备序列，RN 应用集中适配的窗口期也正在到来。开发者需要面对的不止 Pura X Max 一台设备：折叠、展开、分屏、悬停，这些窗口形态会轮番出现，页面需要在每一种形态下都体验合格。

以Pura X Max为例，它的两块屏幕规格就和直板机、平板都不一样：折叠态外屏宽高比 10:14，分辨率 1264×1848（459×672 vp）；展开后内屏宽高比 14:10，分辨率 1828×2584（664×939 vp），显示面积接近平板。同一套页面，需要在两块规格迥异的屏幕之间无缝切换。

图 2 ｜ Pura X Max 的折叠态、悬停态与展开态

上述还只是设备侧的硬件标称参数。真正动手适配才发现，从页面结构到交互细节都要重新过一遍：

• 布局要重排：首页、主 Tab、频道页这些页面，信息放多密、区块怎么分、栏数怎么增减，都得按窗口形态重新盘一遍；存量页面也要补充各种形态下的回归测试。

• 导航要重新约定：小屏中整页跳转的交互，在大屏上变为区域内的内容替换；路由怎么走、状态怎么还、返回手势管到哪一层，全部需要重新定义。

• 三态切换要接得住：折叠、展开、悬停轮换时，页面分区要跟着形态迁移，开合的瞬间用户的操作和状态不能断。

• 避让规则更复杂：折痕、挖孔、状态栏、手势条，以及多窗口下的窗口三键和装饰栏，其位置随形态、窗口模式和横竖屏动态变化。

• 交互与场景组件要联动：手势、按键、鼠标的响应要保持一致的手感；弹窗类组件，也需要跟着窗口形态切换呈现方式。

• 开发成本随形态成倍增长：若按形态逐个实现适配，窗口形态越多，开发和维护投入越难收敛。

适配的合格线有两条：开合切换的瞬间，用户的操作不失效；展开后的大屏也不能只是"拉大的手机"，而要装得下更密集的信息、更顺手的操作。上面这些难题，下文的适配实践会逐一给出对应的解法。

二、CPF-RN 的多设备布局解法

React Native 前端本身并不缺自适应的底子：Flexbox 弹性布局让容器随窗口伸缩，useWindowDimensions 把尺寸变化实时交给页面，百分比与相对布局天然适配不同宽度。直板机时代，处理横竖屏切换、不同屏幅与安全区，这一层能力基本够用。

进入折叠屏时代，仅"跟得上尺寸"已不够：窗口在折叠、展开、分屏、悬停之间轮换，分栏怎么切、三态怎么迁移、避让区怎么跟、返回手势管到哪一层，都需要"懂形态"的组件支撑。

CPF-RN 的做法是：通过 TurboModule 与 Fabric，把 HarmonyOS 的窗口尺寸、折叠状态、避让区等系统能力汇进共享 JS 层，在 React Native 固有能力之上补齐一层响应式组件——断点、栅格、分栏、折叠三态、避让、交互归一与弹窗。因此，适配不再是"为每个形态写一版页面"，而是"写一套会随信号变化的页面"。

图 3 ｜ React Native 固有自适应能力与 RNOH 响应式组件的总体架构

先看最常见的场景效果：同一套页面，折叠时按单栏呈现；展开后屏幕变宽，信息密度、栏数与避让自动跟上，不需要为展开态单独编写版本。

图 4 ｜ 同一套页面在折叠态与展开态下的表现

相比按形态逐个写适配的"抄一遍、测一遍"，把规则收拢到组件层，局面就反过来了：断点与栏数共用同一套分档，用户的选择和页面层级交给 JS 状态管理，导航只声明"进入详情""返回上一级"等业务意图，避让统一交给接口，手势、按键与鼠标的响应多端一致——规则写一遍，每个形态自动套用，适配做完一次就是终点。核心逻辑跨形态复用，为折叠与展开打磨的能力，同样适用于平板、分屏、小窗乃至 PC 多窗口场景。

三、CPF-RN 的多设备适配实践

折叠屏并非CPF-RN 布局能力后补的模块——立项之初，多形态就是设计前提。设备侧的窗口尺寸、折叠状态与避让区变化，经 CPF-RN 汇入共享层，页面随之刷新，折叠、展开、分屏、悬停均能平滑承接。仅仅把画面摆对还不够：路由、避让、交互也接进了同一条响应链路，形态切换时，操作照样跟手、不断档。

接下来我们从实际开发落地角度，依次介绍断点、栅格分栏布局、形态感知导航、折叠三态与悬停适配、避让区处理、多输入交互归一、自适应弹窗七大核心场景的实践方案。

3.1 断点：让页面"感知"形态变化

断点是多设备适配的第一块基石。RN 的 Dimensions 只返回像素尺寸，而多设备设计通常以断点描述页面形态——CPF-RN 生态提供了与系统一致的横向、纵向断点，并支持按业务自定义。

业务通过断点 Hook 为不同断点声明不同取值：列表列数、内容取舍、图片尺寸等都随窗口变化自动切换，不必再手写尺寸判断。展开态全屏（竖屏）处于横向 md / 纵向 lg 断点，折叠态外屏（竖屏）处于横向 sm / 纵向 lg 断点，分屏与悬浮窗下的断点分布同样有明确预期，页面在每个形态下的结构因此可控。

图 5 ｜ 断点驱动：折叠态单栏 ↔ 展开态多栏

这套断点能力与 CPF-RN 深度协同：在 OpenHarmony 上，断点划分与系统断点语义保持一致；无论设备处于折叠、展开、分屏还是悬停形态，业务面对的都是同一组断点 Hook——一套规则，多形态生效。

3.2 布局：栅格与分栏

在断点之上，典型布局场景都有现成解法：列表、瀑布流、轮播等重复布局结合断点控制列数与间距；插图与文字组合、底部与侧边导航等挪移布局通过栅格组件完成断点间的位置迁移；单列列表等缩进布局按断点调整留白。

分栏布局由两个开箱即用的组件承担。侧边栏组件支持嵌入、覆盖与自动三种显示模式，可拖拽调节宽度并在空间不足时自动收起；自适应分栏组件提供单栏、双栏与自动模式——自动模式下窗口宽度达到阈值即切换双栏，导航栏宽度、内容区最小宽度、显示状态回调均可配置。

图 6 ｜ 栅格在不同断点下的表现

3.3 导航：跳转方式随形态切换

手机上的跳转，一页换一页；大屏上，列表和详情往往同屏共存——点一下条目，换的只是右边那一块。页面上写的还是"进详情""往回退"这类意图；至于开新页还是换区域，由当前窗口形态决定。折叠展开的过程中，路由栈与选中状态由数据驱动，用户的任务链路不断。

对存量应用，CPF-RN 另有一条低成本路径——平行视界：写一份配置打开分栏开关、指定左栏主页，再用 导航库 @react-native-ohos/native-stack 组织页面——每个 Screen 都是独立的原生页面容器，直接复用系统的分栏能力，应用即可在宽屏、折叠屏设备上分栏显示。左侧固定为主页，路由跳转只发生在右侧；右栏内部的连续跳转也只影响右栏栈，左栏切换分类时替换右栏内容，避免用户从新分类返回时看到旧分类的详情页。

图 7 ｜ 平行视界：左栏主页、右栏详情

平行视界的配置足够简单：一份随应用打包的 JSON 配置，经 Metro 虚拟模块映射后即可被 JS 层直接读取。分栏开关分别对应折叠屏展开态（短边 480–700vp）与平板宽屏（短边 700vp 以上）两类窗口；homePage 指定左栏主页，需与路由名称完全一致（区分大小写）；fullScreenPages 声明跳转后退出分栏的页面（如视频播放、图片查看）；此外还可按需开启虚拟容器、主动横屏全屏等行为。若分栏未生效，可依次排查开关是否打开、窗口短边是否达到阈值、homePage 与路由名是否一致；修改配置后需清除 Metro 缓存，并确认配置已随应用包重新安装到设备。

3.4 折叠屏三态与悬停态

Pura X Max 有折叠态、悬停态、展开态三种状态。CPF-RN 将桥接来的 HarmonyOS 折叠屏能力封装为一组简单接口：判断设备是否可折叠、获取当前折叠状态、获取折痕区域、监听折叠状态变化——页面据此在形态切换时完成布局重组。

在此基础上，两个容器组件直接面向三态布局。分栏容器将页面声明为主要区域、次要区域与扩展区域，并为展开态、悬停态、折叠态分别配置分区比例与位置，组件随当前状态自动完成"折叠态上下分区 → 展开态左右分区"的形态迁移；悬停态容器面向免手持场景——上半屏播放视频、下半屏展示标题与控制条，支持自动进入半折叠形态、开合动画与状态回调，折痕避让由容器统一处理。

图 8 ｜ 悬停态：上半屏视频、下半屏控制区，折痕避让

3.5 避让区：该避开的，交给组件

Pura X Max 的避让区会随使用状态实时变化：窗口模式切换（全屏 / 分屏 / 悬浮窗）、窗口方向变化（横竖屏切换）、折叠状态切换（展开 / 折叠），都会引起避让区变化。

状态栏、导航条、挖孔、刘海、折痕，加上 PC 多窗口的三键与装饰栏——这些"不能挡"的地方，CPF-RN 都收进了同一套避让区接口：经 TurboModule 直读系统能力，要取就取、要监听就监听；安全区域容器则让子内容自动避开各形态下的避让区。布局写一次，各形态下都能正确避让。

图 9 ｜ 各形态下的避让区

3.6 交互：一套事件逻辑走到底

返回手势一划，退掉的该是整个页面，还是右栏里的上一层？列表拖拽、长按菜单，在折叠屏和直板机上的手感是否一致？

CPF-RN 用一套与社区手势库用法对齐的 API 解决这些问题：在 HarmonyOS 上，交互组件通过 Fabric 组件桥接系统手势，按键与鼠标事件同样被统一监听。点击、长按、拖拽及组合手势开箱即用，长按菜单等常用组件也被一并封装——业务只面对一套交互逻辑，各端行为天然一致。

图 10 ｜ 手势、按键、鼠标交互归一

3.7 场景化封装：弹窗

弹窗是受窗口形态影响最直观的场景：同一个操作，手机上从底部弹出最顺手，到了大屏再从底部弹出就显得局促。自适应弹窗组件让弹窗跟着形态走——小屏从底部弹出，窗口变宽后自动切换为侧边或居中样式，也支持全屏弹出；拖拽关闭、高度档位、自定义头部与动画参数开箱即用。业务只需准备弹窗内容，呈现成什么形态，全部交给组件。

图 11 ｜ 弹窗随窗口形态自动切换

四、写在最后

折叠屏给跨端开发出了一道新题：以前跨端回答的是"代码能不能到处跑"，现在还要回答"界面跟不跟得上变化"——屏幕在变、窗口在变、操作方式也在变。

从 CPF-RN 多设备适配的实践看，效果已经可见：折叠时用户看到的是一页，展开后自动变成多栏，中间不丢状态；写页面的人自始至终维护的是同一份逻辑；断点、栅格、分栏、避让、交互这些能力，做一次、反复用。核心体验放在共享 JS 层，各平台原生增强的空间也留了出来。

展望未来，硬件还将持续演进——新的屏幕形态和交互方式还会不断出现。届时，跨端能力的意义就不只是节省人力：面对新硬件，谁能先把体验做上去，靠的正是这套沉淀下来的响应式能力。

屏幕能折，体验不断。

五、关于 rn_multidevice_layout_scenepkg

完整的场景示例代码已在Atomgit开源，开发者可以登录Atomgit页面搜索“CPF-RN/rn_multidevice_layout_scenepkg”关键词了解详情。仓库包含断点、自适应布局、折叠屏、平行视界、避让区、多输入交互、弹窗等全套Demo示例，开发者可直接参考示例快速接入上述适配能力：

• 仓库地址：CPF-RN/rn_multidevice_layout_scenepkg - AtomGit

• 组件库清单：

@hadss/react_native_breakpoints（断点能力）

@hadss/react_native_adaptive_layout（布局与折叠屏组件）@hadss/react-native-adaptive-sheet（自适应弹窗）

@hadss/react_native_avoid_area（避让区）

@hadss/react_native_uni_input（交互归一）

@hadss/react_native_adaptive_video（短视频自适应布局）

• Sample 工程：

adaptive_layout_sample、parallel_sample、foldable_sample、avoid_area_sample、uni_input_sample、waterflow_sample、multidevice_sample