一体机 XR 性能优化实战

总预算 11.1 ms
├── 游戏线程（Game）    3.5 ms   逻辑、动画、物理、脚本
├── 渲染线程（Draw）    3.0 ms   剔除、排序、提交命令
├── GPU                 4.5 ms   光栅化、着色、后处理
└── 余量                0.1 ms   实际上需要留 1 ms 应对抖动

不同刷新率下的预算：
  72 Hz  → 13.9 ms 总预算，GPU 约 6.0 ms
  90 Hz  → 11.1 ms 总预算，GPU 约 4.5 ms
  120 Hz →  8.3 ms 总预算，GPU 约 3.5 ms

单眼 2064 × 2208 ≈ 4.56 M 像素
双眼合计         ≈ 9.12 M 像素

对比 1080p（2.07 M 像素）：
  Quest 3 的双眼像素数约为 1080p 的 4.4 倍

因此「1080p 上跑 60 fps」的场景，
在一体机上直接搬过来大约只能跑 15 fps。

Unreal：
  stat unit     → Game / Draw / GPU 三行时间，一眼看出瓶颈
  stat gpu      → GPU 各阶段耗时明细
  stat rhi      → DrawCall、三角形、显存
  stat scenerendering → 各渲染阶段

Unity：
  Profiler      → CPU 与 GPU 分栏
  Frame Debugger→ 逐 DrawCall 分析
  XR Stats      → 单眼/双眼分辨率与填充率

1. 脚本 Update 过多
   数百个 MonoBehaviour.Update 的调用开销本身就可观
   → 用统一的管理器集中更新，或用 ECS/Job System

2. 物理与动画开销
   骨骼数量、碰撞体数量、物理步进频率
   → 限制骨骼数、合并碰撞体、物理降频

3. GC 分配
   每帧 new 对象导致周期性 GC 停顿（可达数毫秒）
   → 复用对象池、避免装箱、避免字符串拼接

// 反例：每帧分配
void Update() {
    var list = new List<Enemy>();        // 每帧分配
    var s = "HP: " + hp.ToString();      // 字符串分配
}

// 正例：复用
readonly List<Enemy> _cache = new();
readonly StringBuilder _sb = new();
void Update() {
    _cache.Clear();
    _sb.Clear().Append("HP: ").Append(hp);
}

; 高收益配置示例
r.ScreenPercentage=80              ; 降分辨率，最有效
vr.FoveationLevel=2                ; 注视点渲染
r.Shadow.MaxResolution=1024        ; 降阴影分辨率
r.Shadow.CSM.MaxCascades=1         ; 只留 1 级级联
r.VolumetricFog=0                  ; 体积雾极贵
r.SSR.Quality=0                    ; 关屏幕空间反射
r.PostProcessAAQuality=0           ; 移动端用 MSAA 而非 TAA

固定分辨率的两种错误：
  设得太高 → 掉帧，晕
  设得太低 → 帧率有余量但画面糊

动态分辨率的作用：
  按当前帧时间自动调整渲染分辨率
  帧时间超预算 → 降分辨率（直到下限）
  帧时间有余量 → 升分辨率（直到上限）

; UE 动态分辨率配置
r.MobileDynamicResolution=1
r.Mobile.DynamicResolution.MinScreenPercentage=70
r.Mobile.DynamicResolution.MaxScreenPercentage=100
r.MobileContentScaleFactor=0.85

分辨率与像素数的关系（容易算错）：
  缩放系数 0.8 → 像素数变为 0.8² = 64%
  缩放系数 0.7 → 像素数变为 0.7² = 49%

因此从 1.0 降到 0.8，GPU 渲染负载几乎减半，
这是一体机上单点收益最大的调整。

FFR 与降分辨率的区别：
  降分辨率：整体均匀降低 → 中心也糊
  FFR：中心保清晰，只降周边 → 观感损失更小

因此 FFR 的优先级高于降分辨率：
  先开 FFR 等级 2，再考虑降分辨率到 0.85

功耗预算（Quest 3 量级）：
  屏幕与背光      约 3~5 W
  追踪与传感器    约 1~2 W
  SoC（CPU+GPU）  约 5~8 W
  整机           10~15 W

电池：约 5000 mAh / 3.8 V ≈ 19 Wh
续航 ≈ 19 Wh / 12 W ≈ 1.6 小时

1. 主动降载：检测到温度上升，主动降分辨率与帧率
2. 分级策略：温度区间对应不同的降载档位
3. 用户可见：在设置里显示「设备温度较高，已降低画质」
4. 避免锯齿：降载要平滑过渡，不能突然掉帧

温度区间示例（表面温度）：
  < 38 ℃  正常，全性能
  38~42 ℃ 轻度降载（分辨率降 10%）
  42~45 ℃ 中度降载（分辨率降 20%，帧率降档）
  > 45 ℃  重度降载（限制帧率到 72，关闭阴影）

ASTC 块大小与质量：
  4x4  → 8 bpp，质量最好，体积大
  6x6  → 3.56 bpp，平衡（推荐）
  8x8  → 2 bpp，体积小，细节损失明显
  12x12 → 0.89 bpp，仅适合粗糙纹理

经验：UI 与法线贴图用 6x6，远处环境贴图用 8x8。

判断某个特性是否值得保留的方法：
  关掉它，看帧时间下降多少，再看观感损失多少
  若帧时间降 15% 以上而观感损失可接受 → 关掉

  典型结论：
    体积雾 → 关（省 20%~30%，观感影响小）
    实时阴影 → 减到 1 个（省 15%~25%）
    Bloom → 保留（省不到 5%，观感影响大）

adb logcat -s ThermalManager:V VrApi:V     # 热状态与降频日志
adb shell dumpsys thermalservice           # 系统热服务状态
adb shell ovrgpuprofiler -t                # Quest 专用 GPU 时间抓取

第 0 步：建立基线
  □ 打包版本 + 真机 + 目标帧率
  □ 记录 stat unit 的三项时间
  □ 记录设备温度与功耗

第 1 步：定位瓶颈
  □ 判断 Game / Draw / GPU 谁是主导
  □ 用 Profiler 下钻到具体函数或渲染阶段

第 2 步：按收益排序优化
  □ 降分辨率（收益最大，先做）
  □ 开注视点渲染等级 2
  □ 关体积雾、降阴影分辨率与级联数
  □ 减少 Overdraw 与半透明
  □ 纹理压缩与流送
  □ 减少 DrawCall（合批、实例化、LOD）

第 3 步：稳定性
  □ 开动态分辨率保帧率稳定
  □ 加主动热管理降载策略
  □ 检查 GC 分配是否为零

第 4 步：验证
  □ 连续运行 30 分钟看是否降频
  □ 在最重场景下测量
  □ 让非开发者试戴确认观感可接受