企业官网建设流程全解析

1. 让 Neo3 不晕不卡的底线，和我怎么把目标拆成数字

前两篇我们把风格化村庄搭进了 Unity，模型、地形和基础交互都通了，接下来最现实的问题就是：这个村庄能不能在 PICO Neo3 单机端稳住帧率。我说的单机端，指的是直接跑在头显自己的系统里，不走 PC 串流、不做服务器推流。Neo3 用的是骁龙 XR2，虽然这颗芯片在当年已经算移动 VR 里的旗舰，但它本质上还是一颗被塞进头显的移动端 SoC，散热和供电都卡得死死的，你不能拿 PC 显卡的逻辑去预估它的上限。头显端一旦掉帧，用户感受到的不是“有点卡”，而是强烈的眩晕和拖影，所以性能优化在这里不是加分项，是及格线。

我一开始先给自己定了个硬指标：至少保住 72Hz 的输出节奏。这里有个很简单的换算，72Hz 下每帧可用时间大约是 13.9ms，CPU、GPU、驱动、系统调度全都要从这里面挤。我给自己留了不到 1ms 的余量，也就是说 CPU 加 GPU 的实际开销必须控制在 13ms 以内，哪一项超了，就得先查明是哪一项超、为什么超，再谈怎么调。没有这个量化目标之前，我只会产生“感觉有点卡”“感觉变流畅了”这种模糊判断，而这种感觉在 VR 项目里几乎不可信，因为轻微掉帧带来的位置延迟可能已经达到几十毫秒，等你能察觉，身体早就开始晕了。

后来我养成了一个习惯：每轮改动前先记基线，改动后再记差异，所有改动都落到一张表格里。下面这组数据就是我正式做优化之前的基线，记录的场景是村庄主街，玩家站在路口环顾四周，没有 NPC、没有特效触发，纯粹是静态场景的空跑：

这张表是整轮优化的出发点。我可以很坦诚地讲，第一版场景在 PC 上跑起来还挺像回事，但一上 Neo3 就是另一个世界。PC 上有独立显卡替你扛住大部分渲染开销，真机上每一毫秒都要省着花。另一点必须先说明：CPU 卡不一定是你写的逻辑卡，也可能是物理、动画、粒子，甚至合批计算在捣乱；GPU 卡不一定都是贴图太大，还有可能是 overdraw、后处理和带宽不够。所以别急着开调，先把数据看清楚。

1.1 为什么帧率目标必须具体到“哪一段”帧时间

很多项目组做 VR 优化时只盯平均帧率，看到 68fps 就觉得差不多，实际上这是被平均数据骗了。VR 里的稳定性远比平均值重要。一秒钟时间里，前面 30 帧都稳定在 12ms，最后 3 帧突然跳成 20ms，镜头的运动就会出现肉眼可见的卡顿，用户的感受甚至会比长期 20ms 更差。所以我后来不看“平均 fps”，只看“帧时间曲线里的尖刺”。Unity Profiler 里可以直接看 PlayerLoop 的耗时曲线，我给自己定的底线是：任何一个瞬间，CPU 和 GPU 的帧时间都不要超过 15ms，否则宁可再砍一层细节，也要把尖刺压平。

1.2 抓数据时我用得最顺的一套工具组合

Unity 自带的 Profiler 是绕不开的。把 Neo3 连上 ADB 之后，我在编辑器里直接跑 Profiler 的 Android 模式，CPU 耗时、PlayerLoop、脚本调用、GC Alloc 都能逐帧看。这里有个极其重要的经验：不要只看编辑器里跑的数值。编辑器里就算跑 200 帧，真机也可能只有 30 帧，尤其是 GPU 相关的问题，PC 显卡替头显挡了太多时间。我日常会开三个东西：Unity Profiler 看 CPU 和脚本分配，Frame Debugger 看合批顺序和每个批次的内容，以及 PICO 自己的性能面板，实时读帧率和温度。如果需要更细的 GPU 统计，再接 Snapdragon Profiler。

为了不把真机测试变成盲人摸象，我写过一段很小的调试脚本，挂在游戏对象上，把关键指标直接输出到 Logcat 和屏幕角落：

