Unity VR一体机优化实战：从8 FPS到72 FPS的完整复盘

先说结论：一个用 Unity 开发的卡通风格化 VR 项目，在 PICO Neo3 上一体机模式跑，最初平均帧率只有 8 FPS，画面基本等于幻灯片加高延迟。我花了大约两周时间，最终把帧率拉到 72 FPS 并且稳定锁定，过程中动过的刀有遮挡剔除、合批、Shader 瘦身、光照方案替换、后处理压缩、渲染缩放和注视点渲染，每一刀下去帧率都有可感知的提升。这篇就当我的复盘笔记，适合正在做 Unity VR 一体机项目的朋友参考，尤其是跟我一样在风格化美术路线里挣扎的——它比你想的更容易卡，但也比你想的更有优化空间。

1. 项目背景：一个"看起来很美"的风格化场景是怎么卡成幻灯片的

1.1 我的处境：NPR 美术路线的甜蜜陷阱

项目是个产品展示类的 VR 体验，美术选的是卡通风格化渲染（NPR，非真实感渲染）路线，人物是赛璐璐质感的二次元角色，场景里有几个展台、一圈主题墙和若干可交互道具。这种路线的卖点是辨识度高、氛围感强，客户一眼就喜欢。问题也出在这——NPR 不等于低负载，为了维持"卡通味"，场景里塞满了描边、色阶渐变、边缘光、半透明粒子特效。

最初一次实机 Demo 我永生难忘：戴上 PICO Neo3，转头动作稍微快一点，画面就出现明显的卡顿和撕裂，手部控制器摆动半秒才跟手，同屏的研发小哥直接笑出声说"这是 PPT 版 VR"。当时的帧率记录平均 8 FPS，最低能掉到 5 FPS 以下。说句实话，那一刻项目里没有人觉得这东西还能救回来——包括我自己。

我先说一个判断：这种卡顿并不是某一个单点问题，而是整个渲染链路上每个环节都在超支。风格化项目尤其容易陷入"每个效果都不算贵、但加起来爆了"的境地。所以后来我做优化的思路很明确：先量化每一笔开销，再从最贵的项目动手，而不是靠感觉乱调。

1.2 先把账算明白：72 FPS 意味着什么

在做任何优化之前，我先把目标帧率换算成了帧时间。PICO Neo3 默认刷新率是 72Hz，也就是说每帧只有约 13.9ms（1000/72）的预算。而 8 FPS 对应的帧时间是 125ms——两者差了整整 9 倍。这 9 倍里既包含 GPU 的渲染压力，也包含 CPU 端提交命令、游戏逻辑、资源加载等所有环节的压力。

另外必须强调一个 VR 特有的认知：平均帧率达标没有意义，稳定才是生命线。普通手游跑 60 FPS 偶尔掉到 40，玩家可能只是觉得"有点卡"；VR 里帧率一旦低于刷新率，头显就要做补帧和空间扭曲，画面会发虚、错位，眩晕感立刻上来。所以我的目标不是"从 8 到 72"这么简单，而是"每一帧都稳定锁在 13.9ms 以内"。

顺带说一嘴硬件底牌。PICO Neo3 用的芯片是高通骁龙 XR2，GPU 是 Adreno 650，放在手机端算是旗舰级别，但真被拉进 VR 场景里要求就不一样了：双眼渲染分辨率 3664x1920，每帧要处理的像素大约是 700 万——这是普通手机屏幕的两到三倍。换句话说，一个在手机上"随手写写"的 Pass，在 VR 里就要吃掉两到三倍的开销。这也是为什么很多人把做好的普通移动端项目直接打包到一体机上，帧率会惨不忍睹。

1.3 优化前必须做的性能基线记录

我建议所有优化工作开始之前，先做一版性能基线。我的做法是：把项目用 Vulkan 图形 API、开启开发构建，通过 adb 连接实机；在场景里固定一条飞行路径，戴上头显走 3 分钟，期间用 Unity Profiler 和 PICO 侧的帧率工具记录数据；最后导出一份带 CPU、GPU、渲染线程、DrawCall、三角形数的截图。

