从拿到“把风格化村庄塞进 PICO Neo3”这个需求到现在，前两篇已经解决了整体架构选型和流程搭建，这篇本来是打算写写“穿模修复”，结果真正动起手来才发现，绝大多数时间都花在了“怎么让它不卡”上。一个在PC上可以开满特效的风格化小镇，放到PICO Neo3这颗高通XR2上，如果不做一套完整的移动端优化流程，基本是没法玩的。
先说结论：优化这件事，不是一个单独抽出来的“收尾步骤”，而是一整套从资源、渲染、光照到运行时的系统工程。这篇就是我个人在挪这个村庄过程中踩过坑之后的完整记录，给你一个可以直接照着做的清单和思路。
1. 项目概述与硬件底阶分析
1.1 为什么风格化村庄在 PICO Neo3 上会卡
PICO Neo3用的处理器是高通骁龙XR2，GPU是Adreno 650，内存8GB，整体性能放在2021年算移动端VR的主流偏上水平，但和桌面平台完全不是一个量级。最直观的差距在于：桌面显卡做的是单屏输出，而VR一体机必须同时渲染左右眼两幅画面，每帧的着色工作量天然翻倍。再加上PICO Neo3的屏幕是3664×1920，双眼分辨率下像素量不小，实际渲染压力远高于普通手机游戏的规格。
很多人在PC上做场景时习惯了“堆资源”：模型面数不控制、贴图用2048甚至4096、灯光用一堆实时灯、粒子特效随手挂，到一体机上全部变成性能炸弹。我和团队当时把村庄场景导入PICO工程后，第一轮测试帧率只有三十几帧，画面还不时的严重抖动，几乎不可用。查了下Profiler，瓶颈依次是渲染管线的Overdraw、Draw Call数量过大、GPU端Fragment负载太高，以及少量脚本层的GC分配。
1.2 确定优化目标与预算
做优化之前，必须先定一个可以量化的指标，不然就是瞎调。PICO Neo3支持72Hz和90Hz两种刷新率，一体机上建议优先做到72Hz稳定，因为90Hz对GPU的负载几乎是线性增加。帧预算方面，72Hz下一帧的渲染时间大约13.9ms，90Hz下只有11.1ms。考虑到它是移动端SoC，CPU和GPU是共享功耗的，实际预留的余量要更多一些。
以下是我在立项时给团队定的“资源预算表”，你可以对照着修改：
| 项目 | 预算 | 备注 |
|---|---|---|
| 帧率 | 72Hz，稳定不掉帧 | 首测以72Hz为目标 |
| 单帧时间 | <= 13ms | 留出一些CPU余量 |
| Draw Call (渲染线程) | <= 120 | 移动端尽量压制 |
| 三角形数量 | <= 200k（全场景） | 风格化场景可以更低 |
| 纹理内存 | <= 600MB | 包含所有mipmap |
| 场景内实时光源 | 0~1个 | 风格化尽量去除实时光源 |
| 脚本GC Alloc | 每帧 < 10KB | 避免频繁的垃圾回收 |
定好预算之后，剩下的所有操作都是往这个数字靠拢。实际过程中，只要Draw Call在120以内，三角形在200k以内，通常就能跑到72Hz，具体还要看Shader复杂度。
2. 优化方案的整体架构
2.1 渲染管线选择：为什么锁死URP
在Unity里适配一体机，第一件要做的事情是把渲染管线切到URP（Universal Render Pipeline）。其实Unity 2022以上的版本，很多新项目都默认URP了，VRS等移动端特性也都在URP下面支持。没有特殊情况不要用HDRP，它虽然画面漂亮，但很多功能在Adreno 650这种移动GPU上根本不现实。风格化村庄本身对光照的真实性要求不高，URP完全够用。
切换URP之后，还需要做减法。我们团队在Project Settings里把不用的功能尽量关掉：阴影质量里的级联数从默认的4降到1，阴影距离缩到50米以内，后处理只保留必要的Color Grading和Bloom（后者在风格化村庄里几乎等同于灵魂效果，不能丢，但要用升采样版本）。URP Asset的渲染分辨率也可以调整，配合PICO的固定注视点渲染（FOV前向渲染）做动态分辨率缩放，在低负载时期降低一半渲染分辨率，画质下降不显眼但帧率能稳定不少。
之所以优先用URP而不是自己写管线，是因为它的SRP Batcher是现成的，配合无光照的特定材质，可以让CPU端的渲染状态切换成本大幅降低。你自己去手写一套管线去做这些批量处理，一周能出个雏形就不错了，运营维护下来成本极高。
2.2 宏观分层：资源、渲染、物理、脚本
优化这套村庄，不是只做“减面”或者“减少灯光”这一类单点动作，我把整个项目拆成了四层，每一层都要单独过一遍：
- 资源层：网格面数、纹理尺寸、贴图压缩格式、材质球数量、资源冗余清理。
- 渲染层：LOD、遮挡剔除、静态合批、GPU Instancing、SRP Batcher、阴影距离控制。
- 物理层：尽量用静态碰撞体、减少动态刚体数量、精简Collider形状（用简单的Box代替复杂MeshCollider）。
- 业务层：脚本里的Update逻辑、定时器、对象池、字符串拼接、Find调用、协程堆积。
每一层需要专门的工具去检测。比如资源层用Unity自带的Texture Analyzer和Frame Debugger，渲染层看Profiler里的Rendering和Batching信息，物理层看Physics Profiler，脚本层直接看CPU耗时倒排。在我的项目中，出问题最多的其实是渲染层和业务层，资源层因为风格化模型本身就比较精简，压力反而不算大。
2.3 性能分析工具怎么用
调试优化最忌讳“凭感觉改”。你觉得自己某个材质复杂砍了20%性能，结果砍错了地方反而更糟。我常用的工具有这些：
- Unity Profiler：必须跑真机上看，Editor里的性能数据基本都是骗人的。
- PICO Device Simulator：PICO提供的PC端模拟，适合逻辑调试，性能模拟不准，但开发效率高。
- RenderDoc：逐帧抓GPU事件，可以看每个物体消耗的像素数和时间，非常适合排查哪些物体在霸占GPU。
- Adreno GPU Profiler：高通出品的GPU级分析工具，能直接看到着色器占用、纹理采样带宽、总线带宽。这是移动端VR优化中非常实用但容易被忽视的工具，因为很多性能问题实际上不在CPU而在于GPU的纹理带宽耗尽。
个人建议：每一次改动前，先抓一份基线数据；每次改动后，再抓一份对比数据。没有基线数据，你后续所有所谓的“优化效果”都是臆测。
3. 网格与绘制优化的实操细节
3.1 三角形预算与LOD策略
风格化村庄的特点是建筑结构简单、边缘锐利、色彩干净，这给了它一个很大的福利：三角形数量需求其实很低。一个接近正方体的民房，用500到1000个三角形已经足够精致，关键是贴图纹理要好、法线要准。可惜很多团队是从外包手里拿资产，动辄一面墙一个房子就上万面，这在一体机上根本顶不住。
我的建议是给村庄里的每一类物件设置LOD组，比如：房子的LOD0是2000面，LOD1是800面，LOD2是300面，LOD3是替换成a片假体或者直接使用Distance Culling（距离超过150米直接消失）。LOD切换距离需要实机测试，因为VR里看东西，重要物体在眼前哪怕距离稍远如果突然LOD跳变会非常明显，所以要把小房子的LOD换挡调得更靠后，反而是那些远处的小装饰，可以很早就切掉。
LOD的好处不只是减少顶点，它还能减少纹理采样压力：LOD1使用2048纹理，LOD2换成512纹理，这样在内存和带宽上都有收益。这个收益是成体系的，别只把它当“减少面数”。
3.2 合批策略：静态合批、动态合批、GPU Instancing
村庄场景里最多的就是大量重复的房屋、树木、石块，这类物体是GPU Instancing的最佳适用对象。尤其是树木，风格化树叶通常是一张Alpha测试的透明贴图，如果不做合批，每棵树一个Draw Call，两百棵树就两百个Draw Call，直接超出预算。
实操中我是这样处理的：
- 静态建筑（墙壁、屋顶、路面）：全部标记为“Static Batching”，并保证它们都是相同的材质（或者少数的变体）。
- 重复物件（树木、石头、小栅栏）：禁用静态合批，改用GPU Instancing，在材质Shader中启用了INSTANCING_ON关键字，批量绘制。
- 动态物件（推车、可以互动的门板）：使用SRP Batcher，尽量减少材质之间的Shader变体差异，以便合并Draw Call。
这里需要注意：静态合批和GPU Instancing不能同时作用在一个物体上，你应该区分哪些是彻底静态的，哪些是会复用的独立物件。村庄里大部分物件都是静态的，我最终把Draw Call从初始的380多降到了95左右，主要靠的是静态合批，以及把几十种互不兼容的材质统一成同一份Shader的多个参数变体。这一步骤收益巨大，比减面还明显。
3.3 材质与Shader定制的极致
风格化村庄有个特点：同一类材质往往差异在颜色和贴图上，这非常适合做成一个材质基类配上纹理变体。比如墙面材质，可以用同一份URP标准Shader，通过不同的BaseMap和Color参数来区分白墙、灰墙、黄墙。这样所有墙面就能走SRP Batcher，而不是每个墙单独一个材质球。
另外，风格化渲染常用到边缘光、卡通描边、透明混合。如果直接在URP默认Lit上挂这些效果，会引入一堆额外指令和采样。我的经验是：为风格化项目定制一个精简的移动端Shader，只保留BaseMap、NormalMap、Smoothness、Emission、以及两份遮罩图（比如AO+颜色偏移）。所有特效都做成Shader可选开关，按需开启。实测这样的Shader相比Lit可以节省约25%的GPU时间，因为减少了法线计算分支和光照模型复杂度。
最关键的一个步骤：彻底移除场景里所有透明材质的实时阴影投射。透明物体在实时阴影下会触发两次渲染（一次ShadowPass、一次MainPass），而且多个透明物体叠加时Overdraw严重。村庄里的塑料花、草、透明纱窗就是当时卡顿大头。把这些改成只接受烘焙阴影，并让它们在Renderer的Cast Shadows中设为Off，帧率立刻上来。
4. 光照与烘焙优化
4.1 彻底拥抱烘焙光照
PICO Neo3这类一体机上，实时渲染光照的代价相当高。一个村庄如果想保留“一个主太阳光”的实时全局光照概念，基本上会引发阴影计算、光照探针、天光、反射等一整串性能开销，直接掏空帧预算。我的处理思路是：把场景做成全静态烘焙，所有光源在编辑器里烘焙后，运行时不再有任何实时光。
具体做法：在Unity场景里，将自然环境的灯光（主太阳、补光、天空光）全部标记为Static，使用Lightmapping Mode里的Mixed模式，广场景物标记为“Contribute GI = true”，烘焙出Lightmap。对于风格化村庄，我们使用了一块256x256分辨率的lightmap tile，因为风格化画面本身色块鲜明，不太需要精细渐变，低分辨率反而能保留像素感，也节省内存。
遇到动态物体需要和静态场景有光照交互时，用Light Probes（光照探针）。散布在村庄道路和广场上的探针数量不用多，七八个就够了，很省资源。
4.2 阴影优化的取舍
实时阴影在移动VR里是最要命的部分。我们团队最终把实时阴影全部关掉了，改用以下方案代替：在房屋和路面上预烘焙一张假阴影贴图贴在地上（decal材质），本质上是一张带模煳边缘的黑色透明贴图，贴合地面角度的半透明网格。这种假阴影在风格化场景里效果极其自然，而且零运行成本。
如果你实在需要物体之间产生遮挡关系，可以在Lighting设置里保留一个级联阴影，但阴影距离控制在15米内，阴影分辨率调低到1024。实测这个配置在村庄广场附近可以看见明显的阴影贴图颗粒，但在清晰度和帧率之间做取舍，我最终选择关掉，只保留假阴影。
另外还要注意反射。URP里如果用实时反射探针，每个探针都会让范围内的物体额外执行一次反射渲染。合理做法是用一个“天空盒反射”替代：把所有光滑物体的Smoothness设低，配合一张环境反射贴图（Cubemap），足以表现陶罐、水桶、窗户玻璃的光泽感。
4.3 风格化光感在受限条件下如何保留
风格化村庄的精髓其实不是真实光照，而是“亮部干净、暗部利落、颜色有辨识度”。所以优化不能把光照调的乌漆嘛黑。我后来用的方案是“烘焙主光 + 后处理补光”：烘焙时，主阳光方向固定，亮部呈奶黄色；后期用Color Grading抬升阴影亮度，并加强对比度，让画面更有“手涂感”。
一个我踩过的坑是：Bloom强度在PC上看着刚刚好，但在PICO Neo3的OLED屏上会显得刺眼，而且Bloom全屏模糊会掩盖画面细节，也让GPU的即时后处理压力增大。最后我把Bloom阈值调高、半径缩小，风格化氛围反而更清爽。这个参数不能照搬PC工程，需要逐台真机看效果微调。
5. 内存与运行时优化
5.1 纹理压缩与贴图优化
一体机的显存（实际是系统内存划拨一部分）不是无限量的。我们最初把PICO Neo3跑起来后，内存到1.6GB，打开Profiler一看，纹理占掉800多MB，大部分是PNG直转的RGBA32格式。这种格式在桌面平台没问题，移动端却必须改成压缩纹理。
推荐做法：所有颜色贴图使用ASTC 6x6或8x8压缩，法线贴图用ASTC 5x5（因为法线精度要求更高一点），透明贴图得单独注意Alpha通道质量。尺寸上遵循“能小则小”原则：大件用1024，中等用512，远景重复小件用256。就像前面说的，LOD2切换时把纹理尺寸也一起切换，这种组合拳能显著降低内存。
5.2 资源管理与加载策略
PICO Neo3内存8GB，但系统、管线、Unity运行时再加VR运行时占掉不少，留给应用的实际只有3~4GB。村庄场景如果一次性全量加载，光场景网格、贴图、Shader、Prefab就能吃掉一大半。
这里建议用Addressables做资源分组：村庄的公共地形、天空、永久建筑作为常驻资源；进入房屋时动态房间内家具、地图上的交互NPC、大型装饰物等按需加载和释放。如果项目本身不强依赖热更新，用Unity自带的Scene Load模式（多场景叠加）也可以。我在村庄项目里分成了Base场景、Village_House_A、Village_House_B、Village_Event等子场景，进入一定范围内再异步加载。
5.3 脚本与GC优化
移动端CPU其实也挺弱，而脚本GC分配是最常见的“隐形杀手”。我在Profiler里看到的是每帧GC Alloc持续在40KB以上，最终定位到几个来源：在Update里频繁使用字符串拼接生成HUD文本；频繁Instantiate和Destroy物品（比如落叶、雪花、可拾取道具）；每次交互时new一个列表。这种虽然没有让程序直接崩，但会周期性卡顿（GC挂起）。
处理手法很常规但有效：
- 把所有文本显示改成预分配的StringBuilder，并且只在内容变化时更新。
- 落叶、飘雪粒子一律用ParticleSystem而不是生成小物体；物品掉落用对象池管理。
- 每帧需要计算的Vector3乘法，尽量避免new临时数组，改为传struct参数。
这个场景优化完之后，脚本GC Alloc基本降到每帧5KB以下，卡顿感明显减少。对于VR来说尤其重要，因为任何一点点卡顿都会让用户立刻出现眩晕感。
6. 常见问题与排查技巧实录
6.1 PICO Neo3 上画面偏糊或闪烁
有段时间画面边缘一直发虚，我以为是渲染分辨率开低了，结果查下来是固定注视点渲染的默认设置与我们的后处理不兼容，尤其Bloom会在注视区外产生闪烁。PICO的PICO_XR SDK里有FOV Stencil功能，如果你打开了固定注视点，后处理效果尽量使用URP的Volume，不要在Renderer Feature里挂自定义材质的来回采样。另外动态分辨率的调节阈值要设定好，不要在相机移动时频繁升降渲染分辨率，否则用户会看到清晰度一跳一跳的，更容易晕。
6.2 掉帧但Profiler看不出明显热点
遇到过一种场景：帧率低，但CPU和GPU的耗时在Profiler里都不算高。后来发现是热功耗降频——骁龙XR2在机身发热到一定程度后会自动降频，导致性能断崖式下跌。解决方法是优化整体功耗：降低渲染分辨率、关闭不必要的后处理特效、限制粒子数量、减少每帧的Overdraw。这其实是一个正循环：画质收益微小、功耗却极大的特效，果断去掉，温度稳定后帧率反而稳定。
6.3 光照烘焙后物体发光异常
烘焙时如果场景中存在未标记Static的模型，或碰撞体与视觉网格不一致，Lightmap的UV可能因为第二套UV缺失而错乱，导致物体部分区域不受GI。强烈建议所有参与烘焙的模型，导入设置里勾选“Generate Lightmap UVs”，并检查贴图接缝。
6.4 常见问题速查表
| 现象 | 排查方向 | 我的处理 |
|---|---|---|
| 整体帧率低 | GPU Fragment 超载 | 压缩纹理、降低渲染分辨率、关闭实时阴影 |
| 进入区域瞬间卡顿 | 异步加载阻塞 | 提前预加载，使用协成或者异步加载缓冲 |
| 画面偏亮发白 | Bloom阈值 / HDR色调映射不当 | 调整Color Grading，关掉Debug视图 |
| 物体闪烁抖动 | LAOD 切换 / 阴影Z-fighting | 延长LOD切换距离，微调网格位置 |
| 内存占用随场景上升 | 资源未释放 | 检查Scene卸载时是否遗漏Assets.UnloadUnusedAssets |
7. 写在最后的经验和一点冷门技巧
做了这三轮“把风格化村庄塞进PICO Neo3”的折腾，最大的感受是：优化的本质是“用预算约束做取舍”。你不可能既保全部高频材质细节，又要求72Hz流畅运行，还让内存只有1.5GB。你要做的，是把场景里“用户根本注意不到”的部分砍掉或者弱化，把“一眼入魂”的风格元素留在最适当的位置。
最后分享一个小技巧：移动端VR场景中，相机朝向后方的物体其实完全没有渲染意义。利用PICO的追踪设备信息，实现一个简单的“朝向剔除”，让相机背后的物体提前结束渲染（通过脚本把相机的剔除平面自定义成前方110度范围），可以再白拿10%~15%的渲染性能。这个优化没有改变任何画面呈现，但成本为零，效果极好。
每个项目其实都没有终局，后续我可以把这个村庄场景再接上时序冷热资源调度，甚至可以尝试加入卡通描边Shader的移动端版本。但至少目前，它在PICO Neo3上已经跑得又稳又漂亮了。
