TL;DR：折叠状态变化会改变预览容器与相机流的契约，不能只靠缩放补救。本文梳理停止、重建、恢复和回归检查的边界；示例尚未在当前 SDK 或真机完成编译运行。

折叠展开后相机预览为什么会拉伸：重建预览流的边界【鸿蒙心迹】

> 适用场景：ArkUI 应用中的扫码、拍照、直播、视频通话或 OCR 预览，会经历折叠/展开、旋转、分屏或窗口大小改变；现象包括预览被拉伸、黑屏、画面停在旧帧、拍照后异常，或切换前后摄后恢复失败。

相机预览出问题时，最诱人的修复方式是改一个 width、height 或 objectFit。它有时能把画面看起来调回来，却常常在下一次形态切换后再次失效。原因是相机预览不是普通图片：UI 容器的尺寸、承载预览的 Surface、预览输出、会话配置、方向和镜头能力共同构成一条资源链。窗口已经变了，旧链路若仍按旧 Surface 和旧比例运行，拉伸、黑屏或冻结就并不意外。

本文把处理策略收敛成一个可审查的边界：UI 层只报告“展示约束已改变”，相机会话层决定是否需要有序释放并重建预览流，业务层负责保留用户任务。代码为架构伪代码与官方资料的静态对照，当前没有可编译 API 26 工程，未在已连接 API 26 真机或模拟器执行相机权限、Surface、预览流或拍照验证。 不同机型、镜头和 CameraKit 版本必须在目标环境补测。

先区分四件事：画面变形不一定是布局问题

一次折叠动作可能同时改变四类输入：第一，应用可用窗口的宽高；第二，预览容器最终的实际尺寸；第三，显示方向或旋转关系；第四，当前可用镜头、Surface 生命周期和会话状态。只盯着第一项很容易误判。比如窗口从竖屏比例变成近似横向比例，UI 虽然按新宽高摆好了 XComponent，但 Camera 仍向旧的预览输出推帧，画面会在新的容器里被填充、裁剪或停滞。

华为的大屏适配指南把扫码、拍照、直播、视频通话和 OCR 列为需要重点验证相机方向、预览比例、前后摄切换，以及窗口或屏幕方向变化后状态的场景。这不是额外的“机型兼容测试”，而是提醒我们：相机预览的正确性天然依赖形态和会话状态组合。一个普通直板机上的首次启动成功，不能推导出折叠、悬停、旋转和分屏也成功。

把“是否重建”从像素变化中解耦

不要在每一次 onAreaChange 中直接关闭并重启相机。预览容器可能因工具栏、键盘、动画或小幅分栏调整发生多次尺寸变化；无条件重建会造成频繁黑屏、相机占用竞争和用户操作中断。更可靠的模式是先收集一个预览约束快照，再由单一协调器判断新旧快照是否真正跨过需要重配的边界。

快照不一定要保存每个像素。它至少应明确：容器的有效宽高、期望显示方向、目标比例桶、当前镜头、预览 Surface 是否已就绪、用户是否正在拍摄/录像。把这些输入归一化后，协调器可以区分“小幅布局抖动”“形态切换”“镜头切换”“Surface 销毁重建”等不同事件。前者可能只更新 UI overlay，后者才进入相机会话重配。

下面的伪代码只表达职责，不能直接当作 CameraKit 可运行实现。真实接口、权限回调和资源释放顺序必须以项目所用 SDK 的官方 API 为准。

type PreviewConstraint = {
  width: number
  height: number
  ratioBucket: string
  rotation: number
  cameraId: string
  surfaceReady: boolean
}

class PreviewCoordinator {
  private applied?: PreviewConstraint
  private rebuilding: boolean = false

  async apply(next: PreviewConstraint) {
    if (!next.surfaceReady || this.rebuilding) return
    if (this.samePipelineConstraint(this.applied, next)) {
      return // 仅叠层或普通布局更新，不触碰相机会话。
    }
    this.rebuilding = true
    try {
      await this.stopPreviewSafely()
      await this.releaseOldOutputs()
      await this.createPreviewOutputFor(next)
      await this.configureSessionFor(next)
      await this.startPreview()
      this.applied = next
    } finally {
      this.rebuilding = false
    }
  }
}

