企业官网建设流程全解析

说实话，这个系列写到第四篇，评论区催更的比前面任何一次都多。前几篇聊了场景怎么搭、资源怎么导，但那都还停留在"能跑"的阶段，这次要解决的是"在一体机上又好又稳地跑"。风格化村庄这种项目，放在PC上随便来，Draw Call上千也无所谓，但到了PICO Neo3上，一切都要重新记账。

这台的配置大家都眼熟：骁龙XR2平台、Adreno 650 GPU、6GB运行内存，单眼分辨率1832×1920，刷新率默认72Hz，可以开到90Hz。听起来不算差，可自媒体生态系统的常态是"保底40帧、偶尔掉到30"，稍微优化不到位就是晕眩现场。这篇我把我从场景体检到最终定版的全过程拆开讲，包括我自己踩过的坑，适合正在做移动VR或者想给一体机项目做性能瘦身的朋友抄作业。

1. 先把PICO Neo3的账算清楚：优化不是凭感觉删东西

1.1 风格化村庄在移动VR里的"吃性能点"

很多人觉得风格化等于低模、等于省性能，这是个误区。低面数确实能省掉一部分顶点压力，但风格化村庄的特征恰恰是"小而多"：几十栋房子、几百棵树、铺满屏幕的草地、反复出现的小道具。单看一个模型没什么，乘上数量就非常可观了。而且为了做出"干净的颜色、清晰的轮廓、没有噪点"的卡通感，我一开始不自觉地把贴图尺寸、采样数量都往高了调，这恰恰戳中了移动GPU最痛的几个位置。

村庄场景还有个特点：空间关系密。屋子之间挨得近、视线遮挡多，听上去是好事，但如果不做遮挡剔除，所有可见不可见的物体全都进渲染队列，白白浪费。风格化场景的材质又常常是带Ramp采样、半透明边缘处理的Toon Shader，一旦shader复杂了，overdraw和填充率问题比PC上严重得多。

还有个很容易忽略的点：VR是双倍渲染。左眼一次右眼一次，同一帧的工作量翻倍。前面PC上跑的帧率直接除以二，才是这台机器上的感觉。所以"看着不复杂的场景"和"跑着不卡的场景"完全是两码事。

1.2 骁龙XR2这块平台的真实预算

我给自己列了一张表，所有优化动作都以它为基准，超过红线的要么砍掉要么换方案。先看看这台设备的关键参数：

有了这张表，我的优化原则就一句话：把每帧13.8ms的预算花在玩家真正看得到的地方。远处的山如果只占屏幕10个像素，就不配拥有完整的gpu运算。

1.3 我划的三条红线

第一，Draw Call（严格说是SetPass Call）的目标压在80以内。这个数字对村庄场景来说不算激进，但考虑到双眼渲染和OpenXR层的开销，留点余量总是好的。

第二，纹理内存加网格内存的总和控制在400MB以下。PICO Neo3的6GB内存里，系统、Unity引擎、渲染缓冲、音频各占一块，剩下给资源的部分其实没有想象中多。

第三，充满电量从进场景到持续运行20分钟，帧率不允许掉到60以下。不要求一直贴着72Hz满帧，偶尔掉一两帧可以接受，但不能稳稳地下滑。

这三条红线会在后面每个环节反复用到。优化就是个"不断地问自己：这个东西值几个毫秒"的过程。

2. 几何层面的大扫除：合并网格、LOD与遮不住的面

2.1 导进Unity后我先做了个面数体检

我没急着开改，先从Unity Profiler和Frame Debugger里把场景的真实家底摸了一遍。结果不怎么好看：全场景三角面到了120万，SetPass Call 486，光静态物体就占了大头。其中草地的面数夸张得离谱——每一丛草都是独立的小网格，长得还挺密，一铺就是几万丛，我当初导入的时候居然没意识到这是移动平台的地雷。