using UnityEngine; public class PerfMonitor : MonoBehaviour { private float _fps; private void Update() { _fps = 1f / Time.unscaledDeltaTime; if (Time.frameCount % 30 == 0) { Debug.Log("[Perf] FPS=" + _fps.ToString("F1")); } } private void OnGUI() { GUI.Label(new Rect(10, 10, 300, 40), "FPS: " + _fps.ToString("F1")); } }

这段代码很简单，但它最大的价值不是显示帧率，而是提醒我：每次改动之后，都要用同一个测试路线、同一个时间段去对比，不能在 A 状态下测一次，又跑到 B 状态去测另一次，那对比结果没有意义。优化场景走固定测试路径，至少走两遍，取第二遍的数据，因为第一遍往往还带着加载、Shader 编译之类的瞬时开销。

1.3 摸清 Neo3 的硬件底线再动刀

XR2 这颗芯片的移动端 GPU 性能确实不差，但绝对算不上富裕，它要同时喂两块屏幕、两只眼睛的渲染分辨率，单眼分辨率本身又比普通手机高不少。所以村庄项目里最大的一块开销其实不是模型面数，而是纹理带宽和绘制调用。移动 GPU 的像素填充率还行，带宽却很容易被大尺寸 RGBA 纹理吃光，这就是后面我把纹理压缩放在优先位置的原因。

还有一件必须提前知道的事：头显会热，热了就会自动降频，帧率会像过山车一样一阵一阵地掉。我最终把 CPU 和 GPU 都压在 60% 负载以内，一部分原因就是要给散热留出缓冲区。如果你调完一轮跑几分钟没问题，但是戴 20 分钟之后就开始卡，不用怀疑，大概率是负载贴得太满，芯片一降频就崩了。这种问题不是“再优化一个功能”能解决的，而是要从整体预算上退一步。

2. 材质、合批和绘制调用的实战战役

风格化村庄这种项目有个典型陷阱：每栋房子都单独做一个材质。做模型的时候很爽，一个大色块一个材质球，颜色直接在材质面板里拖，省事。结果到了 Unity 里，40 多栋房子、几十个小品，每个物件两三个材质球，绘制调用直接就翻上天了。我第一版场景在 PC 上有 384 个 DC，看起来还能跑，到了 Neo3 上 GPU 帧时间直接 12.6ms，剩下 1ms 给 CPU，基本等于不可玩。

当时我做的第一件事不是删模型，而是把场景里所有小物件的材质统一起来。统一不是让它们全部变成同一个颜色，而是让它们共用同一套 Shader、同一种贴图排布方式、同一份纹理图集。比如屋顶瓦片、木板墙、石头台阶，我全部放进一张 2048 的图集里，用 UV 切片去取对应区域。这样一来，三个材质球就能覆盖整个村庄百分之七十的小物件，因为只要贴图像素一样、Shader 路径一样，Unity 就会把它们归到更少的批次里。

2.1 屋顶、墙面、招牌全部塞进一张色卡

具体怎么做图集，我多说两句。我在 Photoshop 里新建一张 2048x2048 画布，先用纯色块划分区域，把屋顶的瓦片色、木墙的棕灰色、石头的浅灰色分别填进不同的格子，再在格子里叠一层简单的程序化纹理，让砖缝、木纹有一点细节。关键点在于：每个色块区域之间要留出足够的空隙，不然 UV 采样时会把隔壁格子的颜色吸进去，形成渗色边。

UV 展开时对应到图集块区，不要偷懒用整张 0-1 空间。后来发现，这种“一张图集管整村”的做法，不仅带来了合批收益，还顺带解决了另一个问题：风格化场景里如果每栋房子的材质都有微小的色差，视觉上会很碎，统一图集之后，整个村子的色彩基调反而更整体了。这里也提醒一句：半透明物件和不透明物件千万不要混到同一张图集里，透明渲染顺序和不透明渲染顺序的规则完全不同，混在一起会导致物件显示层级错乱，整理起来非常痛苦。

2.2 静态合批、SRP Batcher 和 GPU Instancing 到底怎么选

先说结论：我在 URP 下最终开的是 SRP Batcher，而不是静态合批。SRP Batcher 解决的是 CPU 提交绘制的开销问题，它可以把不同材质、但使用同一套 SRP Batcher 兼容 Shader 的物体合并到一个绘制提交流程里，对移动端来说，CPU 端省下来的时间非常直观。要让它生效，自定义 Shader 里不能使用一些内置的废弃属性，否则合批条件不满足，绘制调用会一个一个散开。