这里的关键不在 async，而在两个约束。第一，旧会话、旧输出和旧 Surface 的释放必须有确定顺序；不要一边向旧输出推帧，一边让新容器等待。第二，任何失败都需要把协调器留在可恢复状态，例如明确为“未启动”，让下一次合法约束能重试；不能半释放后仍把 applied 写成新值。

Surface 生命周期要成为第一等输入

相机开发里常见的误区是把 Surface 当作一个永久字符串或永久句柄。官方 Camera FAQ 对双路预览的说明指出，图像流通过 Surface 传递：拍照流可以使用 ImageReceiver 的 Surface，预览流使用 XComponent 的 Surface，并通过该 Surface 创建预览输出。这说明 Surface 不是旁枝，它就是数据通道的一部分。若承载节点重新创建、销毁或尚未 ready，继续复用旧通道会让问题在不同设备上表现得非常随机。

因此，页面层应该向协调器明确报告 Surface ready/invalid，而不是仅报告“窗口变宽”。协调器在 Surface 无效时只保存待应用的约束，不启动预览；Surface 就绪后再检查这份待应用约束是否仍然最新。这样可避免形态切换中先收到尺寸变化、后收到节点创建的竞态，也避免旧异步回调把已经过期的会话又拉起来。

可把状态最少划为：IDLE、WAITING_SURFACE、CONFIGURING、RUNNING、RELEASING、ERROR_RECOVERABLE。不必追求复杂状态机，但任何相机操作都应知道自己属于哪一类。比如用户在配置中连续折叠两次，第二个约束不应并行发起第二次 configure，而是覆盖待处理快照，待第一次结束后只应用最新状态。

方向、比例和裁剪必须说清楚谁负责

预览“看着不对”至少可能有三种不同结果：画面被拉伸，意味着 x/y 缩放比例不同；画面完整但有留黑，意味着保持比例后容器有剩余空间；画面铺满但边缘被裁掉，意味着使用了裁剪填充。它们不是谁绝对正确，而是产品应该为扫码框、拍照取景、视频通话和 OCR 分别选择的策略。

扫码通常更在意识别区域和取景框对应关系，不能悄悄把识别坐标当成被拉伸后的显示坐标；拍照取景可能允许适量裁剪但要明确预览与最终照片比例的差异；视频通话更需要避免人脸被不自然压扁。若只是把 Surface 强制填满容器，三种任务都会在某些比例下出错。设计和代码审查时至少写清：输入帧比例是什么、显示区比例是什么、使用 fit 还是 crop、叠层坐标由哪一个坐标系计算。

官方关于相机旋转术语的资料也强调设备方向、镜头角度和屏幕显示角度是不同概念。实现中不应把“设备横过来了”直接当成“预览应旋转 90 度”。先确定平台输出、镜头传感器、界面显示分别提供什么信息，再由一个转换层产出叠层和拍照展示需要的方向。把这些换算散落在点击切换镜头、布局回调和拍照回调里，后续几乎无法调试。

折叠变化期间，优先保护用户任务

用户打开相机往往不是为了看一个自适应动画，而是为了扫一个码、拍一张照或完成认证。形态变化时，首要目标是避免重复触发拍摄、丢失已输入内容或让快门按钮处于假可用状态。重建期间可以短暂显示“正在调整预览”的非阻塞状态，但不要显示一块静止旧帧并允许用户点击快门；也不要因为切换会话就把用户已经选择的镜头、闪光设置或取景模式无声重置。

对录像和连续帧处理要额外谨慎。是否允许录制中折叠、是否应锁定方向、是否必须先停止录制，都是产品和能力边界问题，不能从拍照预览的实现自动推导。若缺少目标机型和正式 API 验证，最稳妥的做法是明确标记为待验证策略，提供安全退出或提示，而不是宣称会无缝恢复。

回归矩阵：组合比单次开相机更重要

