企业官网建设流程全解析

这个系列做到第五期，前面几篇已经把风格化村庄从零导入到 PICO Neo3，场景能跑、画面能看、交互也能动。但说实话，那只是“能跑”，离“流畅跑”还有不小的距离。一体机这东西很诚实：你的画面好不好看是艺术家说了算，能不能稳住帧率是性能面板说了算。

这期我不打算再铺新功能，专门做减法——讲怎么把一个堆满房屋、篱笆、树木和草丛的风格化村庄，真正压进 PICO Neo3 的性能预算里。你会看到我从帧率曲线、Draw Call、光照烘焙、Shader 精度到内存流式加载的完整折腾过程，也会看到哪些优化是立竿见影的，哪些免费性能其实是陷阱。

1. 先看清 Neo3 的底子，再谈怎么压

1.1 硬件预算：11.1 毫秒里装下一个村庄

PICO Neo3 用的骁龙 XR2 平台，GPU 是 Adreno 650。这颗 GPU 在手机里跑普通游戏问题不大，但放在 VR 里就要吃双份资源：左右眼各渲染一遍，分辨率合计差不多 3664×1920，还要卡着 72Hz 刷新率，每帧给 Unity 的时间只有 11.1 毫秒左右。

我上一期把完整村庄场景跑了一轮统计，结果挺扎心的：帧时间普遍在 18 到 20 毫秒徘徊，某些俯视街道的画面直接飙到 25 毫秒。这说明不是“调调阴影”“关个后处理”就能救回来的，必须从渲染链路上一层一层往下拆。

风格化村庄还有它的特殊性。它不像写实场景靠贴图细节和光照层次取胜，而是靠大量重复的小物件铺出生活气息。一栋房子有木板墙、柱子、柴堆、屋檐，路边有篱笆、石块、树桩，几百个零碎物体，单个面数不多但各占各自批次。这正好打在移动 VR 的两大软肋上：CPU 渲染线程的 Draw Call 排队，GPU 顶点单元的细碎三角形过载。

1.2 用 Profiler 把问题钉死，别拍脑袋优化

做优化之前，我先把问题量化了。Unity Profiler 直接连真机，开 Deep Profile 看主线程耗时；GPU 端用 Snapdragon Profiler 抓 Adreno 650 的计数器，可以看 ALU 占用、纹理采样、光栅化压力。PICO 自己也有性能监控面板，在开发者模式里能叠加显示帧时间、温度、CPU/GPU 频率。

我记录了一个基准数据，方便后面对比：

• Draw Call：842
• SetPass Call：109
• 总三角面：约 2.1M
• CPU 主线程：6.4ms
• 渲染线程：5.6ms
• GPU 帧耗时：15 到 20ms 波动
• 内存峰值：4.4GB

问题集中在两块：Draw Call 太多导致 CPU 渲染线程排队，GPU 填充率被半透明植被和后处理压满。后面所有优化基本围绕三条线展开：批处理、烘焙、Shader 裁剪。

这里有个经验想提一下：VR 项目不要只看 Profiler 平均值，要看最坏帧和掉帧分布。某个瞬间跑到 25ms 如果发生在快速转头时，比平均 12ms 还危险，因为转头掉帧很容易造成眩晕，而且体感比普通掉帧更敏锐。

2. 批处理组合拳：把 842 个 Draw Call 压进 150 以内

2.1 SRP Batcher：先白捡一波性能

我用的渲染管线是 URP，第一个要开的优化就是 SRP Batcher。这个开关在 Player Settings 的 Rendering 面板里，原理是把相同材质的网格合批渲染，避免每帧重复绑定材质、传 uniform、切换渲染状态。风格化村庄里同材质复用率极高，一大排房子共用同一种墙面材质，正好是 SRP Batcher 的主场。

但要提醒一句：SRP Batcher 不是开了就万事大吉。如果你的材质用了 MaterialPropertyBlocks，或者自定义 Shader 里写了大量不合批的代码路径，合批就会静默失效。我检查了一圈，把几个自写 Shader 改造成标准 SRP 兼容路径，确认 Inspector 面板显示 “SRP Batcher: 合批中” 才算数。

只是开了 SRP Batcher 之后，Draw Call 并没有立竿见影降下来，因为真正的瓶颈不是大物件的合批，而是大量零散小物件。于是又上了第二招：在编辑器里把同材质、同区域的网格物理合并成一张大网。

2.2 按区域合并 Mesh，把零碎件焊成整体