体检的具体做法很简单。菜单里Window → Analysis → Profiler，在CPU Usage里看Renderer的CreatePlayerLoopCall，或者直接用Frame Debugger的Draw Call列表，把所有物体按面数和调用次数排序。这一步花不了十分钟，但数据一出来，哪些是"隐形大爷"一目了然。

很多人优化喜欢直接在模型软件里无脑减面，我觉得顺序反了。先搞清楚钱花在哪个环节，再动手。引擎里体检完，我才拿着列表回到Blender和原工程去处理，这样每一步的改动都能对上账。

2.2 合并与减面的实际操作

村庄里大量房屋是由墙体、屋顶、门、窗户这些部件拼起来的，每个部件单独一个Mesh、单独一个材质。这在小场景里问题不大，但几十栋房子加起来，Draw Call就爆了。我的做法是：同一种风格的房子，把静态部件在编辑器里直接合并成一个Mesh，材质也统一成一张图集里的不同区域。

合并前先统一每个部件的Transform，在Unity里选中所有子物体，用Mesh.CombineMeshes接口合并，同时把材质改成同一个Material，靠Tiling偏移或UV重映射来区分部位。做这一步时有一个点特别重要：原始Mesh文件保底副本别丢。合并以后动画、替换、微调都很难做，所以我的工程里总有一份"未合并备份"，这是一个很土但很实用的习惯。

减面方面，我重点盯的是那些"离玩家近但不需要细节"的东西，比如草。Blender里草叶单根用Plane加十字交叉，面数不高，问题是数量。我一边把草的密度降到原来的40%，一边在Unity里加了LOD，近距离用完整草丛，远一点直接换成交叉片。视觉上几乎没有区别，但整体面数掉了近一半。

2.3 树木草地的Instancing改造

村庄里最密集的是树和草。树干、树冠、草丛，这类大量重复的物体，最佳解法是GPU Instancing。同一个Mesh、同一个Material，GPU只需要一次提交就能画一片，这是移动平台的神器。

实际操作路径：给材质打开Enable GPU Instancing，把树、灌木、石头这类重复物体都勾上。然后注意一个坑——Instancing和静态合批是互斥的，同一个物体别又标Static又开Instancing，那样Unity可能优先走合批，反而失去Instancing的灵活性。树这种可能要受风力动画影响的，我用的是Shader里做顶点偏移，不靠Transform动画，这样Instancing仍然有效，否则一动起来就得打断合批。

草地的情况特殊一点，密度太高，Instancing虽然能砍Draw Call，但面数和填充率问题依旧。所以我除了削密度，还给草地大区域用了一个单独的"绿地面片"，远看是一整片带色调差异的地皮，近处的草叶才用Instancing点缀。这样既保住了风格化的"草感"，又没让GPU在每帧都做大量无意义的裁切。

2.4 这轮改造后的Draw Call数字

改造完我重新开了一次Frame Debugger，数字已经像样多了：SetPass Call从486降到127，三角面从120万降到大约45万。这还没做遮挡剔除，如果片区之间天然挡得厉害，后面还有的一压。

这里说个我自己的体会：很多人优化只盯着"数量变小了"看，但我在意的是"观众看出去的那一眼有没有变化"。合并网格以后，个别墙角、窗台因为有共用一个材质球，颜色过度会比原来"平整"一点。解决办法是在贴图里直接画好AO和边缘阴影，给材质加一层烘焙过的细节法线，尽量模拟原来的分隔感。风格化项目的好处就在这里，你可以用"多一些美术处理"换"少一些性能开销"，观感上反而更干净。

3. 纹理和内存：风格化不是"贴图越大越好"

3.1 ASTC压缩参数选择

风格化场景的贴图有个迷思：颜色块干净、边缘锐利，就一定得用高分辨率？其实不是。卡通风格的颜色过渡通常是大面积色块，512×512足够，我的屋顶、墙面贴图基本控制在512，个别主要建筑用的1024，地面和地形用的2048但配合区域重复，实际效果和4096差别不大。