为什么要盯实机而不是盯编辑器？因为编辑器的 Profiler 数据在 PC 显卡上没有任何参考价值，VR 一体机的发热降频、驱动开销、双重渲染这种东西只能在真机上暴露出来。基线数据出来了，优化方向才不是猜。当时我的基线是这样的：平均帧率 8 FPS、单帧耗时约 125ms，其中主线程 25ms、渲染线程 20ms，GPU 独占 80ms 以上。看到这个分配，我基本明白了：这是一个 GPU 重负载项目，CPU 端的逻辑和渲染提交还算健康，问题全部集中在怎么把 GPU 从 80ms 压进 6-7ms 里面。

这里有一个值得记住的经验：先看帧时间大头在哪，再动刀。如果 CPU 主导，你拼命压 GPU 就没用；反过来也一样。这也是很多新手优化两天没动静的原因——一直在优化错误的一侧。

2. 问题定位：不靠猜，用 Profiler 和抓帧工具把病根挖出来

2.1 四个工具的配合使用

这一节我直接给出当时用的工具清单和分工：

• Unity Profiler：看 CPU 主线程、渲染线程、GPU 时间占比，以及 GC、资源加载、内存水位。我习惯把 CPU Usage 和 Rendering 两个模块同时开，一个看逻辑开销，一个看渲染开销。
• RenderDoc：抓取单帧渲染数据，看 DrawCall 调用记录、Pass 数、贴图绑定、Overdraw 情况。它能把"为什么这个物体这么慢"拆开看。
• adb + gfxinfo：取系统层面的帧时间分布，尤其适合判断"用户可感知的卡顿"是否真实存在，也能辅助查看掉帧峰值落在哪一秒。
• PICO 侧的开发者调试工具：主要用来看 HMD 渲染的帧率、掉帧位置和重投影状态，工具名因 SDK 版本不同有差异，以你手头版本为准。

连接实机没什么可多说的：开启开发者模式后用 adb devices 确认设备在线，Unity Profiler 选择对应的 Android 设备即可远程分析。RenderDoc 抓帧需要以 Vulkan 或 GLES 启动项目，然后在捕捉界面选择设备进程、点击 Capture。关键是这四样工具数据要互相印证，防止被单一工具误导——比如 Profiler 报 GPU 高，但 RenderDoc 里 Pass 数并不多，那可能是驱动层问题，方向和常规优化就完全不同了。

2.2 一帧 RenderDoc 抓帧日志能告诉你什么

我在初始版本上抓了一帧，日志量大得离谱。整理后的关键信息是这样的：

• DrawCall 总数 350 以上，静态合批几乎没有生效，场景中大量小物件以独立批次提交；
• 顶点三角形总量在 300 万到 400 万之间，对于这个场景规模来说明显超标；
• 主方向光照开了实时阴影，导致每帧额外多了一层阴影 Pass，每个角色的 Shadow Caster 还要再跑一遍顶点；
• 角色描边用的是典型的 Inverted Hull（背面放大加正面剔除）方案，单个角色至少 2 个额外 Pass，相当于角色整体渲染成本翻了三倍；
• Bloom、屏幕空间环境光遮蔽（第三方实现）和屏幕空间描边同时挂在后处理链表里，每个全屏效果都要在 3664x1920 的帧缓冲上跑一遍；
• 粒子系统数量倒不算多，但半透明粒子存在大面积重叠，Overdraw 严重，粒子区域帧缓冲写入次数高达 5-6 层。

看到这里我反而松了口气：没有"显卡烧坏"这种玄学问题，全是能理解和能控制的开销。这类问题虽然多，但排队有序，从最贵的开始砍，效果非常稳定。

2.3 判断优先级：哪些值得先动，哪些不能动