Unity 的 Mesh.CombineMeshes 可以在编辑器阶段把一堆 Mesh 合成一张大 Mesh。我在工程里写了个简单的编辑器工具，流程大致是：

1. 按村庄分区（北区、中心区、溪流区）把物体分组。
2. 分组内再按材质、颜色继续细分。
3. 检查顶点数和索引数是否超限，单个 Mesh 超过 65535 个顶点需要把 IndexFormat 改成 32Bit。
4. 合并后把零散的 BoxCollider 统一挂到合并对象上，减少物理组件数量。
5. 烘焙光照时把每个 Mesh 的 UV2（光照 UV）一并合并过去。

合并过程最容易翻车的是碰撞体和光照。如果保留大量细小 Collider，物理引擎依然拖后腿；光照 UV2 如果不合并，烘焙出来会出现奇怪的暗块。我第二版就出过这事：房屋木板合并后，窗户下面墙面出现颜色断层，查了半天才发现是 Mesh.CombineMeshes 默认没处理第二个 Mesh 的 uv2 通道，后来手工把 mesh.uv2 拷贝合并才解决。

结果比较直观：仅一个北区，320 个对象就合并成了 48 个 Mesh，材质切换次数明显下降。整个场景 Draw Call 从 842 降到 300 上下，CPU 渲染线程的排队压力小了一大截。

2.3 植被不能靠蛮力：LOD 与面片剔除

村庄最烧性能的不是房子，而是树和草。风格化树的常见做法是一个大球体加上十几层树叶面片，一棵树几千面不算多，可 200 棵树就是几十万面。更麻烦的是半透明树叶的排序，CPU 每帧都要重新计算，场景一复杂就卡。

我做了三件事：第一，给每棵树挂 LOD Group，近处用完整 3D 树，中距离切简化模型，远处直接切换到十字交叉的 Billboard 卡片。第二，草的模型从“一片片草叶”改成“三片交叉面片”，每簇草控制在 24 个三角形以内。第三，关闭所有草的阴影投射，只在地面保留树的阴影。

还有个细节：LOD 过渡默认的 Cross Fade 在 VR 里偶尔会同时渲染两个 LOD，导致一帧内双倍负载。我干脆全部改成硬切，牺牲一点平滑度换帧时间稳定。

3. 光照体系：风格化的灵魂，也是渲染的包袱

3.1 最少的光源数量，最多的烘焙收益

风格化村庄的氛围全靠光照做出来。但移动端每加一盏实时点光源，都意味着额外的动态阴影计算和多次采样开销。很多人容易陷入“多放灯点亮氛围”的思路，在 PC 上没事，在 Neo3 上就是灾难。

我的最终方案是：场景里只有 1 个平行光，外加最多 2 到 3 个实时补充点光源，其余氛围光全部走烘焙。烘焙参数我调了几轮，落地配置是全局光照全开，灯光模式以 Baked 为主，光照贴图分辨率用 2048，Progressive GPU Lightmapper 在编辑机上跑。一块 300×300 的村庄场景，每次烘焙从 2 分钟到 20 分钟不等，但输出质量干净很多。

这里有个重要前提：场景内尽量避免小面积 UV 重叠，烘焙前我都会用光照 UV 工具检查，把重叠的地方展开重排。漏光问题多半出在这个环节，后面单独说。

3.2 阴影与 AO 的取舍：砍一半阴影，留八成立体感

实时阴影是 Adreno 650 的大敌。阴影的 Cascade 每多一级，着色器里的采样开销就翻一倍。我最终使用了 Shadow Cascade 2 Cascade，最大阴影距离压到 12 米，超出部分完全依靠烘焙。风格化村庄的近景有清楚阴影，远景模糊就模糊，远处本来就是饱和度渐变的背景，没有人会去抠远山有没有影子。

AO 的做法我换了一种思路：不开 SSAO 后处理，而是把烘焙 AO 直接合成进漫反射贴图里。具体操作是先用高模或者低模加法线贴图烘焙出一张 AO，再和基础色贴图叠加，材质在受光面再用 Lambert 模型的明暗做增强。风格化画面里，AO 带来的立体感比细分模型、高光细节都明显。有朋友问我为什么他的村庄看起来很平，我基本第一反应就是你漏了 AO。

3.3 光照图压缩与 UV2 检查

光照图在 Android 平台默认可能被压缩成 ETC2，这种格式在渐变暗部容易出 block 状色带。我在 Build Settings 里把 Android 平台纹理压缩改成 ASTC，光照图单独用 8×8 块。实测色带几乎消失，内存占用还降了 30% 左右。