移动平台更重要的是压缩格式。PICO Neo3这类骁龙平台，最稳的是ASTC，比ETC2在颜色精度和边缘表现上都好，而且支持Alpha。我统一选了ASTC 6×6，这是一个在画质和内存占用之间比较平衡的参数。

ASTC的压缩不是导入后自动完成的，需要在Import Settings里把Texture Type和Format正确设置，然后在Build Settings里开Texture Compression，或者用Addressables时指定平台后的Compress。我最初大意了，直接在Inspector里选了某个格式，打包时Unity又按平台重压了一遍，内存数字和预览完全对不上，浪费了半天排查。记住：一套贴图、两处配置，Editor里要调，Build Settings里也要选对。

3.2 图集、Mipmap和Read/Write开关的讲究

纹理内存吃紧的时候，图集是立竿见影的手段。我把每栋房子的漫反射、AO、细节噪声分别打成Atlas，比如"所有屋顶贴图进一个图集""所有墙面进一个图集"。这样做的好处不只是省内存，还能减少材质数量，间接压Draw Call。代价是美术侧改起来麻烦一点，换一张瓦片颜色可能要动整个图集，所以我把常见配色都预先塞进去，避免反复返工。

Mipmap这个开关我纠结了很久。开了，多占约1/3内存；不开，远景大面积色块会出现闪烁和摩尔纹。村庄这种场景，屋顶、草地、墙面全是高对比度纹理，不开Mipmap根本不行。我的折中是：近景主要建筑开，大面积地形必须开，细小树叶和草丛关掉，因为它们基本不会被缩小到引起闪烁的尺寸。

还有一个非常重要的开关：Inspector里的Read/Write Enabled。默认如果开着，Unity会把纹理拷一份到CPU内存，方便你运行时读取像素，但这意味着内存直接翻倍。我的村庄场景里没有任何运行时改纹理的需求，所以全部关掉。这一项改动省下来的内存相当可观。

3.3 内存实测：从逼近上限到留出余量

优化完纹理后，我用Memory Profiler拉了一次运行时内存分布：纹理内存从最初的530MB降到240MB左右，网格内存从80MB降到35MB，加上引擎和系统开销，整体不到400MB。这个余量意味着场景里再塞一两个动态NPC、几个交互特效，内存还扛得住。

这里有个容易翻车的点：Unity的资源上传到GPU后，Inspector里显示的原始大小和运行时内存并不完全一样。有时候你在编辑器里把某张贴图调小了，内存却纹丝不动，多半是Shader里还有别的采样器（比如细节图、法线图）没压缩，或者某些贴图被放进了Resources目录导致双重加载。我排查时是逐个Material用Frame Debugger看绑定纹理，一个一个对账，效率虽然不高，但能找出很多"你以为没在用其实一直在用"的隐藏纹理。

4. 光影方案：用烘焙和"假光影"换掉实时阴影

4.1 为什么一体机上"真实颜值"不能靠实时阴影

风格化村庄如果完全没阴影，就显得飘，缺乏"扎根"的重量感。但PICO Neo3上开平行光实时阴影，代价是非常沉重的：阴影贴图每帧多一次渲染，阴影分辨率一高，整个GPU帧预算就被吃掉一块。我实测过，开了4096分辨率的实时阴影，帧时间从10ms直接跳到14ms以上，而且场景大、物体多，阴影边缘在移动时还会出现"爬动"的视觉噪声，非常出戏。

有人可能会说"那我阴影分辨率调低一点不就行了"。低分辨率阴影在PC上看也许是糊一点，但在VR里近眼观察会放大得很明显，满屏锯齿状黑影，观感相当糟糕。所以我的结论是：村庄这种场景，根本不该走实时阴影这条路。

4.2 烘焙Lightmap与AO的落地流程

