Univer电子表格性能测试：FPS、内存泄漏3个阈值卡死线上卡顿
【免费下载链接】univerUniver is a full-stack framework for creating and editing spreadsheets / word processor / presentation on both web and server.项目地址: https://gitcode.com/GitHub_Trending/un/univer
表格数据过万后滚动掉帧、来回切换工作簿越用越卡？Univer 的 e2e 性能测试给你一套现成的量化打法：FPS 分场景卡阈值，内存泄漏卡 1MB/200KB/6MB 三道上限，跑通即上手。
快速判断你的系统有没有问题
先跑三条最轻量的诊断，不用改任何代码。
手段一：跑滚动 FPS 测试。命令pnpm test:e2e e2e/perf/scroll.spec.ts，它会模拟滚轮事件测 5 秒帧率。正常值：空表格 ≥50 FPS，冻结窗格 ≥30，合并单元格 ≥20，密集样式文本 ≥25。低于阈值就该警惕。
手段二：查堆内存增量。命令pnpm test:e2e e2e/memory/memory.spec.ts，读 CDP 的JSHeapUsedSize（浏览器实际占用的 JS 堆字节数）。正常值：两次加载工作簿的增量 ≤1MB，二次实例销毁差 ≤200KB，整体泄漏 ≤6MB。超了说明有引用没断开。
手段三：抓运行时报错。命令pnpm test:e2e e2e/disposing/disposing.spec.ts，反复创建、销毁工作簿，监听pageerror。正常值是全程 0 报错；一旦出现，多半是销毁路径有悬空引用。
图：Univer多工作表实例并行渲染，性能测试的对照场景
按优先级排好调优动作
跑 FPS 基线，锁定掉帧场景
先做这一步：命令pnpm test:e2e e2e/perf/scroll.spec.ts，不改任何配置，只读数。
为什么有效：measureFPS用requestAnimationFrame逐帧计帧，同时输出中位数帧耗时和 Top10 最差帧，能把"偶尔一卡"和"持续掉帧"区分开。定位到具体场景再动优化，不猜。
怎么验证：输出里FPS数值必须高于该场景阈值——空表格 50、冻结 30、合并 20、密集样式 25。任一场景不达标，把它作为下一轮优化的目标。
卡内存泄漏阈值，超线就查快照
FPS 达标后做这步：命令pnpm test:e2e e2e/memory/memory.spec.ts，对照e2e/memory/memory.spec.ts里三个常量。
为什么有效：测试在每轮操作后强制 GC 再读数，排除未回收缓存的干扰；超限时会自动 dump 堆快照到test-results/，用 DevTools 的 Memory 面板打开就能找到未释放的对象链。
怎么验证：unit_memory_overflow≤1,000,000 字节、instance_memory_overflow≤200,000、univer_memory_overflow≤6,000,000。任一超限，打开对应.heapsnapshot对比两次快照的引用差。
压实例销毁路径，验证 0 报错
内存不超线后做这步：命令pnpm test:e2e e2e/disposing/disposing.spec.ts，覆盖 0 行、500 行、1000 行、3000 行工作簿的反复加载与销毁。
为什么有效：销毁路径是引用断开最密集的地方，行数为 0 的边界最容易被漏掉。用例全部通过才说明监听器和 Canvas 资源都断干净了。
怎么验证：两个用例结束errored均为 false，控制台无Page error。有任何报错，优先查对应行数的加载/销毁配对逻辑。
把指标接进 CI 遥测
最后做这步：设SHOULD_REPORT_TO_POSTHOG=true环境变量，e2e/utils/report-performance.ts会把每次 FPS 和内存增量带 git hash 上报。
为什么有效：本地机器性能波动大，只有 CI 同机器的历史曲线能看出"这次提交让 FPS 掉了多少"。单次跑通不算闭环，趋势不涨才算。
怎么验证：CI 跑完后能看到perf.sheet.scroll.*和*_memory_overflow事件落库。新提交 FPS 比上一版低 10% 以上，就该在 PR 里说明原因。
跑一遍验证闭环
- 起 e2e 服务：
pnpm serve:e2e，确认http://localhost:3000/sheets/可访问。预期：页面渲染出表格，无 404。 - 跑 FPS 基线：
pnpm test:e2e e2e/perf/scroll.spec.ts。预期：5 个场景全绿，FPS 分别 ≥50/30/20/50/25。 - 跑内存测试：
pnpm test:e2e e2e/memory/memory.spec.ts（超时上限 150 秒）。预期：三项增量 ≤1MB/200KB/6MB，test-results/生成两份.heapsnapshot。 - 跑销毁测试：
pnpm test:e2e e2e/disposing/disposing.spec.ts。预期：3 个用例全绿，0 个pageerror。 - 对比优化前后：把优化前的 FPS 和内存增量记下来。示例基线：空表滚动 52 FPS、二次实例增量 150KB；若优化后掉到 40 FPS 或涨到 300KB，回归没修反而变差，直接回滚排查。
图：Univer电子表格默认渲染基线，FPS 对比测试的对照画面
避坑速查
| 坑点 | 典型症状 | 正确做法 |
|---|---|---|
| 不强制 GC 就读内存 | 增量虚高几倍，误判泄漏 | 用e2e/memory/util.ts的getMetrics，先 GC 到堆稳定再读数 |
| 本机跑 FPS 当结论 | 同一场景今天 55 FPS 明天 30 | 固定 1280x720 视口，以 CI 单 worker 结果为准 |
| 只测 dispose 不测内存 | 用例全绿但堆还在涨 | dispose 测试通过后必须补跑内存测试 |
| 测试数据当真实数据 | 1200 行过线、5 万行照卡 | 性能问题按场景数据量分别下结论 |
| 忘挂 e2e 页面 API | 用例秒红，报E2EControllerAPI未定义 | 确认用的是dev:e2e构建，带测试钩子 |
把 FPS 和 3 个内存阈值写进 CI，后续每次 PR 自动跑，掉线立刻拦下。
【免费下载链接】univerUniver is a full-stack framework for creating and editing spreadsheets / word processor / presentation on both web and server.项目地址: https://gitcode.com/GitHub_Trending/un/univer
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