UV2 同样容易被忽略。每栋房子在光照图上的 UV 必须均匀展开，尽量占满 0 到 1 空间，并且不同面片之间留至少 4 个像素间距，否则烘焙采样会串色。这个检查我写成了 Editor 脚本，批量扫描场景所有 MeshRenderer 的 lightmapIndex 和 negativeScale，自动列出有问题的对象，手动修复。

漏光问题最开始也严重：墙体跟地面接触的缝隙，烘焙之后从侧面看会透出底面的颜色。解决办法是给墙体和柱子底部加一小段“封边”几何体，几厘米厚，能挡住这种渗色。烘焙参数里还要把 padding 调高一点，数值太小同样容易漏。

4. Shader 和渲染特性：把 Adreno 650 的每一毫秒花在刀刃上

4.1 Single Pass Instanced 白捡 CPU 渲染线程

这个设置是现阶段最值得检查的，没有之一。在 Project Settings 的 XR Plug-in Management 里选择 PICO，然后把 Stereo Rendering Method 改成 Single Pass Instanced。原理是左右眼共用一次渲染流程，通过 GPU 实例化一次绘制两眼的视锥。开之前渲染线程是 5.6ms，开完直接降到 4.1ms。

这种提升是免费的。唯一的风险是自定义 Shader 里的立体渲染相关代码，如果用 Multi Pass 那套写法，可能只渲染一只眼睛。所以我统一检查了一遍自写 Shader，凡涉及 view projection 的地方都改用 Unity_Stereo 相关的宏或者 instancing 声明。

4.2 Shader 精度和 Keyword 裁减

移动端 GPU 对 half（mediump）的吞吐明显高于 float。自定义 Shader 里，凡是颜色采样、UV 偏移、漫反射公式计算，能写成 half 就不要用 float。ShaderGraph 里可以单独设置每个节点的 Precision，手写 Shader 时 fragment 阶段尤其注意。

Keyword 变体则是个暗坑。我一开始保留了一堆材质开关，比如高光开关、细节贴图开关、程序化噪点开关，编译之后 Shader 变体数量爆炸，Android 上光加载就要卡好几秒。后来用 Shader Variant Collection 只收录实际用到的变体，把 Lit 和自定义风格化 Shader 的常用组合全部纳入，其余全部剔除，变体数从两千多缩到三百多，启动卡顿少了一秒多。

4.3 MSAA、HDR 与后处理：能关就关，能省就省

填充率在 VR 里是最贵的资源。我一开始为了柔和边缘开了 4x MSAA，GPU 时间直接多出 4 毫秒，完全接受不了。后来换成了 2x MSAA 配合材质里的 AlphaToMask，草和头发的边缘不会明显闪烁。如果你的场景是干净的大色块风格化，甚至可以尝试完全关闭 MSAA，用 TAA 后处理替代，但我实测 TAA 在快速转头时有残影，最后放弃了。最稳的还是 2x MSAA。

HDR 在 URP 里我也关掉了。HDR 需要更高精度的中间缓冲，移动端 GPU 的带宽吃不消，视觉收益又很有限。关闭之后颜色调整在 sRGB 空间做，画面观感差别很小。至于 Bloom、Vignette 这类后处理，我一个都没留。风格化村庄的好光根本不需要额外辉光，保留一档颜色分级自己控制就够了。

5. 内存和资源流式：6GB 也能装下大村庄

5.1 纹理别贪大：风格化细节本来就少

风格化画面就是颜色平涂，不靠超高分辨率纹理。墙面用 256×256 绰绰有余，草皮 128×128 到 256×256 足够，只有需要表现细微粗糙度变化的地方才用 512。之前美术同学扔来一套 2K 纹理的资源包，转成 ASTC 4K 进 Unity 后内存直接多了 500MB，画面观感提升几乎为零，全部降级之后，内存数字非常可观。

所有贴图压缩格式我统一用 ASTC：漫反射纹理用 6×6，光照图和纯色纹理用 8×8。还需要确认 Generate Mip Maps 是开着的，否则物体在斜视角下会出现纹理闪烁，mipmap 在移动端也是带宽优化神器。

5.2 AssetBundle 与按区域流式加载

Neo3 的内存可用部分满打满算 4GB 上下，一个村庄所有资源全挤进内存必爆。我按玩家动线把村庄切成三块：入口区、中心广场区、溪流农田区。运行时只保留玩家所在区块和邻接区块，其余动态卸载。

