Skip to content

1.2.6

Choose a tag to compare

View all tags
@github-actions github-actions released this 29 Sep 05:43
· 1 commit to main since this release
1.2.6
0b5faca

你这次把调试日志开着，日志直接给出了两条我上一轮没修掉的问题。

日志里的两条硬证据

记录位置：…写作 第9版….pdf 第 356 页 → 第 1 页        ← 0.4 秒后又翻回来
记录位置：…写作 第9版….pdf 第 1 页 → 第 356 页
记录位置：…写作 第9版….pdf 第 356 页 → 第 356 页        ← 页码没变也照样写
视图就绪：…写作 第9版….pdf（pdf）…                    ← 同一个文件两分钟内"就绪"4 次
  • 页码在 356 ↔ 1 之间来回跳：说明记录的「位置」在被两个来源交替覆盖；
  • 同一路径反复"视图就绪"：说明视图在被反复重建/重载 —— 这正是 4GB 的形态。

改了什么

① 同一份文件开在两个叶子里 → 只记录「活跃叶子」的位置，并且一个都不恢复。
两个视图各写一次就是那个 356 ↔ 1 的来回覆盖；而"恢复"在这里更糟 —— 两个窗格各有各的位置，恢复谁都是把另一边的人拽走。只剩一个叶子时一切照旧。

② 不再每拍改写 pdf.js 的内部对象。
pdf.js 每个视图都握着 store.database.files === 那张表。我以前每拍都换一个新数组，于是每拍都要把所有 store 重新绑一次 —— 等于每秒一次改写别人的内部状态。现在表对象保持身份（原地同步），绑定只在视图新出现时做一次；applyPdf 也不再自己手写 store.file，统一交给对平逻辑做。

③ 顺手修的：preparePdfFor 现在合并全部记录（以前只带当前那一条，写回时可能把别的 PDF 的条目从表里抹掉）。

这次日志会自己说明问题

  • 视图就绪：… key=<叶子|路径> —— 同一个文件反复出现不同的 key = 视图在被反复重建（我怀疑的和 4GB 相关的就是它）；
  • 视图关闭：key=… —— 与上一行对着看；
  • 记录位置：…（差异：scrollTop: 11→604） —— 页码一样却判定变了时直接告诉你是哪个字段在动；
  • 套用 PDF：… 想第 356 页，套用前第 1 页，读回第 356 页（共 653 页） —— 分辨跳页是我们干的还是 pdf.js 自己重载后落的位。

仍然要请你配合的一件事

4GB 那个我还没找到源头。这次改的是"我们能控的读写与内部改写"，量级应该明显下来；但如果还崩，请做一次对照实验（一分钟）：禁用「View Memory」→ 重启 → 快速打开那两个 PDF。

  • 还崩 → 是 Obsidian + pdf.js 自己的事；
  • 不崩 → 是我们的锅，我接着挖。

回归

视窗侧 187 → 199、合并 44，全绿。新增的"双叶子"用例在旧行为下会红（记录在两个窗格之间来回翻）。

Assets 5
Loading