1. 项目背景与优化目标拆解1.1 为什么 PICO Neo3 上的 8 FPS 是个典型困局PICO Neo3 搭载的是高通骁龙 XR2 平台GPU 是 Adreno 650CPU 是 Kryo 585 架构从硬件规格上看它本质上就是一台被塞进头显里的旗舰级手机。很多从 PC 端 VR 或者从 Unity 编辑器直接打包上来的项目第一次跑在这台设备上时帧率会惨不忍睹——我手上这个项目最初实测就是 8 FPS画面卡成幻灯片转头延迟高到让人晕眩。这个数字不是偶然的。8 FPS 意味着单帧耗时 125 毫秒而 VR 的硬性门槛是 72 FPS单帧 13.9 毫秒中间差了将近 9 倍。更关键的是VR 是双目渲染左右眼各渲染一次实际 GPU 负载是普通手游的两倍左右。所以当你在编辑器里看到 60 FPS 的场景搬到 Neo3 上很可能直接掉到 20 FPS 以下。我拿到这个项目时的第一反应不是急着改代码而是先做性能归因。因为盲目优化是最容易踩坑的——你可能花三天优化了 Shader结果发现瓶颈其实在 CPU 的 DrawCall 上。这个项目的美术风格是风格化卡通渲染NPR用了大量自定义 Shader、描边、渐变贴图还有不少半透明特效这些都是移动端 VR 的性能杀手。1.2 优化目标的量化拆解我把目标拆成了几个可量化的指标而不是笼统地说要流畅指标项优化前目标值说明平均帧率8 FPS72 FPS单帧预算 13.9msCPU 主线程约 90ms 8ms留出余量给 GPUGPU 耗时约 110ms 12ms双目合计DrawCall约 480 120移动端建议值SetPass Call约 210 40影响状态切换开销三角面数约 180 万 60 万单眼可见纹理内存约 1.2GB 400MB避免带宽瓶颈这张表是我做优化时的作战地图。很多人优化 VR 只盯着帧率看但帧率是结果不是原因。真正要控制的是上面这些中间指标。比如 SetPass Call 这个指标很多新手根本没听说过但它直接决定了 GPU 的状态切换次数在移动端 Tile-Based 渲染架构下状态切换的代价比桌面端大得多。提示PICO Neo3 的屏幕刷新率是 72Hz所以 72 FPS 是及格线不是优秀线。如果项目有余力建议往 90 FPS 冲因为帧率越高运动到成像延迟Motion-to-Photon Latency越低晕动症越轻。1.3 优化前的准备工作先测量再动手在动任何一行代码之前我做了三件事这三件事后来证明是整个优化过程中最省时间的决定。第一用 Unity Profiler 连接真机抓取数据。注意不是连编辑器是连真机。编辑器的性能数据和真机差得离谱尤其是 GPU 部分。连接方式是通过 USB 调试在 Profiler 里选择 AndroidPlayer然后重点看 CPU Usage、GPU Usage、Rendering 三个模块。第二开启 PICO 的 Performance Overlay。PICO 开发者后台有一个实时性能面板可以显示当前帧率、GPU 利用率、CPU 利用率、温度。这个面板的好处是它不占用 Profiler 的采样开销能反映最真实的运行状态。第三做一次裸场景基线测试。我把场景里所有物体隐藏只留一个空相机测出这台设备在当前渲染管线下的空场景帧率。结果是 72 FPS 满帧说明设备本身没问题问题全在场景内容上。这个基线很重要它告诉你优化的天花板在哪里。2. 核心瓶颈定位与优化思路2.1 用 Profiler 定位真正的瓶颈真机 Profiler 抓下来的数据让我有点意外。我原本以为瓶颈在 GPU因为风格化渲染的 Shader 通常很重。但数据显示CPU 主线程耗时 90ms其中 Camera.Render 占了 55ms而 GPU 耗时只有 40ms 左右。也就是说CPU 在等 GPU但 GPU 其实没那么忙——典型的 CPU Bound。进一步展开 Camera.Render发现里面主要是Culling剔除和 Sorting排序的开销。场景里有大量小物件每个都有自己的 RendererUnity 在做视锥剔除和排序时花了大量时间。同时 DrawCall 高达 480SetPass Call 210这两个数字在移动端是灾难级的。GPU 这边虽然只有 40ms但相对 12ms 的目标还是超了 3 倍多。主要开销在半透明特效的 Overdraw和描边 Pass 的额外绘制上。风格化渲染的描边通常是第二个 Pass等于把模型画了两遍Overdraw 直接翻倍。2.2 优化策略的优先级排序基于上面的数据我制定了这样的优化优先级先降 DrawCall 和 SetPass Call——这是 CPU 瓶颈的主因收益最大再处理 Overdraw 和半透明——这是 GPU 瓶颈的主因然后优化 Shader 复杂度——降低每像素计算量最后做 LOD 和剔除优化——减少无效绘制这个顺序很重要。很多人一上来就优化 Shader结果 DrawCall 没降下来CPU 还是卡。正确的做法是先把画多少的问题解决再解决每笔画多贵的问题。2.3 渲染管线的选择为什么从 Built-in 切到 URP这个项目最初用的是 Built-in 渲染管线。Built-in 在移动端的问题在于它没有 SRP BatcherShader 变体管理混乱而且很多内置效果如后处理在移动端开销很大。我把它切到了URPUniversal Render Pipeline。切换的理由有三个SRP Batcher能大幅降低 SetPass Call只要 Shader 兼容 SRP Batcher相同 Shader 的不同材质可以合批不用改材质属性Shader 变体剥离URP 的 Shader 变体管理更清晰可以精确剥离不需要的变体减少包体和加载开销后处理栈优化URP 的 Volume 后处理在移动端有专门的优化路径比 Built-in 的 OnRenderImage 高效切换 URP 不是无痛的。所有自定义 Shader 都要重写成 URP 的 HLSL 结构光照模型、阴影、雾效都要重新适配。但这一步的收益是长期的值得投入。注意切 URP 之前一定要备份项目。我见过太多人切到一半发现某个 Shader 搞不定想回退又回不去。建议用 Git 开一个分支专门做管线迁移。3. DrawCall 与 SetPass Call 的实战优化3.1 静态合批与动态合批的正确用法DrawCall 从 480 降到 120我主要靠的是合批。但合批不是无脑开就行这里面有很多坑。静态合批Static Batching适用于场景中不移动的物体。开启方式是在 Player Settings 里勾选 Static Batching然后把物体的 Static 标记打开。但要注意静态合批会把所有静态物体的顶点数据合并到一个大 Mesh 里如果场景很大这个 Mesh 会非常占内存。我的做法是按区域分组把场景分成几个区块每个区块单独合批而不是全场景一个大合批。动态合批Dynamic Batching适用于小物件但有严格限制顶点数不能超过 300且不能使用不同的材质实例。在 URP 下动态合批的效果其实有限因为 SRP Batcher 已经能处理大部分情况。我的建议是优先用 SRP Batcher动态合批作为补充。实测数据对比合批方式DrawCallSetPass Call内存开销无合批480210低仅静态合批260150中静态动态200120中高静态SRP Batcher13045中全部开启11538高可以看到SRP Batcher 是降 SetPass Call 的关键。它不需要合并 Mesh只是把相同 Shader 的材质数据打包上传所以内存开销小效果却很好。3.2 GPU Instancing 在风格化场景中的应用场景里有大量重复的植被、石头、装饰物这些是 GPU Instancing 的完美目标。开启方式很简单在材质的 Inspector 里勾选 Enable GPU Instancing然后确保这些物体用的是同一个材质。但 GPU Instancing 有个限制每个实例的材质属性必须相同。如果你想让每棵树颜色不一样就得用 MaterialPropertyBlock而 MaterialPropertyBlock 会破坏 SRP Batcher 的合批。所以这里有个取舍如果物体数量多且外观一致用 GPU Instancing如果物体数量少但需要差异化用 MaterialPropertyBlock如果物体数量多且需要差异化考虑把差异烘焙到顶点色或贴图里我最后的方案是植被用 GPU Instancing 顶点色差异化。每棵树的颜色差异通过顶点色传递这样既保持了 Instancing又有视觉变化。3.3 图集合并与材质精简风格化渲染通常有很多小贴图渐变图、噪声图、遮罩图。这些贴图如果各自独立就会产生大量材质和 DrawCall。我的做法是把所有风格化贴图合并到一张 2048x2048 的图集里然后用 UV 偏移来采样。这样原本 20 多个材质可以合并成 2-3 个材质DrawCall 直接降一个数量级。合并图集时要注意贴图的 Wrap Mode 要统一否则采样会出问题图集边缘要留 Padding避免 Mipmap 采样时出现接缝用 Sprite Atlas 或者 TexturePacker 这类工具自动合并不要手动拼实操心得合并图集后Shader 里的采样代码要改成用图集 UV。我建议写一个宏或者函数来统一处理 UV 转换避免每个 Shader 都手写一遍容易出错。4. GPU 侧优化Overdraw、Shader 与后处理4.1 半透明特效的 Overdraw 治理Overdraw 是移动端 GPU 的头号杀手。所谓 Overdraw就是同一个像素被绘制了多次。半透明特效是 Overdraw 的重灾区因为每个半透明片元都要参与混合而且不能做深度剔除。我用Scene View 的 Overdraw 模式在 Scene 视图左上角的下拉菜单里选 Overdraw来可视化 Overdraw 情况。红色越深Overdraw 越严重。优化前的场景特效区域几乎全红。治理手段有几个缩小特效面积很多特效其实不需要那么大缩小 30% 视觉上几乎看不出但 Overdraw 直接降一半降低特效层数粒子系统的层数从 5 层降到 2-3 层用 Alpha Test 代替 Alpha Blend对于不需要半透明的部分如树叶、草用 Alpha TestCutout代替 Alpha Blend这样能参与深度写入减少 Overdraw控制特效的渲染顺序让不透明的先画半透明的后画减少无效混合实测下来光这一项就把 GPU 耗时从 40ms 降到了 25ms。4.2 风格化 Shader 的移动端精简风格化渲染的 Shader 通常包含基础色、阴影、高光、描边、边缘光、渐变映射。这些在 PC 上跑没问题但在移动端要精简。我的精简原则是能烘焙的烘焙能近似的近似能砍的砍。阴影从实时阴影改成烘焙阴影 简单的 Ramp 贴图。风格化渲染本来就不追求物理正确用 Ramp 贴图控制阴影过渡反而更符合美术风格高光从 Blinn-Phong 改成简单的 Step 函数风格化高光本来就是硬边的边缘光用顶点法线和视线方向的点积近似不用逐像素计算描边从屏幕空间描边改成背面外扩描边虽然质量略低但开销小很多Shader 里的数学运算也要精简。比如pow(x, 2)改成x * xnormalize能省则省sin/cos用查找表代替。这些微优化单个看起来不起眼但乘以百万级像素就很可观了。4.3 后处理栈的取舍URP 的后处理栈包含 Bloom、Color Grading、Vignette、Depth of Field 等。在移动端 VR 上Depth of Field 和 Motion Blur 基本不能用开销太大。Bloom 也要谨慎因为它是多 Pass 的而且分辨率越高越贵。我的后处理方案是Bloom保留但降低分辨率用 Half Res 或 Quarter Res并限制 Bloom 的半径Color Grading保留用 LUT 贴图开销很小Vignette保留开销可忽略其他全部关闭另外URP 的后处理默认是在双目渲染之后做的这意味着后处理要对两只眼睛各做一次。如果后处理很重可以考虑用Single Pass Instanced渲染模式让后处理只做一次。但 Single Pass Instanced 对 Shader 有要求需要适配。注意Single Pass Instanced 在 PICO Neo3 上需要开启 Multiview 支持。在 Player Settings 的 XR Settings 里勾选 Multiview然后在 URP 的 Asset 里开启 Single Pass Instanced。这个模式下Shader 里的unity_StereoEyeIndex会失效需要用UNITY_SETUP_STEREO_EYE_INDEX_POST_VERTEX宏来处理。5. LOD、剔除与场景管理优化5.1 LOD 分级与切换距离设置LODLevel of Detail是减少三角面数的经典手段。但 LOD 的设置很有讲究设置不好会出现跳变Popping在 VR 里跳变特别明显因为双眼视差会放大这种不连续感。我的 LOD 设置原则LOD0完整模型用于 0-5 米LOD170% 面数用于 5-15 米LOD240% 面数用于 15-30 米LOD315% 面数用于 30 米以上切换距离不是拍脑袋定的而是根据屏幕像素覆盖率来算的。一个物体在屏幕上占的像素越少LOD 就可以越低。我写了一个小工具在 Scene 视图里显示每个物体的屏幕像素覆盖率然后根据这个来调 LOD 距离。另外LOD 切换时可以用Cross Fade模式让两个 LOD 之间平滑过渡减少跳变感。但 Cross Fade 会增加 Overdraw所以要权衡。5.2 视锥剔除与遮挡剔除视锥剔除Frustum Culling是 Unity 默认开启的但它的效果取决于物体的 Bounds 设置。如果 Bounds 设置得过大剔除就会失效。我检查了场景里所有物体的 Bounds把那些 Bounds 明显偏大的重新计算了一遍。遮挡剔除Occlusion Culling在 VR 里特别有用因为 VR 的视野有限很多物体被墙壁、地形挡住。但遮挡剔除需要烘焙 Occlusion Data而且烘焙很耗时。我的做法是对静态场景烘焙 Occlusion Data对动态物体用Occlusion Portal或者手动控制烘焙时把 Smallest Occluder 和 Smallest Hole 调小提高剔除精度烘焙完后DrawCall 又降了 20 左右。5.3 场景分块与异步加载如果场景很大一次性加载所有内容会爆内存。我的做法是把场景分成多个区块用异步加载Addressables 或 AssetBundle按需加载。具体策略是玩家周围 20 米内的区块常驻内存20-50 米的区块预加载50 米外的区块卸载这样内存占用从 1.2GB 降到了 400MB 左右而且加载时的卡顿也少了。实操心得异步加载要注意加载时机。不要在玩家转头时加载因为加载会占用主线程导致掉帧。最好在玩家移动时、或者场景切换时加载。另外加载的优先级要根据玩家的朝向动态调整朝向哪边就先加载哪边。6. 常见问题与排查技巧实录6.1 优化后帧率不升反降的排查这是优化过程中最常见的问题。我遇到过好几次改了一堆东西结果帧率反而降了。原因通常有几个合批破坏了 SRP Batcher如果你用了 MaterialPropertyBlockSRP Batcher 会失效SetPass Call 反而升高LOD 切换太频繁如果 LOD 距离设置得太近物体会在 LOD 之间反复切换每次切换都有开销异步加载抢占了主线程加载线程和渲染线程抢 CPU导致掉帧Shader 变体爆炸如果 Shader 变体太多每次切换材质都要编译 Shader造成卡顿排查方法是用 Profiler 对比优化前后的数据看哪个指标变差了。不要凭感觉要看数据。6.2 PICO Neo3 特有的性能陷阱PICO Neo3 有几个特有的坑我在优化过程中踩过温度墙Neo3 跑久了会发热发热后 GPU 会降频帧率会掉。所以优化时要留余量不能贴着 72 FPS 跑最好留 10-15% 的余量电池模式Neo3 在省电模式下会限制性能测试时要确保设备在性能模式后台进程Neo3 的后台进程会占用 CPU测试前要清理后台Multiview 兼容性不是所有 Shader 都兼容 Multiview不兼容的 Shader 会渲染错误或者性能下降6.3 常见问题速查表问题现象可能原因排查方法解决方案帧率突然掉到 30温度墙降频查看设备温度降低 GPU 负载留余量转头时卡顿异步加载抢占主线程Profiler 看主线程调整加载时机画面闪烁LOD 切换太频繁Scene 视图看 LOD调整 LOD 距离左右眼画面不一致Multiview 不兼容检查 Shader适配 MultiviewSetPass Call 居高不下SRP Batcher 失效检查材质移除 MaterialPropertyBlock内存持续增长资源未释放Profiler 看内存检查 Addressables 释放6.4 优化过程中的经验教训最后分享几条我在这个项目里踩过的坑第一条不要过早优化。我一开始花了两天优化一个 Shader结果后来发现那个 Shader 只占了 2% 的 GPU 时间。优化要基于数据不要基于直觉。第二条优化要有优先级。先解决大头再解决小头。DrawCall 从 480 降到 120 的收益远大于把某个 Shader 优化 10%。第三条留余量。不要贴着 72 FPS 跑因为设备会发热、会有后台进程、会有峰值负载。留 10-15% 的余量才能保证稳定。第四条多测真机。编辑器的数据和真机差很多尤其是 GPU 部分。所有优化决策都要基于真机数据。第五条记录每次改动。我建了一个表格记录每次优化的改动、预期收益、实际收益。这样能快速定位哪些改动有效哪些无效。这个表格后来成了团队的优化知识库。这个项目从 8 FPS 优化到 72 FPS前后花了大约三周时间。其中 DrawCall 优化占了一周GPU 优化占了一周剩下的时间在做测试和调优。优化不是一蹴而就的是一个不断测量、改动、验证的循环。希望这些经验能帮到正在做 VR 优化的朋友少走一些弯路。 
长河君 · 2026/10/3 10:40:45 · 阅读 1.2k PICO Neo3 VR性能优化实战：从8 FPS到72 FPS的DrawCall与GPU调优
1. 项目背景与优化目标拆解1.1 为什么 PICO Neo3 上的 8 FPS 是个典型困局PICO Neo3 搭载的是高通骁龙 XR2 平台GPU 是 Adreno 650CPU 是 Kryo 585 架构从硬件规格上看它本质上就是一台被塞进头显里的旗舰级手机。很多从 PC 端 VR 或者从 Unity 编辑器直接打包上来的项目第一次跑在这台设备上时帧率会惨不忍睹——我手上这个项目最初实测就是 8 FPS画面卡成幻灯片转头延迟高到让人晕眩。这个数字不是偶然的。8 FPS 意味着单帧耗时 125 毫秒而 VR 的硬性门槛是 72 FPS单帧 13.9 毫秒中间差了将近 9 倍。更关键的是VR 是双目渲染左右眼各渲染一次实际 GPU 负载是普通手游的两倍左右。所以当你在编辑器里看到 60 FPS 的场景搬到 Neo3 上很可能直接掉到 20 FPS 以下。我拿到这个项目时的第一反应不是急着改代码而是先做性能归因。因为盲目优化是最容易踩坑的——你可能花三天优化了 Shader结果发现瓶颈其实在 CPU 的 DrawCall 上。这个项目的美术风格是风格化卡通渲染NPR用了大量自定义 Shader、描边、渐变贴图还有不少半透明特效这些都是移动端 VR 的性能杀手。1.2 优化目标的量化拆解我把目标拆成了几个可量化的指标而不是笼统地说要流畅指标项优化前目标值说明平均帧率8 FPS72 FPS单帧预算 13.9msCPU 主线程约 90ms 8ms留出余量给 GPUGPU 耗时约 110ms 12ms双目合计DrawCall约 480 120移动端建议值SetPass Call约 210 40影响状态切换开销三角面数约 180 万 60 万单眼可见纹理内存约 1.2GB 400MB避免带宽瓶颈这张表是我做优化时的作战地图。很多人优化 VR 只盯着帧率看但帧率是结果不是原因。真正要控制的是上面这些中间指标。比如 SetPass Call 这个指标很多新手根本没听说过但它直接决定了 GPU 的状态切换次数在移动端 Tile-Based 渲染架构下状态切换的代价比桌面端大得多。提示PICO Neo3 的屏幕刷新率是 72Hz所以 72 FPS 是及格线不是优秀线。如果项目有余力建议往 90 FPS 冲因为帧率越高运动到成像延迟Motion-to-Photon Latency越低晕动症越轻。1.3 优化前的准备工作先测量再动手在动任何一行代码之前我做了三件事这三件事后来证明是整个优化过程中最省时间的决定。第一用 Unity Profiler 连接真机抓取数据。注意不是连编辑器是连真机。编辑器的性能数据和真机差得离谱尤其是 GPU 部分。连接方式是通过 USB 调试在 Profiler 里选择 AndroidPlayer然后重点看 CPU Usage、GPU Usage、Rendering 三个模块。第二开启 PICO 的 Performance Overlay。PICO 开发者后台有一个实时性能面板可以显示当前帧率、GPU 利用率、CPU 利用率、温度。这个面板的好处是它不占用 Profiler 的采样开销能反映最真实的运行状态。第三做一次裸场景基线测试。我把场景里所有物体隐藏只留一个空相机测出这台设备在当前渲染管线下的空场景帧率。结果是 72 FPS 满帧说明设备本身没问题问题全在场景内容上。这个基线很重要它告诉你优化的天花板在哪里。2. 核心瓶颈定位与优化思路2.1 用 Profiler 定位真正的瓶颈真机 Profiler 抓下来的数据让我有点意外。我原本以为瓶颈在 GPU因为风格化渲染的 Shader 通常很重。但数据显示CPU 主线程耗时 90ms其中 Camera.Render 占了 55ms而 GPU 耗时只有 40ms 左右。也就是说CPU 在等 GPU但 GPU 其实没那么忙——典型的 CPU Bound。进一步展开 Camera.Render发现里面主要是Culling剔除和 Sorting排序的开销。场景里有大量小物件每个都有自己的 RendererUnity 在做视锥剔除和排序时花了大量时间。同时 DrawCall 高达 480SetPass Call 210这两个数字在移动端是灾难级的。GPU 这边虽然只有 40ms但相对 12ms 的目标还是超了 3 倍多。主要开销在半透明特效的 Overdraw和描边 Pass 的额外绘制上。风格化渲染的描边通常是第二个 Pass等于把模型画了两遍Overdraw 直接翻倍。2.2 优化策略的优先级排序基于上面的数据我制定了这样的优化优先级先降 DrawCall 和 SetPass Call——这是 CPU 瓶颈的主因收益最大再处理 Overdraw 和半透明——这是 GPU 瓶颈的主因然后优化 Shader 复杂度——降低每像素计算量最后做 LOD 和剔除优化——减少无效绘制这个顺序很重要。很多人一上来就优化 Shader结果 DrawCall 没降下来CPU 还是卡。正确的做法是先把画多少的问题解决再解决每笔画多贵的问题。2.3 渲染管线的选择为什么从 Built-in 切到 URP这个项目最初用的是 Built-in 渲染管线。Built-in 在移动端的问题在于它没有 SRP BatcherShader 变体管理混乱而且很多内置效果如后处理在移动端开销很大。我把它切到了URPUniversal Render Pipeline。切换的理由有三个SRP Batcher能大幅降低 SetPass Call只要 Shader 兼容 SRP Batcher相同 Shader 的不同材质可以合批不用改材质属性Shader 变体剥离URP 的 Shader 变体管理更清晰可以精确剥离不需要的变体减少包体和加载开销后处理栈优化URP 的 Volume 后处理在移动端有专门的优化路径比 Built-in 的 OnRenderImage 高效切换 URP 不是无痛的。所有自定义 Shader 都要重写成 URP 的 HLSL 结构光照模型、阴影、雾效都要重新适配。但这一步的收益是长期的值得投入。注意切 URP 之前一定要备份项目。我见过太多人切到一半发现某个 Shader 搞不定想回退又回不去。建议用 Git 开一个分支专门做管线迁移。3. DrawCall 与 SetPass Call 的实战优化3.1 静态合批与动态合批的正确用法DrawCall 从 480 降到 120我主要靠的是合批。但合批不是无脑开就行这里面有很多坑。静态合批Static Batching适用于场景中不移动的物体。开启方式是在 Player Settings 里勾选 Static Batching然后把物体的 Static 标记打开。但要注意静态合批会把所有静态物体的顶点数据合并到一个大 Mesh 里如果场景很大这个 Mesh 会非常占内存。我的做法是按区域分组把场景分成几个区块每个区块单独合批而不是全场景一个大合批。动态合批Dynamic Batching适用于小物件但有严格限制顶点数不能超过 300且不能使用不同的材质实例。在 URP 下动态合批的效果其实有限因为 SRP Batcher 已经能处理大部分情况。我的建议是优先用 SRP Batcher动态合批作为补充。实测数据对比合批方式DrawCallSetPass Call内存开销无合批480210低仅静态合批260150中静态动态200120中高静态SRP Batcher13045中全部开启11538高可以看到SRP Batcher 是降 SetPass Call 的关键。它不需要合并 Mesh只是把相同 Shader 的材质数据打包上传所以内存开销小效果却很好。3.2 GPU Instancing 在风格化场景中的应用场景里有大量重复的植被、石头、装饰物这些是 GPU Instancing 的完美目标。开启方式很简单在材质的 Inspector 里勾选 Enable GPU Instancing然后确保这些物体用的是同一个材质。但 GPU Instancing 有个限制每个实例的材质属性必须相同。如果你想让每棵树颜色不一样就得用 MaterialPropertyBlock而 MaterialPropertyBlock 会破坏 SRP Batcher 的合批。所以这里有个取舍如果物体数量多且外观一致用 GPU Instancing如果物体数量少但需要差异化用 MaterialPropertyBlock如果物体数量多且需要差异化考虑把差异烘焙到顶点色或贴图里我最后的方案是植被用 GPU Instancing 顶点色差异化。每棵树的颜色差异通过顶点色传递这样既保持了 Instancing又有视觉变化。3.3 图集合并与材质精简风格化渲染通常有很多小贴图渐变图、噪声图、遮罩图。这些贴图如果各自独立就会产生大量材质和 DrawCall。我的做法是把所有风格化贴图合并到一张 2048x2048 的图集里然后用 UV 偏移来采样。这样原本 20 多个材质可以合并成 2-3 个材质DrawCall 直接降一个数量级。合并图集时要注意贴图的 Wrap Mode 要统一否则采样会出问题图集边缘要留 Padding避免 Mipmap 采样时出现接缝用 Sprite Atlas 或者 TexturePacker 这类工具自动合并不要手动拼实操心得合并图集后Shader 里的采样代码要改成用图集 UV。我建议写一个宏或者函数来统一处理 UV 转换避免每个 Shader 都手写一遍容易出错。4. GPU 侧优化Overdraw、Shader 与后处理4.1 半透明特效的 Overdraw 治理Overdraw 是移动端 GPU 的头号杀手。所谓 Overdraw就是同一个像素被绘制了多次。半透明特效是 Overdraw 的重灾区因为每个半透明片元都要参与混合而且不能做深度剔除。我用Scene View 的 Overdraw 模式在 Scene 视图左上角的下拉菜单里选 Overdraw来可视化 Overdraw 情况。红色越深Overdraw 越严重。优化前的场景特效区域几乎全红。治理手段有几个缩小特效面积很多特效其实不需要那么大缩小 30% 视觉上几乎看不出但 Overdraw 直接降一半降低特效层数粒子系统的层数从 5 层降到 2-3 层用 Alpha Test 代替 Alpha Blend对于不需要半透明的部分如树叶、草用 Alpha TestCutout代替 Alpha Blend这样能参与深度写入减少 Overdraw控制特效的渲染顺序让不透明的先画半透明的后画减少无效混合实测下来光这一项就把 GPU 耗时从 40ms 降到了 25ms。4.2 风格化 Shader 的移动端精简风格化渲染的 Shader 通常包含基础色、阴影、高光、描边、边缘光、渐变映射。这些在 PC 上跑没问题但在移动端要精简。我的精简原则是能烘焙的烘焙能近似的近似能砍的砍。阴影从实时阴影改成烘焙阴影 简单的 Ramp 贴图。风格化渲染本来就不追求物理正确用 Ramp 贴图控制阴影过渡反而更符合美术风格高光从 Blinn-Phong 改成简单的 Step 函数风格化高光本来就是硬边的边缘光用顶点法线和视线方向的点积近似不用逐像素计算描边从屏幕空间描边改成背面外扩描边虽然质量略低但开销小很多Shader 里的数学运算也要精简。比如pow(x, 2)改成x * xnormalize能省则省sin/cos用查找表代替。这些微优化单个看起来不起眼但乘以百万级像素就很可观了。4.3 后处理栈的取舍URP 的后处理栈包含 Bloom、Color Grading、Vignette、Depth of Field 等。在移动端 VR 上Depth of Field 和 Motion Blur 基本不能用开销太大。Bloom 也要谨慎因为它是多 Pass 的而且分辨率越高越贵。我的后处理方案是Bloom保留但降低分辨率用 Half Res 或 Quarter Res并限制 Bloom 的半径Color Grading保留用 LUT 贴图开销很小Vignette保留开销可忽略其他全部关闭另外URP 的后处理默认是在双目渲染之后做的这意味着后处理要对两只眼睛各做一次。如果后处理很重可以考虑用Single Pass Instanced渲染模式让后处理只做一次。但 Single Pass Instanced 对 Shader 有要求需要适配。注意Single Pass Instanced 在 PICO Neo3 上需要开启 Multiview 支持。在 Player Settings 的 XR Settings 里勾选 Multiview然后在 URP 的 Asset 里开启 Single Pass Instanced。这个模式下Shader 里的unity_StereoEyeIndex会失效需要用UNITY_SETUP_STEREO_EYE_INDEX_POST_VERTEX宏来处理。5. LOD、剔除与场景管理优化5.1 LOD 分级与切换距离设置LODLevel of Detail是减少三角面数的经典手段。但 LOD 的设置很有讲究设置不好会出现跳变Popping在 VR 里跳变特别明显因为双眼视差会放大这种不连续感。我的 LOD 设置原则LOD0完整模型用于 0-5 米LOD170% 面数用于 5-15 米LOD240% 面数用于 15-30 米LOD315% 面数用于 30 米以上切换距离不是拍脑袋定的而是根据屏幕像素覆盖率来算的。一个物体在屏幕上占的像素越少LOD 就可以越低。我写了一个小工具在 Scene 视图里显示每个物体的屏幕像素覆盖率然后根据这个来调 LOD 距离。另外LOD 切换时可以用Cross Fade模式让两个 LOD 之间平滑过渡减少跳变感。但 Cross Fade 会增加 Overdraw所以要权衡。5.2 视锥剔除与遮挡剔除视锥剔除Frustum Culling是 Unity 默认开启的但它的效果取决于物体的 Bounds 设置。如果 Bounds 设置得过大剔除就会失效。我检查了场景里所有物体的 Bounds把那些 Bounds 明显偏大的重新计算了一遍。遮挡剔除Occlusion Culling在 VR 里特别有用因为 VR 的视野有限很多物体被墙壁、地形挡住。但遮挡剔除需要烘焙 Occlusion Data而且烘焙很耗时。我的做法是对静态场景烘焙 Occlusion Data对动态物体用Occlusion Portal或者手动控制烘焙时把 Smallest Occluder 和 Smallest Hole 调小提高剔除精度烘焙完后DrawCall 又降了 20 左右。5.3 场景分块与异步加载如果场景很大一次性加载所有内容会爆内存。我的做法是把场景分成多个区块用异步加载Addressables 或 AssetBundle按需加载。具体策略是玩家周围 20 米内的区块常驻内存20-50 米的区块预加载50 米外的区块卸载这样内存占用从 1.2GB 降到了 400MB 左右而且加载时的卡顿也少了。实操心得异步加载要注意加载时机。不要在玩家转头时加载因为加载会占用主线程导致掉帧。最好在玩家移动时、或者场景切换时加载。另外加载的优先级要根据玩家的朝向动态调整朝向哪边就先加载哪边。6. 常见问题与排查技巧实录6.1 优化后帧率不升反降的排查这是优化过程中最常见的问题。我遇到过好几次改了一堆东西结果帧率反而降了。原因通常有几个合批破坏了 SRP Batcher如果你用了 MaterialPropertyBlockSRP Batcher 会失效SetPass Call 反而升高LOD 切换太频繁如果 LOD 距离设置得太近物体会在 LOD 之间反复切换每次切换都有开销异步加载抢占了主线程加载线程和渲染线程抢 CPU导致掉帧Shader 变体爆炸如果 Shader 变体太多每次切换材质都要编译 Shader造成卡顿排查方法是用 Profiler 对比优化前后的数据看哪个指标变差了。不要凭感觉要看数据。6.2 PICO Neo3 特有的性能陷阱PICO Neo3 有几个特有的坑我在优化过程中踩过温度墙Neo3 跑久了会发热发热后 GPU 会降频帧率会掉。所以优化时要留余量不能贴着 72 FPS 跑最好留 10-15% 的余量电池模式Neo3 在省电模式下会限制性能测试时要确保设备在性能模式后台进程Neo3 的后台进程会占用 CPU测试前要清理后台Multiview 兼容性不是所有 Shader 都兼容 Multiview不兼容的 Shader 会渲染错误或者性能下降6.3 常见问题速查表问题现象可能原因排查方法解决方案帧率突然掉到 30温度墙降频查看设备温度降低 GPU 负载留余量转头时卡顿异步加载抢占主线程Profiler 看主线程调整加载时机画面闪烁LOD 切换太频繁Scene 视图看 LOD调整 LOD 距离左右眼画面不一致Multiview 不兼容检查 Shader适配 MultiviewSetPass Call 居高不下SRP Batcher 失效检查材质移除 MaterialPropertyBlock内存持续增长资源未释放Profiler 看内存检查 Addressables 释放6.4 优化过程中的经验教训最后分享几条我在这个项目里踩过的坑第一条不要过早优化。我一开始花了两天优化一个 Shader结果后来发现那个 Shader 只占了 2% 的 GPU 时间。优化要基于数据不要基于直觉。第二条优化要有优先级。先解决大头再解决小头。DrawCall 从 480 降到 120 的收益远大于把某个 Shader 优化 10%。第三条留余量。不要贴着 72 FPS 跑因为设备会发热、会有后台进程、会有峰值负载。留 10-15% 的余量才能保证稳定。第四条多测真机。编辑器的数据和真机差很多尤其是 GPU 部分。所有优化决策都要基于真机数据。第五条记录每次改动。我建了一个表格记录每次优化的改动、预期收益、实际收益。这样能快速定位哪些改动有效哪些无效。这个表格后来成了团队的优化知识库。这个项目从 8 FPS 优化到 72 FPS前后花了大约三周时间。其中 DrawCall 优化占了一周GPU 优化占了一周剩下的时间在做测试和调优。优化不是一蹴而就的是一个不断测量、改动、验证的循环。希望这些经验能帮到正在做 VR 优化的朋友少走一些弯路。