HarmonyOS 6.1.1 Camera：AUTO_FRAMING能力查询后，怎样区分声明支持与真机生效

现场采集页面里出现"AUTO_FRAMING 已声明"时，验收记录很容易被写得过头：有人把它当成系统已经接管构图，有人又因为没有可直接比较的画面而把整项检查停在"无法判断"。对影像素材验收而言，两种处理都会丢掉关键信息。前者把能力枚举误写成结果，后者则没有留下后续复核所需的条件。

更稳妥的做法是把问题拆成三层：会话是否声明该能力；是否已经向系统控制中心发出控制请求；当前页面究竟观察到了什么。当前项目还补了一条可在模拟器重复操作的分析链，把"已声明、未声明、请求异常"以及人工构图和焦距条件分别记录。它用于还原判断过程，不替代相机画面，也不把本地状态当成采集合格结论。

一、先把"支持"放回它应在的位置

AUTO_FRAMING 首先是会话能力判断，而不是画面评价。页面在取得相机会话后，依次检查控制中心是否可用、支持效果列表中是否包含 AUTO_FRAMING；满足条件才请求启用控制中心。这个过程能说明当前会话声明了什么、页面尝试了什么，不能从中推出人物或目标已经被完整纳入画面。

ts 复制代码

if (!session.isControlCenterSupported()) {
  this.enterManualFramingFallback('控制中心不支持，切换人工构图');
  return;
}
const supportedEffects = session.getSupportedEffectTypes();
if (!supportedEffects.includes(camera.ControlCenterEffectType.AUTO_FRAMING)) {
  this.enterManualFramingFallback('AUTO_FRAMING 未声明，切换人工构图');
  return;
}
session.enableControlCenter(true);

这段代码能够证明页面把"控制中心不可用"和"AUTO_FRAMING 未声明"分成两个明确出口，并且只有声明存在时才发出控制请求。它不能证明控制请求一定被系统执行，更不能证明某一帧的构图已满足业务规范。

验收时建议把状态写成"声明支持""未声明""请求异常"之一，而不是统一写成"自动构图正常"。前两个状态对应能力清单，第三个状态对应调用过程；它们都需要和页面上可观察的画面或人工复核另行对应。

二、声明缺失不是失败结论，而是构图策略的切换条件

素材验收真正需要的是下一步能做什么。若能力未声明，当前项目不把会话标成不可用，而是把构图模式转为人工构图待确认。此时仍可记录采集对象、复核人和构图要求，只是不能把人工动作伪装成系统控制中心的结果。

模拟器分析区把这个分支做成可重复的状态转换：先记录"已声明"，再切换到"未声明"，随后还可模拟"请求异常"。这样测试人员可以检查文案是否足够区分三种情况，也能验证人工构图入口是否只在相应条件下开放，而不依赖某一次硬件环境的偶然表现。

当前状态	可以记录的事实	不应写入验收结论的内容
已声明	会话支持列表包含 AUTO_FRAMING。	已自动完成构图。
未声明	页面已进入人工构图分析条件。	系统自动构图失败。
请求异常	控制请求没有形成可用状态。	当前画面一定不合格。
人工构图	人工复核可按既定框选要求继续。	系统已经接管或优化画面。

三、为什么焦距设置要从自动构图主线中拆出来

自动构图解决的是系统是否可尝试调整构图，手动焦距则是人工构图分支下需要保留的另一个会话条件。两者都可能影响现场判断，但不能互相替代。尤其在 AUTO_FRAMING 未声明时，把焦距滑块直接当成"自动构图的替代结果"，会让后续人员无法知道页面到底执行了哪一种判断。

当前项目把模拟器焦距记录限制在"未声明、人工构图"的分析分支。记录动作保存的是待设值、状态和时间；它不会向相机会话写入参数，也不会声称画面已经变清晰。

ts 复制代码

if (this.simulatorFramingState !== 'not_declared') {
  this.simulatorFocusState = '未设置：仅在"未声明、人工构图"分析分支比较手动焦距条件';
  return;
}
this.simulatorFocusState = `已记录模拟器分析焦距：${this.simulatorFocusDistance.toFixed(1)}（不写入 CameraSession）`;

这段代码能够证明焦距分析具有前置门禁，并且本地记录不调用相机会话。它不能证明指定数值对应真实镜头的焦点距离、景深或素材清晰度。

四、把画面复核留在最后一层，而不是让能力字段代替它

影像验收可以把画面复核设计成一张独立记录：采集对象是否完整、关键区域是否被遮挡、人工构图说明是什么、需要重拍的原因是什么。它的输入可以参考能力状态和焦距条件，但结论必须来自实际观察的画面材料，而不是来自支持列表或按钮状态。

当前页面的本地复核记录正是为了保留这一层：它显示分析状态、最后记录时间和不能推出的边界。即便后续有新的设备环境或画面证据，也能从"声明 → 请求/回退 → 焦距条件 → 画面复核"这条链继续，而不会需要反向猜测旧结论来自哪里。

五、异常出现后应交接什么

控制请求异常最忌讳的处理是反复点击直到页面出现"可用"字样。正确的交接材料至少包括：当前会话是否声明能力、控制请求处于何种状态、是否已经转入人工构图、是否记录过焦距条件，以及画面复核还缺什么。这样下一位复核人员可以补齐缺失的一层，而不是把异常覆盖成一次没有来源的成功。