GPU Instancing 适合大量相同的物件，比如村子里的树、栅栏、路边的石头。它们的网格必须相同，材质相同，只是位置、旋转、缩放不同。我一开始把树干和树冠分成两个 SubMesh，结果 Instancing 直接失效，因为 Unity 默认要求同一个 Mesh 上的所有 SubMesh 一起实例化。后来我把每棵树合并成一个 Mesh，用顶点色区分树冠和树干的部分，才把整片小树林从 60 多个 DC 压到了 3 个。

地面、主路这类又大又平的东西，我用了静态合批，构建时把网格合并成更大的网格，减少状态切换。代价是构建时间和内存会增加，但对大块地面来说足够值得。一句话总结我的选择：建筑和复杂小物件走 SRP Batcher，成片重复树木石头走 GPU Instancing，超大地形地表走静态合批。

2.3 MaterialPropertyBlock 真香，但千万别每帧 SetColor

风格化村庄里的房子需要表现每户的不同：窗台颜色、招牌底色、门帘色调。我早期用脚本直接GetComponent<MeshRenderer>().material = newMaterial，每栋房子都 new 一个材质球，结果内存爆炸，而且材质一变，SRP Batcher 的合批就段掉了。后面换成 MaterialPropertyBlock，用同一个材质球，只是在渲染时往实例属性里塞一份颜色变化：

var block = new MaterialPropertyBlock(); renderer.GetPropertyBlock(block); block.SetColor("_BaseColor", windowsColor); renderer.SetPropertyBlock(block);

必须注意，不要在 Update 里每帧 Set，因为大量物体会吃 CPU。我是在初始化或状态改变时刷新一次，比如玩家晚上进入室内，我才更新室内灯光相关属性。还有一个很容易踩的坑：Block 里设置的属性名必须和 Shader 里暴露的属性严格一致，差一个下划线都不行，不然就会无声无息地失效。

2.4 Shader 变体其实也在拖慢启动

另一个容易被忽略的问题：URP 默认会编译大量 Shader 变体，如果你不小心勾了一堆 Keywords，构建体积和运行时加载时间都会涨。我最后一口气把不需要的关键字全部关掉，比如 Projector、Soft Particles、Additional Lights，然后建了一个 Shader Variant Collection，把场景中用到的变体提前打进构建。这个动作不会直接影响帧率，但会降低启动时的卡顿和内存峰值，对真机体验的改善非常明显。

3. 光照烘焙与渲染管线取舍

村庄这种场景，最适合风格化渲染的做法是把光照做成烘焙光照贴图，不依赖实时 GI。实时阴影是移动端最贵的开销之一：一盏实时方向光开阴影，再加上比较远的阴影距离，在 Neo3 上就能吃掉几毫秒的 GPU 时间。房子在马路上的投影、屋檐底下的暗部，这些东西在静态环境里用烘焙一次性解决，既稳定又便宜。

我把场景里的物件分成静态和动态两类：地面、房子、栅栏、树木这些不会动的都标记 Static，参与光照贴图烘焙；村民、可交互道具、玩家自己走动时经过的区域用 Light Probe 去取烘焙光的颜色和亮度。在 URP 里把全局光照设置成 Baked Indirect，只保留一盏 Directional Light 参与烘焙，然后把其他实时光源全部删掉。实际运行时，方向光要么关闭，要么只留很低的强度，这样场景里完全没有实时光影开销。

3.1 为什么我坚持按区域分开烘焙

村庄地图整体不算特别大，但走走逛逛也有几百米的范围。如果一次性烘焙全部都进一张光照贴图，贴图纹素有限，小房子转角阴影都会糊掉。我按玩家会路过的区域分区，几个路面区块分别烘焙，每个区用 1024 或 2048 分辨率的 Lightmap，这样墙角、屋檐、门洞的 AO 能看清，墙面不会像一张塑料片。

3.2 Light Probe 的数量别贪多

对于动态物体，我一开始在每个路口摆四五个 Light Probe，担心角色经过时亮暗过渡不自然。实际烘焙完之后发现，探针太密反而会出现暗亮闪烁，因为多个探针插值产生的高频变化在移动过程中很容易暴露出不连续感。后来我只在道路交叉点、广场、巷口布置 3-4 个，效果立刻稳定。Light Probe 的问题从来不是越多越好，而是要紧扣视觉分区，一个大的露天广场只需要中心一个，配合边缘几个就够。

