问题
PerfCat 停止会话时，摘要原先在 FX（JavaFX 的界面线程）渲染路径里扫描完整日志并计算 FPS 分布；导出前也会完整复制与校验一遍数据。这两件事都压在 UI 线程上，会话越长、日志越多，界面负担越重。这轮改动把完整计算、复制与校验移到后台，保留原始日志、统计口径和档案格式。
设计
核心问题是代次。第一次停止会冻结当时的请求；重启后日志列表被整体替换，旧的后台任务仍在读旧代次的完整数据。结果回写时按请求对象身份核对结果与完成状态——UUID 相同、绑定相同，并不能证明还是同一个代次，所以身份判定必须落在请求对象本身。这样，迟到的旧结果即便算完了，也写不进新会话。
历史保存复用既有的历史 worker 完成捕获、保存与重扫；历史行的文本、顺序和条目身份都在后台准备好，列表安装、角色调和与控件更新仍在 FX 线程完成。这不是把所有 UI 工作都后台化。
验证
一致性验证不是看界面卡顿消失或导出成功提示。我用真实线程暂停旧请求，再用同 UUID 重启或 reset，然后释放旧请求：检查旧代次内容完整，且确认它无法写回新会话。另用独立的 Python 脚本按记录核对时间、数值、状态与数量，并在这些合成场景中把改动前后的完整档案做字节级对比，结果字节一致——这一结论限于本次合成输入，不从夹具外推全部真实会话。
失败路径同样有验证：同内容重存、冲突保全、损坏档案隔离、旧指纹拒绝、角色重新绑定、超限明确失败并保留旧目标，都有对应场景覆盖。但有一条边界要写准：历史保存成功发布之后，如果重扫失败，磁盘上可能已经有新文件——不能把“失败”概括成“任何失败都不会产生磁盘变化”。
边界
2026-10-25 的后台化与一致性验证之后，2026-10-28 我用 1000 份合成档案输入在真实界面跑通了基本流程：保存、同内容重存、回放、比较、替换档案被拒绝与退出。这补充的是真实 UI 操作的证据；输入是合成档案，没有设备与 ADB 参与。源码确认一致后复用了既有的测试证据，并没有在当天重跑全量测试。
这条记录不能证明长期响应、内存上界或整机开销，也不提供任何加速倍数：完整日志仍随会话增长，旧请求与新会话可能同时持有各自的日志，后台任务数受控也不代表内存有界。条件回放仍是未证明状态，新的逐帧引擎尚未接入周期性 live FPS，本次改动没有新增任何 FPS 资格——这两个限制在本次改动之后没有变化，也不会因为后台化顺带“完成”。
本文关联项目：PerfCat —— Android 性能采集与会话分析