1. 为什么性能优化要分类来做在真实项目里性能问题从来不是某个函数慢这么简单。一个掉帧现象背后可能是 Draw Call 过多、GC 抖动、物理计算爆炸、纹理内存超限、脚本逻辑空转中的任意一种甚至是它们叠加的结果。所以工程上更有效的做法是先按资源维度分类建立检查清单再针对具体引擎落地技巧。分类的价值在于让排查有顺序避免凭感觉改代码让团队有统一的性能预算Budget语言让优化成果可度量、可回归。下面先给出通用的分类框架再分别整理 Unity 与 Cocos Creator 的实战技巧。2. 性能优化分类总览性能问题CPU 侧GPU 侧内存侧加载与 IO网络与逻辑脚本逻辑 / GCDraw Call / 批处理物理与动画Overdraw / 填充率Shader 复杂度后处理与分辨率纹理 / 网格 / 音频托管堆与对象池资源包与首包场景切换与预加载协议与同步频率AI 与寻路2.1 CPU 侧脚本逻辑与 GC避免每帧 new 对象临时 Vector、List、字符串拼接都是 GC 大户。减少 Update 数量成百上千个Update空转是常见隐形开销能合并就合并能事件驱动就别轮询。字符串与装箱score: score每帧执行会产生大量临时字符串枚举作为字典 Key 会装箱。算法复杂度O(n²) 的碰撞检测、每帧全量排序、每帧Find查找都是典型雷区。2.2 CPU 侧Draw Call 与批处理合批的前提是材质、贴图、渲染状态一致图集Atlas是 UI 与 2D 场景的第一优化手段静态物体标记 Static动态小物件考虑 GPU InstancingUI 层级中穿插不同材质会打断合批注意节点顺序。2.3 GPU 侧Overdraw 与填充率半透明 UI 层层叠加是移动端最大杀手全屏 UI 面板叠加 3~4 层就可能吃掉大半带宽全屏后处理Bloom、Blur在低端机上要提供降级开关Shader 里避免discard、避免复杂分支、避免逐像素的高开销计算。2.4 内存侧资源与托管堆纹理是内存第一大户尺寸、压缩格式ASTC/ETC2、Mipmap 都要按平台规划音频区分长音与短音长音用流式加载托管堆关注 Mono/IL2CPP 堆的峰值与碎片避免频繁大对象分配。2.5 加载与 IO首包与热更包分离按场景/玩法做分包预加载与异步加载结合避免切场景卡顿资源引用计数要能真正释放防止加载了但没卸载。2.6 网络与逻辑同步频率按重要性分级自己/队友/远处单位状态同步做增量与压缩避免全量广播寻路与 AI 分帧计算不要所有单位同一帧跑 A*。3. Unity 实战技巧3.1 Profiling 先行Profiler看 CPU 主线程与渲染线程Frame Debugger看 Draw Call 拆分Memory Profiler抓快照对比定位纹理与托管堆泄漏真机 Profiling 才是准的Editor 数据只能做相对参考。3.2 脚本层// 反例每帧产生临时字符串与闭包voidUpdate(){label.textHP: hp/maxHp;}// 正例缓存 StringBuilder值变化时才刷新privatereadonlyStringBuilder_sbnewStringBuilder(32);privateint_lastHp-1;voidUpdate(){if(hp_lastHp)return;_lastHphp;_sb.Clear();_sb.Append(HP: ).Append(hp).Append(/).Append(maxHp);label.text_sb.ToString();}用CompareTag(Player)替代tag Player避免字符串比较高频查找用字典缓存别在Update里GetComponent/Find大量同类对象用Job System Burst或ECS处理纯计算逻辑。3.3 渲染层SRP Batcher同 Shader 变体下可显著降低 SetPass Call注意材质属性要放在 CBUFFER 中GPU Instancing大量相同 Mesh 的植被、子弹、小怪首选Occlusion Culling与LOD Group配合使用远景降模UI 用Canvas 拆分频繁变化的元素单独一个 Canvas避免整块重建关闭不必要的Raycast TargetUI 事件检测也是 CPU 开销。3.4 资源与内存纹理按平台设置压缩格式UI 图集控制在 2048 以内使用Addressables做资源加载与释放配合引用计数对象池复用子弹、特效、飘字避免频繁 Instantiate/Destroy音频短音效设为 Decompress On Load长 BGM 设为 Streaming。3.5 物理与动画固定时间步Fixed Timestep不要设得过小碰撞体优先用简单形状Mesh Collider 只给静态关键物体动画用Animator 的 Culling Mode关闭不可见角色的更新大量骨骼动画考虑 GPU Skinning。4. Cocos Creator 实战技巧4.1 渲染与合批自动合批依赖同材质同贴图UI 图集要规划好避免一张图一个材质使用多纹理合批Multi-Texture Batching减少 Draw Call2D 场景注意节点层级穿插不同材质的节点会打断合批慎用Mask / Graphics组件它们会打断合批并增加额外 Draw Call。4.2 脚本与 GC// 反例每帧创建临时对象update(dt:number){constposthis.node.position.clone();pos.xthis.speed*dt;this.node.setPosition(pos);}// 正例复用临时向量private_tmpnewVec3();update(dt:number){Vec3.copy(this._tmp,this.node.position);this._tmp.xthis.speed*dt;this.node.setPosition(this._tmp);}避免在update中做getComponent、find、字符串拼接事件监听记得off否则节点销毁后仍被引用导致泄漏大量逻辑用schedule降频不必每帧执行。4.3 资源管理使用Asset Bundle分包按场景/玩法拆分控制首包体积resources.load加载的资源要release注意引用计数纹理压缩按平台选择Android ETC2、iOS ASTC避免运行时解压预制体Prefab实例化用对象池NodePool是官方提供的现成方案。4.4 UI 与 2D 优化Label 使用Char Cache / BMFont长文本频繁刷新是性能黑洞减少 Label 的Overflow重排动态文本尽量用固定尺寸滚动列表用虚拟列表只渲染可视区域内的 Item关闭不需要的Widget对齐更新减少每帧布局计算。4.5 原生与平台小游戏平台注意包体与内存上限微信小游戏对内存尤其敏感使用WebGL / 原生时关注首帧加载时间做启动优化真机调试用 Chrome DevTools 或引擎自带 Profiler 看帧耗时分布。6. 不同优化方案的实际收益量级下面给的是中低端安卓机骁龙 6 系 / 天玑 700 级别上的经验量级用于判断值不值得做不是精确基准。真实数据一定要以自己项目的 Profiler 为准。优化项典型收益生效前提备注消除每帧字符串拼接GC Alloc 从每帧几 KB 降到接近 0卡顿尖峰明显减少该逻辑确实每帧执行收益体现在卡顿而非平均帧率合并 Update / 事件驱动脚本 Update 总耗时降 20%~50%Update 数量在数百级以上数量少时几乎无感UI 图集重构 Canvas 拆分Draw Call 降 30%~60%UI 重建耗时降一半以上原本图集碎片化严重图文混排场景收益打折GPU Instancing同屏数百个相同物件时Draw Call 从数百降到个位数材质/网格完全一致需要支持 Instancing 的 ShaderSRP BatcherSetPass Call 降 50% 以上同 Shader 变体、属性在 CBUFFER对 Draw Call 数量本身无影响关闭多余 Raycast TargetUI 事件检测 CPU 耗时降 10%~30%界面上有大量非交互 Graphic改动成本极低性价比高纹理压缩格式修正纹理内存降 50%~75%原本用了未压缩或 RGBA32需注意画质与加载耗时对象池替代 Instantiate瞬时卡顿基本消除峰值帧耗时降 30%高频生成销毁的物件首次创建仍有开销降低 Overdraw去全屏遮罩GPU 填充率降 20%~40%低端机帧率提升明显半透明层叠 ≥ 3 层移动端收益远大于 PC后处理降级开关低端机帧率提升 10~20 FPS原本开了 Bloom/Blur表现损失需美术确认物理碰撞体简化物理耗时降 30%~70%大量 Mesh Collider手感风险高需谨慎虚拟列表长列表滚动帧率从 20 提升到稳定 60列表项 50实现成本中等6.1 怎么读这张表收益分两类一类降平均耗时如 Draw Call、物理一类降卡顿尖峰如 GC、Instantiate。后者对玩家体感影响更大优先级往往更高性价比排序改动小、风险低的先做——关闭 Raycast Target、纹理压缩、对象池这三项通常一周内能落地且几乎无副作用收益打折是常态表里的数字是理想条件下的上限图文混排、历史包袱、美术要求都会让它打折实际能拿到 50%~70% 就已经不错。6.2 一个真实的优化顺序示例假设一个中低端机上稳定 25 FPS 的 2D 卡牌项目按收益/成本排序大致是先看 Profiler确认瓶颈在 CPU 还是 GPU若是 GC 尖峰 → 对象池 消除字符串拼接通常能消掉大部分卡顿若是 Draw Call 高 → 图集整理 Canvas 拆分先动高频界面若是 GPU 填充率 → 去全屏半透明遮罩、后处理降级最后才考虑架构级重构合并 Update、换渲染管线因为风险最高。5. 现实约束理论上能改实际上改不动前面列的都是正确的事但真实项目里很多优化点在纸面上成立、在工程上却动不了。这一节专门讲这些知道但做不到的地方避免读者照着清单硬改反而踩坑。5.1 美术表现与合批的天然冲突最典型的就是图文混排。理论上把 UI 里所有图片和文字排到同一张图集、同一材质下Draw Call 能压到极低但实际项目里策划要求标题文字压在插画上、插画再叠一层描边这种层叠关系本身就决定了渲染顺序顺序一乱合批就断每个活动页面的美术资源是外包分批交付的图集规划往往在需求变更中被反复打散文字用 BMFont 还是系统字体、图片是否带透明通道都会让同材质这个前提失效。结论图文交替导致的 Draw Call 增加多数情况下是需求成本而不是技术成本。真正能做的不是消灭它而是把静态背景层和动态内容层拆成两个 Canvas / 两个渲染层让静态部分只重建一次给 UI 定一个Draw Call 预算例如单个全屏界面 ≤ 30超了才去谈图集重构优先优化高频出现的界面主界面、战斗 HUD低频活动页不值得为几个 Draw Call 大动干戈。5.2 架构与历史包袱老项目的 Update 满天飞理论上合并 Update 收益很大但一个跑了三年的项目脚本分散在几十个预制体上改动面覆盖全部玩法回归测试成本远超收益第三方 SDK 与插件很多性能热点在不可修改的 SDK 内部广告、统计、支付只能通过延迟初始化降低调用频率在外围缓解引擎版本锁定想用新版本的合批优化或 Job System但项目锁在旧版本升级带来的兼容风险大于性能收益。结论这类问题要用外围手段解决——降频、延迟、分帧、开关而不是改内部实现。5.3 优化收益与风险的权衡有些优化能改但风险大于收益把Mesh Collider全换成Box Collider物理开销确实降了但碰撞手感变了玩家能感知到卡进墙里把动画帧率从 30 降到 15CPU 省了但动作表现明显变糙把纹理从 2048 降到 1024内存省了一半但 UI 在高端机上肉眼可见地糊。结论性能优化永远是和表现、手感、工期做三方博弈。判断标准应该是这个优化玩家能不能感知到感知不到的才值得做。5. 通用优化原则与落地建议先测量再优化没有 Profiler 数据的优化都是猜测设定性能预算如中端机稳定 30 FPS、Draw Call 150、内存 300MB建立回归机制把关键场景做成性能测试用例每次版本对比分级降级画质档位、特效开关、分辨率缩放给低端机留后路优化要可回滚每次只改一个变量记录数据变化。7. 总结性能优化不是一次性任务而是贯穿项目生命周期的工程习惯。分类清单帮你不漏项引擎技巧帮你改得准Profiler 数据帮你改得对而现实约束和收益量级帮你判断哪些值得改。把这几件事做成团队流程掉帧问题才会从玄学变成可解。