| 场景 | 操作 | 预期观察点 |

| --- | --- | --- |

| 冷启动折叠态 | 授权后打开预览 | Surface 就绪后只启动一次，比例与取景框一致 |

| 预览中展开 | 保持预览再展开设备/窗口 | 不拉伸、不长期黑屏；最终只保留最新约束对应的会话 |

| 展开中折叠 | 连续快速改变形态 | 无并发重建风暴；旧回调不会复活旧输出 |

| 旋转或分屏 | 改变显示方向/可用区域 | 方向、叠层和触控坐标同源更新 |

| 切换镜头 | 在不同形态下前后摄切换 | 预览、快门和错误状态可恢复，不沿用不兼容参数 |

| 拍照/录像边界 | 重建前后触发操作 | 禁用或排队规则明确，无错误快门或资源泄露迹象 |

| 权限与后台 | 授权拒绝、切后台再回前台 | 协调器回到可恢复状态，界面说明清楚 |

回归记录应包含设备/窗口形态、系统版本、镜头、入口、是否已有相机占用，以及最终日志或用户可见结果。本文没有这些真实测量，所以上表是测试设计而不是已经通过的设备结果。

失败路径比成功路径更值得提前设计

相机资源有一个现实特点：它不是每次都按理想顺序可得。用户可能刚授予权限又切到后台，另一应用可能暂时占用摄像头，Surface 可能在会话配置之前销毁，镜头切换可能在形态变化期间发生。若实现只存在“成功后开始预览”这一条线，任何一个中断都会留下难以判断的半完成状态：按钮还亮着但没有帧、loading 永远不消失、下一次进入不再发起请求。

建议把错误拆为至少三种处理方式。可重试错误，例如短暂资源占用或 Surface 尚未就绪，应保留待应用约束并提供明确的重试入口；需要用户动作的错误，例如权限被拒绝，应说明为什么需要权限、如何前往设置或继续使用无相机路径；不可继续错误，例如当前设备缺少所需镜头能力，应退出预览模式并保留已填写的业务信息。无论哪一种，都不要把底层错误码直接堆给用户，也不要在无节制的定时器里反复创建会话。

协调器的 finally 同样要避免成为“吞掉错误”的地方。它只负责恢复内部的排他状态，例如结束 rebuilding 标记；失败状态、最新约束和用户可见提示仍需被明确记录。下一次窗口变化、权限恢复或点击重试时，代码才能根据真实状态决策，而不是猜测上一次操作走到了哪一步。

权限、前后台和导航返回应进入同一资源协议

很多预览问题表面发生在折叠时，实际是形态变化与前后台事件重叠造成的。比如用户展开设备后马上切换应用，UI 容器回到前台时尺寸已经稳定，但相机会话可能因后台释放而失效；若只监听宽高变化，就不会触发恢复。反过来，用户从详情页返回相机页时，原来的 Surface 可能已经不是原实例，盲目复用旧 session 又会埋下黑屏。

可以把页面生命周期转成协调器可以理解的事件：foreground 只表示“允许尝试恢复”，background 只表示“停止需要前台资源的预览或按产品策略挂起”，surfaceReady 表示“已有可用承载面”，userRequested 表示“用户仍需要相机任务”。当这些条件同时满足才开始或恢复预览。这样形态变化只是众多事件之一，不会被误当成唯一开关。

对于有导航栈的应用，返回规则也要明确：返回只是遮住相机页时是否继续占用摄像头？进入子页面编辑参数后回到相机页，是保留原预览还是重建？如果产品需要快速回到取景，缓存用户选择的镜头和模式是合理的；如果资源策略要求离开即释放，也应该让回到页面的恢复路径可见、可测。关键不是选哪一种，而是不要让生命周期行为依赖偶然的组件销毁顺序。

用最小复现把问题与业务代码隔离

当真实项目里出现拉伸或卡死，不要第一时间在完整业务页面里叠加日志和补丁。先做最小复现：一个显示 Surface 的容器，一个最小预览会话，一个可打印的约束快照，一组触发折叠/旋转/窗口变化的操作。最小复现的价值不是证明业务没有问题，而是帮助区分“平台行为、资源时序、UI 测量或业务状态竞争”分别来自哪里。

