一、前言

为桌面物品增加采集，意味着用户要投入更多操作，也可能改变后续等待时间和设备负担。但等待更短，并不足以成为选择方案的理由：第5篇提出的物品辨认、关键部位查看和连续视角观察，仍须在相同口径下评价。

首先要说清“帧数”。采集唯一帧数按批次与帧标识去重；推入调用次数记录实际调用；成功返回调用次数依据返回语义统计；成功推入所关联的唯一帧数还要再次去重。同一帧重复推入会增加调用次数，却没有新增独立观察。唯一帧更多，也不保证观察方向更多。

二、变量与条件

2.1 在同一覆盖范围内设计规模组

沿用固定物品、移动设备的采集方式，保持距离、背景、照明、镜头、变焦、路线范围、高度及俯仰规则。拟在同一路线各段安排不同采样密度，形成较小、基准、较大规模组；具体数量与采样规则在执行前登记，不预设通用最少帧数。

这里的关键是让各组都覆盖计划路线。例如，小规模组如果只采路线开头，大规模组却绕到背面，比较中就同时改变了规模和覆盖。应逐段记录计划采样与实际输入，再核对图像中真正可见的表面。达到计划数量，不能代替覆盖检查。

每次按协议新采集，并使用各自新建的会话。不在旧会话中继续加帧后称为独立对照，也不假定前篇证据索引已经构成可离线重放的数据包。各组仍遵守宽1080像素、高1440像素及图像与相机信息对应的输入约束；输入检查不因规模实验而放宽。

新采集会带来位姿、曝光与运动差异，增加密度也可能延长采集时长。第3篇的观察标签与偏差记录继续保留。因此，本协议比较的是采集方案，不能声称已经完全隔离帧数的因果作用。

图1为计划关系与界面规划，数量待填写，不代表实际采集轨迹或系统关键帧选择结果。

2.2 固定运行条件，记录采集留下的热状态

实验继续关联设备型号、芯片、系统完整构建号、SDK、API级别和样本档案，补充应用构建配置、调试连接、后台负载、屏幕设置、供电、初始电量、环境温度与散热布置。环境引用指向当次确定记录，避免后续修改覆盖旧条件。

热状态至少分开记录采集前与重建启动前。即使采集开始时条件相近，不同采集时长也可能改变重建起点。测不到的状态保持未知，不能用“已静置”代替温度证据。恢复条件、重复计划及执行顺序预先登记，轮换规模组顺序，避免始终让大规模组最后执行。

保存格式及配置保持一致；PLY与运镜MP4分组分析。质量比较引用同一qualityPlanRef，并核对实际观察范围。视频片段与模型观察路线不能直接混比，空质量记录也不表示合格。

C1记录一个规模组的计划骨架。全部字段为应用设计，标识建档时分配；条件引用包含上述具体设置，实际值另存。

{
  "performancePlanId": null,
  "scaleGroupId": null,
  "experimentId": null,
  "sampleId": null,
  "baselineId": null,
  "environmentRef": null,
  "qualityPlanRef": null,
  "executionState": "notExecuted",
  "plannedConditions": {
    "captureProtocolRef": null,
    "samplingRule": null,
    "plannedUniqueFrameCount": null,
    "runtimeConditionsRef": null,
    "thermalMeasurementPlanRef": null,
    "recoveryRule": null,
    "saveConfigurationRef": null
  },
  "actualConditions": null,
  "repeatPlan": null,
  "executionOrder": null,
  "deviations": null
}

三、执行过程

3.1 先建立测量口径，再选择工具

系统负责关键帧选择、重建与保存，应用负责条件、调用和事件记录，外部工具承担经核验的性能测量。一个标为“内存”的数值，必须同时说明测量对象和指标定义，才有比较意义。

指标	拟记录口径	解释限制
阶段耗时	应用起止事件、同一单调时间基准、单位	包含调度与通知延迟，不称纯算法时间
内存	具体指标、进程或系统范围、单位、采样间隔	应用进程值不自动代表重建全部系统消耗；不同口径不混合
温度与温升	测点、传感器或仪器、方法、初值及采样值	表面、电池与芯片温度不互相替代
热等级	热事件原值、时间及解释依据	不是摄氏温度；没有事件不证明没有升温
能耗相关量	已核验边界内的功率或累计能量、工具及方法	供电端输入能量不自动等于电池消耗或重建净能耗
电量变化	同口径起止电量及观测时段	仅作粗粒度现象，不直接换算精确能耗

