30秒演示很流畅，为什么上线就卡？美颜AR测试漏了什么

一个美颜AR的验证原型，在办公桌前跑30秒测试，画面可以完美无瑕。但把它放进真正要交付的产品里，它照样会卡。 问题不在于“性能与画质二选一”。真正要决定的是：哪些效果必须在哪些设备上保持可用，在什么样的持续负载下可用，以及当这个约定无法满足时，应用该做什么。 所以一次有用的测试，不能只看一个平均帧率数字。它应该： - 覆盖有代表性的效果组合，而不是逐个单独测； - 运行时间足够长，能暴露持续性的性能衰减； - 能区分“初始化失败”和“渲染压力过大”； - 在测试条件不达标时，主动判定数据无效； - 验证降级后的低开销配置是否真的能恢复； - 保留足够证据，事后能解释清楚一个结果是怎么来的。 这套测试边界用 TypeScript 搭建。它不依赖任何虚构的腾讯 RTC API 名称——所有跟 SDK 相关的调用都留在适配器后面，你按目标平台的文档去接就行。 腾讯 RTC 美颜 AR 覆盖实时美颜滤镜、美妆、贴纸、虚拟背景、虚拟形象、手势识别，以及图像/视频增强等能力。具体支持哪些场景，以官方美颜 AR 概览为准。 **先定负载约定，再写压测循环** 把每个效果单独测一遍是不够的。用户会把效果叠加使用，会在变化的场景里移动，会话开着的时间也远比演示长。 所以要基于产品实际会暴露给用户的能力，定义一个小型矩阵。只纳入应用真正提供的功能。一个“全部开启”的合成配置可以当作压力用例，但它不能替代有代表性的负载。 设备分组同样要小心。User-Agent 字符串不是性能测量结果。应该基于真机结果维护产品自有的设备档位，并且保留一个“未知”档，在有证据之前先按保守策略处理。 **把测试策略写成数据** 先建一个最小的浏览器 TypeScript 项目： mkdir beauty-ar-performance-lab cd beauty-ar-performance-lab npm init -y npm install -D typescript vite npx tsc --init mkdir src 然后添加 src/policy.ts，定义设备档位、效果配置、验收预算和测试用例四种类型。设备档位分为 entry、standard、high、unknown；效果配置包含分辨率、目标帧率、效果列表和性能模式；验收预算包含最低交付率、P95 输出间隔上限、最长长任务时长、最大应用耗时和最大恢复时间。 下面是一个策略示例——它不是腾讯 RTC 的基准值，也不是通用推荐值： 一个 entry 档的持续用例，时长 120 秒，配置为 960×540、目标 24 帧、开启美颜和美妆、平衡模式；恢复配置降到 640×360、目标 20 帧、只开美颜、性能模式；预算要求最低交付率 0.9、P95 输出间隔不超过 100 毫秒、最长长任务 150 毫秒、最大应用耗时 5 秒、最大恢复时间 3 秒。 这里每一个数字都应该替换成基于你预期体验和实测设备得出的产品决策。把策略放进版本控制，比照抄任何一组阈值都重要。这样一次 pull request 就能回答一个具体问题：是负载变了，是验收约定变了，还是实现退化了？ **把美颜 AR 集成放进可测量的边界后面** 测试框架需要观察应用真实的输出路径。只数 requestAnimationFrame 的调用次数，测的只是浏览器调度，它不能证明美颜 AR 处理后的帧真的产出了。 在 src/adapter.ts 里定义一个窄接口：包含 prepare、applyProfile、onOutputFrame、dispose 四个方法。在应用能确认“一帧处理结果已经到达预期渲染输出”的那个点上实现它。如果你的集成没有暴露完成回调，就去埋点应用自有的渲染目标，而不是拿 UI 动画的 tick 来顶替。 把性能模式、分辨率、帧率和效果选择，映射到目标平台上腾讯 RTC 美颜 AR SDK 所支持的配置面。官方低端设备性能优化实践指南建议按设备档位做适配、选择合适的性能模式、控制分辨率和帧率，并在必要时关闭开销较大的分割或 3D/GAN 类效果。 适配器在配置失败时应该让 applyProfile() 报错。它不能因为旧配置还在出帧，就报告成功。 **用显式状态跑测试** 性能测试本身也是一个异步应用。如果它的状态是隐式的，一次超时的初始化或一个被隐藏的浏览器标签页，都可能意外变成一个通过的结果。 添加 src/harness.ts，定义运行状态：idle、preparing、running、recovering、complete、invalid、failed。指标包含已运行时长、输出帧数、交付率、P95 输出间隔、最长长任务时长、首窗口帧率和末窗口帧率。运行结果包含用例 ID、状态、配置 ID、原因列表，以及可选的指标和恢复时间。