3.3 后处理能省则省，发光效果用贴图模拟

我原本想保留 Bloom，让村头的灯笼和玻璃窗有一点发光感。但 Ne3 真机上跑全屏后处理，尤其是 Bloom 加 TAA 抗锯齿，整帧 GPU 时间大约会多 2ms，偶尔还会带来边缘闪烁。想要便宜的“发光感”，其实可以用 Shader 里的自发光贴图模拟：把灯笼、蜡烛区域的 Emissive 强度调高，再叠加一张柔光贴图，看起来一样有温暖的光感，代价却小得多。移动端屏幕像素密度本来就不低，抗锯齿开不开差别没那么大，我最后干脆关掉了 TAA，只留 FXAA，甚至测试时发现不开 AA 也问题不大。

4. 网格、LOD 和遮挡剔除的逐块击破

风格化模型有个天然优势：它不需要超高精度。我起初在 Blender 里把一个磨坊做了 8 万面，把木纹的每一道刻痕都模型化，结果第一版真机帧时相当难看。后来我把磨坊减到 1.2 万面，轮廓几乎没有变化，因为风格化渲染真正起作用的是剪影和色块的干净边界，不是微表面上的凹凸细节。

减面原则非常简单：先保轮廓，再保转角，最后才保纹理起伏。木纹细节可以全部删掉，用 UV 贴图在平面上画出木纹方向即可；圆柱体的分段数可以大方减少，在一块色块下，8 段和 24 段的视觉效果差距极小。用 Blender 的 Decimate 工具时我会选择“Planar”模式，它会保留表面的大平面，而不是把墙面剪成乱七八糟的碎三角。

4.1 LOD 的三档设置

村庄里多数小道具远看只是一两个色块，没必要全精度渲染。我给主要建筑和密集树木加了三级 LOD：LOD0 是原始高模，LOD1 减到 60%，LOD2 减到 25%，同时切到纯贴图表现。切换距离我在编辑器里通过调整同样大小和屏幕占比来控制，低端头显上可以适当激进一点，但要注意别在近距离就切到低模，风格化物体一旦边缘突然走样，会比写实渲染更明显。

关于 LOD 切换方式，我强烈建议关闭 Crossfade，也就是不做两个 LOD 级之间的交叉淡入。Crossfade 会同时绘制两个 LOD 级，造成瞬间双份 draw call，还会让切换画面出现轻微半透明叠影，移动端上感知并不好。我全部改成直接硬切，虽然会偶发性地看到边缘跳变，但整体节奏更干净。

4.2 Occlusion Culling 的调参心得

很多人对遮挡剔除的理解就是勾选 Static、然后烘焙，就完事了。实际上，村庄这类半封闭场景反而是遮挡剔除收益最明显的，你站在巷子里时，身后的几十栋房子如果还在一栋一栋画，GPU 负载完全是白费。问题是，这个功能调起来并不像想象中那么省心。

我第一轮调试时经常看到“明明被挡住了却还在渲染”的情况。后来发现，OcclusionArea 的大小和摆放位置影响极大，它必须包住主视角移动区域和主要静态物体。只勾选静态还不够，需要把遮挡物的 Occluder Static 打开。门洞、窗户这类小空隙会让剔除系统很难判断，设置太紧，会漏掉很多物体；设置太松，又可能出现“墙角后面的东西穿墙显示”的错觉。我最后的平衡方法是：把房间、胡同切成独立的小 OcclusionArea，并使用里头的准确 geometry，而不是让一个巨大的 OcclusionArea 覆盖整个村庄。烘焙完成后，用 Scene 视图的可视化数据检查一遍，确认几乎看不到的建筑都被剔掉。

4.3 动态物件别塞进遮挡剔除系统

村民和可交互道具是动态的，把它们也放进 OcclusionArea 会导致每帧都在快速更新遮挡关系，CPU 开销反而上升。我把村民排除在遮挡物之外，只当作遮挡对象（Occludee），让系统只判断它们是否在房子背后，不需要它们去遮挡别人。树冠类似，能剔除的树直接剔，但不要在遮挡面板里把树冠当成重要的 Occluder，否则树叶的透明区域会造成大量误判。