记录时应把时间顺序写完整：何时拿到 Surface，何时收到尺寸，何时停止旧 session，何时创建新输出，何时收到预览首帧，期间是否有权限或后台事件。只记录“黑屏了”无法帮助后来的人复现；把序列记录出来，才可能发现是“Surface 先销毁后还被使用”还是“新 session 在旧 session 未释放前开始”。如果使用日志，注意不要记录用户画面、身份证件、扫码内容或其他敏感帧数据。

最小复现也适合验证版本差异。把当前项目 SDK、目标 API、设备型号、镜头和窗口形态写入复现说明；如果低版本没有相同接口，就明确退化策略，而不是为了统一文章示例虚构一段兼容代码。对相机这类硬件能力，清楚的“不支持/待验证”比看似通用的假保证更有价值。

评审清单：谁拥有哪一种状态

最后可以用一个所有权清单做代码审查。UI 组件拥有自身布局和叠层展示，但不拥有相机会话；预览协调器拥有约束比较、串行重建和资源状态，但不拥有业务导航；业务页拥有用户选择、拍摄意图和错误文案，但不应直接跳过协调器去操作输出对象；数据层拥有拍照结果保存，但不能反向决定预览 Surface 的生命周期。任何状态被两个层级同时修改，都是下一次形态切换的隐患。

这个边界还能让测试更精确：UI 测试检查叠层和按钮是否随比例变化；协调器测试检查同一约束不重复重建、最新约束覆盖旧约束；集成测试检查授权、后台、镜头、形态切换组合；真机测试才判断特定镜头和设备上的首帧、比例和稳定性。每一层都验证自己能证明的内容，避免用一次视觉截图替代整条资源链的验证。

结语：把预览当作资源会话，而不是一块会缩放的图片

折叠屏和多窗口并没有制造新的相机原理，它们只是更频繁地暴露旧假设：容器永远不变、Surface 永远有效、方向只有一个、会话可以随时并行重启。把 UI 约束、Surface 生命周期、会话重配和用户任务分层后，预览问题才会从“某台设备偶尔黑一下”变成可观察、可恢复、可验证的状态变化。

资料与验证边界

• 鸿蒙电脑与平板适配指南：相机方向、预览比例、前后摄和窗口/方向变化需验证的依据。

• 应用内相机拍照后图片花屏 FAQ：预览流与拍照流使用 Surface 的资料依据。

• 相机旋转术语：设备方向、镜头角度和屏幕显示角度需区分的资料依据。

• Pura X Max 适配指南：折叠、旋转或切屏后重校方向并重建预览流的官方建议。

• 配图均为原创概念图；文章未包含真机相机采集、性能数据或可运行 CameraKit 工程。上线前应在目标 SDK、目标设备和真实权限/镜头组合下完成编译与回归。

补记说明：前文给出的是设计边界与排查原则，偏"应该怎样"。这一节补上一次具体问题的完整定位闭环：从现象、最小复现、时序证据，到根因判定、修复与验证。目的是把"是什么"推进到"为什么"和"所以呢"。本节代码为与设备无关的纯逻辑，已在本地实际运行；相机链路、Surface、预览输出与真机行为均未在本文环境验证，末尾单独列明边界。

从「看起来拉伸」到「可判定的问题」

先把标题里的现象写成一个能被证伪的问题陈述，而不是一句感受：

在折叠态（预览容器 920×720）正常显示的应用，展开为大窗口（1200×540）后，预览画面被横向拉长。问：这是 UI 容器尺寸算错，还是相机预览输出仍按旧比例推帧？判定标准是什么？

这个陈述里有四个可检查的量：输入尺寸、输出尺寸、缩放方式、以及相机会话是否重建。只有把现象拆到这个粒度，后面才有可能用证据而不是直觉下结论。

第一步是区分三种视觉结果，因为它们指向完全不同的责任层：

