系列前两篇我们聊完了怎么把风格化村庄的模型、贴图和光照从PC端迁到PICO Neo3场景是塞进去了效果在编辑器里看着也还行。但拿到真机上跑一圈问题全冒出来了——转身掉帧、场景一复杂就发热、渲染帧率上不到72Hz更有意思的是有些地方明明模型不多帧时间却高得离谱。这次我彻底不绕弯子了直接把项目接上Profiler把村庄场景从头到尾扒了一遍把拖累帧时间的几个大头全揪了出来。这篇不聊虚的直接讲我在优化风格化村庄渲染时做的几件实事怎么定位CPU和GPU瓶颈、怎么在不丢掉风格化观感的前提下砍掉过度绘制、怎么让合批和遮挡剔除真正生效以及最后从33ms优化到15ms左右的完整过程。整个过程都是在PICO Neo3真机上验证过的Unity版本用的2021.3 LTS渲染管线是URP。1. 量化问题先行PICO Neo3的硬件底子与帧时间预算1.1 先搞清楚PICO Neo3能干什么PICO Neo3搭载的是骁龙XR2平台这是一颗为XR设备准备的SoC理论性能不弱但散热和功耗限制摆在那里实际持续性能远没有纸面数据那么漂亮。屏幕刷新率支持72Hz和90Hz我在VR项目里一般直接锁定72Hz。为什么不用90Hz72Hz下帧时间预算是13.9ms90Hz下只有11.1ms而一体机跑风格化场景时往往连13.9ms都压得很吃力90Hz只会让压力翻倍。这里要特别注意13.9ms不是全程归你用的。XR设备在渲染左右眼之外还有系统级的ATW、透视、追踪等环节实际游戏逻辑和渲染只能分到其中的一部分。我在PICO Neo3上通过Unity XR插件查看留给Unity的帧窗口大约在11ms到12ms之间再减去脚本和物理逻辑的时间渲染预算大概只有8ms到9ms。很多人发现画质调完还是很卡就是因为没把预算算清楚实际可用的渲染窗口其实非常窄。判断设备到底剩多少窗口可以用Unity的Frame Timing Stats也可以在Profiler里直接看WaitForTargetFPS和Present相关的时间。我习惯在开发早期就把这个数字打出来显示在角落这样后续写性能优化的每一步都能有个硬性参照而不是等掉帧了才开始猜硬件到底吃了几碗饭。1.2 用Profiler定位瓶颈在CPU还是GPU在Unity里开Profiler后第一步不是急着看哪个模块高而是先切到性能分析模式。我习惯把Profiler的Target Platform设为PICO Neo3对应的窗口然后跑一段固定的场景巡视路径一边走一边记录。看CPU Usage和GPU Usage的比值。如果CPU耗时高说明Draw Call、脚本、物理、动画、粒子这些系统在抢时间如果GPU耗时高说明Shader复杂度、填充率、纹理带宽顶不住。我当时的Profile数据非常有代表性CPU平均耗时9msGPU平均耗时22ms。其实不用想瓶颈在GPU。这时候如果我去合并网格、砍Draw Call效果会非常有限因为CPU根本不是主要瓶颈。真正要动的是Shader、Overdraw、Render Scale、纹理尺寸这些会压满像素的东西。如果你看到CPU和GPU都高一般先处理CPU因为CPU瓶颈往往会造成明显的卡顿而GPU瓶颈的表现是慢慢掉帧到十几帧更隐蔽。还有一个容易忽略的点把Profiler里的Present和VSync相关的时间剔除后再看真正的CPU/GPU时间。一体机上VSync和画面输出经常被系统同步卡住有些人看到帧时间高就开始优化结果优化半天发现是Present同步的问题白忙一场。1.3 记录三组数据的基准原则优化最忌讳凭感觉。我给自己定的规矩每次优化前必须记录三组数据——平均帧时间、最高帧时间、Draw Call加SetPass Call。然后优化一轮再跑同样的路径看看各降了多少。如果一轮优化改了好几个变量后面发现问题就没法判断到底哪一步起了作用这属于自找麻烦。这里专门说下峰值帧时间。平均值好看但偶尔飙出一条尖峰说明某些帧在做特别重的操作常见来源是GC Alloc、动态合批失败、Shader编译或者遮挡剔除的更新。这些尖峰在VR里比平均值更要命你可能察觉不到明显的掉帧但头部转动时会有一瞬间的画面迟滞眩晕感就是这么来的。所以我每次看数据都要打开Timeline视图把帧时间曲线拉出来看专挑那些尖峰帧去查原因。实际上我建议把“记录基准”这一步也自动化直接在工程里写一个简单的性能记录脚本跑固定路径时按快捷键记录平均帧时间、Max帧时间、DrawCall和SetPass Call输出成CSV。这样改一版数据存一版后面整体对比时一目了然比自己拿本子记靠谱得多。2. GPU侧的釜底抽薪风格化村庄的Overdraw与像素填充率2.1 为什么风格化场景尤其容易喂饱GPU风格化村庄看起来简单——低多边形、色块、卡通材质——但把它喂给GPU时反而很容易爆填充率。原因有三个第一风格化场景通常喜欢用半透明白模做植物、草丛、树叶这些材质虽然单个看着面积不大但堆叠起来每个像素会被渲染好多遍第二低多边形模型经常使用硬边和大量锐角渲染时需要更频繁地切换多边形状态第三为了让颜色明快风格化材质经常在Shader里做颜色偏移、边缘光、淡入淡出之类的效果这些效果都要在像素着色器里跑每一滴都有成本。我当时把场景里所有半透明物体列了一遍光是草、花、水面、烟雾加一起就占了场景物体的四分之一。这些半透明物体会让渲染器从后往前排Overdraw直接翻倍。移动端的GPU内存带宽本来就不富裕风格化村庄这种又满又密的构图填像素的速度很快就跑不赢帧时间预算。有一个比较直观的验证方法在Unity里使用RenderDoc抓一帧用Overdraw可视化着色器查看像素重复渲染次数。我在村庄中心区域的Overdraw数值高到离谱某些草丛茂盛的位置同一像素被写了七八次这几乎等于把分辨率翻了几倍在跑。看到这个数据之后我就知道必须从渲染机制上砍掉重复写入。2.2 砍Overdraw但不破坏视觉密度透明改不透明靠贴图取胜Overdraw的典型解法是减少半透明物体的实际绘制。我的做法很直接把草、灌木、树叶这些“本来能做半透明”的材质全部改成不透明材质。你可能担心这样会失去通透感其实风格化的草在真实感画面上本来就不靠透明来体现靠的是交叉面片和贴图。把Alpha Blend改成Alpha Test更准确地说是Alpha Clip面片中央画密集草叶周围画透明缝隙这样既能渲染出棵棵分明的草又不用反复写后台缓冲。改完材质后的Shader关键部分大概是这样的// 半透明草改Alpha Clip草 Tags { Queue Geometry RenderType Opaque } Pass { // ... ClipMask(i.uv); // 原来这里的Blend SrcAlpha OneMinusSrcAlpha 直接移除 // 把alpha低于阈值的光照片段剔除 }你可能会觉得Alpha Clip仍然会产生一些额外指令但GPU处理Alpha Clip比处理Blend要快得多因为Blend必须读回后台缓冲再混合而Clip直接丢弃片元。实测同一片草地在改完材质后帧时间降低明显而视觉上草叶边缘仍然有锯齿配合风格化画风反而更“卡通风”。改完草之后我又做了一件事把水面材质里的折射计算去掉。移动端的水面没法做屏幕空间反射折射更不可能我用一个简单的半透明水色叠加波纹法线贴图效果在村庄场景里完全够用。这样一处调整Overdraw又降了一截而且视觉上的差异几乎看不出来。2.3 Shader优化从Full Precision到Medium Precision的实战风格化村庄的Shader一般不会特别复杂但如果每个材质球用了很多浮点运算叠加起来还是能压垮GPU。优化Shader的关键就一条移动端能用半精度就用半精度能用贴图就不用计算。在URP里最简单粗暴的优化是把Shader里的float改成half。我排查了所有自写Shader把没必要的float精度全部下调到half涉及颜色混合、UV扰动、顶点位移这类操作视觉上没有任何区别但中等精度指令在部分移动GPU上速度优势明显。另一些常见的坑包括在像素着色器里写pow、sin、cos、smoothstep的连乘这些数学函数对移动GPU很不友好能放到顶点着色器就放到顶点着色器或者直接用贴图采样代替。然后是光照部分。风格化村庄不需要物理正确的多光源实时光照我把光源数量压到最少只保留一个实时方向光其他光源全部用烘焙光照贴图。实时阴影直接关掉在URP里把Shadow Cascades设为No CascadesShadow Type设为None。烘焙光照和阴影足够村庄场景使用还能给风格化画面增加手绘质感的软阴影效果。如果你一定要保留实时阴影我建议把阴影距离砍到10米以内阴影分辨率降到512或者只对主角周围的几棵建筑开阴影。村庄里那些远景的房屋阴影人眼根本不会注意到砍掉之后能省下一大块GPU时间。3. CPU侧的减负艺术Draw Call、合批与网格重组3.1 CPU时间去哪了Draw Call只是冰山一角很多人一说优化就提减少Draw Call但Draw Call本身并不是CPU消耗的大头。真正的大头是SetPass Call和数据上传——每次切换Shader Pass、切换材质球CPU都要做一堆状态验证和传输工作。在Profiler里能看到SetPass Call往往比Draw Call少但对CPU时间的贡献却更明显。我在PICO Neo3上看自己的数据一开始Draw Call有320个SetPass Call有150个平均每个SetPass要状态切换两到三次。这些切换大部分来自材质球之间的差异有的用Alpha Clip有的用Alpha Blend有的贴图大小不一致有的Tiling不一样。想让合批真正生效第一步不是合并网格而是让同类型物体用同一套材质球统一Shader参数减少状态切换。用Frame Debugger逐帧看的时候尤其明显同一个房屋模型因为材质球里Color参数差一点点就被拆成两个Draw Call。这种零碎状态切换是CPU侧最隐蔽的浪费。我后来把所有房屋材质做成预设体统一颜色、统一Tiling、统一Metallic和Smoothness参数Draw Call数字立刻下去了一截。3.2 静态合批、动态合批与GPU Instancing的取舍三种方式各有适用场景。静态合批适合纹理朝向固定、不会动的场景物体它把多个网格合并成一个代价是内存和构建时间上升动态合批适合顶点数很少的小物体但有900个顶点的限制一旦物体顶点数超了就只能放弃合批GPU Instancing适合大量使用相同网格和相同材质的物体它把一个Draw Call对应一堆实例非常适合村庄里大量重复的树、石头、围栏。我的选择是三者混用把房屋、墙面、屋顶这类大体量网格做静态合批因为它们不会动也不需要变形把散落的小石头、小木箱、矮篱笆做动态合批顶点数基本都在900以内把大量重复的树木和草丛用GPU Instancing同一棵树一个Draw Call就能渲染几十棵。三种方式的具体取舍可以参考这个表格技术适用场景顶点限制内存开销我的使用对象静态合批固定不动的网格无较高合并网格会复制顶点数据房屋、墙面、屋顶动态合批顶点数很少的小物体900顶点内较低石头、木箱、篱笆GPU Instancing大量相同网格相同材质无硬性限制但有实例数上限较低树木、草丛、灌木需要特别提醒的是GPU Instancing在URP里和Lightmap兼容性要检查一下。如果实例化的物体用的是光照贴图可能要调整材质球的Keyword才能让Instancing生效。我当时用了一个小技巧给实例化物体单独建一套不带光照贴图的材质视觉效果差别不大但优化效果立竿见影。3.3 LOD与遮挡剔除的配置细节LOD组很简单给主要物体房子、树、凉亭、水塔做三档模型LOD0是高模、LOD1是中模、LOD2是低模然后按照距离切换。PICO Neo3的屏幕像素密度高但VR设备对远距离物体的细节其实不太敏感我把切到LOD1的距离压到12米左右切到LOD2的距离压到25米左右比PC端激进很多视觉上几乎感觉不到差别但每帧要渲染的三角形数和填充面积少了很多。LOD切换时要小心“文件闪烁”现象两级模型如果在细节上差距太大玩家会看到物体突然“瘦一圈”。我给风格化村庄的LOD1和LOD2保留了基本造型轮廓只是删减法线细节和小的附着物比如屋顶上的烟囱、围栏边的木桩差距控制在一个合理的范围内。实践中可以先在编辑器里把摄像头拉远逐级观察切换效果再回去调整距离阈值。遮挡剔除是另一个容易被忽略的大头。Unity的遮挡剔除需要提前烘焙我一开始图省事没做结果场景里远处的房子和近处的高墙互相重叠每一帧都在渲染大量被挡住的东西。后来给场景添加了Occlusion Area把村庄的多个区域包进去烘焙数据后帧时间明显降了一截。尤其是站在村庄中心的时候视线被建筑群挡住旁边那些根本看不到的房子都不渲染了帧时间能再少两三毫秒。还要特别注意遮挡剔除对动态物体并不友好动态物体默认不会被静态遮挡剔除。如果场景里有跑来跑去的NPC或者飘动的粒子它们依然会被渲染。所以遮挡剔除主要用于静态建筑、树木和地形动态物体还是得依赖其他优化手段。4. 实操记录一次从33ms到15ms的完整优化过程4.1 建立基准先记录很差的数据优化之前我先记录一组完整的基准数据这组数据代表“很差但真实”的起点后面每一步优化的效果都会拿它做对比。场景状态PICO Neo372Hz模式Render Scale为1.0实时阴影开启没有做任何LOD和遮挡剔除所有材质都还保持着PC端的参数。我沿着村庄主街道从南到北走了一遍用Profiler记录平均帧时间。结果相当难看平均帧时间33msDraw Call 320SetPass Call 150部分转弯处帧时间甚至飙到50ms以上。这个数据虽然烂但它足够真实也说明优化空间大。刻意记录这种数据有一个额外好处如果后面优化过程中出现“越改越卡”的情况能第一时间回退到初始场景重新对比。我通常给初始状态单独存一个场景版本命名比如“Baseline_Bad”后续所有改动都从它衍生出去出了问题直接切回来就行。4.2 每一轮只动一个变量记录一次对比我把整个优化过程拆成五轮每轮只动一个主要变量然后记录数据。优化轮次主要操作平均帧时间Draw CallSetPass Call备注1初始状态33ms320150全阴影开2Render Scale 0.828ms320150画质略降3关闭实时阴影19ms320150效果巨大4静态合批网格合并17ms15862CPU明显减负5LOD组遮挡剔除15ms12148接近预算上限这五轮做完平均帧时间从33ms降到15ms虽然还不到72Hz的13.9ms预算线但已经非常接近配合系统级的Reprojection实际体验顺畅了非常多。每轮改动我都另存了一个场景版本万一一轮改崩了可以快速回退。为什么第二轮要把Render Scale先降到0.8因为真机上很多性能问题在低分辨率下跑一遍之后会暴露得更清楚。Render Scale降下来如果帧时间没有明显改善说明瓶颈不在填充率可能在Shader或者CPU如果帧时间一下子就降下来了那就顺着GPU方向继续查。我这次降到0.8发现帧时间只降了5ms说明像素填充虽然是瓶颈之一但还压着另一个更大的问题——实时阴影。关掉实时阴影之后帧时间直接降到19ms这一步是全场收益最大的一次操作。实时阴影在移动端几乎是灾难尤其在低多边形场景里阴影贴图的分辨率稍微调高一点带宽和GPU时间就成倍往上走。我的结论是风格化村庄优先用烘焙光照贴图哪怕要花几分钟离线烘焙也是完全值得的。4.3 纹理、图集与压缩格式的最终调整在前四轮把渲染大头压下来之后我又对纹理做了一次整理。风格化村庄里的颜色贴图往往不讲究分辨率有些素材直接从素材商店拿过来就是2048分辨率但放在PICO Neo3这种一体机上看根本用不上。我把所有大尺寸贴图统一压缩到1024或512并设置成ASTC格式。ASTC 6x6的块大小在画质和性能之间最平衡8x8块能进一步省显存但画质损失看得见。村庄里大量重复的木屋、石头、草垛用几张图集合并减少材质切换带来的状态变化。Mipmap对降低放大屏幕时的带宽压力非常有帮助我全部打开再配合适当的各向异性过滤远看近看都不会闪。这里有一个贴图压缩的坑ASTC不是所有引擎格式都默认支持PICO Neo3的GPU是支持ASTC的但你在Unity里构建时必须确认Texture Importer里选对了Android格式。如果格式选错了Unity会默认转成RGBA32未压缩格式那显存占用和带宽消耗会直接爆炸帧时间比优化前还难看。纹理尺寸也不是越小越好。我在村庄入口做了一面比较大的酒馆招牌结果降到512后近看糊得不行。最终解决方案是招牌保留1024但周围墙面压到512远处山体压到256。这个思路是“给玩家眼前的东西留足够细节远处的东西能省就省”整体画面观感几乎没有损失。5. 常见问题与排查技巧实录5.1 合批失效的十大原因速查优化过程中最容易遇到的问题就是合批失效。我自己整理了一张速查表排查顺序按出现频率排原因表现对策多个材质球共享同一份Shader但参数不同同一模型被拆分多次合并材质球参数统一Material材质ID不同但Unity按ID合批无法合批使用同一个Material实例物体不是静态静态合批无法生效勾选StaticLightmap index不同合批被打断统一光照贴图UV顶点数超过动态合批上限Draw Call飙高拆网格或改GPU Instancing使用了不可合批的Shader内置粒子、雾特效等无法合批换自定义Shader物体在不同Layer上合批容易失效放同Layer顶点属性过于复杂无法合批简化Mesh使用多Pass Shader每个Pass单独Draw减少Pass数量材质启用了GPU Instancing但不满足实例化条件反而增加Draw Call检查材质Keyword和网格实话说合批失败场景里最常见的还是材质球不统一、顶点数超上限这两条。我排查时一般先选中一个高Draw Call的物体看它周围有没有同模型如果同模型却分成了多份那多半就是材质球或者Lightmap的问题。使用Frame Debugger能看到每个Draw Call的具体原因Unity会标注合批失败的原因照着提示改就行。5.2 Shader变体膨胀与包体失控移动端项目里Shader变体膨胀很容易把人坑了。URP会根据材质启用的Keyword编译大量变体比如你场景里用了某个带Shadows的Lit材质哪怕场景不启用阴影编译器可能依然把阴影相关的变体编进去。构建一次动不动出来上千个变体包体直接变大启动时Shader编译的卡顿也跟着来。解决方法是去Project Settings里配Shader Control把用不到的Keyword全部关掉。我自己用了一套“最小变体集合”只保留Alpha Clip、Lightmap、GPU Instancing这几个Keyword的变体阴影、雾效、粒子、HDR相关的全部排除。配置完之后构建速度提升了一截真机进场景的首帧卡顿也少了很多。如果你不想在全局设置里改也可以用ShaderVariantCollection手动收集需要的变体。做法是先用ShaderVariantCollection记录当前场景中实际用到的变体然后构建时只打包这组变体。这个方案更精准但维护成本高一些适合变体已经稳定之后再用。5.3 遮挡剔除漏剔导致帧时间骤升遮挡剔除调试的一个常见现象是站在某个角落帧时间正常走几步突然掉帧严重一查发现一堆远处的房屋没被剔除。排查方法是打开Occlusion Culling窗口的Visualize面板逐个Region查看遮挡数据是否覆盖了所有可能产生遮挡的建筑群。如果漏剔的区域正好在Occlusion Area外Unity就不会做剔除计算。我给村庄追加了多个Occlusion Area覆盖主街道两侧、广场、河岸几个视线交叉区域。注意Occlusion Area不要放得太大太大的Occlusion Area反而会导致烘焙时间变长和更新开销变大所以拆成一组小区域是最合适的。另外一个容易踩的坑是静态物体生成Mesh Collider时遮挡物只认Occluder Static标志。如果你勾了Static但没勾Occluder StaticUnity会认为它是被遮挡物而不是遮挡物可能造成漏剔。我排查时会在Occlusion窗口里把IsOccluder列调出来确保主要建筑都勾上了。5.4 GC Alloc与随机性掉帧最后说一个特别容易被忽视的坑GC Alloc。脚本里如果每次Update都new一个List、数组或者用LINQ、字符串拼接就会产生垃圾内存。Unity这边GC回收时会卡顿尤其在一体机上更容易造成随机性掉帧。我优化时的做法是给所有可能频繁调用的逻辑做对象池预先分配数组尽量用for循环代替LINQ。比如给场景里散落的树叶粒子做独立池复用初始一帧只分配一批叶子实例后面每帧在池里取和放回不再产生GC。还有一个细节是避免在Update里读取Transform组件因为每一次Read/Write Transform都会产生同步开销。把这些代码级小坑解决之后Profiler里的GC Alloc曲线终于能从一条毛刺变成一条直线。如果你用的是Unity 2021以上的版本还可以在代码里多用Span或者用NativeArray配合Burst编译把内存分配频率降到最低。移动端VR项目里很少需要复杂的热更新逻辑纯计算部分用Burst能省出一大截CPU时间。这套流程跑完我的最大体会是移动端VR优化真不是靠几个技巧就能一劳永逸的每个场景都有自己的瓶颈点。关键是让优化变成一种可测量的习惯先记录数据再动一个变量跑一遍再记录对比循环。最终我不光把帧时间从33ms拉到15ms左右更重要的是学会了怎么在动手之前就知道该往哪边使劲。下一步我打算把优化完的场景拿去做更多极限测试比如同时出现大量角色、加一些动态天气系统看看哪些地方还会冒出新瓶颈。如果你也在搞类似的移动端风格化场景遇到掉帧时先别急着堆优化技巧先把你自己的Profiler数据贴出来看看CPU和GPU到底谁在拖后腿。这一招真的能帮你省下好几个晚上的瞎折腾。