给问题排优先级的时候，我用了两个标准：一是这项开销占总渲染成本的比重，二是动它是否会影响美术效果表达。两者冲突时就找替代方案，而不是硬砍。优先级高的项是：Overdraw 和阴影 Pass、角色描边 Pass 数、DrawCall 冗余、后处理全屏开销。优先级相对低的是顶点数量——因为 300 万三角形在这个场景规模下还能压，但压面数要动模型，修改成本和返工量都很大，不如先把渲染管线里的浪费清掉。

我特别不建议一开始就去调渲染分辨率或加注视点渲染（FFR）。那属于"压画质换性能"的保底手段，应该在所有结构性优化做完之后再用。早早就把分辨率降到 0.8，后面每一项优化带来的画质损失都会被放大，而且你根本分不清帧率的提升到底来自分辨率还是来自结构优化。先把结构问题清干净，再用分辨率或者 FFR 做最后收口，这才是合理顺序。

3. 从 8 到 72 的核心优化动作，按性价比排序

3.1 第一刀：遮挡剔除、视锥剔除和静态标记一起做

很多 Unity 项目在 VR 一体机上性能不行，第一反应是换硬件或者压画质，但往往连最基础的遮挡剔除都没开。我检查项目时发现，遮挡剔除压根没烘焙，场景里大量被墙面、柱子挡住的物体依然在提交绘制，GPU 有一大块时间在渲染玩家根本看不见的东西。

VR 场景的视线范围特别窄，玩家视野大概 100 度左右，而且头显追踪方向经常被物体挡住，所以遮挡剔除的收益比普通手机项目更明显。我的做法是：把主结构静态物体的 Static 标志勾上，并且把 Occluder 和 Occludee 都设置好，入口在 Window > Rendering > Occlusion Culling；选择场景里的主体墙面和柱子作为 Occluder，其余小道具作为 Occludee，原则是"最大最密的物体优先做 Occluder，别拿一堆细碎物体去挡大面积视线"；调整烘焙分辨率，在 PICO 上我通常用中间档，烘焙耗时十几分钟；烘焙完成后走 Profiler 对比 DrawCall 变化。

结果很实在：DrawCall 从 350 降到 280 左右，FPS 从 8 涨到 10-11。注意，这一步的收益不像后面那么夸张，因为场景并不算大。但它至关重要——它把"无效绘制"这个基础浪费清掉了，为后面的每一刀腾出了干净的空间。我见过一些项目做完遮挡剔除后 FPS 直接翻倍的，但那通常是开放场景；我们这个紧凑展馆场景，收益差不多 20%。

另外别忘了视锥剔除本身有没有生效。如果场景里物体的 Bounds 设置有问题，比如 SkinnedMeshRenderer 的 Bounds 没更新，CPU 端裁剪效率会变低，同样会拉高开销。当时角色动画的 Bounds 我手动调过一版，结果对裁剪影响不大，但对阴影合框的影响特别大，这部分在后面阴影部分还会涉及。

3.2 第二刀：把 DrawCall 从 280 压到 110——合批三板斧

DrawCall 在移动 GPU 上到底贵不贵，一直是争论话题。但对 VR 一体机来说，每一个 DrawCall 都要经过 CPU 驱动层提交、GPU 顶点处理、光栅化前准备，成本比 PC 高得多。350 个 DrawCall 放在 PC 上毫无感觉，放在 Adreno 650 上就是巨大的时间黑洞。

我用的合批三板斧，按对项目的收益排序：

第一，SRP Batcher。我们用的是 URP，SRP Batcher 属于管线级缓存方案。我打开 Project Settings > Graphics，把 SRP Batcher 开关打开，然后用 Frame Debug 检查每个批次的类型——凡是显示 SRP Batcher 的批次都说明材质属性被缓存复用。当时只做这一步，DrawCall 就从 280 降到 180 左右，因为场景里大量物体共用同一套 URP 风格化 Shader，材质属性缓存后，Shader Pass 可以整批提交，省掉了大量的切换开销。