视觉结果	直接含义	责任层	优先检查
画面被拉伸	x/y 缩放比例不同	显示区与输入帧比例不一致	输入帧比例、容器比例、fit/crop 策略
完整但留黑	保持比例，容器有剩余	布局策略	叠层坐标系、取景框对齐
铺满但边缘裁掉	使用了裁剪填充	产品取舍	预览比例与最终照片比例差异

若观察到的是第一种，就不能只检查 XComponent 的宽高——因为 UI 可以按新宽高正确摆放，而 Camera 仍在向旧 Surface 推帧。此时真正需要确认的是：形态变化有没有触发一次有序的预览流重建。

最小复现：一次展开动作的完整时序证据

不要先在完整业务页面上打补丁。用最小复现把问题与业务代码隔离：一个承载预览的容器、一个最小会话、一份可打印的约束快照、一组形态变化操作。复现时按固定顺序记录事件，而不是只记"黑屏了"：

1. 折叠态冷启动，等待 surface_ready 与首帧；
2. 触发一次轻微布局抖动（如键盘弹出使容器高度少 8px），记录是否发生重建；
3. 展开为大窗口，记录 size_change、旧输出释放、新输出创建、首帧回调；
4. 展开态旋转 90°，再切一次前后摄；
5. 期间主动销毁并重建一次 Surface，观察旧回调是否复活旧输出。

记录的时间顺序大致如下（字段为结构示意，非实测设备日志）：

t=0    IDLE             surface_ready   surfaceId=s0
t=12   WAITING_SURFACE  size_change     920x720  ratioBucket=1.3
t=15   CONFIGURING      configure       rotation=0 cameraId=back
t=31   RUNNING          first_frame     ratioBucket=1.3
t=240  RELEASING        size_change     1200x540 ratioBucket=2.2
t=246  RELEASING        release_output  surfaceId=s0
t=251  WAITING_SURFACE  surface_ready   surfaceId=s1
t=268  RUNNING          first_frame     ratioBucket=2.2

有了这份序列，才能区分"Surface 先销毁后还被使用"和"新 session 在旧 session 未释放前启动"这两类完全不同的故障。只记录现象无法复现，记录顺序才可能定位。

勘误：前文那段 PreviewConstraint 代码的语言标注写成了 kotlin，但内容是 ArkTS/TypeScript 风格的架构伪代码，应视为 TypeScript 示意；标注错误不应被当作真实 API 依据。

纯逻辑层：能在本机复现的判定结果

"是否重建"的判断本身与设备无关，可以单独验证。下面这段是完整可运行的最小实现（Python 3 表达同一逻辑，便于读者直接复现），它把宽高归一化成一位小数的比例桶，再比较新旧约束；刻意不用 width / height 原值做判断，这样工具栏、键盘造成的小幅抖动不会触发重建。

def to_ratio_bucket(width, height):
    if width <= 0 or height <= 0:
        return "invalid"
    return f"{width / height:.1f}"

def diff_constraint(prev, nxt):
    if prev is None:
        return "first"
    if not nxt["surfaceReady"]:
        return "none"                                  # Surface 未就绪时不决策
    if prev["surfaceReady"] != nxt["surfaceReady"]:
        return "surface"
    if prev["ratioBucket"] != nxt["ratioBucket"]:
        return "ratio"
    if prev["rotation"] != nxt["rotation"]:
        return "rotation"
    if prev["cameraId"] != nxt["cameraId"]:
        return "camera"
    return "none"                                      # 只更新 UI 叠层

实际运行结果（本地 Python 3.13 执行，非示意值）：

步骤	输入（宽×高 / 方向 / 镜头 / Surface）	比例桶	diffConstraint	是否重建
冷启动（折叠态）	920×720 / 0° / back / ready	1.3	first	是
键盘弹出，容器少 8px	920×712 / 0° / back / ready	1.3	none	否
展开为大窗口	1200×540 / 0° / back / ready	2.2	ratio	是
展开后旋转 90°	1200×540 / 90° / back / ready	2.2	rotation	是
Surface 被销毁	1200×540 / 90° / back / invalid	2.2	none	否
新 Surface 就绪	1200×540 / 90° / back / ready	2.2	surface	是
切换到前置镜头	1200×540 / 90° / front / ready	2.2	camera	是

