开场一个我啥都没做它就合并了的疑惑小王发现场景里几个小物体的 DrawCall 自动合并了他很好奇“我没写任何合批代码啊Unity 自己就把它们合并了它具体在幕后做了什么为什么有的能合、有的不能合为什么老鸟说动态批处理’用不好反而更慢’”老鸟说“动态批处理是 Unity每帧自动帮你做的’拼单’但它不是免费的——CPU 要把多个模型的顶点重新计算、拼到一起今天把它幕后每一步做的事拆给你看你就懂为什么它有门槛、也有坑了” 第一幕动态批处理到底是什么核心定义动态批处理(Dynamic Batching) Unity每帧自动把多个小的动态物体 合并成一个DrawCall提交给GPU ↓ 目的: 减少DrawCall,降低CPU提交开销 ↓ 关键词: 动态(可移动) 每帧自动做为什么需要它问题: 每个物体一个DrawCall 100个小石头 100次DrawCall → CPU忙于喊话给GPU ↓ 动态批处理: 把它们拼成1个DrawCall → CPU喊一次就够了 ↓ 省的是CPU提交DrawCall的开销!和静态批处理的区别静态批处理(Static) 针对不动的物体 预处理时合并,运行时省事 → 空间换时间,快但吃内存 动态批处理(Dynamic) 针对会动的小物体 每帧实时合并 → 每帧都要CPU算,有运行时开销! ↓ 本篇重点: 动态的每帧实时合并 第二幕CPU 每帧具体做的事⭐核心动态批处理的幕后步骤每帧,对符合条件的物体,CPU要 【第1步】收集可合批的物体 找出用同一材质、符合条件的小物体 【第2步】变换顶点到世界空间⭐关键开销 每个物体的顶点,本来在模型空间 要用各自的变换矩阵 把顶点变换到世界空间 【第3步】把变换后的顶点拼进一个大缓冲 所有物体的顶点合并到一个顶点缓冲 【第4步】用一个DrawCall提交这个大缓冲 GPU一次画完所有 ↓ 关键: 第2步变换顶点是CPU干的活!生动理解为什么要变换顶点普通渲染: 每个物体带着自己的位置矩阵 GPU拿模型顶点 矩阵 → 算出世界位置 (GPU干变换) 动态批处理: 要拼成一个缓冲 但每个物体位置不同! 不能直接堆一起(位置会错乱) ↓ 所以CPU要先手动把每个物体的顶点 按各自位置变换到世界空间 → 变成已经在正确位置的顶点 → 再拼一起,GPU直接画 ↓ 这个CPU变换顶点就是动态批处理的成本!关键洞察成本在CPU动态批处理的账 省了: CPU提交多个DrawCall的开销 花了: CPU每帧变换所有顶点的开销! ↓ 如果物体顶点太多: 变换顶点的开销 省下的DrawCall开销 → 反而更慢! ↓ 这就是为什么有顶点数限制! 第三幕动态批处理的严格条件条件1顶点数限制⭐最关键✅ 物体顶点数不能太多! (通常限制在~300-900顶点属性范围) 具体看用了多少顶点属性 ↓ 为什么? 因为CPU要变换每个顶点 顶点太多 → CPU变换开销爆炸 → 得不偿失 ↓ 所以动态批处理只适合小物体!顶点属性的计算限制不是单纯顶点数,而是顶点属性数 用的属性越多,能合批的顶点越少 - 只有位置: 能合批更多顶点 - 位置法线UV: 能合批的顶点减少 - 还有切线等: 更少 ↓ Unity文档: 顶点属性总数有上限 属性多 → 单个物体顶点上限就低条件2同一材质⭐✅ 必须用同一个材质(同一材质实例) 不同材质 → 不能合批 (不同材质 不同渲染状态/参数) ↓ ⚠️ 注意: 材质实例不同也不行! 改了材质属性可能产生新实例 → 断批条件3其他限制✅ 还需满足 - 相同的Shader Pass - 不能有多Pass Shader - 缩放方面的一些限制 (非统一缩放曾有限制) - 不能用不同的光照贴图 - 受实时阴影/光影响会复杂化 - 不能用GPU Instancing同时 ↓ 条件很多,容易不小心就断批!生动理解条件苛刻动态批处理像很挑剔的拼单 要拼单必须: - 东西不能太大(顶点数限制) - 目的地一样(同材质) - 打包方式一样(同Shader) ... ↓ 稍有不同就不给拼 所以实际能用上的场景有限! 第四幕为什么说用不好反而更慢陷阱顶点变换开销核心矛盾 动态批处理省的是DrawCall提交(CPU) 但花的是顶点变换(也是CPU!) ↓ 如果物体顶点多: 变换开销 DrawCall省的 → 净亏损! ↓ 所以顶点多的物体 宁可不合批(各自一个DrawCall) 也别动态批处理!生动理解得不偿失拼单的隐藏成本 省: 少喊几次上菜(少几个DrawCall) 花: 但要把每家的菜 重新摆盘拼一大盘(变换所有顶点) ↓ 如果菜量巨大(顶点多): 摆盘的功夫 少喊话省的功夫 → 还不如各上各的! ↓ 这就是用不好反而慢!现代趋势更推荐其他方案⚠️ 现代Unity(URP/HDRP) - SRP Batcher更高效(不同材质也能优化) - GPU Instancing适合大量相同物体 ↓ 动态批处理在现代管线中: - 有时被SRP Batcher替代 - 使用场景变窄 ↓ ✅ 优先考虑SRP Batcher / Instancing 动态批处理作为补充 第五幕三种批处理对比对比表动态批处理 静态批处理 GPU Instancing ───────────────────────────────────────────────────────── 适用 小的动态物体 静止物体 大量相同网格 合并时机 每帧实时 预处理一次 提交时 CPU开销 每帧变换顶点! 低(预处理过) 低 内存 低 高(存合并数据) 低 物体能否动 能 不能(静态) 能 顶点数限制 严格(小物体) 无严格限制 无 材质要求 同材质 同材质 同材质网格 ───────────────────────────────────────────────────────── ↓ 动态批处理: 每帧变换是它的独特成本!选择建议✅ 什么时候用什么 大量相同的物体(树、草、敌人) → GPU Instancing⭐ 静止不动的物体(建筑、地形) → 静态批处理 小的、会动的、同材质物体 → 动态批处理(补充) URP/HDRP通用优化 → SRP Batcher⭐ ↓ 动态批处理不是首选,是特定小场景补充️ 第六幕实战要点怎么开启动态批处理✅ Player Settings / Graphics里 - 勾选Dynamic Batching ↓ 满足条件的物体会自动合批 (你不用写代码,引擎自动做)怎么让物体能合批✅ 要让物体动态合批 - 顶点数控制在限制内(小物体!) - 用同一个材质(共享材质,别产生实例) - 用简单的Shader(单Pass) - 避免不同的光照/阴影影响 ↓ 用Frame Debugger看为什么没合批!用 Frame Debugger 验证✅ 打开Frame Debugger - 看物体是否合批了 - 没合批时,看提示原因: 顶点太多 材质不同 等 - 照着原因调整 ↓ (呼应前面Frame Debugger的用法!)实战判断值不值得用✅ 判断动态批处理是否划算 物体顶点少 数量多 同材质 → 可能划算,开启试试 物体顶点多 → 别指望动态批处理(会超限) → 考虑Instancing或静态 用Profiler对比开启前后: → CPU渲染耗时降了才是真的好 ↓ 数据说话,别想当然!⚠️ 第七幕常见误区误区1以为它完全免费❌ 合批总是好的,开着就对了 → 动态批处理有CPU顶点变换开销! ↓ ✅ 顶点多的物体合批反而亏 要权衡误区2不知道为什么没合批❌ 开了动态批处理但没生效,不知原因 → 条件很苛刻,容易断批 ↓ ✅ 用Frame Debugger看断批原因误区3材质实例化断批❌ 运行时修改material属性 → 产生新材质实例 → 断批! ↓ ✅ 共享材质;要改属性用 MaterialPropertyBlock(配合Instancing)误区4现代管线还硬用它❌ URP项目里只依赖动态批处理 → SRP Batcher往往更优 ↓ ✅ 现代管线优先SRP Batcher Instancing误区5大模型也想合批❌ 给高面数模型开动态批处理 → 顶点超限,根本合不了 → 就算合了,变换开销也巨大 ↓ ✅ 动态批处理只给小物体✅ 动态批处理理解检查清单原理 □ 明白它是每帧自动合并DrawCall □ 明白CPU要变换顶点到世界空间⭐ □ 明白成本在CPU变换顶点 □ 明白为什么有顶点数限制 条件 □ 知道顶点数(属性)限制⭐ □ 知道要同一材质 □ 知道要同Shader单Pass □ 知道各种断批因素 权衡 □ 明白顶点多时可能更慢 □ 会用Frame Debugger查断批原因 □ 会用Profiler验证是否划算 选型 □ 知道大量相同物体用Instancing □ 知道静止物体用静态批处理 □ 知道现代管线优先SRP Batcher 一句话总结动态批处理具体在做什么它是 Unity 每帧自动把多个小的、同材质的动态物体合并成一个 DrawCall。幕后关键步骤CPU 要把每个物体的顶点用各自的变换矩阵手动变换到世界空间再拼进一个大顶点缓冲最后一次提交。核心洞察它省的是CPU 提交 DrawCall的开销但花的是CPU 每帧变换所有顶点的开销——所以有严格的顶点数限制物体顶点太多时合批反而更慢条件苛刻同材质、单 Pass、顶点数限制、易断批现代管线URP优先用 SRP Batcher 和 GPU Instancing动态批处理作为补充。核心口诀动态批处理每帧合CPU变换顶点是关键顶点太多反而慢同材质单Pass才能合用FrameDebugger查断批现代优先SRP Batcher 动态批处理要点速查表要点内容本质每帧自动合并DrawCallCPU做的事变换顶点到世界空间拼缓冲⭐成本所在CPU顶点变换(所以限顶点数)顶点限制严格(小物体才行)材质要求同一材质、单Pass易断批材质实例化、不同光影等陷阱顶点多时反而更慢验证Frame Debugger查断批现代替代SRP Batcher / Instancing 一句话记住核心动态批处理不是免费午餐——它用CPU 变换顶点的开销换少提交几个 DrawCall。只适合小的、同材质的动态物体顶点一多就得不偿失现代 URP 项目优先 SRP Batcher 和 GPU Instancing 延伸从动态批处理看权衡哲学【优化没有银弹,一切是权衡】 动态批处理完美诠释了优化的本质: 它省一样(DrawCall提交) 却花另一样(顶点变换) ↓ 优化 把开销从贵的地方 挪到便宜的地方 ↓ 但如果挪错了(顶点太多): 反而从便宜挪到贵 → 更慢! ↓ 所以优化的铁律再次显现: ① 理解成本在哪 ② 权衡是否划算 ③ 用数据(Profiler)验证! ↓ 不理解原理的优化,可能是负优化!