第二，静态合批。静态合批把不会移动的物体在运行前合并成一个大的网格提交，DrawCall 继续往下压。要注意的是，静态合批虽然省 DrawCall 但会涨内存，合并后的顶点数据要常驻显存，所以只对关键静态物体开启，不能无脑全勾。

第三，GPU Instancing。场景里有大量重复的小道具、椅子、灯箱，这些用 GPU Instancing 渲染时，每批次可以塞几十上百个实例。我给这些重复物体统一材质和网格，然后直接开启 Instancing，渲染线程的压力又降一截。

做完这三板斧，DrawCall 稳定在 110 左右，FPS 从 11 涨到了 24-28。这里我说一句真心话：DrawCall 的数量不是唯一指标，但它是风格化 VR 项目最容易立刻见效的指标。Frame Debug 里看到一排排 Batch 变成 Instanced 和 Static Batch 的时候，那种成就感比改任何 Shader 都强。

3.3 第三刀：风格化 Shader 瘦身——从 5 个 Pass 减到 2 个

到这一步，GPU 时间大头已经到了 Shader 这里。先还原一下当时的风格化角色 Shader：漫反射用 Ramp 贴图做色阶，主光方向计算，然后叠加一层菲涅尔边缘光，再叠加一层高光，最后是 Inverted Hull 描边——加起来 5 个 Pass 朝上，每个角色都要完整跑一遍。

这种"什么效果都想要"的 Shader，在 PC 上没毛病，但 VR 里等于每个像素烧了五遍钱。我的做法是重新拆分 Pass：

• 漫反射色阶：保留，这是风格化的灵魂；
• 菲涅尔或者边缘光：合进同一个 Pass，用 uv 和 NdotV 算边缘 Mask，不再额外开 Pass；
• 高光：直接砍掉，或者改成单张贴图控制的静态高光，不参与实时计算；
• 描边：彻底换方案。Inverted Hull 对模型依赖大，每个角色额外 2-3 个 Pass，我切到了屏幕空间描边加法线细节的方案——用深度和法线信息在后处理阶段生成描边，角色 Shader 只留一个 Pass 负责输出必要属性，描边的视觉厚度可以通过后期参数控制。这里要说明，屏幕空间描边会有一些细节丢失，比如细曲面边缘容易断线，但对项目的整体卡通感来说完全够用，而且性能比 Inverted Hull 好一个数量级。

Shader 瘦身做完之后，角色的渲染成本从三倍变成一倍多一点，GPU 帧时间肉眼可见下降。当时 Profiler 里 GPU 的时间从大概 50ms 压到 22ms，FPS 从 28 涨到了 40 上下。这一步是我整个优化过程中收益最大的一刀，也回答了开头那个问题：NPR 卡不一定是因为卡通，而是因为实现卡通的方式太低效。

还有一个容易被忽视的点：Shader 变体。URP 默认会给每个 Shader 生成一整套变体，如果项目里开了很多无关的 Keyword，编译出来的变体数量能到几千个，没有预编译的变体在运行时第一次使用会产生卡顿。我用分析器扫了一遍，把用不到的 Keyword 全部删掉，场景里常用 Shader 的变体数从 800 多压到 200 以内。这个动作不直接影响稳态帧率，但显著减少了运行时加载闪断，对体验的稳定性影响很大。

3.4 第四刀：实时阴影换烘焙，光源数量砍到最低

我一开始没敢动光照方案，因为美术对阴影质量有要求：展台上需要有清晰的接触阴影。但 Profiler 数据把这个矛盾摆到了台面上——实时方向光阴影一开，每帧都要生成 Shadow Map，VR 双通道下相当于场景整体光栅化三遍，这个成本对一体机来说是毁灭性的。