温升是同一测点相对指定初值的变化，必须注明初值取自采集前还是阶段启动前。功率描述能量消耗的快慢，能量描述一段时间内的累计量；单个功率读数不能代替整段能量。若根据功率采样估算能量，还需交代时间覆盖、积分方法和缺测影响。

选择工具前，核清型号、版本、支持范围、指标定义、权限、精度和导出方式。现有资料没有具体性能工具依据，第1篇预期在本篇落实的工具选择仍有缺口；当前只能确定选择标准，不提供采样命令，也不宣称某工具已覆盖全部指标。

工具连接、采样和日志本身可能影响任务，比较时保持设置一致，必要时另做开销检查。外部工具与应用使用不同时间轴时，保存对齐方法与误差；未对齐的采样仍可保留，但不能把峰值强行归到某次调用。

C2描述单条采样结构。measurementScope填写进程、系统、测点或供电边界；method关联完整方法记录。sampleTime表示测量时刻及其时间口径，不能以导入时间替代。

{
  "performanceRunId": null,
  "reconstructionTaskId": null,
  "metricName": null,
  "measurementScope": null,
  "value": null,
  "unit": null,
  "sampleTime": null,
  "clockMethod": null,
  "toolAndVersion": null,
  "method": null,
  "missingReason": "尚未执行测量",
  "evidenceRefs": []
}

这些是应用字段，不是SDK指标成员。缺测原因与数值分开保存，null不替换为0；空骨架也不计作一次有效采样。

图2为测量布置规划，具体测点、工具和能力尚待落实，没有温度或能耗数据。

3.2 分别测量重建与保存

沿用第4篇手动保存方案：启动时writeInfo为空，确认重建成功且满足保存条件后，再提交保存。这样能分开观察两个阶段，但阶段终态、返回语义和完整保存配置必须先按目标SDK核清；现有指南片段不足以直接实现可靠调度。

重建从HMS_SpatialRecon_StartSession调用前计时，到对应重建完成通知接收为止。保存从HMS_SpatialRecon_SaveResultToFile调用前计时，到对应保存完成通知接收为止。两端采用同一单调时间基准，避免日历时钟调整干扰持续时间计算。

调用返回和通知结果分别保留，接口返回不表示任务结束。明确失败通知可以形成失败阶段的持续时间，但应与成功耗时分开；结束通知缺失、归属不明或结果无法解释时，保留不完整区间。应用等待超时不能充当SDK终止证据。

重建通知接收至保存调用前的等待单列，并记录等待原因。采集、输入处理和文件检查另记；只测重建与保存，不能称为整个三维记录流程的总成本。采集与输入处理若重叠，也不能直接相加得到总时长。

每次启动后仍按实际前后台情况调用HMS_SpatialRecon_SetRunningMode。遵守同一时刻只有一个会话重建、只有一个会话保存MP4的限制。指南明确MP4保存涉及渲染与编解码资源，因此保存不能被视作没有成本的附带动作。

C3仅说明事件与采样的关联规则，不重写第4篇调度，也不补造完成状态枚举。

关联 performanceRunId、reconstructionTaskId 与阶段记录
读取第4篇 timing 中的起止事件引用和 pauseIntervalRefs
对重建、保存分别处理：
    核验任务归属、调用与通知类型、结果解释契约
    若任一项不足：保留原始证据，停止该阶段完整区间计算
    核验起止时间来自同一单调基准，单位一致且顺序有效
    若边界缺失或无效：耗时保持 null，记录原因
    否则计算完整经过时间，按成功或明确失败分别归档
    暂停区间单列，默认不扣除

对每项性能采样：
    核验指标定义、测量范围、单位及采样有效性
    核验与任务时间轴的对齐方法及误差
    若无法可靠对齐：保留采样，不分配到具体阶段
    否则关联相应阶段，保存缺测范围与采样间隔
    仅对有效样本计算采样最大值，注明覆盖范围
不以进度值判成功，不插值补造缺失证据

离散采样最大值只说明采到的最大读数，不能保证覆盖真实瞬时峰值。若启动附近缺测，应明确缺测区间，而不是只留下一个看似完整的“峰值内存”。

图3为无比例的事件关系规划，不是执行轨迹；当前没有耗时数据或内存曲线。

3.3 记录热事件、暂停与重复实验

重建指南建议订阅COMMON_EVENT_THERMAL_LEVEL_CHANGED，在相应过热条件下暂停并提示。启动重建后可通过HMS_SpatialRecon_PauseSession请求暂停，通过HMS_SpatialRecon_ResumeSession请求继续。订阅实现、等级含义和阈值仍缺依据，本文不补写相关API代码。