5. 纹理压缩和运行时内存的斤斤计较

纹理是移动 VR 项目里最容易忽视的隐形炸弹。一张 2048x2048 的 RGBA 未压缩贴图在内存里占约 16MB，如果你放十几张，几百 MB 就没了。Neo3 整机运行内存本身不算宽裕，系统还要占走一块，留给游戏的部分远比想象中少。我在优化中把大部分贴图都转成 ASTC 压缩格式，具体用几乘几的压缩率，取决于贴图类型：纯色风格贴图用 ASTC 6x6 甚至 8x8 问题不大，树叶、树冠这类边缘需要透明的，用 ASTC 4x4，保证透明边缘不糊。

我给了一组自己用的压缩参考表：

5.1 图集比大贴图好管，但两类必须分开

上面说的色卡图集统一了材质，纹理方面我也按用途分成两类：不透明色卡集和透明贴图集。透明集里放的是窗格、花草、旗帜，这两类永远不要混到同一个图集里，因为透明排序规则完全不同，强行合并会导致渲染顺序错乱，一会儿这面旗子被墙挡住，一会儿又穿到最前面。图集还有一个好处：每次进入场景只需要预加载一张大图集，不用临时去加载几十个小贴图，性能尖刺少了很多。

5.2 不要无脑开 Mipmap

Mipmap 能减少远处高光闪烁，但它会额外增加约三分之一的内存。地面、大建筑这类物体必须开 Mipmap，因为玩家会从远处看到它们；UI 和小型道具贴图我全部关掉了 Mipmap，因为玩家不会离那么远，远处的模糊闪烁几乎不存在。这里最常见的误区是“无脑开 Mipmap”，结果内存涨了三分之一却完全没解决实际问题。合理做法是一张贴图一张贴图过，看它在实际场景距离中是否会产生闪烁，再决定开关。

5.3 内存预算从 2.1GB 压到 1.5GB 的过程

第一版内存的大头是三块：高模 Mesh 常驻、材质球数量多、贴图压缩不足。三个阶段走下来：材质球统一后内存明显下降；Mesh 按 LOD 加载，把高精度模型从运行时资源束里剔除；贴图全面压缩后占用继续下降。最后真机运行内存稳定在 1.5GB 左右，给系统和热管理留出很大余量。如果你想复现这套流程，建议构建后用 ADB 拉一下真机的实际内存统计，千万别只看编辑器里的 Profiler，编辑器内存和真机完全是两码事。

6. 这轮优化收尾时我验证过的几个细节

整个优化过程中，有一个反直觉的发现：真正让我把画面观感提上去的，不是增加了什么特效，而是关掉了很多看似“画面加成”的功能。后处理 Bloom、体积雾、实时光追阴影，这些在 PC 上一开就很好看，但到 Neo3 上却会毁掉风格。在移动端高刷面前，稳定帧率远比多两个特效重要。这话不是口号，是我一次次在真机屏上对比之后得出来的结论：稳定 72fps 的画面，观感远好于偶尔掉到 50fps 的“高画质模式”。

我在收尾阶段会做一次真机循环测试：戴上头显，沿着村庄主路来回走 5 分钟，同时开着性能面板看帧时间曲线，看有没有某个区域突然飙升。一般来说，飙升来源是进入新区域时触发加载，或者某个大遮挡物体刚好进入视野。我后来的做法是把加载拆到玩家接近之前，用异步加载，不要在同一帧里一次性实例化一堆对象。另一个细节是热衰减：长时间运行后如果帧率开始回落，优先排查有没有不必要的持续计算，比如每帧遍历所有村庄物件检查状态，这种 CPU 持续高负载会让发热问题雪上加霜。

最后分享一条我踩过的经验：如果优化到某个阶段，数据过了、帧率也稳了，手感却还是不对，别急着继续压渲染，先看一眼 PICO 的刷新率设置和应用侧渲染分辨率。有几次我以为“场景太重”，其实只是把应用分辨率调到默认之外，Neo3 的实际输出分辨率跟着变了，画面才显得迟滞。做移动 VR 优化，本质上就是把自己的每一个判断拿到真机上重新验证一遍，别人给的参数能帮你少走一半路，剩下的一半，你得亲自把帧时间曲线调平，把每个转角的体验踩过一遍，这才是“塞进头显”的真正含义。