3.4 KiB
ENG-13 性能资源探针的最小观察时间
MOD-03在新的实际安装包上执行正式性能配对时，Firefox第一轮报告因一项candidate 资源观察只有349ms而失败。该项是第二组chapter的最后一次资源探针；原门槛要求 至少350ms，因此失败是有效的观察缺口，不能把它四舍五入成通过或覆盖原报告。 Chromium/WebKit同轮完成，仍有既有体积/计时review-required信号。
原因与修复范围
冻结BASE-06夹具在记录起始时钟后只执行一次原生setTimeout(350)，然后记录实际 performance.now差值。名义延时不等于该次记录一定已满350ms；现有证据不能进一步 区分计时量化和原生调度因素，不能据此断言Firefox存在特定计时器实现缺陷。
修改只在scripts/performance-fixture.mjs的当前适配层加入waitForObservation。
它按同一个实测时钟计算剩余时间，等待后重新核对，不足时继续等待剩余部分。
使用probe已有的原始定时器，不把观察器自身加入播放器待释放定时器列表；没有
改变库的清理动作。记录仍使用实际now()-waitStarted，保持超出的实测时间。
refactor/fixtures/performance.js、旧JSON、所有计时阈值及350ms校验均不修改。
适配层对旧、新两个播放器使用相同处理；构造/ready/play/destroy计时循环、媒体、
热身、样本数量和交替顺序不变。变化仅限计时采样之外的销毁后资源观察窗口及
原有结果传输替换，测试逐字反向恢复冻结源来保护这个边界。
验证
- 原报告保留：
run-firefox-ERtLa6/report.json，observedMs=349，校验明确失败； 原Chromium/WebKit报告也保留，不把本轮重测覆盖到它们。 - 虚拟单调时钟覆盖首次349ms后补1ms、原生超出到364ms时保留实测值、已经满足 时不再等待，以及定时器拒绝原样传播。原349ms候选报告变体仍须被校验器拒绝。
- 适配层测试证明去掉结果传输和最小观察适配后，内容与冻结文件完全一致。
- 使用同一
run-rawoRh实际安装的core/chapter产物重新执行三引擎完整三组配对。 包的源文件、构建工具和安装字节由现有严格验证器核对；该补丁不改变包内容。
最终9项测试通过（含冻结发布性能/压缩基线），定向lint、严格工具链、计划及风险 校验通过。原生三引擎三项完整配对测试通过，共108个旧新资源窗口，54个候选窗口 均通过严格清理检查。最短实际观察为Chromium350.2000000476837ms、Firefox350ms、 WebKit350ms；没有取整或使用名义延时代替真实值。第二轮没有计时reviewSignals， 但首轮Chromium销毁计时信号仍保留，不能把样本波动当作本补丁带来的计时收益。 三引擎均因原有分发体积信号保持review-required。
具体最终结果、环境、来源指纹、原失败和修复后报告见 机器证据。该任务只处理观察窗口 可靠性，不能把review-required变成性能发布通过；MOD-03及ENG-PERF-01/02继续。 也不表示所有插件、物理设备、远端CI或最终候选发布完成。无新依赖或API改动。
回退本任务提交即可恢复旧适配器；不要回写冻结夹具或放宽350ms断言。原失败应 继续保留。完成后独立本地提交；不push/publish。