浏览器节流适合早期诊断，实体低端手机和笔记本才适合发布验收。测试时应固定同一段对话，记录启动、帧稳定性、输入延迟、内存、温度、电池模式、中断和恢复。Avatar 无法维持目标质量时，核心产品路径仍必须可用。
1. 建立真实设备矩阵
不要用“iPhone”或“Android”作为一个测试项。矩阵至少包含设备级别、操作系统、浏览器、内存、电池状态和网络条件。优先选择客户群中真实存在的旧设备，而不是随机购买最便宜的设备。
Chrome Device Mode可模拟视口和部分网络条件，但不能准确模拟另一台设备的 CPU、GPU、内存和散热。Chrome 校准节流适合建立可重复的开发基线，最终仍需实体机验证。
Android 可以使用 Chrome Remote Debugging，iOS 可使用 Web Inspector，从真实设备获取网络、控制台和性能信息。
2. 固定测试脚本
为所有设备使用同一流程：打开产品、进入 Avatar 功能、播放短回复、播放长回复、执行一次打断、切换后台、恢复、模拟网络变化并结束。相同脚本让不同设备结果可以比较。
不要只观察平均 FPS。记录 P95 长帧、首个稳定动作、输入到停止播放的延迟、内存峰值和会话后的资源释放。Long Tasks API可帮助定位阻塞主线程的任务；INP则可反映用户交互响应。
3. 测试持续负载和热降频
短测试可能看不出问题。运行足够长的会话，观察设备升温后帧率、音频连续性和交互延迟是否下降。开启省电模式再重复一次，因为实际用户并不会为 Avatar 关闭系统设置。
使用 Chrome Performance Panel分析长任务、脚本、布局和绘制。若平台提供图形诊断，也应记录纹理上传和着色器编译。测试期间不要运行无关录屏工具，除非你已确认它不会改变结果。
4. 测试后台、丢失上下文与恢复
用户切换标签页时，浏览器可能暂停动画或限制定时器。Page Visibility API可以让产品在后台降低视觉工作，回到前台后再恢复。WebGL 上下文丢失时，应处理 webglcontextlost，而不是让音频继续、画面永久冻结。
5. 设定降级梯度
性能不足时，不要只有“全开”与“失败”两个状态。可依次降低渲染比例、帧率、视觉细节，最后进入纯音频或文字。每一级都要保留停止、关闭和返回核心工作流的控制。
发布前把测试结果与Avatar 资源加载方法一起评审。如果目标设备在下载阶段就超出预算，再优化渲染没有意义；若网络传输是主因，可参考实时 Avatar 带宽测量指南。