配套写了 7 条断言（小幅抖动不重建、比例桶/方向/Surface/镜头变化分别触发对应分支、Surface 无效时不决策），7/7 通过。

这组结果回答了一个具体工程问题："容器高度少 8px"和"折叠展开"在判定逻辑上确实被分到了不同分支，前者返回 none 只更新叠层，后者返回 ratio 才重建会话。这正是"把是否重建从像素变化中解耦"的可验证含义——它不再是一句设计原则，而是一组能跑出来、能被断言检查的输出。

需要强调：这里验证的只是约束归一化与差异判定，不是相机预览本身。比例桶取一位小数是本文为演示选定的粒度，真实工程应按目标设备支持的预览比例与抖动范围重新标定。

根因判定、修复与验证清单

有了时序和判定结果，就可以把"为什么会拉伸"收敛成三条互斥的根因链，每条都写明需要什么证据：

候选根因	支持它的证据	排除它的证据	对应修复
UI 容器宽高算错	日志中容器尺寸与目标比例不符，但输入帧比例正常	容器尺寸正确、first_frame 比例也正确	修布局，不动相机会话
旧预览输出未释放	size_change 后没有 release_output，或旧回调复活旧输出	释放与新建顺序完整、状态机无并发重建	串行化释放/创建，接住外部关闭回调
比例/方向未按新形态重配	比例桶已变化但 diffConstraint 返回 none，或方向换算散落在多处	返回 ratio/rotation 且会话已重配	归一化比例桶，集中方向换算

对开头那个具体现象，若时序里出现「size_change 之后直接 first_frame，中间没有 release_output」，那么第二条链成立的概率最高：UI 已经按 1200×540 摆好，但相机仍向旧比例的输出推帧，画面被填充到新容器里，于是"看起来被拉伸"。这个结论是可证伪的——补上释放/新建步骤后，如果 first_frame 的 ratioBucket 变成 2.2 且画面不再拉伸，链成立；否则应回到第一条或第三条重新取证。

修复后的验证按以下清单逐项判定，而不是"看一眼觉得好了"：

• 轻微布局抖动时 diffConstraint 返回 none，预览不闪黑；
• 展开时返回 ratio，时序中能读到完整的释放 → 新建 → 首帧；
• first_frame 的比例桶与容器比例桶一致；
• 旋转与切镜头分别走 rotation / camera 分支，不遗留不兼容参数；
• Surface 销毁期间不发起配置，恢复后只应用最新约束；
• 权限拒绝、相机被占用、返回前台三类路径都能回到可恢复状态；
• 上述每一项在新系统设备与低版本设备上各跑一遍，并记录真实日志。

回退路径同样要明确：若新约束逻辑引入误判，可先把比例桶比较退回到"任何尺寸变化都重建"，虽会带来黑屏，但功能可用，便于灰度定位；不要保留一个既不重建也不更新的中间状态。

补记的验证边界与时效性

• 本文环境为 2026-11-10，讨论对象为 HarmonyOS 7 / API 26.0.0 及配套 DevEco Studio 26.0.0；版本敏感的接口签名、权限与释放顺序请以当前目标 SDK 的官方 API 参考为准，旧版资料只作线索。
• 已在本地实际运行：约束归一化与差异判定的纯逻辑（Python 3.13，7/7 断言通过），上表输出为该次运行的真实结果。
• 未完成：ArkTS/C++ 编译、模拟器运行、真机相机权限与 Surface 验证、预览流与拍照验证、性能测量。时序表、回归矩阵与根因表均为测试设计与定位框架，不是已通过的设备结果。
• 文中不提供 CameraKit 可运行工程；PreviewCoordinator 相关方法均为工程对接点示意。真实项目请在目标 SDK、目标机型和真实权限/镜头组合下补齐编译与回归后再上线。