我的取舍是：静态场景完全走烘焙光照。整个展馆的 Lightmap 烘焙出来后，接触阴影用烘焙的高分辨率 AO 和方向贴图把细节找回来；动态角色用 Light Probe 组承接照明，不再单独开实时阴影。如果你确实还需要一点动态阴影，那次时代的妥协方案是：实时阴影只留给主角色，阴影分辨率压到 1024，阴影距离控制在 3 米内，同时把软阴影关掉。

做完这些，GPU 帧时间又降了 5ms 左右，FPS 稳定在 50 出头。美术部的反馈是"感觉画面变平了一点"，但戴上头显体验后基本都接受了——在 VR 里，动态卡顿的画质损失远比阴影细节更容易被注意到。这个取舍我觉得很值：先用静态烘焙保住空间感和基础氛围，等 GPU 预算有富余了，再考虑能不能给主角加点动态阴影。

3.5 第五刀：后处理全屏特效，从三个减到一个半

后处理是 VR 性能的隐形杀手。设备要渲染 700 万像素，一个全屏 Bloom 会让所有像素再经过一遍，环境光遮蔽又让所有像素多次采样。我们当时后处理链表里同时挂了 Bloom、屏幕空间环境光遮蔽和屏幕空间描边，等于每一帧画面被反复画了好几轮。这种集成方式在 PC 上不会有问题，在 XR2 上就是灾难。

我的处理原则是：把 3D 渲染像素里的"额外计算"尽量减掉，同时把屏幕空间计算降到最少。首先，环境光遮蔽直接移除，风格化场景靠烘焙 AO 和手摆 AO 撑立体感，不需要实时环境遮蔽；其次，Bloom 保留但降档，质量等级调到 Medium 或 Low，采样次数大幅下降，视觉上光晕的感觉还在，只是边缘稍微紧一点；最后，把屏幕空间描边和 Bloom 合并到一个后处理 Pass 里做——先用半分辨率做 Bloom 运算，再在同一个 Pass 里做边缘检测，避免第二次全屏遍历。

这一套下来，GPU 帧时间从 22ms 压到了 13ms 附近，FPS 从 50 涨到了 62 左右。需要提醒一句：后处理降级是最"画质敏感"的操作，一定要在实机上反复对比，别只看编辑器里的画面。我在 PICO 上和外部显示器上分别看过，确认没有明显的脏画面才定下来。

当时的经验是，每个后处理效果都要问三个问题：用户真的注意到它了吗？它在这个场景里承担了什么视觉目标？能不能在着色器或者纹理层面完成同样效果？能省就省，一个都不留。以此为标准，我在项目里砍掉了三个多余后处理项，把 GPU 预算全部还给了场景主次表现。每次我忍不住想加一个"看起来好看"的特效时，就把这三个问题重新问一遍，能过就加，过不了就压进烘焙、贴图或者 Shader 里。

3.6 最后一刀：渲染缩放与固定注视点渲染兜底

结构优化做完，FPS 已经到了 62 左右，离 72 还差一口气，而且这一口气不是靠某个大项能补上的，要靠整体预算收口。这个阶段才轮到渲染分辨率和固定注视点渲染。

渲染分辨率说的是内部渲染分辨率，不是屏幕物理分辨率。PICO Neo3 物理分辨率是 3664x1920，渲染管线一般不会按 100% 跑，XR SDK 里有一个渲染缩放系数，我用 1.0 和 0.92 之间做了几组测试。0.92 的缩放意味着渲染像素总量减少约 15%，视觉上几乎分不清，但 GPU 压力立刻下来。

固定注视点渲染（FFR）是 XR 设备的标配能力：人眼只有中心区域分辨率极高，边缘区域天然模糊。PICO 的 XR SDK 提供级联设置，可以把画面外围的渲染密度降低，中心保持 100%。我当时开的是低档位，画面边缘的分辨率下降虽然能在静态图里看出模糊，但动态观察时，人眼追踪的中心区域保持清晰，画面体验完全没问题。

