折叠屏展开以后，应用得到更多宽度，但不一定得到更多高度；电脑窗口也可能比手机横屏更窄。适配《拼棋派对》时，先看当前内容区域，再决定导航、棋盘和工具怎样分配空间，比只按设备名称放大控件更可靠。
本篇接着面对面布局，分析窗口尺寸、设备类型与状态保留。代码对应1.0.19；折叠演示来自本系列API26模拟器取证，电脑演示采用此前R14适配阶段的模拟器记录，分别标明范围。
本文目录
测量应用实际内容区域
主页面给根组件设置onAreaChange，更新viewportWidth和viewportHeight。这里测量的是组件可用区域，布局计算不直接采用显示器物理像素。
typescript
.onAreaChange((oldArea, newArea) => {
this.viewportWidth = this.areaNumber(newArea.width);
this.viewportHeight = this.areaNumber(newArea.height);
})电脑标题栏、系统区域、导航和内边距都会减少玩法空间。外层窗口足够大，并不等于棋盘区域也一样大。项目后续通过duelContentWidth等函数扣除导航与边距，玩法需要继续扣除自己的标题、状态和工具。
面积变化事件可能连续触发。计算函数应从当前状态推导，不在测量回调里重新创建棋局或写入本地记录。否则拖动窗口会重复开局，甚至生成多条无意义战绩。
宽高与设备类型共同判断
当前布局函数有大屏、短横屏、桌面与座位偏好等条件。电脑的双人象棋与双人24点固定左右同向；移动设备面对面模式保留上下朝向。设备类型决定操作场景，窗口尺寸决定空间组织。
例如侧边导航的出现会改变内容宽度，玩法网格列数也随布局变化。大屏目录可以多列，短横屏则优先把棋盘与工具分开。阈值属于当前产品的布局选择，不是所有鸿蒙应用通用的标准断点。
| 输入条件 | 需要解决的问题 |
|---|---|
| 当前宽度 | 横向能放几列、工具是否并排 |
| 当前高度 | 棋盘、状态和按钮能否完整显示 |
| 设备类型 | 触摸、鼠标与键盘的主要使用方式 |
| 座位偏好 | 双方同向还是面对面阅读 |
| 导航占用 | 玩法实际可用宽度还剩多少 |
不要把其中一个条件替代所有条件。大屏设备的小窗口仍需要紧凑布局，手机的展开窗口也仍然属于手机设备类型。
布局重排不重新开局
棋盘数组、题号、双方分数与当前选择保存在页面状态中，Builder根据窗口条件选择排列。重排改变的是组件结构，不能把初始化函数放在每次布局判断里执行。
双人24点的面板事件始终携带player，B在上方或右方都调用B的逻辑。象棋共用一份90点数组，窗口变化不会改变棋子索引。这样视图可以调整，玩法状态仍有稳定身份。
检查状态保留时应选一个有变化的局面：走过一步棋、合并过一张牌或已获得一分，再改变窗口。只观察初始棋盘，即使发生了隐蔽重置也很难发现。
本系列第20篇在单屏、双屏、三屏间保留了双人24点第3/6题与A1:B1比分。这证明当时状态保留正常，但不等于各形态操作区都完整。
默认窗口和最大化对照
下面是此前电脑模拟器R14阶段的双人24点窗口效果。双方区域同向，默认窗口和最大化中都需要给牌面、表达式与工具保留位置。
这组素材用于解释已经做过的窗口适配，不是本轮重新启动电脑模拟器的验收。当前源码继续沿用同向策略，仍需在产品修改后重新安装相同构建包验证。
折叠形态对照则来自本系列本轮手机模拟器：
对照同一页面比对照不同玩法更容易发现问题：题目与按钮相同，只改变窗口，才能看清哪些空间被重新分配、哪些工具离开可见区域。
从裁切问题反推高度预算
本轮双屏形态中，A区底部的撤销、清空和提交被裁切。修复顺序应是先计算总可用高度，扣除中央栏和两方工具最小高度，再分配牌面与表达式，最后调整间距。
不能只按宽度给牌设置尺寸：宽度增长会让内容越来越高，两个面板叠放时尤其明显。也不应先把字缩到难读，PC正文和控件文字至少满足项目10fp下限，触摸设备还需保持可点范围。
建议把验收表拆成两列：状态保留与布局可用。前者检查数组、分数、题号，后者检查裁切、重叠、文字和按钮。此次双屏是前者通过、后者有缺口，文章如实保留这个结果。
源码入口：pages/Index.ets 的根区域测量、useDuelSideBySide、useDuelCompactVertical 与各玩法尺寸函数。参考HarmonyOS多设备适配示例。下一篇继续处理电脑输入与焦点恢复。