前几天还在帮同事调一个AVP自动泊车的掉帧问题现象非常典型车机屏幕上渲染了二十几个车位框车辆周围一圈识别到的可用车位画面一多帧率直接掉到30以下GPU基本被打满。开Frame Debugger一看好家伙25个车位框每框按“外框线角标高亮闪烁扫描动效”分了好几层DrawCall总数一路飙到70以上。座舱3D HMI的性能预算本来就紧张这还只是车位框一个功能导航、车控、全景影像都在抢同一块SoC肯定得动手优化。这篇文章我来复盘一下整个AVP车位框DrawCall优化的完整过程问题是怎么定位的、为什么最后选了GPU Instancing这一路、Shader和动画要怎么配合改以及优化之后又踩到的Overdraw、多相机重绘这些坑。做座舱3D的同行或者在做类似“大量同构小物体渲染”场景的应该都能直接照搬思路。1. 一个车位框怎么就把帧率拖崩了先把这个场景拆开看。AVP自动代客泊车在3D HMI里最核心的视觉元素就是地面上一圈一圈的车位框。用户从找车位到选车位再到车辆自己往车位上泊入整个过程眼睛一直盯着这些框所以它的交互层级很高需要描边、需要角标、需要一个扫描的动效提示车位可用选中的框还要高亮变色。1.1 默认实现长什么样大多数刚接手的团队最容易写出来的实现是这样每个车位框单独挂一个MeshRenderer用一个LineRenderer或者自建的网格画出四条边四个角各放一个小图标表示车位号或者车位状态选中态用一个发光的矩形面片叠在位框内部扫描动效再叠加一层带UV滚动的半透明材质或者干脆挂一个ParticleSystem。这种写法本身没错视觉效果确实能出来。问题在于每个车位框的DrawCall至少要拆成3到4个。25个车位框就是75到100个DrawCall。主相机要画后视镜相机有时候也要画同一批车位框那DrawCall就直接翻倍。我这里画一个简单对照让大家先有个概念车位框数量每框默认层数预计DrawCall备注10330未算UI和车身253-475-100未算灯光阴影和多相机503-4150-200大型停车场接近爆表座舱里的3D场景不像游戏那样可以放开手脚它同一时刻还有导航路径引导线、车辆模型、全景地面贴图、天气特效等等多个模块在跑。如果车位框这一个模块就吃掉七八十个DrawCall等后面功能叠加起来低端车机肯定扛不住。1.2 为什么“小物体多”反而是最恶心的场景有个很有意思的事车模本身几万个三角形但车身是一整个静态模型合批之后可能才几个DrawCall完全没问题。反而是车位框这种“单个物体极简、数量极大”的模块最容易把性能搞崩。原因是GPU的渲染管线对状态切换非常敏感。每切换一次材质、每换一个Mesh、每改一次渲染队列驱动都要重新校验渲染状态。就算每个车位框只有一个十几顶点的网格只要它们是25个独立Renderer、用了不同的材质球引擎就只能老老实实提交25次。微机上可能感觉不明显座舱的主控芯片可没有独立显卡那种余量。移动GPU每个DrawCall的固定开销比PC高不少CPU侧还要处理每帧坐标同步、显隐切换、动画刷新大量的时间和电热都耗在“提交命令”本身而不是真正在画像素。1.3 AVP车位框的特殊性状态实时变这里又跟摆放一堆石头、一堆路灯不一样。工程车位的坐标不是美术摆好就完事的是感知算法每帧算出来的车辆一挪动车位框相对车辆的位置就要跟着变车位从“未识别”变“可用”、从“可用”变“目标选中”颜色状态也要变扫描动效还要持续播放。这就让很多游戏里常用的静态优化手段直接失效。静态合批把网格合并后位置就固定了不方便跟着感知结果实时变化动态合批又有一堆限制条件还会增加CPU负载。真正能扛住这种场景的是实例化绘制也就是把25个车位框当成25个“实例”塞进同一个批次。2. 定位阶段的三个工具拆解先别急着调先看清账单优化之前一定要先确认问题在哪不能凭感觉。我那次排查的时候是按这个顺序看的2.1 Frame Debugger 按名称过滤确认每个框的真实绘制次数Unity的Window Analysis Frame Debugger是第一步。打开后先把每一个DrawCall展开看它用的Mesh和Material是什么然后按车位框GameObject的命名规则在搜索框过滤一遍。我当时把车位框统一命名为AVP_Slot_XX_Frame、AVP_Slot_XX_Corner、AVP_Slot_XX_Fx这类格式一眼就能看出同一帧里每类元素被提交了几次。看到的结果是每个框的外框线1次DrawCall四个角标如果用了4个独立的MeshRenderer就是4次DrawCall选中态的高亮面1次DrawCall扫描动效1次DrawCall。一个车位框毛坯状态下都已经快7个DrawCall了20多个框直接上百。Frame Debugger里还能看到一些意想不到的浪费比如有些车位框明明在视野边缘或者被车体挡住却还照样提交说明视锥剔除某个环节也漏了。2.2 Profiler 和真机性能Counter对照Frame Debugger看得是“画了什么”Profiler里则要看“每帧CPU和GPU的时间花在哪”。Unity Profiler里切换到Rendering模块按耗时降序再配合真机上的GPU Counter看Fillrate、Vertex Throughput这些数据基本能确认瓶颈究竟是DrawCall太多、顶点太多还是填充率爆了。移动端有一点要特别记住DrawCall数不是唯一的真相。有时候DrawCall不高但帧率依然很惨那可能是半透明像素叠加了太多层GPU在拼命算片元。所以定位阶段不能只看Batch数一定要把帧时间、顶点数、三角形数、Overdraw一并记录下来优化完才有对比基准。2.3 把阴影和光照排除掉才能看到纯车位框的账单还有一个很容易被忽略的开销源阴影。如果一个实时光源照向车位框车位框又开着Cast Shadows那所有车位框都要为阴影相机再渲染一遍DrawCall直接翻倍。座舱HMI里车位框绝大多数时候是不需要投射阴影的把ShadowCastingMode设成Off阴影相关的Pass直接不参与。同样的道理如果车位框的Shader里走的是多Pass光照渲染哪怕只有一个平行光前向渲染也可能为每个实例产生多个Pass。排查的时候要专门看SetPass count而不是总DrawCall这俩概念经常被混在一起但优化方向完全不同。定位阶段做完我心里大概有数了车位框本身几何很简单不需要大砍模型真正的开销是多次绘制提交和状态切换。那答案基本就朝着“合批”或者“实例化”走了。3. 核心改造GPU Instancing让所有车位框塞进同一个批次这里先给结论AVP车位框这场景最合适的方案是GPU Instancing。不是动态合批也不是静态合批。3.1 为什么动态合批、静态合批在这里都不靠谱Unity的Dynamic Batching很多人一看“动态”两个字就觉得适合实时变化的车位框。实际上它有几个硬限制参与的网格顶点数有上限一般900顶点左右必须使用同一个材质动态合批是CPU每帧把所有网格的顶点数据重新合并一次存进临时顶点缓冲再提交这个CPU开销本身就不小非均匀缩放、Lightmap这类因素会导致合批直接失效。车位框数量一多、状态一变动态合批的CPU开销会抵消GPU侧的收益属于拆东墙补西墙。Static Batching则是把多个静态网格在初始化时合并成一个更大的网格提交次数确实少了但代价是所有物体在内存里会保留一份原始数据加一份合并数据内存占用翻倍而且车位框的坐标是感知算法实时刷新的静态合出来的网格没法跟着变。硬要配合用只能在“停车场地面标线”这类完全静止的元素上顺手做一下而不是做在动态车位框上。3.2 GPU Instancing的正确打开方式GPU Instancing的理念跟合批完全不同它不要求在CPU侧把网格合并而是告诉GPU“这个Mesh你帮我画25遍每个实例的坐标、颜色、动画相位都由实例数据单独提供”。这样一来DrawCall次数变成1但GPU一帧内仍然能画出所有车位框。要让Unity的自动GPU Instancing生效必须同时满足几个条件所有车位框共享同一个Mesh所有车位框共享同一个MaterialShader必须开启Instancing支持每个车位框的差异化属性颜色、高亮状态等通过MaterialPropertyBlock传入而不是用Material.Instantiate去新建材质。我当时的车位框Mesh只做了两层结构一个外框四条边用细长Quad组成共16个顶点、四个角标每个角标一个小矩形也16个顶点整个Mesh几十个顶点。顶部做一个半透明的“扫描线平面”这个平面不单独渲染而是放在同一个Shader里通过世界坐标和时间的运算画出来这部分下一节展开说。代码结构上每个车位框还是挂一个独立的MeshRenderer方便保留Unity自带的视锥剔除但改成了这样// 每帧更新车位框世界矩阵 slotRenderer.transform.SetPositionAndRotation(slotPosition, slotRotation); // 差异属性用PropertyBlock设置避免生成材质实例 slotBlock new MaterialPropertyBlock(); slotBlock.SetColor(_SlotColor, slotColor); slotBlock.SetFloat(_Highlight, isSelected ? 1f : 0f); slotBlock.SetFloat(_Phase, phase); slotRenderer.SetPropertyBlock(slotBlock);这种方式下只要25个车位框用的是同一个Mesh、同一个MaterialUnity引擎就会自动把一帧内的25个实例合并成一次Instanced DrawCall提交。Frame Debugger里看到的Batch数会急剧下降。对应Shader里必须做的标配是#pragma multi_compile_instancing UNITY_INSTANCING_BUFFER_START(Props) UNITY_DEFINE_INSTANCED_PROP(float4, _SlotColor) UNITY_DEFINE_INSTANCED_PROP(float, _Highlight) UNITY_DEFINE_INSTANCED_PROP(float, _Phase) UNITY_INSTANCING_BUFFER_END(Props)然后在顶点/片元着色器里用UNITY_SETUP_INSTANCE_ID取数据。特别注意不要让Shader跑出多个变体材质数量多了之后变体组合也非常容易造成批次分裂。3.3 Renderer.SetPropertyBlock 和 DrawMeshInstanced 怎么选优化的时候还有另一条路不走MeshRenderer直接用Graphics.DrawMeshInstanced一次性把所有车位框的矩阵数组传给GPU。比如Matrix4x4[] matrices new Matrix4x4[slotCount]; // 每帧根据车位数据填充matrices Graphics.DrawMeshInstanced(slotMesh, 0, slotMaterial, matrices, slotCount, slotBlock);这套方式提交次数更少也方便更大规模地控制。但它的代价是失去了Unity的视锥剔除所有实例不管在不在相机视野里都会被整批交给GPU虽然在顶点着色器阶段可以甩掉但本质上浪费了提交和顶点计算量。我的建议是按数量级来选车位框数量在几十个量级用MeshRenderer SetPropertyBlock保留剔除简单可靠对AVP足够车位框数量到几百个、上千个比如智慧停车场全局漫游、大范围车位扫描图时用DrawMeshInstanced并自己做视锥内的矩阵收集省掉无谓绘制。AVP自动泊车场景绝大多数是前一种不用为了炫技把简单问题复杂化。核心合批做完之后Frame Debugger里车位框相关的一次性DrawCall已经从“每框7个”变成“每批1个”了。但视觉需求还没完扫描动效、高亮闪烁、远近渐变如果每个效果再用一个ParticleSystem或者独立Mesh去做那些DrawCall又会原样涨回来。所以下一步是把“状态和动画”全部从美术层下沉到Shader层。4. 把动画、扫描线和高亮全塞进Shader别让动画系统再开额外批次4.1 扫描动效用世界坐标做UV零新增DrawCallAVP车位框上有一条来回扫的光带视觉上提示“这个车位可用”非常常见。以前的做法是做个单独的Quad面片挂在车位框中间材质里滚动一张Mask贴图。优化以后我把这个面片直接做进了车位框Shader里。思路是车位框Mesh内部自带一块和车位内径匹配的半透明平面片元着色器里用这个平面的世界坐标计算一个横向的UV再用frac(worldPos.x * _ScanSpeed _Time.y)生成一条窄带窄带区域输出一个叠加色其他区域透明度归零。大概逻辑如下half scan frac(worldPos.x * _ScanSpeed _Time.y); half scanMask smoothstep(0.0, 0.02, scan) * (1.0 - smoothstep(0.08, 0.10, scan)); col.rgb _ScanColor.rgb * scanMask * _ScanIntensity;这样扫描效果就是纯算法算出来的没有任何额外网格、额外贴图、额外DrawCall。用户看到的效果和原来用ParticleSystem做出来的非常接近但GPU开销几乎可以忽略。4.2 高亮和闪烁一律走实例属性不要每帧SetColor选中车位的场景需要一个呼吸高亮车位框颜色由白色变成青色边框亮度还有节奏地脉动。我见过很多团队在Update里直接改Renderer的material的颜色这种做法问题很大。第一改renderer.material会立即创建一个材质实例哪怕是同一个Shader同一个Mesh只要材质实例ID不一样实例化批次就会分裂。第二每帧改颜色要往GPU上传动态数据更新频率高了以后CPU和GPU的同步开销也不小。正确姿势是把“高亮”当成一个0到1的系数传入实例属性颜色变化和脉动节奏全部放在Shader里实时计算。比如float pulse 0.5 0.5 * sin(_Time.y * _PulseSpeed _Phase); float3 finalColor _SlotColor.rgb * (1.0 - _Highlight) _SelectedColor.rgb * _Highlight; finalColor * 1.0 0.1 * pulse * _Highlight; col float4(finalColor, baseAlpha);这样CPU侧在一帧里只需要在上层决策“这个车位被选中了”的时候把_Highlight从0改成1选中后的脉动效果完全由Shader自己跑不需要任何Unity生命周期参与。车位框位置在变、颜色在变、动画在动但GPU侧提交的实例数据始终只有那几组精简属性。4.3 远处淡化一个LOD系数别切换Mesh车位框分布在停车场里视角转远的时候近处的框和远处的框在屏幕上占据的像素差距极大。以前的做法是距离一远就切换低模版本或者直接隐藏这就会带来LOD切换的突兀感和额外的代码分支。Shader层能做的事情更优雅传入一个归一化的LOD系数在片元阶段根据它裁掉角标细节、降低边框亮度最后自然淡出。由于GPU Instancing本身允许每个实例带不同属性车位框的远近差异不会导致批次分裂几百个框仍然是一条批次到底。动画和状态下沉到Shader以后车位框相关的DrawCall已经非常干净了。但一上真机看帧率还是有意外情况——DrawCall确实降下来了帧耗时却没有预想的那么好。这就到了第二个深水区DrawCall之外的隐藏开销。5. 优化之后又踩到的两个坑Overdraw和多相机重绘5.1 半透明层叠的OverdrawGPU在疯狂算像素车位框在外框线内部叠加了一层半透明底色扫描光带也是半透明的选中高亮又有一层。几层叠在一起对于屏幕正中央那几个车位框单像素可能被片元着色器算了3到4遍。车机分辨率越做越高2K、3K的屏幕填充率压力直接翻倍。CPU侧的DrawCall降了GPU侧的Fillrate反而成了新瓶颈。对策是降低半透明层的像素面积而不是降低透明度把整块的半透明底色改成只有四边宽度扩大一点的颜色渐变选中时再稍微提高中央的透明层但不要做到整面全是50%透。另外扫描光带本身很窄控制它的Alpha阈值不要让半透明区域糊成一整片。移动端GPU的Overdraw是个很容易被忽视的陷阱。Frame Debugger里看的是“命令数量”但发热和耗电往往看的是“片元计算量”。优化完DrawCall以后一定要用真机GPU厂商的分析工具看一遍Overdraw热力图把那些屏幕上看不见却在反复计算的像素揪出来。5.2 多相机会让同一个车位框白画一遍座舱3D HMI不止主屏一个相机。常见的还有仪表盘区域的相机、左右后视镜的拼接相机、甚至副驾屏的独立视角。每个相机只要能看到车位框所在Layer车位框就会被完整地再画一遍。我第一次排查的时候只顾着看主相机Frame Debugger里的Batch数忽略了后视镜相机结果后台统计的帧时间依然高居不下。后来把后视镜相机单独抓帧发现它把整个3D停车场场景又提交了一遍车位框的实例批次重新算了一遍。解决方式很直接车位框单独放一个Layer默认只让主相机渲染这个Layer后视镜相机如果业务上必须要看到车位框相对缩小它的Viewport范围或者对后视镜相机降低车位框LOD系数如果后视镜只是反映车辆侧后方画面不需要车位框直接Culling Mask里把该Layer勾掉。5.3 和UI Canvas的协作文字标签别做成每框一个TextAVP场景里车位框上往往有车位号、距离提示、“可用”按钮这些2D信息。如果这些UI用UGUI实现每个车位框挂一个Canvas下的Text那又会出现一大堆Canvas Batches因为它们不在同一个Atlas里、字体图集也会各自独立。我在项目里把车位ID和状态文字统一收敛到一个UICanvas用如图集方式批量绘制。UI层和3D车位框分离车位框负责3D空间感文字负责信息可读性。显示逻辑上也只有当前高亮的车位框才展开文字详情其他车位框默认只显示极简图标避免所有框的文字同时堆在屏幕上。这里有一个跟DrawCall直接相关的经验UGUI的合批条件是同一Canvas下、同一个材质图集、相邻的层级。同一个车位框的Text和背景图如果靠得近且用同一图集会合并成一个Batch但不同车位框的Text隔着一段距离如果它们不是同一个Canvas渲染队列里的相邻元素就可能被拆分。所以文字部分宁可做成常驻少量几个UI组件动态改内容也不要做成“每框一整套完整TextIcon背景”的密集结构。做完全部优化跑真机数据的时候结果已经和最初完全不同了。我在最后把这组对比数据贴出来顺带把容易复发的问题列成一个清单方便后面维护的人对照。6. 实测数据、回退陷阱和维护清单6.1 优化前后对比同一个AVP场景、同一台车机、同一段包含25个车位框的测试录像指标优化前优化后车位框相关DrawCall782总SetPass calls14346车位框三角形3200800车位框顶点数6400800P50帧耗时35.2ms18.1msP95帧耗时51.0ms22.4ms这里要说明一下优化后依然保留下面的2个DrawCall一个是主相机车位框实例批次一个是同场景下地面照射产生的环境交互层。如果哪天把后视镜相机也开启车位框还会多出对应相机的一份实例批次。6.2 容易复发的坑清单这些问题在我后续几个项目里都碰到过几乎一摸一样专门列一下美术同学新增了一种车位框样式直接从Shader里复制出来改了个新材质哪怕是同Mesh同样的顶点只要Material不同批次立刻翻倍。后续加样式要改惨Shader属性不要新建Material文件。有人为了让某个车位框更亮重置了它的材质颜色生成材质实例又打断了一次实例化合批。排查时经常看到一个Material(Instance)挂在车位框上。车位框位置更新时直接transform.localScale new Vector3做非均匀缩放虽然GPU Instancing理论上不受非均匀缩放影响但有些版本的合批逻辑里会触发Rebatch。最好统一放在实例属性里用float3 slotSize传递。阴影没关干净。只要有一个车位框打开了Cast Shadows阴影Pass又会把整个批次的实例重画一遍Frame Debugger里表现为一模一样的批次重复提交。车位框统一设成ShadowCastingMode.Off。扫描动效的Shader精度不够在部分高通GPU上出现块状扫描带美术又叠了一层ParticleSystem补救DrawCall涨上去。遇到扫描线精度问题优先把时间精度从half提到float。6.3 维护这类3D HMI模块的长期建议再往后做团队里一定要立两条规矩第一车位框这类“同构大量出现”的元素从设计阶段就要把模型、Shader、实例属性当成一整包来管理。新来的同学拿到手不能让他在Unity编辑器里随意给一个车位框挂特效组件而是通过一个统一的SlotRendererController去配置。第二性能测试不是开发完才测。AVP车库、城区停车场这些场景至少准备三档档位最低端车机的极限模式、主销车型的标准模式、高端车型的完整效果模式。车位框的数量、是否开启扫描动效、半透明层是否启用都应该有对应的运行时档位开关而不是靠美术删文件来适配。最后再说一个我实操时的小习惯每次改完这类渲染优化别急着看帧率先在Frame Debugger里把车位框相关的合批数量和Shader变体数量截图存档。出问题时回退也方便对照历史截图半小时内基本能定位是哪个环节重新引入了批次。AVP车位框的优化本质上就是不断把“每个车位框小单元”的开销变成“整批车位框”的开销把动态变化的东西都收编到Shader数据里。这个思路通了往后做路口引导线、做道路标识、做泊车路径光带都是一样的套路。