这两个设置加在一起，GPU 帧时间从 13ms 压到了 8ms 左右。至此帧率来到 72 FPS 并稳定锁住。最后我在 Profiler 里看到满帧的绿色曲线时，那种感觉比拿到任何牌子的认可都开心。这一阶段如果你用 PICO 官方 SDK，相关配置入口通常都在"渲染设置"分类下，不同版本的接口名字可能不同，但原理就这些：先压渲染量，再压边缘像素，最后保中心清晰。

4. 优化前后数据复盘：每一刀到底带来了多少

4.1 分阶段帧率与帧时间变化表

我完整记录了每个主要动作前后的数据，以下是简化版：

表格里 DrawCall 在 Shader 阶段几乎没变，因为 Shader 瘦身砍的是顶点和像素处理次数，不是批次数量；而光照阶段也没怎么动 DrawCall，主要是省了 Shadow Pass 的光栅化。这说明什么？说明 DrawCall、三角形数量、像素 Shader 开销、Overdraw 是几根独立的柱子，每一项都要单独度量，不要互相替代。

4.2 帧时间结构的变化，CPU 和 GPU 的平衡

初始 125ms 的帧时间里，GPU 占了大头。优化后期，GPU 时间反而比 CPU 时间更小：GPU 约 7ms，主线程约 5ms，渲染线程约 2ms，合计在 13.9ms 内完成。这个分布是我追求的状态：GPU 不能成为瓶颈，CPU 也不应该排队等待。

VR 渲染有个特殊点：CPU 要提前提交渲染命令，GPU 再执行，引擎会在两者之间做流水线重叠。如果 GPU 时间远小于刷新间隔，CPU 提交晚了几毫秒也没关系；反过来，如果 GPU 是瓶颈，哪怕 CPU 空闲到冒烟，画面也是卡的。所以我们优化方向上一直朝"先救 GPU"走，这个判断在数据上被完全验证了。

后面我还做了一次 CPU 侧清理：场景里每帧都有几处 LINQ 调用和若干次 GC Alloc，虽然量不大，但会偶尔造成掉帧峰值。我把高频代码改成缓存和对象池，虽然稳态帧率没变，因为 GPU 预算已经富余了，但 Profiler 的帧时间曲线明显更平，P95 帧时间从 16ms 降到 14ms 以内。在 VR 项目里，我宁可牺牲一点内存也要把峰值压住，因为掉帧远比占用一点内存的体验危害大。

4.3 验证方法：别只看平均帧率，要看 P95 和掉帧曲线

优化完成后，我在 PICO 上连续飞行测试 10 分钟，全程记录帧时间分布。评判标准我定为：

• 平均帧率不低于 71.5 FPS；
• P95 帧时间不超过 14.2ms，略小于 13.9 的预算，留一点余量；
• 全程掉帧次数低于 5 次；
• 掉帧峰值不超过 30ms，也就是不超过两帧。

为什么要看 P95 而不是平均？因为平均掩盖了抖动。曾经有一段代码在优化后平均帧率还是 72，但每 3 秒钟会有一次 20ms 的尖刺，体感上就是"每隔一会抽一下"。用平均帧率评估，你根本看不到这个问题。只有把帧时间曲线拉出来，把尖刺当成安全事故来找，VR 的稳定性才有保证。

另外我也专门检查了发热降频：PICO Neo3 在长时间负载后芯片会降频，如果在降频点帧率仍能控制在 69-72 之间，才算通过。我们最终测试里，连续 20 分钟没出现明显降频带掉的帧，说明性能预算还留了 5%-10% 的余量。这个余量很重要，因为真到了用户手里，环境温度和后台进程你都控制不了。

5. 容易被忽略的坑与工程经验，全写在下面

5.1 VR 优化和手机游戏优化的本质差别