我的方案是彻底的"静态烘焙路线"。场景里所有静态物体在Lighting界面里设置为Contribute GI，直接光和环境光都烘进Lightmap，动态物体（NPC、可交互的门）用Light Probes采样间接光照，一部分小物件干脆在贴图里画死了AO和假接触阴影。

具体操作上，我把Bake时的参数调得比较克制：Lightmap Resolution用的2 texels per unit，对于村庄这种中等密度场景够用了；Compression设成ASTC；Ambient Occlusion打开，强度调到0.15左右。注意烘焙前一定要处理好UV2（Lightmap UV），很多物件UV2是乱的，烘出来的光斑会花。我不会把所有东西堆一场烘焙，而是分区域、分高度烘焙，避免整个村庄一次性烘，既慢又容易覆盖细节。

烘焙完还要做一个动作：把Lightmap的Size控制在可接受范围。全场景的Lightmap Texture一多，内存照样涨。我的村庄烘出来大约6张2048，打开时统一压成ASTC，内存压力可控。

4.3 后处理做减法，我留下了哪些

最初版本我挂了完整的Post Processing栈：Bloom、Vignette、Color Grading、AO，以为这样画面就"高级"。上机以后帧率惨不忍睹。后来我做了个有些心痛的决定：把Bloom删掉，Vignette删掉，只留下Color Grading和极轻的Tonemapping。风格化村庄本身颜色鲜明，色板干净，Bloom反而会把画面搞得"糊"，删了以后观感更加利落。

关于AO后处理，我用烘焙AO替代了屏幕空间AO。风格化场景本来就不追求物理准确的阴影，贴图里的AO已经能给出足够的"分量感"，屏幕空间AO在移动端又贵又容易出杂点，没必要留。

还要提醒一件事：URP管线的Render Scale和MSAA。PICO Neo3的分辨率不低，Render Scale尽量保持1，不要去调低，否则近眼全是马赛克。MSAA我用的4x，它比在shader里做各种平滑要便宜，而且对风格化边缘的抗锯齿效果明显好。后处理栈里的抗锯齿我直接关掉，避免二次生效导致边缘过肉。

5. 上机联调的完整链路：Profiler、Frame Debugger与温度监控

5.1 我的测试流程和设备设置

所有优化做完，最刺激的是上机实测。我在PICO Neo3上开启开发者模式，用adb无线连接Unity，跑Profiler。同时把PICO系统自带的性能面板（开发者选项里的性能监控）打开，让帧率、CPU、GPU占用悬浮在画面上，这样测试时不用切出应用就能看数据。

链路是这么搭的：PC和头显连同一个WiFi，头显里打开应用，adb tcpip 5555后，Unity Profiler的Target选Remote，设备上就会实时传回CPU、GPU、Rendering各模块的耗时。要注意的点是无线调试时Profiler的数据传输本身会消耗设备资源，所以我会把Profiler的深度采样关掉，只保留最粗粒度的模块，等定位到具体瓶颈再局部开启。

我给自己定了一条测试路径：从村庄大门进入，沿主路走到尽头，再看两个侧巷，每个地点停留10秒，转一圈，然后跑步穿过村庄。这样一整个流程基本覆盖了近景、远景、密集建筑区和开阔区域的所有场景形态。

5.2 实测帧率与卡顿定位过程

第一轮实测的数据比编辑器里好看太多，但问题也没藏住。整体平均帧率在66帧左右，离我72帧的目标有距离。Profiler里一眼看到主线程的Render thread和Game thread都在负载高位，但GPU反而没有那么忙。这说明瓶颈在CPU侧的提交上，根源还是Draw Call不够低。

我回来又做了一轮"压Submission"的优化：把更多细小物体合并，顺便检查有没有多余的Canvas组件混进来。这轮优化后帧率基本贴着72跑了，掉帧只出现在进入某些建筑物密集的窄巷时，持续时间不到1秒。用Frame Debugger看那一瞬间，新增的Draw Call大多是大量的室内小物件，我最后给每个室内群组也做了合并和LOD，问题就算解决了。