实现上用一个简单的 AssetBundleManager 维护引用计数。进入新区块前先预加载，等资源实例化完成后再卸载旧区资源，避免场景切换时出现大面积穿帮。加载过程采用异步加批处理，每帧最多实例化 5 棵树或者 10 个摆件，防止单帧卡顿。如果你不想手写这套，直接上 Addressables 也行，但要仔细配置它的常驻内存策略，默认行为有时候会把用不到的资源留在内存里。

5.3 小心 AssetBundle.Unload(true) 的连锁坑

第一版流式系统里我踩过一个经典的坑：用 AssetBundle.Unload(true) 卸载旧区块，结果房屋模型消失后，共享的同名纹理和 Mesh 也被卸载，其他区块出现了大量紫皮材质。原因是多个 Bundle 引用了同一个共享资源，强行整包卸载把这部分也带走了。

解决办法：把纯资源（纹理、Mesh、Material）放进独立的共享 Bundle，场景实例放进另一个 Bundle，场景包卸载时只删实例，共享资源等引用计数归零再卸载。宁可多打一点包体，也别让共享资源被误杀。

6. 长期 72 帧比瞬间 72 帧难得多

6.1 热降频：给性能多留一截余量

Neo3 散热条件不如手机，持续运行 20 分钟后芯片会主动降频。我做过一次马拉松测试，GPU 频率从 750MHz 一路降到 600MHz 左右，帧时间从 8.5ms 慢慢拉长到 11.5ms。所以优化目标不能是“刚好压在 11.1ms”，而要留 20% 余量，尽量把 GPU 帧耗时控制到 8.5 到 9ms 之间。这样即使降频也能稳住 72。

主动管理发热也很重要：少开实时全局光照、别开超采样、热起来就降渲染比例。这些都是压低温度、延长满血时间的长效因素。

6.2 动态分辨率脚本

负载压力大的时候，宁可牺牲一点点锐度也不能掉帧。我在 URP 的相机组件上挂了一个动态分辨率脚本，每帧读取 GPU 耗时，超过阈值就调低 URP 的 Render Scale，负载降下去再缓慢恢复。

伪代码大概是这样的：

float currentScale = GetCurrentRenderScale(); if (GpuMs > 10f) currentScale = Mathf.Max(0.85f, currentScale - 0.05f); else if (GpuMs < 7.5f) currentScale = Mathf.Min(1.0f, currentScale + 0.02f); var cameraData = Camera.main.GetComponent<UniversalAdditionalCameraData>(); cameraData.renderScale = currentScale;

注意 UI 要放在 Screen Space Overlay 或者单独相机渲染，不受 renderScale 影响，否则出现界面和场景一起变糊的情况。

6.3 性能等级与 CPU/GPU 上限

PICO XR SDK 提供了性能等级设置，可以在运行时调整设备的功耗策略。我一开始直接调到高性能档，结果发热明显加快，温度上来之后系统还是会强制降频。最后改成带温度监控的动态策略：温度低于阈值时用高性能档，接近阈值就自动切回平衡档。这个方案在体验长跑时表现比固定档位稳妥得多。

7. 复盘优化数据，以及接下来还能折腾什么

7.1 优化前后对比

整个优化阶段结束以后，同一台 Neo3、同一段村庄漫步路径的数据对比如下：

这个结果基本满足了我的预期：画面看起来没有明显变差，近景细节保留完整，草和树的密度没减太多，但帧率曲线平了，转头时不再有那种让人皱眉的卡顿。

7.2 还能继续做的三件事

第一，如果要加入 NPC 和复杂交互，CPU 预算还要被咬一口，碰撞体、寻路、动画系统的开销都得提前按帧分配好。第二，遮挡剔除还能做得更精细，比如按空间网格只渲染玩家视野方向上的房屋和树木，能再砍掉一批浪费的三角形。第三，加载优先级可以更智能，不只是按距离，还要考虑玩家朝向，提前加载视线前方区块，回头时不会出现明显的资源加载感。

这次折腾到这就先收个尾。说实话中间也冒出过“干脆把场景改成低多边形方块世界算了”的念头，但最终发现只要把数据一项项拉出来优化，Neo3 完全能跑一个看着像样的风格化村庄。我个人在项目里的体会是，一体机的优化不在某一招，而是每毫秒都值得较真——当你把 Draw Call、贴图、Shader、内存和发热全部压到合理量级，那个稳稳的 72 帧，才是风格化村庄在这个头显里最好的状态。