摘要
战斗记录 App（Battle Notes）的实时模式在玩家玩游戏时持续读取画面。读取由一个路由程序（router，把一张截图分给各个读取器的程序）调度，分两类：
- 旁路读取：行动条（按行动顺序排列的兵堆卡片）、攻击预览、信息页等，每次约 1 秒，优先执行；
- 主读取：会话截图的整体读取，每次约 5 秒，只在旁路空闲时进行。
读到的东西交给状态估计（SE，把观察累积成对局状态和对手构筑的推断），再生成给玩家看的简报。
用户用安装版实时玩了三局，第一局的简报里同一条“【魔法净变化】我方 +43（147→190）”重复了 6 次，魔法净变化一共 59 行。原因不是读错，而是帧的顺序：主读取取的是队列里 15–37 秒以前的画面，SE 却按截取顺序把它排在新的旁路读数后面，于是 HUD 魔法值在新旧之间来回跳，每跳一次都被当成一次变化。
修复后，每张关键帧截图都记下它的画面时间（媒体秒），组 SE 请求时按画面时间排序。三局的魔法来回跳从 68 / 3 / 20 次降到 1 / 0 / 0，可疑读数从 28 / 13 / 9 降到 3 / 1 / 1。
要回答的问题
实时模式下简报里重复、来回跳的数值变化从哪来？按画面出现的时间排序能否消除？
数据与来源
- 用户于 10 月 14 日 23:58 起用安装版 10.14-1 实时玩的三局（23:58、00:35、00:44 开始），只读这些会话，不修改。
- 没有这三局的金标准（人工核对的真实减员和魔法变化）。
方法
诊断： 从会话日志看，实时模式下路由一次只做一件事，旁路读取优先；主读取大约每 13 秒完成一张，取的是队列里 15–37 秒以前的画面（例如在 741.7 秒取走的是 705.9 秒的帧），而且不总按时间先后取。SE 请求里会话截图按截取顺序排，旁路读数插在“当时已有的截图”之后——于是新鲜的旁路读数（魔法 147）后面跟着旧截图（190），再跟新的旁路读数（147）……
修复（App）：
- 每张关键帧截图提交时，把它的画面时间记在会话里。
- 组 SE 请求时，如果所有截图和旁路读数都有画面时间，就按画面时间排序；只要有一张没有（旧会话、手动截图、文件夹导入），就保持原来的顺序。保存的旧请求不变。
对比： 对同一请求分别用原顺序和按画面时间排序跑 SE；截图时间取自会话日志里的提交记录。
设置
三局的帧数分别为 268、20、96。
结果
| 局 | 帧 | 顺序 | 简报行 | 魔法净变化行 | 魔法来回跳 | 减员段 | 回升段 | 可疑读数 | 减员合计 |
|---|---|---|---|---|---|---|---|---|---|
| 23:58 | 268 | 原顺序 | 169 | 59 | 68 | 35 | 7 | 28 | 633 |
| 按画面时间 | 77 | 13 | 1 | 31 | 1 | 3 | 483 | ||
| 00:35 | 20 | 原顺序 | 14 | 3 | 3 | 3 | 0 | 13 | 193 |
| 按画面时间 | 10 | 1 | 0 | 15 | 0 | 1 | 696 | ||
| 00:44 | 96 | 原顺序 | 31 | 11 | 20 | 19 | 3 | 9 | 146 |
| 按画面时间 | 9 | 0 | 0 | 18 | 0 | 1 | 119 |
“魔法来回跳”是同一英雄 HUD 魔法值出现 A→B→A 的次数；“可疑读数”是前后相同、中间单独不同、不算作减员的读数。
两种方向的错误都出现了：按原顺序，第一局的来回跳让减员多算（633）；00:35 那局反而把真实减员当成可疑读数藏掉了（按画面时间排序后减员段从 3 变成 15）。
第一局实测耗时（安装版，用户边玩边跑）：行动条读取中位 1.2 秒（p95 1.7）、攻击预览 0.6 秒（p95 0.9）、信息页 1.1 秒（p95 1.5）。
失败与负结果
- 实时性问题没解决： 主读取取的画面仍然晚 15–37 秒。是否在实时模式下让信息页只走旁路、或让主读取让路，是一个取舍，当时待定。
- 第一局攻击预览读了 67 次，其中 29 次“没找到预览牌”（每次约 0.6 秒）；预览原图读完即删，无法再核对。
局限
- 没有这三局的金标准，表中是 SE 输出的对比，不是对真实减员或魔法变化的核对，也不是准确率。
- 只有三局，其中一局只有 20 帧。
结论与下一步
简报里重复、来回跳的变化主要来自帧顺序而不是读错；按画面时间排序后大部分消失。下一步要处理的是主读取本身取帧太晚的实时性问题，以及攻击预览“没找到”的浪费。
Comments