查看 webxr 耗时需利用 performance api 结合 requestanimationframe 的回调机制，在每一帧渲染前后记录时间戳并计算差值。具体做法是在 onxrframe 中通过 frame.getviewerpose() 获取姿态数据，并在调用 renderer.render() 前后分别使用 performance.now() 打点，从而分离出渲染管线与逻辑处理的耗时。
如何分离 WebXR 渲染帧的各阶段耗时
要精确分析性能瓶颈，必须将一帧的时间拆解为“应用逻辑”、“视图投影计算”和“GPU 提交”三个部分。核心在于捕获 XRFrame 对象后，立即记录开始时间，在处理完所有场景图更新后记录中间时间，最后在 renderer.render() 执行完毕后记录结束时间。这样得到的差值分别对应 CPU 侧的逻辑开销和 GPU 侧的绘制调用开销。
const session = await navigator.xr.requestSession('immersive-vr');
const frameTimeRef = { start: 0, logicEnd: 0, renderEnd: 0 };
session.requestAnimationFrame((time, frame) => {
// 1. 记录帧起始时间
frameTimeRef.start = performance.now();
// 2. 处理 XR 逻辑（如获取姿态、更新模型）
const pose = frame.getViewerPose(referenceSpace);
updateScene(pose);
// 3. 记录逻辑结束时间
frameTimeRef.logicEnd = performance.now();
// 4. 执行渲染
renderer.render(scene, camera);
// 5. 记录渲染结束时间
frameTimeRef.renderEnd = performance.now();
console.log(`Logic: ${(frameTimeRef.logicEnd - frameTimeRef.start).toFixed(2)}ms`);
console.log(`Render: ${(frameTimeRef.renderEnd - frameTimeRef.logicEnd).toFixed(2)}ms`);
session.requestAnimationFrame(arguments.callee);
});上述代码展示了如何在单帧内通过三个时间点切分耗时。运行该程序后，控制台会输出类似 “Logic: 2.50ms” 和 “Render: 8.20ms” 的数据。开发者应重点关注 Logic 耗时是否超过 1-2ms，以及 Render 耗时是否导致帧率低于 90fps。若 Logic 耗时过高，需优化 updateScene 中的矩阵运算或场景遍历；若 Render 耗时过高，则需减少 Draw Call 或降低几何复杂度。
立即学习“Java免费学习笔记（深入）”；
如何监控 WebXR 会话期间的平均帧率与掉帧情况
单次帧的耗时波动可能具有偶然性，因此需要建立长周期的监控机制来统计平均帧率（FPS）和检测掉帧。实现方法是维护一个固定大小的环形缓冲区或使用滑动窗口算法，持续收集每帧的总耗时（即当前帧 start 与上一帧 start 之间的时间差），并据此计算瞬时 FPS。当瞬时 FPS 显著低于目标值（如 72fps 或 90fps）时，标记为掉帧事件。
let lastFrameTime = performance.now();
let frameCount = 0;
let totalFrames = 0;
let fpsHistory = [];
const WINDOW_SIZE = 60; // 监控最近60帧
function monitorFPS(currentTime) {
const delta = currentTime - lastFrameTime;
lastFrameTime = currentTime;
const instantFps = 1000 / delta;
fpsHistory.push(instantFps);
if (fpsHistory.length > WINDOW_SIZE) {
fpsHistory.shift();
}
totalFrames++;
const avgFps = fpsHistory.reduce((a, b) => a + b, 0) / fpsHistory.length;
if (instantFps < 70) { // 假设目标为90，低于70视为严重掉帧
console.warn(`Dropped Frame! Instant FPS: ${instantFps.toFixed(1)}`);
}
if (totalFrames % 60 === 0) {
console.log(`Average FPS over last ${WINDOW_SIZE} frames: ${avgFps.toFixed(1)}`);
}
}将此监控函数集成到 requestAnimationFrame 循环中，即可实时输出性能指标。预期结果是控制台每隔约一秒打印一次平均 FPS，并在发生卡顿时报警。通过观察 fpsHistory 数组的变化趋势，可以判断性能问题是持续性的（如内存泄漏导致的逐渐变慢）还是突发性的（如某次复杂的物理计算）。这种基于时间差的监控方式不依赖外部工具，完全在运行时内部完成，适合部署在最终用户环境中进行远程诊断。
WebXR 渲染线程与主线程的资源竞争如何影响耗时
在 WebXR 应用中，如果主线程执行了阻塞性操作（如大型 JSON 解析、复杂布局重排或同步网络请求），会导致 requestAnimationFrame 回调延迟触发，进而直接增加 logicEnd 与 start 之间的时间差，表现为“逻辑耗时”飙升。这种现象并非 GPU 性能不足，而是 JavaScript 主线程被占用所致。解决思路是将非关键任务移至 Web Worker，或在 XRFrame 回调中仅保留最必要的姿态更新和渲染指令。
