mirror of
https://github.com/zhw2590582/ArtPlayer.git
synced 2026-10-08 19:06:15 -08:00
71 lines
5.0 KiB
Markdown
71 lines
5.0 KiB
Markdown
# PKG-DANMUKU-07 稳定性工作记录
|
||
|
||
本任务已在12后的运行时完成下述限定范围验收，任务与提交状态以tasks.json及Git为准。
|
||
06类型检查、11/12修复与本任务证据分别维护；真实模型、完整组合和发布验收仍待后续任务。
|
||
|
||
## 已执行的时间窗口诊断
|
||
|
||
`test/browser/danmuku-timing-diagnostic.spec.js`在候选核心中比较实际npm5.3.0插件与
|
||
06候选源码，使用本地90秒视频的短片段、原生RAF/媒体时钟和真实Worker。独立RAF
|
||
观察与实际readys getter采样分别记录；getter只包装读取，不修改返回数组或状态。
|
||
每例3条弹幕，后置sentinel证明间隔后仍能正常发送。12项诊断通过意味着取证完成，
|
||
不代表漏掉弹幕的结果可以作为稳定性通过。
|
||
|
||
| 场景 | Chromium | Firefox | Windows WebKit | 新旧共同结果 |
|
||
| --- | --- | --- | --- | --- |
|
||
| 注入800ms主线程工作 | 最大媒体帧间隔约800ms | 约777–809ms | 约838–856ms | 前两条未进入任何readys采样，sentinel显示 |
|
||
| beforeVisible等待600ms | 原生帧间隔约19–21ms，采样间隔616–618ms | 帧44ms，采样583–609ms | 帧63–64ms，采样622–647ms | 第一条与sentinel显示，中间条未采样 |
|
||
|
||
这解释了两种不同来源：前者浏览器主线程无法及时调度，后者浏览器仍在出帧，但
|
||
插件等待当前异步准备完成而不再读取新的候选窗口。±0.1秒和串行回调都有明确
|
||
历史语义；后续方案必须比较seek、hide/show、stop/start和false重试边界，不能
|
||
直接改成无限追赶或并行回调。当前不据此声称全部真实负载问题已解决。
|
||
|
||
报告位于refactor/.cache/danmuku07-timing-diagnostic.json，日志及附件保留同名前缀。
|
||
候选是11计时修复之前的06源码，具体构建SHA在每项danmuku-timing-observation中；
|
||
后续变更需说明哪些观察仍适用，不把旧报告冒充新提交的验证。
|
||
|
||
## 当前下一步
|
||
|
||
以下为本轮执行入口的历史清单，现已通过最终66项原生用例落实本任务范围。
|
||
下一实施阶段为08组合或其他已就绪包任务；09分发和真实Mask模型/设备仍不能据此关闭。
|
||
|
||
1. 11计时修复和12采样修复已分别提交并核验；当前HEAD为
|
||
`4f559cb31d6b69a37439c6db2d32ca28ae5c78f3`，恢复本任务。
|
||
12源码/main/legacy各102项浏览器通过，慢回调中间行已恢复；CPU完全阻塞
|
||
的未采样窗口仍保留。见[12证据](baselines/danmuku-frame-sampling-validation.json)。
|
||
2. 对实际持续播放记录scheduled、readys、callback、placed、visible、recycled及
|
||
原生RAF/媒体间隔，区分false、拒绝、轨道满、取消和错过采样。
|
||
3. 比较正常密度、密集队列和连续生命周期后的节点池、Worker、监听器与计时器。
|
||
已有受控三小时快进只证明离散状态，不是真实三小时播放或内存测量。
|
||
4. 根据证据决定是否需要兼容内部修复，并为每个独立修复保留任务和commit。
|
||
5. 明确Mask可依赖的当前队列/DOM/事件边界，再交付07验收与后续08组合矩阵。
|
||
|
||
不增加任意弹幕上限，不通过修改媒体时钟、预置ready或放宽断言伪造负载通过。
|
||
|
||
## 本轮新增的持续播放与边界取证
|
||
|
||
`test/browser/danmuku-stability.spec.js` 使用候选核心、实际npm5.3.0/候选插件、
|
||
原生视频/RAF/Worker，每秒2或20条，各三轮14秒实际媒体推进。每轮追加12秒
|
||
的时间戳序列，余下时间用于自然显示和回收；逐条记录采样/显示/回收，同时记录
|
||
状态池、节点/空闲池、真实帧和可选未强制GC的堆内存读数。不是三小时耐久测试，
|
||
也不把不同浏览器的performance.memory当作可比的泄漏证明。
|
||
|
||
首轮Chromium两个用例因测试误把`load(rows)`当作替换，在第二轮队列断言失败：
|
||
收到48/480，错误预期24/240。核对运行实现后按既有追加契约修正为累计队列数，
|
||
当轮显示数量仍严格断言24/240；没有改变生产API。失败报告与trace保留在
|
||
`refactor/.cache/danmuku07-stability-first.json`及同前缀results中。
|
||
|
||
Mask静态审查已确认其直接依赖只有核心video/root层/ready/destroy，未读取弹幕
|
||
队列或Owner。已纠正旧契约对根层创建归属的错误描述；核心模板及节点绑定为依据。
|
||
后续CSS mask边界测试明确不加载真实模型，不代替Mask03/05的候选生命周期与组合验收。
|
||
|
||
最终补强了非空Worker、实际节点复用、每条状态归属和跨轮显示/回收恰好一次检查。
|
||
12负载、6共享mask层、48资源测试共66项在三引擎全部通过，0重试/跳过。
|
||
见[变更记录](changes/2026-09-13-PKG-DANMUKU-07-stability.md)和
|
||
[机器证据](baselines/danmuku-stability-validation.json)。
|
||
|
||
本次候选每秒2条用例三轮72条只分配3个节点、实际复用69次；每秒20条三轮720条
|
||
分配21–22个节点、复用698–699次。旧版对应分配6及24–25个节点。两者该正常
|
||
同步回调负载下都完整显示；差异是本次原生样本观察，不是通用吞吐或长期内存承诺。
|