做过多年的手机优化再转 VR 优化，你会发现两个思路差别非常大。第一，VR 的渲染面积是双通道，因此 DrawCall、三角形、像素费全部按双倍算，很多在手机上还是"可以考虑"的操作，在 VR 里直接就是灾难；第二，VR 对帧时间稳定性的要求极高，手机游戏的"稳定 30 FPS 甚至偶尔 45"在 VR 里基本不合格；第三，头显设备的 GPU 虽然规格高，但功耗和散热受限，长时间高负载后面临降频，优化预算必须留出冗余。

另外很重要的是：VR 里玩家头部运动造成的画面变化，会在视觉上无限放大渲染瑕疵。比如一个 Shader 里轻微的锯齿、后处理降采样造成的像素网格，在静止截图中你察觉不到，但人眼在头戴显示器里旋转视线时能明显感知到"噪点感"。所以我做每一项"牺牲画质换帧率"的改动，都必须在头显里实际转转头、蹲下站起、快速甩视角测试一遍，绝不能在普通屏幕上验收。

5.2 风格化项目的专属陷阱：NPR 不等于低性能

很多团队选风格化路线有个潜意识：卡通渲染意味着不是写实，应该更轻量。这其实是个彻头彻尾的误解。NPR 项目最容易在三个地方失控：

第一，描边方案。Inverted Hull 类描边本质是让模型再渲染一遍并放大，别人一个模型一个 Pass，你三个角色光描边就占了 6 个 Pass，像素开销几乎翻倍。如果在项目早期就确定好描边要走屏幕空间还是法线，后期能省掉至少一次推倒重做。第二，色阶过渡。Ramp 贴图本身不贵，但如果每个模型都搞 2-3 层叠加色阶，还加上大量的材质分离，代价就起来了。第三，粒子特效。风格化项目很喜欢用光点、星尘、漂浮粒子来增强氛围，这些粒子的半透明叠加在 Overdraw 上非常夸张。

对风格化项目，我的建议是：在美术定案阶段就让 TA 提供一份性能预审报告，把 Shader Pass 数、材质实例数、粒子叠加层数写清楚，超过预算的让美术先出降级方案再实现。这个习惯如果能在项目前中期养成，后面比什么优化都省事。

5.3 给美术和策划的一份性能预算表

我整理了一份最简性能预算表，贴在项目群里当协作规范，这里直接贴出来给你们参考。如果你的设备也是 PICO Neo3 级别的一体机，可以照抄门槛，再根据实际美术量微调：

这张表不是吓唬美术，而是给团队一口标准锅。我建议用一张简单的性能测试关卡（固定路线 5 分钟的环游）作为门禁：每提交一次场景修改，跑一遍测试，超过表里的任一指标，先修复再继续做新内容。团队从"看感受"变成"看数字"之后，返工率下降非常明显。

5.4 我的实操心得：一次只改一个变量，从最贵的项目下手

这轮优化走下来，我最大的体会是：性能优化不是玄学，而是一套"测量-假设-验证"的工程方法。你每改一个变量，就重新记录数据，确定它带来的实际收益；被验证有效的改法保留，无效的立刻回滚。不要一口气做五个优化然后躺平，你根本分不清功劳属于谁，下次遇到问题还是不会定位。

另一个体会是优先级。我们这次收益排在前两位的是 Shader 瘦身和 DrawCall 合批，一个解决了像素处理和渲染指令量的问题，一个解决了提交开销的问题。这两个环节在风格化 VR 项目里几乎永远是最大头。先解决最大头，后面所有小优化才显得有意义，否则你优化半天细节，结果 GPU 还是被两个大坑拖死，帧率纹丝不动，人的心态很容易崩。

最后送大家一个小技巧：每一轮优化前，用录制功能把该阶段的 Profiler 数据存档，加上优化标签。这样哪怕三个月后项目因为需求变动性能回退了，你也能翻出存档，一句话定位"回退到了哪个状态的性能水平"。我在这次项目里就靠这个档案让三个月的性能没有反复。如果后面有机会，我会继续写一写 PICO 侧的 SDK 细调、AB 包加载和内存水位优化，那也是 VR 项目里值得做的一整套工程。