摘要

截图路由（router，把一张截图分给各个读取器的程序）在读取战斗日志（Logs，游戏里逐行记录攻击、伤害、施法的窗口）时，会先初始化两个文字读取组件：一个通用面板 OCR，另一个是专门读数字和小单元格的识别器。日志只用前者，却每次都加载后者。

本实验（P66 系列的一项）做了两件事：

  1. 已采用：数字识别器改为“第一次被真正用到时才加载”，之后常驻复用。单独读日志的请求不再加载它。四张旧开发图的输出除了耗时字段外完全相同。
  2. 未采用：试了把日志区域放大到 2 倍、3 倍再读，看能不能读全。结果完整的 11 行日志页反而读得更差。

要回答的问题

  • 去掉日志请求里不必要的模型加载，输出是否完全不变？耗时有什么变化？
  • 把日志区域放大后再读，能否提高完整读出的行数？

数据与来源

四张旧开发图（原图路径登记在实验输入文件里，没有复制原视频或生成裁图）：一张 11 行完整日志页、一张洞穴地图的邻近日志图、一张没有日志的生物面板、一张没有日志的魔法书。这不是十场留出测试，也不是 App 端到端或全场景验收。

方法

延迟加载

数字识别器改为第一次被准备页、HUD、单位面板或魔法书页使用时才加载，加载失败仍然抛错，不伪造空读数。同一帧的 OCR 缓存只在像素完全相同时复用，请求结束就清空。公开入口、字段、三遍读取原文、接受标准都不变。

测量脚本按顺序调用生产路由的日志模式，先保存全部结果，再与改动前逐项比较。输入只有原图路径，没有参考框或答案。

放大对照

日志读取的接受规则是：一行文字由三次读取得到，三次一致才接受。原来三次分别是“整图、区域原尺寸、区域 1.5 倍”。对照把三次换成更大的放大倍数，定位框来自实际算法输出（不是人工参考），原图不修改。注意三次读数来自同一个模型，不是三份独立证据。

设置

GPU 上使用已缓存的 PP-OCRv6 medium 模型，不下载、不新建环境。两轮测量串行运行，文件缓存和 GPU 首次初始化等没有控制。

结果

延迟加载

图片 改前秒数 改后秒数 输出
11 行完整页（首次请求） 32.277 5.248 12 行框含回合标题、6 个字面声明，不变
洞穴邻图（预热后） 0.609 0.578 7 行框、4 个声明，不变
无日志生物面板 0.321 0.300 拒识，不变
无日志魔法书 0.375 0.327 拒识，不变

四张响应除各层级的耗时字段外完全相同，包括浮点 OCR 分数、原文、UNKNOWN、原因和来源。改前都加载了数字模型，改后都没加载。四份新响应都被 App 现有的严格解析器接受。

不能把 32.277 → 5.248 秒全部归功于这次改动：两轮串行，没有控制文件缓存和 GPU 首次初始化。有依据的只是“少加载了一个无用模型”这个事实。这里也只含解码、路由和读取，不含进程启动、UI、状态推断或排队；首次请求仍没达到 3 秒。

放大对照

三次读取所用版本 完整 11 行页 洞穴 6 行 结论
整图、原尺寸、1.5 倍（当前） 6/11 4/6 当前基线，仍不高
原尺寸、1.5 倍、2 倍 3/11 4/6 完整页更差，不采用
1.5 倍、2 倍、3 倍 2/11 4/6 完整页更差，不采用

计数是规范化、去空白后的整行文字完全匹配，不是伤害字段准确率；两张图共 17 条旧参考，不是新的盲测对局。

失败与负结果

  • 放大方案让完整日志页读得更差，未采用；生产默认、App 格式和三遍接受规则都没改。
  • 首次全套测试出现 95 个失败和 9 个错误，原因是 Windows 临时路径过长（WinError206），改用短目录后全套通过，没有为此改生产逻辑。
  • 最初误用了不含 Qt 的环境跑 GUI 测试，出现 3 个收集错误，换到已有环境后通过。
  • 收尾时删除测试临时目录的命令被执行环境拦截，约 102.3 MiB 的可重建临时文件没有删掉，记录在案。

局限

  • 四张图只是速度和兼容检查，两张日志页只是放大的失败对照。
  • 软件测试（新增 5 项、相关 134 项、Perception 全套 5,924 项、App 相关 93 项通过）证明的是行为不变，不是视觉准确率。
  • 日志 95%、英雄面板、法术预览、冷却及视频自动联动都没有因此完成。

结论与下一步

延迟加载是一个安全的小改动：读日志不再背一个无用模型，结果逐字节不变。放大不是提高日志读取的出路。下一步应先补完整日志的失败类型参考（少于三行、滚动截断、时间戳符号丢失、相近兵种名、半透明、无日志说明框），按至少十场录像隔离来源，固定参考后再选一个有依据的定位/文字方法做对照。