暂停请求、能够确认的暂停区间、继续请求分别记录。发出请求不意味着立即进入相应状态。默认报告完整经过时间；只有暂停边界可靠且扣除规则预先明确，才另报扣除后的时间，它仍包含调度等开销，不能称为纯计算时间。

如果未来同时观察到温升、热等级变化与耗时增长，可以报告这些现象及时间关系，不能直接写成“规模增加导致降频”。降频判断需要独立证据，原因分析还需考虑采集起点、后台负载及输入差异。

每次重复都保留原始记录，包括中断、失败、条件偏差和缺测，不只保留最快一次。重新采集后的任务属于协议重复，并非完全相同输入的重跑。要求相关任务全部结束后才销毁会话，且不保证并发能力；收尾仍需确认无并发访问，不能为赶下一轮而提前释放。

图4为记录结构规划，重复编号和测量值待填，不表示已经触发热事件或暂停。

四、观测结果

4.1 先检查可比性，再整理结果

当前尚无实测结果。下表按单次记录展开，实际比较时每次重复分别填写；占位不计为实验样本。

记录项	当前内容	后续依据
规模组、重复编号	待关联／待填写	计划与执行顺序
采集唯一帧、推入调用、成功返回调用、成功推入唯一帧	均为null	批次、逐次返回与去重规则
系统关键帧数	未知	当前无读取依据
重建／保存结果及耗时	未执行／null	调用、通知、时钟与单位
内存指标、范围及采样最大值	待确定／null	工具定义、原始采样与覆盖
测点温度、初值、温升	均为null	同测点同方法记录
热事件、暂停区间	待关联	事件原值及边界证据
能耗相关量、电量变化	均为null	测量边界、方法与时段
质量检查及共同范围	待关联／待评价	逐产物检查记录
条件偏差与缺测原因	待填写	执行记录

先核对环境、指标定义、保存配置和质量范围，再决定哪些记录进入相应汇总。每项指标分别报告有效次数、逐次值，并在适合时给出中位数与最小—最大范围。中位数表达排序后的中间位置，范围保留本组波动；它们都不能替代原始记录或证明普遍规律。

失败与未完成任务另列，已经取得的采样继续保留，避免只看成功案例掩盖代价。缺失值保持null并附原因，不插值制造完整曲线。每次实际产物分别关联质量结果，不能拿一个代表产物的检查覆盖同组全部任务。

只有共同观察范围明确，才能讨论质量与成本的取舍。当前没有依据写出“规模越大越慢”“质量收益趋于饱和”或最佳规模，空表也不能承担趋势证据。

图5为空记录页规划，状态为未执行、质量待评价、产物待关联，尚无质量—成本实测比较。

4.2 向第7篇交付候选产物或明确缺口

有实际产物后，交接应包含任务归属、文件检查、质量范围、成本记录及未解决问题。在共同质量范围内讨论等待时间与资源成本，并保留选择理由；质量未评价时，不按耗时选出“最优产物”。

C4用单个产物的交接骨架关联计划与单次记录。performanceRunId指向该次条件、事件和采样集合，多个产物分别建立关联。当前标识为空，blockingStage只表达准备缺口，不是SDK失败状态。

{
  "performancePlanId": null,
  "scaleGroupId": null,
  "performanceRunId": null,
  "captureBatchId": null,
  "reconstructionTaskId": null,
  "environmentRef": null,
  "artifactRef": null,
  "artifactCheckRefs": [],
  "qualityCheckId": null,
  "qualityPlanRef": null,
  "performanceRecordRefs": [],
  "executionState": "notExecuted",
  "conclusionScope": null,
  "selectionReason": null,
  "blockingStage": "preparation",
  "knownFacts": [
    "尚无实际任务、产物和性能采样",
    "第5篇尚未形成实际质量基线"
  ],
  "missingEvidence": [
    "匹配环境的性能工具依据待补",
    "阶段判定及保存配置契约待补",
    "实际执行材料与同口径质量检查待补"
  ]
}

第7篇仍需验证实际加载、视角操作、页面切换和资源释放。重建成本较低不能推出浏览更流畅，保存完成也不能代替加载兼容性证据。

五、结论

即使后续完成测量，结论也只适用于记录中的设备、系统、SDK、样本、采集方案、保存配置、工具口径与质量范围。现场新采集伴随输入差异，少量重复不足以推出设备或算法的普遍规律。

输入规模不等于关键帧规模。没有关键帧观测依据，就不报告每关键帧成本，也不由耗时变化解释内部计算复杂度。内存、温度、热等级、功率、能量和电量变化分别解释；测不到的量明确缺失。