六、把一次检查写成可追溯的验收记录

仅有"声明支持"这一句时，下一位复核人员无法知道检查发生在什么会话、页面是否发出控制请求，更无法判断现场画面复核是否还没开始。账号3的记录不应追求把状态写得漂亮，而应让每一个结论都能回到对应证据层。一次 AUTO_FRAMING 检查至少需要留下以下四组内容：

记录组	应保留的字段	解决的复核问题	不能替代的材料
会话能力	控制中心可用性、效果列表、声明结果。	当前判断的前提是什么。	实际取景截图。
请求过程	是否尝试启用控制中心、异常文字、操作时间。	代码路径走到了哪里。	系统内部执行回执。
人工回退	未声明或异常时的构图要求、焦距条件、复核人。	人工为什么可以接管。	系统构图效果。
画面核验	目标完整性、遮挡、清晰度、是否重拍。	素材是否可进入下一步。	对能力声明的反向证明。

其中最重要的是不要倒推：画面复核通过，不能证明系统启用了 AUTO_FRAMING；能力已声明，也不能代替画面复核。两条记录可以在同一次采集里并存，但它们的来源不同、解决的问题不同，应当分别进入验收单。

一个实用的操作顺序是：先在页面记录能力情形，再记录请求或回退原因；若进入人工构图，记录焦距条件和构图要求；最后再把实际画面交给素材质量复核。这样即使后续换了设备、重启了会话或重新拍摄，也不会把不同轮次的状态混在一起。

七、三种常见误判，以及怎样在页面上纠正

误判一：支持列表里有能力，就直接写"已自动构图"。 支持列表只能说明当前会话声明了某项控制效果。纠正方法是保留"声明支持"原文，并另设"画面观察"字段；没有画面材料时，该字段应保持待复核，而不是用能力字段填满。

误判二：请求没有报错，就把人工构图入口关闭。 请求未报错只能说明页面没有捕获到当前调用异常，不能保证系统画面已经满足采集要求。纠正方法是让人工复核独立于请求状态存在：它既可以确认系统画面是否适用，也可以在未声明或异常时接管构图。

误判三：焦距数值变化，就把它写成清晰度结果。 焦距值是一个参数条件，清晰度是对影像材料的判断。纠正方法是分别写"记录的焦距条件"和"画面清晰度复核"；前者可由模拟器分析重复验证，后者必须根据相邻画面材料给出结论。

当前项目的模拟器区正好用于演练这些纠正动作。它让状态在已声明、未声明和请求异常之间转换，并在未声明分支开放焦距条件记录。验收人员可以检查门禁、提示语和时间记录是否正确，而不需要为了完成这项分析去伪造一帧相机画面。

八、适用于素材验收的最小判定表

在现场节奏紧、复核人员又不在同一地点时，建议把"能否继续采集"和"能否判定素材合格"拆开。前者由会话状态与回退策略决定，后者由实际画面决定。下面这张表可以直接作为交接时的判断口径：

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

这张表的目的不是把所有相机能力都归入一个流程，而是限制每个状态能说的话。对账号3而言，克制结论比扩张结论更有价值：后续任何人都应能看出，哪一条来自代码条件，哪一条来自本地分析，哪一条仍需要画面复核。

FAQ

AUTO_FRAMING 已声明后，还需要保留人工构图吗？

需要。声明支持解决的是"当前会话可尝试什么"，人工构图解决的是"当前素材怎样被复核"。两者不是互斥的质量结论；人工复核至少应能指出目标是否完整、关键区域是否被遮挡。

模拟器中的"请求异常"可以写成相机故障吗？

不可以。它只表示本地分析链选择了异常分支，用于检查页面如何保留缺口和交接动作。真实会话异常应以当前会话的错误文字和操作记录单独说明。

为什么文章还记录焦距条件？

因为在人工构图分支中，焦距条件是可交接的操作事实。它能帮助下一位人员复现当前判断前提，但不能单独说明画面清晰度或实际焦点位置。

必要条件｜从SDK到设备的依赖链路

本文技术点的运行链路必须按以下顺序成立：

SDK/API ：工程使用 HarmonyOS 6.1.1（API 24），DevEco Studio 和 Hvigor 能完成 entry 模块构建。
Kit ：源码实际引入本文所需 Kit，例如 @kit.CameraKit、@kit.MapKit、@kit.NotificationKit、@kit.SpeechKit 或 @kit.VisionKit。
模块/页面 ：页面路由写入 main_pages.json，模块保持 Stage 配置，相关权限写入 entry/src/main/module.json5。
权限：动态能力调用前完成 CAMERA、MICROPHONE 或其他系统授权；网络页面确认 INTERNET 已声明。
系统能力/硬件 ：设备满足本文 API 和能力要求。相机、麦克风、地图、CardRecognition 等能力缺失时必须进入降级分支。

MapKit文章在上述链路后增加服务配置：在 AppGallery Connect 创建或选择项目，绑定与工程一致的包名和签名证书，进入服务管理开通 MapKit，并按控制台要求完成应用服务凭据/授权配置；不要在文章或源码中公开 App ID、Client ID、API 密钥或私钥。完成后再验证地图初始化、搜索或事件回调。