折叠过程中相机预览黑屏三秒：HarmonyOS 7 会话中断与恢复顺序

先看问题是怎么发生的

设备折叠时同时触发窗口尺寸、显示方向和相机可用性变化，三个回调各自调用重建。旧会话尚未释放，新会话又申请相机，最终预览黑屏或卡住数秒。简单延迟 500ms 只是在某台设备上碰巧工作。

验证边界：本文依据文末华为开发者官方资料整理，并用可执行 TypeScript 状态模型验证应用侧分支。当前本机为 API 24 且未连接 HarmonyOS 7 真机，文中的 API 26 代码属于接入骨架，不声称已完成 API 26 编译、真机性能测试或设备兼容认证。上线前仍需在目标 SDK 和真实设备上补齐接口、异常码、权限与性能证据。

根因和工程边界

恢复顺序应由单一协调器控制：标记旧 generation 失效，停止向旧 Surface 写帧，等待目标窗口和显示信息稳定，再基于最新快照创建一次会话。迟到的旧回调只释放旧资源，不能覆盖新状态。超时和失败要落到可重试页面。

案例一：展开时三类回调乱序到达

每次回调只更新最新快照并触发合并调度。调度器读取最终窗口、方向和 cameraId，一次性重建；旧 generation 的 onConfigured 被忽略。

案例二：恢复时相机暂时不可用

进入 recoverableError，保留用户所在页面和最后一帧占位。能力恢复后由用户或明确策略重试，不在后台无限循环申请资源。

可以独立运行的状态模型

class Generation{value=0;next(){return ++this.value}valid(v:number){return v===this.value}}
const g=new Generation();const old=g.next();const now=g.next();if(g.valid(old)||!g.valid(now))throw new Error('会话代际判断错误');

这个小模型只验证应用侧判断，不替代 HarmonyOS 7 真机和目标 SDK。接入平台接口时，应把调用放在模型确定的边界内，并把真实错误码、日志和用户可见结果补进验收记录。

为什么选择这条方案

固定延迟无法表达事件完成条件，容易在慢设备或多窗口下失效。代际与最终快照让任意回调顺序都收敛到最后一次配置。真正的 Camera Kit 调用仍应按官方 API 与目标设备验证。

上线前验证清单

验证项	通过标准
回调乱序：只创建一个最终会话	有可重复步骤、日志或可见结果
旧配置迟到：不能覆盖新预览	有可重复步骤、日志或可见结果
相机暂不可用：展示可重试状态	有可重复步骤、日志或可见结果
页面退出：所有会话归属清楚	有可重复步骤、日志或可见结果
连续折叠三次：资源数不增长	有可重复步骤、日志或可见结果

官方资料与证据边界

1. Pura X折叠适配FAQ

2. Pura X Max典型场景

3. 2026年9月开发者月刊

可复用结论

先把输入、所有者、生命周期和失败回退写成状态，再接入平台能力。这样出现异常时可以回答“哪一步失败、谁负责释放、用户还能做什么”，而不是靠重复调用掩盖问题。