做Unity项目优化绕不开四件事减面、合批、资源管理还有那个一出现就让所有人血压上升的紫材质。我见过太多团队把高模直接拖进场景帧数掉到十几然后对着AssetBundle和Shader一顿猛猜最后发现真正的问题根本不是某一个点而是整条资源链路都没理顺。这篇文章就是把这条链路从头到尾捋一遍模型面数怎么控、Draw Call怎么压、资源怎么分、紫材质到底怎么根除。适合正在做移动端项目、或者Unity项目开始频繁掉帧、内存告警、材质发紫的同学直接照着排查就行。1. 卡顿的根源先分清是面数还是Draw Call在拖后腿1.1 从Profiler里看到底谁在咬帧数很多人一卡就开骂模型面数太高然后开始无脑减面减完发现帧数纹丝不动。这种情况我遇到太多次了。真正的优化第一步不是动手改资源而是先确定瓶颈在CPU还是GPU在渲染还是逻辑在面数还是Draw Call。Unity自带的Profiler能直接看到主线程和渲染线程的耗时Frame Debugger能逐帧看每一条Draw Call的提交过程。打开Profiler跑到目标场景如果看到Rendering项里Triangles数量正常但Batches数量动辄两三百往上那问题大概率是Draw Call。反过来如果单个帧的顶点处理时间明显偏高或者GPU端出现明显的光栅化压力再看是不是模型太密。我自己习惯的记录方式是先跑一轮把“场景物体数量、三角面总数、Draw Call批次、SetPass Call、纹理内存”这五项全部记录。接下来每做一个优化动作再跑同一场景同一路径看这五项数字怎么变。没有这个基线后面的优化就是瞎猜。1.2 面数和Draw Call其实是两笔账面数和Draw Call的成本逻辑完全不一样理解这笔账才能对症下药。面数的成本在量顶点数越多CPU要做的顶点处理、裁剪、变换计算就越多GPU要做的光栅化、片元着色工作也越多。这个成本是“每帧都要付的流水账”场景里只要有一个百万级面数的模型整个帧率都会被拖下水。Draw Call的成本在次数每提交一次绘制命令CPU都要构造渲染状态、做性能验证、还要通过驱动层传到GPU。移动端这块尤其敏感本来CPU性能就赶不上桌面平台几百个Draw Call直接把主线程锁死。我常用的生活化类比是面数高就像搬家时东西特别重每一车都装得很满跑一趟就要花大力气Draw Call多则像快递员频繁空车往返一次次跑每次都不带什么东西但油钱、时间都耗在路上了。所以优化的思路也很明确体重太重就减面跑得太多次就合批。2. 模型减面从源头建模到引擎导入的全链路优化2.1 建模阶段就在做的“面数预算”减面最好的时机是在建模阶段而不是等资源进Unity之后才补救。项目初始化的时候我习惯跟美术团队做一张面数预算表把场景里的物体按重要程度分等级主角和交互物件给最高配额中景物件次之远景和背景物体给最低配额。这样做的好处是美术在建模时就有了约束不会兴致勃勃地把一把椅子做到两万面结果进游戏被镜头一晃带过。面数预算表的分配逻辑很简单离玩家越近、被看到的时间越长、交互越频繁的物体分配越多面数反之尽量压。具体减面的时候有几个操作是性价比最高的删掉看不见的面比如紧贴墙体的背面、地面以下的半截清理重叠顶点和零面积三角形去掉那些平缓曲面上不必要的密集分段。很多新手喜欢用自动减面插件一键处理但我建议自动减面之后一定要人工检查边缘轮廓因为自动算法最容易在轮廓、曲率转折处出现三角面拉长和破洞这类问题在导入Unity后很难修。2.2 Unity导入面板里的关键参数模型进入Unity之后导入面板本身就有一批影响性能和内存的参数很多人忽略了。Mesh Compression建议根据物体用途设置中等偏高的压缩能明显降低网格数据的内存占用。缺点是顶点位置和法线会有轻微精度损失。对近景交互物品建议用Off或Low对场景边缘的大面积低模Medium或High是安全的。Read/Write Enabled默认是勾上的但它意味着Unity会保留一份网格的CPU可读副本内存开销翻倍。没有运行时改网格需求的模型一律关掉。还需要留意Normals和Tangents的设置如果是纯色或不依赖法线贴图的物体Tangents可以关闭。这些导入参数的调整不会改原始建模文件只是影响Unity内部存储和运行时的表现所以改起来没有风险可以放心理顺。2.3 LOD分级才是真正的动态减面如果说导入参数是静态减面那么LOD就是运行时的动态减面。LOD的核心思路是同一个物体准备好几套不同精度的网格相机离得远的时候用最粗糙的那套离得近才上高精度模型。玩家在高强度战斗场景里根本注意不到远处的树干少了几个分段但帧数会明显好起来。Unity里用LOD Group组件来管理这套切换。我给移动端项目的常用配置是LOD0是完整精度模型Screen Relative Height占屏比例约50%以上才显示LOD1是减面到70%左右的中模占屏比例25%左右LOD2是减面到40%的低模占屏比例12%LOD3一般直接用极简模型或干脆Cull。做LOD可以手工减也可以用专门的减面工具批量生成。生成完之后一定要逐级检查切换时是否出现模型“闪烁”或“跳变”烘焙贴图是否还匹配蒙皮动画模型做LOD时骨骼数量和权重是否正确。LOD切换距离不是越小越好太激进的切换会让玩家明显看到模型变粗糙太保守又起不到作用。3. 合批实战把Draw Call真正压下去3.1 Draw Call贵在状态切换很多人知道Draw Call越少越好但不知道为什么。CPU每次提交一个Draw Call中间要经历校验渲染状态、更新常量缓冲区、切换材质和纹理、下发绘制指令。这个过程非常依赖驱动和硬件而且每一帧每个物体都要重新来一遍。同一个场景如果有500个不同材质的物体CPU一帧要做500次全套流程再强的手机也扛不住。合批的本质就是让多个物体共用同一次绘制提交从而省掉大部分状态切换开销。但Unity里的合批方式有好几种它们适用场景完全不同用错了反而更糟。3.2 静态合批场景里“躺平不动的物体”静态合批适合场景里完全静止的物体比如建筑、路障、装饰物。Unity会将这些标记为Static的网格在运行时合并成一个大网格然后一次Draw Call画出来。这是减少Draw Call最立竿见影的方式遮罩场景里几百个静态物体合到几个网格之后批次能降一个数量级。代价也有首先需要额外占用内存因为合并后会生成一份合并网格的副本其次如果一个网格内部引用了多种材质合批时会被拆开所以静态合批对材质统一的要求很高。另外静态合批的网格不能再被独立移动如果某个物体在玩法里被敌人击飞静态合批会让它变成“尸体”无法被正确搬动。我的经验是先确认物体整个生命周期都不会动再勾Static。3.3 动态合批适合小物体但限制很多动态合批是Unity自动处理的一种方式理论上每一帧CPU会把多个小网格组合一次再提交。但它对顶点数有限制单个网格顶多900个顶点实际上受多个属性影响数值会更低材质必须相同某些Shader特性也会阻止合批。Scale存在负值、Lightmap参数不一致的物体不会参与。很多人以为开了动态合批选项就万事大吉实际案例里动态合批经常部分生效一批物体里只有几个满足条件被合了其余的依然单独提交。用Frame Debugger可以看到哪些Draw Call被“Batched”了哪些没有。所以我始终建议小物体可以开启动态合批但不要对动态合批产生依赖关键场景里还是要通过减少材质种类、合并网格来从结构上降低批次。3.4 GPU Instancing与SRP Batcher不同世代的合批方案大量重复的相同物体比如草地、路灯、碎石堆用GPU Instancing才是最优解。GPU Instancing允许一次Draw Call绘制多个实例每个实例通过实例化属性数组区分位置、颜色等差异CPU提交一次GPU循环画几百份。操作上很简单材质面板勾选Enable GPU Instancing然后在代码里通过MaterialPropertyBlock为不同实例设置差异化的颜色、缩放、偏移。需要注意这类物体必须是同一个Mesh和同一套材质而且Instancing对Shader有要求URP/HDRP管线下还要求Shader支持Instancing变体。如果项目用的Unity 2019以后版本并且开启了SRP那么SRP Batcher会在URP/HDRP下自动减少材质状态切换。它和静态合批、动态合批的思路不同不是合并网格而是复用材质属性绑定。简单理解就是CPU不再反复为同一个Shader重新设置一堆材质参数而是缓存起来直接用。用SRP管线的项目把支持SRP Batcher的Shader换成标准写法再配合材质尽量统一批次数字会好看很多。三种合批方式的选择可以参考这个基础逻辑静态不动的建筑群、地形周边静态合批大量运动的重复小物体GPU Instancing少量不满足Instancing条件的分散物体动态合批兜底4. 资源管理模型优化不只是“减面”和“合批”4.1 纹理压缩和纹理集把内存大户管住模型减得再干净一张4K纹理就能把内存吃回去。游戏项目里纹理永远是内存大户很多卡顿根本不是模型引起的而是纹理量太大导致加载后的内存压力、纹理流送瓶颈。移动端纹理建议无脑走ASTC或ETC2压缩。Texture Import Settings里Compression选项不能一直用Default要根据平台选对。比如安卓平台很多设备支持ASTC就优先ASTC 6x6或8x8iOS则看设备能力。RGBA32这种未压缩格式尽量只在UI或特别重要的贴图上用。还要注意Generate Mipmap3D场景物体建议开因为远距离不采样全分辨率纹理能明显省性能但UI图集一般不开不然会浪费内存。纹理集的意义不光在省Draw Call还省切换开销。同一批次渲染的物体如果分别引用了10张不同纹理GPU会频繁切换纹理采样器把相关贴图合并成Atlas后一次切换就覆盖整个批次。做Atlas时记得预留边距和Padding避免线性过滤时出现边缘混色。4.2 AssetBundle分包怎么做才不会依赖地狱AssetBundle的设计目标很简单让资源能在需要时才下载和加载。但分包策略一旦设计错就会出现各种循环依赖、重复下载、Shader丢失甚至代码都跑起来了画面全是紫的。我建议按“功能模块公共依赖”来分所有模型、材质、纹理、Shader必须拆成有明确归属的包公共资源人物、UI、共享Shader单独打一个稳定版本的基础包场景内资源按场景分组。打包之前用依赖分析工具把所有资源的依赖树拉一遍确认一个模型包引用的贴图、材质、Shader都在它所依赖的包里或者被公共包覆盖。这个检查非常重要很多紫材质问题就是在AssetBundle阶段埋下的模型在资源包里但模型用的Shader没被打进任何包或者被打进了更新频率更高的包运行时Shader还没加载完材质就直接回退成紫色。4.3 加载卸载的节奏不能只加载不释放资源管理不只是“如何加载”更要考虑“何时卸载”。Unity的Resources.Load和AssetBundle加载都是带引用计数的加载了不卸载场景切换几次后内存就涨上去了。项目后期常见的“越玩越卡”十有八九是资源泄漏旧场景的模型和纹理还占着内存新场景又继续加载新的。我的做法是给每个业务场景定义一套明确的加载清单和卸载时机进入Loading界面时异步预加载下一场景必需资源场景切换完成且新的根节点激活后再卸载上一个场景的资源包。如果使用的是原生AssetBundle要在加载时记录Bundle对象的引用卸载时严格对应如果项目有权限升级到Addressables可以省掉很多手写的引用计数逻辑但包体规划逻辑还是躲不开。5. 紫材质排查不要一紫就慌按步骤来5.1 紫材质是怎么来的在Unity里材质显示成紫色是引擎在“材质完全不可用时”显示的一种占位颜色。触发原因归纳起来就是运行时找不到Shader或者当前渲染环境不兼容这个Shader。具体分常见三种一种是在Project窗口里材质引用的Shader被删除了或资源路径变化导致Unity找不到另一种是项目从内置管线切换到URP/HDRP旧材质里的Standard Shader没有自动升级整个场景大面积发紫还有一种是AssetBundle运行时加载的Shader没有随包加载材质在运行中被识别成“无Shader状态”。标题里说“紫材质”是优化过程中的一个坑其实它还是最好的报警器一旦某个材质变紫说明资源和代码之间一定有一环断了。5.2 四步排查法遇到紫材质我建议按以下顺序排查不要上来就重做材质。打开Console窗口找材质相关报错。如果提示某个Shader “not found”或者“might be missing”那就锁定了缺谁。在Project窗口选中发紫的材质看Inspector里的Shader下拉框如果显示的是Missing说明引用已失效。这时候再检查Project里的Shader是否还存在。在场景里找到那个紫色物体确认它所属的AssetBundle都加载完成且着色器Shader所在的Bundle先于材质Bundle加载。如果一切看起来都对仍然紫多半是Shader变体在打包时被裁剪了。打开Build Report或者用AssetBundle Inspector确认Shader变体和引用是否完整。5.3 打包阶段根除Always Included Shaders与变体收集排查到最后你会发现紫材质的真正源头往往在打包配置里。Unity打包时只会把场景、代码引用的材质和Shader变体收集进包如果某个Shader只被AssetBundle间接引用或者只通过Shader.Find动态加载打包器很可能认为它没有被实际使用而没有包含。提前做三件事第一Project Settings里的Graphics页签有Always Included Shaders列表把项目里一定会用的Shader加进去避免被裁剪第二Shader变体是很细的问题Shader里的多重开关会产生几千种变体只保留项目实际用到的第三如果代码动态加载材质和Shader要在构建时把相关资源设置进Bundle并确保加载顺序正确。还有一个很多人忽略的点编辑器里表现正常打包后发紫往往是URP/HDRP管线的Shader在构建时没有生成对应平台的变体。记住Shader的编译目标是分平台的Android和iOS的变体编译要同时验证不是编辑器里看到没问题就等于打出来的包没问题。模拟项目X就遇到过类似问题开发机上全部正常真机一跑UI全是紫块最后定位到是Build Target切到Android后Shader缺了Mobile变体。5.4 紫材质排查场景速查表整个场景大面积紫色大概率是管线切换或Standard Shader不兼容用管线的Upgrade功能批量升级材质只有某个模型紫该模型的材质引用丢失或者Shder所在Bundle未加载打包后紫、编辑器不紫Shader被裁剪去Graphics的Always Included Shaders里加安卓紫、iOS不紫平台Shader变体缺失切到对应Build Target重新构建并检查变体集合更新AssetBundle后紫新包没包含Shader依赖重新验证依赖树6. 我自己的优化顺序和几条心得最后分享几个实战经验不一定每条都适用于所有项目但绝大多数情况下按这个顺序做都不会跑偏。先把优化顺序固化下来先做Profiler基线再优化Draw Call然后压面数和纹理内存最后处理AssetBundle和Shader。不要反过来很多团队一上来就疯狂减面结果Draw Call一点没少帧数该掉的还是掉。顺序本身就是经验先解决最抢CPU的绘制开销再考虑模型密度和内存量最后管加载释放节奏。紫材质排查中还有一个小技巧把Always Included Shaders列表和AssetBundle依赖树放在每次构建的检查清单里。每次发版前跑一次全场景扫描把场景和动态加载的Shader清单拉出来和构建报告比对能省去大量线上冒紫的返工时间。别问我怎么知道的被真机上的紫屏教训过几次就记住了。模型优化这个领域没有一劳永逸的方案。每个项目的手感、预算和设备目标都不一样Profile一帧帧看资源一项项理性能就是这么抠出来的。希望这套链路能让你少走点弯路真机跑顺了再回来评论区聊聊。 
长河君 · 2026/10/23 7:07:06 · 阅读 1.2k Unity项目优化全链路实战：减面、合批、资源管理与紫材质排查
做Unity项目优化绕不开四件事减面、合批、资源管理还有那个一出现就让所有人血压上升的紫材质。我见过太多团队把高模直接拖进场景帧数掉到十几然后对着AssetBundle和Shader一顿猛猜最后发现真正的问题根本不是某一个点而是整条资源链路都没理顺。这篇文章就是把这条链路从头到尾捋一遍模型面数怎么控、Draw Call怎么压、资源怎么分、紫材质到底怎么根除。适合正在做移动端项目、或者Unity项目开始频繁掉帧、内存告警、材质发紫的同学直接照着排查就行。1. 卡顿的根源先分清是面数还是Draw Call在拖后腿1.1 从Profiler里看到底谁在咬帧数很多人一卡就开骂模型面数太高然后开始无脑减面减完发现帧数纹丝不动。这种情况我遇到太多次了。真正的优化第一步不是动手改资源而是先确定瓶颈在CPU还是GPU在渲染还是逻辑在面数还是Draw Call。Unity自带的Profiler能直接看到主线程和渲染线程的耗时Frame Debugger能逐帧看每一条Draw Call的提交过程。打开Profiler跑到目标场景如果看到Rendering项里Triangles数量正常但Batches数量动辄两三百往上那问题大概率是Draw Call。反过来如果单个帧的顶点处理时间明显偏高或者GPU端出现明显的光栅化压力再看是不是模型太密。我自己习惯的记录方式是先跑一轮把“场景物体数量、三角面总数、Draw Call批次、SetPass Call、纹理内存”这五项全部记录。接下来每做一个优化动作再跑同一场景同一路径看这五项数字怎么变。没有这个基线后面的优化就是瞎猜。1.2 面数和Draw Call其实是两笔账面数和Draw Call的成本逻辑完全不一样理解这笔账才能对症下药。面数的成本在量顶点数越多CPU要做的顶点处理、裁剪、变换计算就越多GPU要做的光栅化、片元着色工作也越多。这个成本是“每帧都要付的流水账”场景里只要有一个百万级面数的模型整个帧率都会被拖下水。Draw Call的成本在次数每提交一次绘制命令CPU都要构造渲染状态、做性能验证、还要通过驱动层传到GPU。移动端这块尤其敏感本来CPU性能就赶不上桌面平台几百个Draw Call直接把主线程锁死。我常用的生活化类比是面数高就像搬家时东西特别重每一车都装得很满跑一趟就要花大力气Draw Call多则像快递员频繁空车往返一次次跑每次都不带什么东西但油钱、时间都耗在路上了。所以优化的思路也很明确体重太重就减面跑得太多次就合批。2. 模型减面从源头建模到引擎导入的全链路优化2.1 建模阶段就在做的“面数预算”减面最好的时机是在建模阶段而不是等资源进Unity之后才补救。项目初始化的时候我习惯跟美术团队做一张面数预算表把场景里的物体按重要程度分等级主角和交互物件给最高配额中景物件次之远景和背景物体给最低配额。这样做的好处是美术在建模时就有了约束不会兴致勃勃地把一把椅子做到两万面结果进游戏被镜头一晃带过。面数预算表的分配逻辑很简单离玩家越近、被看到的时间越长、交互越频繁的物体分配越多面数反之尽量压。具体减面的时候有几个操作是性价比最高的删掉看不见的面比如紧贴墙体的背面、地面以下的半截清理重叠顶点和零面积三角形去掉那些平缓曲面上不必要的密集分段。很多新手喜欢用自动减面插件一键处理但我建议自动减面之后一定要人工检查边缘轮廓因为自动算法最容易在轮廓、曲率转折处出现三角面拉长和破洞这类问题在导入Unity后很难修。2.2 Unity导入面板里的关键参数模型进入Unity之后导入面板本身就有一批影响性能和内存的参数很多人忽略了。Mesh Compression建议根据物体用途设置中等偏高的压缩能明显降低网格数据的内存占用。缺点是顶点位置和法线会有轻微精度损失。对近景交互物品建议用Off或Low对场景边缘的大面积低模Medium或High是安全的。Read/Write Enabled默认是勾上的但它意味着Unity会保留一份网格的CPU可读副本内存开销翻倍。没有运行时改网格需求的模型一律关掉。还需要留意Normals和Tangents的设置如果是纯色或不依赖法线贴图的物体Tangents可以关闭。这些导入参数的调整不会改原始建模文件只是影响Unity内部存储和运行时的表现所以改起来没有风险可以放心理顺。2.3 LOD分级才是真正的动态减面如果说导入参数是静态减面那么LOD就是运行时的动态减面。LOD的核心思路是同一个物体准备好几套不同精度的网格相机离得远的时候用最粗糙的那套离得近才上高精度模型。玩家在高强度战斗场景里根本注意不到远处的树干少了几个分段但帧数会明显好起来。Unity里用LOD Group组件来管理这套切换。我给移动端项目的常用配置是LOD0是完整精度模型Screen Relative Height占屏比例约50%以上才显示LOD1是减面到70%左右的中模占屏比例25%左右LOD2是减面到40%的低模占屏比例12%LOD3一般直接用极简模型或干脆Cull。做LOD可以手工减也可以用专门的减面工具批量生成。生成完之后一定要逐级检查切换时是否出现模型“闪烁”或“跳变”烘焙贴图是否还匹配蒙皮动画模型做LOD时骨骼数量和权重是否正确。LOD切换距离不是越小越好太激进的切换会让玩家明显看到模型变粗糙太保守又起不到作用。3. 合批实战把Draw Call真正压下去3.1 Draw Call贵在状态切换很多人知道Draw Call越少越好但不知道为什么。CPU每次提交一个Draw Call中间要经历校验渲染状态、更新常量缓冲区、切换材质和纹理、下发绘制指令。这个过程非常依赖驱动和硬件而且每一帧每个物体都要重新来一遍。同一个场景如果有500个不同材质的物体CPU一帧要做500次全套流程再强的手机也扛不住。合批的本质就是让多个物体共用同一次绘制提交从而省掉大部分状态切换开销。但Unity里的合批方式有好几种它们适用场景完全不同用错了反而更糟。3.2 静态合批场景里“躺平不动的物体”静态合批适合场景里完全静止的物体比如建筑、路障、装饰物。Unity会将这些标记为Static的网格在运行时合并成一个大网格然后一次Draw Call画出来。这是减少Draw Call最立竿见影的方式遮罩场景里几百个静态物体合到几个网格之后批次能降一个数量级。代价也有首先需要额外占用内存因为合并后会生成一份合并网格的副本其次如果一个网格内部引用了多种材质合批时会被拆开所以静态合批对材质统一的要求很高。另外静态合批的网格不能再被独立移动如果某个物体在玩法里被敌人击飞静态合批会让它变成“尸体”无法被正确搬动。我的经验是先确认物体整个生命周期都不会动再勾Static。3.3 动态合批适合小物体但限制很多动态合批是Unity自动处理的一种方式理论上每一帧CPU会把多个小网格组合一次再提交。但它对顶点数有限制单个网格顶多900个顶点实际上受多个属性影响数值会更低材质必须相同某些Shader特性也会阻止合批。Scale存在负值、Lightmap参数不一致的物体不会参与。很多人以为开了动态合批选项就万事大吉实际案例里动态合批经常部分生效一批物体里只有几个满足条件被合了其余的依然单独提交。用Frame Debugger可以看到哪些Draw Call被“Batched”了哪些没有。所以我始终建议小物体可以开启动态合批但不要对动态合批产生依赖关键场景里还是要通过减少材质种类、合并网格来从结构上降低批次。3.4 GPU Instancing与SRP Batcher不同世代的合批方案大量重复的相同物体比如草地、路灯、碎石堆用GPU Instancing才是最优解。GPU Instancing允许一次Draw Call绘制多个实例每个实例通过实例化属性数组区分位置、颜色等差异CPU提交一次GPU循环画几百份。操作上很简单材质面板勾选Enable GPU Instancing然后在代码里通过MaterialPropertyBlock为不同实例设置差异化的颜色、缩放、偏移。需要注意这类物体必须是同一个Mesh和同一套材质而且Instancing对Shader有要求URP/HDRP管线下还要求Shader支持Instancing变体。如果项目用的Unity 2019以后版本并且开启了SRP那么SRP Batcher会在URP/HDRP下自动减少材质状态切换。它和静态合批、动态合批的思路不同不是合并网格而是复用材质属性绑定。简单理解就是CPU不再反复为同一个Shader重新设置一堆材质参数而是缓存起来直接用。用SRP管线的项目把支持SRP Batcher的Shader换成标准写法再配合材质尽量统一批次数字会好看很多。三种合批方式的选择可以参考这个基础逻辑静态不动的建筑群、地形周边静态合批大量运动的重复小物体GPU Instancing少量不满足Instancing条件的分散物体动态合批兜底4. 资源管理模型优化不只是“减面”和“合批”4.1 纹理压缩和纹理集把内存大户管住模型减得再干净一张4K纹理就能把内存吃回去。游戏项目里纹理永远是内存大户很多卡顿根本不是模型引起的而是纹理量太大导致加载后的内存压力、纹理流送瓶颈。移动端纹理建议无脑走ASTC或ETC2压缩。Texture Import Settings里Compression选项不能一直用Default要根据平台选对。比如安卓平台很多设备支持ASTC就优先ASTC 6x6或8x8iOS则看设备能力。RGBA32这种未压缩格式尽量只在UI或特别重要的贴图上用。还要注意Generate Mipmap3D场景物体建议开因为远距离不采样全分辨率纹理能明显省性能但UI图集一般不开不然会浪费内存。纹理集的意义不光在省Draw Call还省切换开销。同一批次渲染的物体如果分别引用了10张不同纹理GPU会频繁切换纹理采样器把相关贴图合并成Atlas后一次切换就覆盖整个批次。做Atlas时记得预留边距和Padding避免线性过滤时出现边缘混色。4.2 AssetBundle分包怎么做才不会依赖地狱AssetBundle的设计目标很简单让资源能在需要时才下载和加载。但分包策略一旦设计错就会出现各种循环依赖、重复下载、Shader丢失甚至代码都跑起来了画面全是紫的。我建议按“功能模块公共依赖”来分所有模型、材质、纹理、Shader必须拆成有明确归属的包公共资源人物、UI、共享Shader单独打一个稳定版本的基础包场景内资源按场景分组。打包之前用依赖分析工具把所有资源的依赖树拉一遍确认一个模型包引用的贴图、材质、Shader都在它所依赖的包里或者被公共包覆盖。这个检查非常重要很多紫材质问题就是在AssetBundle阶段埋下的模型在资源包里但模型用的Shader没被打进任何包或者被打进了更新频率更高的包运行时Shader还没加载完材质就直接回退成紫色。4.3 加载卸载的节奏不能只加载不释放资源管理不只是“如何加载”更要考虑“何时卸载”。Unity的Resources.Load和AssetBundle加载都是带引用计数的加载了不卸载场景切换几次后内存就涨上去了。项目后期常见的“越玩越卡”十有八九是资源泄漏旧场景的模型和纹理还占着内存新场景又继续加载新的。我的做法是给每个业务场景定义一套明确的加载清单和卸载时机进入Loading界面时异步预加载下一场景必需资源场景切换完成且新的根节点激活后再卸载上一个场景的资源包。如果使用的是原生AssetBundle要在加载时记录Bundle对象的引用卸载时严格对应如果项目有权限升级到Addressables可以省掉很多手写的引用计数逻辑但包体规划逻辑还是躲不开。5. 紫材质排查不要一紫就慌按步骤来5.1 紫材质是怎么来的在Unity里材质显示成紫色是引擎在“材质完全不可用时”显示的一种占位颜色。触发原因归纳起来就是运行时找不到Shader或者当前渲染环境不兼容这个Shader。具体分常见三种一种是在Project窗口里材质引用的Shader被删除了或资源路径变化导致Unity找不到另一种是项目从内置管线切换到URP/HDRP旧材质里的Standard Shader没有自动升级整个场景大面积发紫还有一种是AssetBundle运行时加载的Shader没有随包加载材质在运行中被识别成“无Shader状态”。标题里说“紫材质”是优化过程中的一个坑其实它还是最好的报警器一旦某个材质变紫说明资源和代码之间一定有一环断了。5.2 四步排查法遇到紫材质我建议按以下顺序排查不要上来就重做材质。打开Console窗口找材质相关报错。如果提示某个Shader “not found”或者“might be missing”那就锁定了缺谁。在Project窗口选中发紫的材质看Inspector里的Shader下拉框如果显示的是Missing说明引用已失效。这时候再检查Project里的Shader是否还存在。在场景里找到那个紫色物体确认它所属的AssetBundle都加载完成且着色器Shader所在的Bundle先于材质Bundle加载。如果一切看起来都对仍然紫多半是Shader变体在打包时被裁剪了。打开Build Report或者用AssetBundle Inspector确认Shader变体和引用是否完整。5.3 打包阶段根除Always Included Shaders与变体收集排查到最后你会发现紫材质的真正源头往往在打包配置里。Unity打包时只会把场景、代码引用的材质和Shader变体收集进包如果某个Shader只被AssetBundle间接引用或者只通过Shader.Find动态加载打包器很可能认为它没有被实际使用而没有包含。提前做三件事第一Project Settings里的Graphics页签有Always Included Shaders列表把项目里一定会用的Shader加进去避免被裁剪第二Shader变体是很细的问题Shader里的多重开关会产生几千种变体只保留项目实际用到的第三如果代码动态加载材质和Shader要在构建时把相关资源设置进Bundle并确保加载顺序正确。还有一个很多人忽略的点编辑器里表现正常打包后发紫往往是URP/HDRP管线的Shader在构建时没有生成对应平台的变体。记住Shader的编译目标是分平台的Android和iOS的变体编译要同时验证不是编辑器里看到没问题就等于打出来的包没问题。模拟项目X就遇到过类似问题开发机上全部正常真机一跑UI全是紫块最后定位到是Build Target切到Android后Shader缺了Mobile变体。5.4 紫材质排查场景速查表整个场景大面积紫色大概率是管线切换或Standard Shader不兼容用管线的Upgrade功能批量升级材质只有某个模型紫该模型的材质引用丢失或者Shder所在Bundle未加载打包后紫、编辑器不紫Shader被裁剪去Graphics的Always Included Shaders里加安卓紫、iOS不紫平台Shader变体缺失切到对应Build Target重新构建并检查变体集合更新AssetBundle后紫新包没包含Shader依赖重新验证依赖树6. 我自己的优化顺序和几条心得最后分享几个实战经验不一定每条都适用于所有项目但绝大多数情况下按这个顺序做都不会跑偏。先把优化顺序固化下来先做Profiler基线再优化Draw Call然后压面数和纹理内存最后处理AssetBundle和Shader。不要反过来很多团队一上来就疯狂减面结果Draw Call一点没少帧数该掉的还是掉。顺序本身就是经验先解决最抢CPU的绘制开销再考虑模型密度和内存量最后管加载释放节奏。紫材质排查中还有一个小技巧把Always Included Shaders列表和AssetBundle依赖树放在每次构建的检查清单里。每次发版前跑一次全场景扫描把场景和动态加载的Shader清单拉出来和构建报告比对能省去大量线上冒紫的返工时间。别问我怎么知道的被真机上的紫屏教训过几次就记住了。模型优化这个领域没有一劳永逸的方案。每个项目的手感、预算和设备目标都不一样Profile一帧帧看资源一项项理性能就是这么抠出来的。希望这套链路能让你少走点弯路真机跑顺了再回来评论区聊聊。