掉帧还有一个隐藏推手：Shader变体。我这个项目的Toon Shader参数多，切换光照状态时Unity会现场执行变体编译，偶发卡顿。排查方法是看Profiler里的Shader.CreateGPUProgram，如果这一项在卡顿时频繁冒头，就该启动Shader Variant Collection，把用到的变体提前打包。这招很老套，但改善极大。

5.3 几个当时差点翻车的隐藏问题

有几个问题不实测根本发现不了。

第一个是温度降频。连续跑了20分钟后，设备明显发热，帧率从72缓慢掉到58，而且没有再恢复。我用系统面板看到CPU频率被压低了。这不一定能用Unity层完全解决，但至少提醒我两件事：一是不该把逻辑每帧跑的东西挪到Update里去，能缓存就缓存；二是很多效果虽然性能合格，但会提升整体功耗，得在"视觉爽感"和"能持续多久"之间做取舍。

第二个是音频资源也想当然。场景里原本放了几个环境音，我是直接拖进来的WAV，忘了压缩。结果启动时加载内存暴涨，直到我在Audio Import Settings里把Load Type改成Streaming，格式压成Vorbis，才缓过来。这类细节在资源体量小的时候毫无感知，但村庄场景杂音多、循环多，累计开销很惊人。

第三个是UI的Canvas。我在场景里加了一个简单的交互提示UI，没有用TextMeshPro而是旧版Text。Text组件在帧率紧张时重建字体纹理，偶发掉帧。换成TMP并关闭Raycast Target后，UI侧的开销几乎降到零。这种事听起来简单，但很多人就是卡在这种小地方。

第四个是镜头远裁剪面。为了能看到村庄尽头的山，我一开始把Camera的Far Clip Plane拉到了800。这对渲染开销的影响其实不算大，但会导致深度缓冲精度下降，近处物体在移动时出现轻微的z-fighting闪面。后来我把远景山体单独做成一个Skybox级别的环境，Camera的Far Clip压到120，主场景精度立刻舒服了。这个优化既省一点填充，又解决了闪面，属于顺手捡到的便宜。

第五个问题则比较深，Vertex Color和阴影烘焙的结合。我的房子模型在Blender里用顶点色刷过旧化效果，导入Unity后烘焙灯光时，我发现Lightmap叠加在顶点色上面之后颜色变得发闷。排查了很久，最后是调整Shader的顶点色混合权重并把烘焙对照检查，才让村庄的暖色调恢复回来。如果你也做风格化场景，记得检查Mesh是否有你没意识到的顶点通道在悄悄影响最终颜色。

6. 写在最后的几句实在话

这轮"把风格化村庄塞进PICO Neo3"的优化，我自己的总结就一句话：优化不是大刀阔斧删东西，而是把所有开销一笔一笔摆到台面上，然后让每一笔钱都花在玩家眼前。面数、Draw Call、纹理内存、光照复杂度、Shader变体、音频加载、UI细节，一轮一轮对账，压下去的是数字，提上来的是沉浸感。

如果让我给还没开始做移动VR优化的朋友一条最实用的建议，我会说：早期就别去追"看着漂亮的画面"，先在设备上把Profiler跑通，用真实数据驱动你决定"保留什么、牺牲什么"。风格化村庄这个体量，只要美术方向够聪明，烘焙阴影加假AO的效果一点都不比实时阴影差，甚至更有"味道"。

最后再分享一个小技巧：做优化时每改一步，截图留档，同时在设备上跑一次基准路径记录帧率，最后把所有改动和帧率变化放到一张表里对比。你会清楚地看到哪些努力值回票价，哪些只是自我安慰。项目做到这里，这台Neo3里的村庄，已经可以放心让人戴上头显在里面散步了。