企业官网建设流程全解析

1. 项目背景与优化目标拆解

1.1 为什么 PICO Neo3 上的 8 FPS 是个典型困局

PICO Neo3 搭载的是高通骁龙 XR2 平台，GPU 是 Adreno 650，CPU 是 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 优化目标的量化拆解

我把目标拆成了几个可量化的指标，而不是笼统地说"要流畅"：

这张表是我做优化时的"作战地图"。很多人优化 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（排序）的开销。场景里有大量小物件，每个都有自己的 Renderer，Unity 在做视锥剔除和排序时花了大量时间。同时 DrawCall 高达 480，SetPass Call 210，这两个数字在移动端是灾难级的。

GPU 这边虽然只有 40ms，但相对 12ms 的目标还是超了 3 倍多。主要开销在半透明特效的 Overdraw和描边 Pass 的额外绘制上。风格化渲染的描边通常是第二个 Pass，等于把模型画了两遍，Overdraw 直接翻倍。

2.2 优化策略的优先级排序

基于上面的数据，我制定了这样的优化优先级：

1. 先降 DrawCall 和 SetPass Call——这是 CPU 瓶颈的主因，收益最大
2. 再处理 Overdraw 和半透明——这是 GPU 瓶颈的主因
3. 然后优化 Shader 复杂度——降低每像素计算量
4. 最后做 LOD 和剔除优化——减少无效绘制

这个顺序很重要。很多人一上来就优化 Shader，结果 DrawCall 没降下来，CPU 还是卡。正确的做法是先把"画多少"的问题解决，再解决"每笔画多贵"的问题。

2.3 渲染管线的选择：为什么从 Built-in 切到 URP

这个项目最初用的是 Built-in 渲染管线。Built-in 在移动端的问题在于：它没有 SRP Batcher，Shader 变体管理混乱，而且很多内置效果（如后处理）在移动端开销很大。

我把它切到了URP（Universal 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，动态合批作为补充。

实测数据对比：

可以看到，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 Test（Cutout）代替 Alpha Blend，这样能参与深度写入，减少 Overdraw
• 控制特效的渲染顺序：让不透明的先画，半透明的后画，减少无效混合

实测下来，光这一项就把 GPU 耗时从 40ms 降到了 25ms。

4.2 风格化 Shader 的移动端精简

风格化渲染的 Shader 通常包含：基础色、阴影、高光、描边、边缘光、渐变映射。这些在 PC 上跑没问题，但在移动端要精简。

我的精简原则是：能烘焙的烘焙，能近似的近似，能砍的砍。

• 阴影：从实时阴影改成烘焙阴影 + 简单的 Ramp 贴图。风格化渲染本来就不追求物理正确，用 Ramp 贴图控制阴影过渡反而更符合美术风格
• 高光：从 Blinn-Phong 改成简单的 Step 函数，风格化高光本来就是硬边的
• 边缘光：用顶点法线和视线方向的点积近似，不用逐像素计算
• 描边：从屏幕空间描边改成背面外扩描边，虽然质量略低，但开销小很多

Shader 里的数学运算也要精简。比如pow(x, 2)改成x * x，normalize能省则省，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 分级与切换距离设置

LOD（Level of Detail）是减少三角面数的经典手段。但 LOD 的设置很有讲究，设置不好会出现"跳变"（Popping），在 VR 里跳变特别明显，因为双眼视差会放大这种不连续感。

我的 LOD 设置原则：

• LOD0：完整模型，用于 0-5 米
• LOD1：70% 面数，用于 5-15 米
• LOD2：40% 面数，用于 15-30 米
• LOD3：15% 面数，用于 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：如果你用了 MaterialPropertyBlock，SRP 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 常见问题速查表

6.4 优化过程中的经验教训

最后分享几条我在这个项目里踩过的坑：

第一条：不要过早优化。我一开始花了两天优化一个 Shader，结果后来发现那个 Shader 只占了 2% 的 GPU 时间。优化要基于数据，不要基于直觉。

第二条：优化要有优先级。先解决大头，再解决小头。DrawCall 从 480 降到 120 的收益，远大于把某个 Shader 优化 10%。

第三条：留余量。不要贴着 72 FPS 跑，因为设备会发热、会有后台进程、会有峰值负载。留 10-15% 的余量，才能保证稳定。

第四条：多测真机。编辑器的数据和真机差很多，尤其是 GPU 部分。所有优化决策都要基于真机数据。

第五条：记录每次改动。我建了一个表格，记录每次优化的改动、预期收益、实际收益。这样能快速定位哪些改动有效，哪些无效。这个表格后来成了团队的优化知识库。

这个项目从 8 FPS 优化到 72 FPS，前后花了大约三周时间。其中 DrawCall 优化占了一周，GPU 优化占了一周，剩下的时间在做测试和调优。优化不是一蹴而就的，是一个不断测量、改动、验证的循环。希望这些经验能帮到正在做 VR 优化的朋友，少走一些弯路。