1. 项目概述当万人同屏成为性能瓶颈在Unity游戏开发中尤其是MMO、RTS、SLG或者大型开放世界项目中我们总会遇到一个终极挑战如何让成千上万个单位、角色或物体同时出现在屏幕上并且还能流畅运行这不仅仅是“卡不卡”的问题而是直接决定了项目的技术天花板和玩家的核心体验。你或许尝试过LOD、遮挡剔除、GPU Instancing甚至ECS但总感觉在管理成千上万个相似但又不完全相同的对象时代码和内存变得一团糟Draw Call绘制调用依然居高不下。今天我们就来深入聊聊一个被严重低估的、源自经典设计模式的解决方案——享元模式Flyweight Pattern它如何成为“万人同屏”这一渲染优化难题的终极粘合剂与内存管理大师。享元模式的核心思想是“共享”。简单来说就是分离对象中“不变”的部分内部状态和“变化”的部分外部状态。对于同屏的万人军队每个士兵的3D模型、基础贴图、骨骼动画数据内部状态其实都是一样的真正不同的是他们的位置、旋转、血量、当前动作帧等实时信息外部状态。享元模式让我们只保存一份模型和贴图数据然后为上万个士兵实例分别管理他们各自的位置等外部数据。这听起来很像GPU Instancing没错享元模式正是GPU Instancing在代码架构层面的指导思想与完美搭档。它解决的不仅是GPU的渲染压力更是CPU侧对象管理的混乱与内存的巨额浪费。本文将从一个实战角度出发不仅讲解享元模式的理论更会结合Unity的渲染管线特别是URP/HDRP、Scriptable Object、Compute Shader乃至最新的ECS架构构建一套从数据层、逻辑层到渲染层的完整高性能同屏解决方案。无论你是正在被性能问题折磨的开发者还是希望提前为大型项目做技术储备这篇文章都将提供一条清晰的路径和大量可直接“抄作业”的代码与配置。2. 核心思路拆解享元模式如何与渲染管线协同要实现万人同屏我们必须从两个层面同时进攻CPU侧的对象管理与内存效率以及GPU侧的渲染效率。享元模式主要攻坚前者并为后者铺平道路。2.1 享元模式的经典与现代演绎传统的享元模式定义包含FlyweightFactory工厂、Flyweight享元接口、ConcreteFlyweight具体享元和UnsharedConcreteFlyweight非共享享元。在Unity的语境下我们可以这样映射ConcreteFlyweight内部状态这就是我们的共享数据。在Unity中最佳的载体是ScriptableObject。我们可以创建一个SoldierData的ScriptableObject里面存放共享的Mesh、MaterialShader使用支持Instancing的、动画控制器、基础属性如移动速度、攻击力等。成千上万的士兵实例都引用这同一个ScriptableObject资产。外部状态每个士兵独有的数据如worldMatrix位置、旋转、缩放、health、state闲置、移动、攻击等。这些数据不能放在共享资产里需要单独存储。FlyweightFactory一个管理所有共享SoldierData资产的管理器负责按需加载和提供引用避免重复加载。客户端使用享元的对象传统模式下我们可能还会有一个Soldier的MonoBehaviour类。但在追求极致的架构中这个类会变得极其“瘦”它只持有对共享SoldierData的引用和一个用于存储外部状态的数据结构如一个简单的struct。更好的做法是直接摒弃每个士兵一个GameObject的传统模式。2.2 从GameObject到数据驱动架构演进传统MonoBehaviour GameObject的模式在万人规模下单是GameObject自身的开销和每帧Update调用就是灾难。我们的架构需要演进数据集中化将所有士兵的外部状态位置、血量等存储在集中的数据结构中比如一个ListSoldierExternalState或一个NativeArray如果使用ECS/Burst。这个数组就是我们的“万人数据表”。轻量级逻辑更新使用一个MonoBehaviour或一个Systemin ECS来遍历这个数据表根据游戏逻辑AI、输入批量更新所有士兵的外部状态。这个过程可以利用Job System和Burst Compiler进行多线程并行计算极大提升CPU效率。渲染分离渲染系统不直接操作GameObject。它读取这个集中式的“万人数据表”结合共享的SoldierData内部状态通过GPU Instancing或Graphics.DrawMeshInstanced接口一次性提交所有士兵的渲染命令。这才是Draw Call合并的终极形态。注意这里有一个关键抉择点。如果你的士兵需要复杂的、差异化的交互如被鼠标精确点选、受复杂的物理影响完全脱离GameObject会比较困难。此时可以采用“Hybrid”模式为需要交互的少数单位保留GameObject而将大部分仅用于渲染的“背景”单位采用纯数据驱动渲染。享元模式在这种混合架构中同样能有效管理共享资源。2.3 与URP/HDRP渲染管线的对接现代Unity渲染管线URP/HDRP对Instancing有很好的支持。你需要确保Shader支持士兵材质所使用的Shader必须启用GPU Instancing选项。URP/Lit Shader默认支持。自定义Shader需要在属性块添加[PerRendererData]标签并在顶点着色器中正确使用unity_ObjectToWorld等内置instancing矩阵。数据传递通过MaterialPropertyBlock来传递每个实例独有的外部状态如颜色、纹理偏移等避免因为材质属性不同而打断Instancing合批。在万人同屏下更高效的做法是将所有实例的变换矩阵Matrix4x4打包到一个大的ComputeBuffer中然后在Shader中通过SV_InstanceID来索引获取各自的矩阵。渲染调用在负责渲染的MonoBehaviour或System中在Update或特定的渲染回调中调用Graphics.DrawMeshInstanced或Graphics.DrawMeshInstancedIndirect。后者更强大它允许你通过一个Compute Buffer来指定绘制参数甚至可以实现视锥体剔除Frustum Culling和遮挡剔除Occlusion Culling在GPU端完成进一步减轻CPU负担。3. 实战构建一个万人同屏渲染系统的核心实现让我们抛开理论直接动手搭建一个最小可行系统。假设我们要渲染1万个简单的立方体“士兵”。3.1 第一步创建共享数据与外部状态首先创建享元的内部状态即SoldierDataScriptableObject。// SoldierData.cs using UnityEngine; [CreateAssetMenu(fileName NewSoldierData, menuName Soldier/Soldier Data)] public class SoldierData : ScriptableObject { public Mesh mesh; // 共享的网格 public Material material; // 支持GPU Instancing的材质 // 其他共享属性如基础血量、移动速度等 // public float baseHealth; // public float baseSpeed; }接着定义外部状态的结构。为了性能我们使用struct。// SoldierExternalState.cs using UnityEngine; public struct SoldierExternalState { public Vector3 position; public Quaternion rotation; public Vector3 scale; public Color color; // 例如用于区分队伍 // 辅助方法将状态转换为渲染用的矩阵 public Matrix4x4 GetLocalToWorldMatrix() { return Matrix4x4.TRS(position, rotation, scale); } }3.2 第二步构建数据管理与逻辑更新系统创建一个SoldierManager来集中管理所有士兵的外部状态和逻辑。// SoldierManager.cs using UnityEngine; using System.Collections.Generic; public class SoldierManager : MonoBehaviour { public SoldierData sharedSoldierData; // 拖入创建好的SoldierData资产 public int soldierCount 10000; public float spawnArea 100f; private ListSoldierExternalState soldierStates; private ListMatrix4x4 matricesForRendering; private MaterialPropertyBlock materialPropertyBlock; private Color[] teamColors; void Start() { InitializeSoldiers(); InitializeMaterialPropertyBlock(); } void InitializeSoldiers() { soldierStates new ListSoldierExternalState(soldierCount); matricesForRendering new ListMatrix4x4(soldierCount); teamColors new Color[] { Color.blue, Color.red }; for (int i 0; i soldierCount; i) { SoldierExternalState state new SoldierExternalState(); // 随机位置 state.position new Vector3( Random.Range(-spawnArea, spawnArea), 0, Random.Range(-spawnArea, spawnArea) ); state.rotation Quaternion.identity; state.scale Vector3.one; // 随机分配队伍颜色 state.color teamColors[Random.Range(0, teamColors.Length)]; soldierStates.Add(state); matricesForRendering.Add(state.GetLocalToWorldMatrix()); } } void InitializeMaterialPropertyBlock() { materialPropertyBlock new MaterialPropertyBlock(); // 如果需要传递每实例颜色我们需要一个Color数组但DrawMeshInstanced不支持每实例的MaterialPropertyBlock。 // 替代方案将颜色编码到顶点色或第二个UV通道或者在Shader中使用从大纹理中采样纹理图集。 // 这里为简化我们先不传递每实例颜色。 } void Update() { UpdateSoldierLogic(); RenderSoldiers(); } void UpdateSoldierLogic() { // 这里是你的游戏逻辑移动、AI决策等。 // 例如让士兵简单地向中心点移动 Vector3 center Vector3.zero; float speed 5f * Time.deltaTime; for (int i 0; i soldierStates.Count; i) { SoldierExternalState state soldierStates[i]; Vector3 direction (center - state.position).normalized; state.position direction * speed; // 更新旋转面向移动方向简化 if (direction.sqrMagnitude 0.01f) { state.rotation Quaternion.LookRotation(direction); } soldierStates[i] state; // 注意struct是值类型需要写回列表 matricesForRendering[i] state.GetLocalToWorldMatrix(); } } void RenderSoldiers() { if (sharedSoldierData null || sharedSoldierData.mesh null || sharedSoldierData.material null) return; // 关键渲染调用一次性绘制所有实例 // Graphics.DrawMeshInstanced有每批次1023个实例的限制需要分批次绘制 int batchSize 1023; for (int i 0; i matricesForRendering.Count; i batchSize) { int count Mathf.Min(batchSize, matricesForRendering.Count - i); var batchMatrices matricesForRendering.GetRange(i, count).ToArray(); Graphics.DrawMeshInstanced( sharedSoldierData.mesh, 0, sharedSoldierData.material, batchMatrices, count, materialPropertyBlock, UnityEngine.Rendering.ShadowCastingMode.On, true // 接收阴影 ); } } }3.3 第三步优化与进阶——使用ComputeBuffer与Indirect Drawing上述方法DrawMeshInstanced在每帧需要从CPU传递大量矩阵数据到GPU当数量极大时仍有开销。更高级的做法是使用Graphics.DrawMeshInstancedIndirect配合ComputeBuffer。将数据上传至GPU在Start中将soldierStates数据位置、旋转等打包到ComputeBuffer中。使用Compute Shader进行剔除与LOD编写一个Compute Shader在GPU端根据摄像机视锥体对ComputeBuffer中的实例进行剔除并生成一个Args Buffer参数缓冲区其中包含实际需要绘制的实例数量。间接绘制调用Graphics.DrawMeshInstancedIndirect传入共享的Mesh、Material以及这个Args Buffer。GPU将根据Args Buffer中的信息进行绘制完全避免了CPU对不可见物体的处理。// 进阶SoldierManager部分代码示例 public class AdvancedSoldierManager : MonoBehaviour { // ... 之前的数据声明 ... private ComputeBuffer positionBuffer; private ComputeBuffer argsBuffer; public ComputeShader cullingComputeShader; private uint[] args new uint[5] { 0, 0, 0, 0, 0 }; void Start() { // ... 初始化soldierStates ... InitializeComputeBuffers(); } void InitializeComputeBuffers() { // 创建存储位置/旋转的Buffer (例如每个实例一个float4表示位置一个float4表示四元数) int stride System.Runtime.InteropServices.Marshal.SizeOf(typeof(Vector4)) * 2; // 示例大小 positionBuffer new ComputeBuffer(soldierCount, stride); // 将数据上传到ComputeBuffer // ... 填充positionBuffer数据 ... // 创建参数Buffer argsBuffer new ComputeBuffer(1, args.Length * sizeof(uint), ComputeBufferType.IndirectArguments); uint numIndices (sharedSoldierData.mesh ! null) ? (uint)sharedSoldierData.mesh.GetIndexCount(0) : 0; args[0] numIndices; // 索引数量 args[1] (uint)soldierCount; // 实例数量 args[2] sharedSoldierData.mesh.GetIndexStart(0); args[3] sharedSoldierData.mesh.GetBaseVertex(0); args[4] 0; // 实例起始偏移 argsBuffer.SetData(args); } void Update() { UpdateSoldierLogicOnGPU(); // 使用Compute Shader更新逻辑和剔除 RenderSoldiersIndirect(); } void UpdateSoldierLogicOnGPU() { // 将摄像机视锥体平面等信息传递给Compute Shader // 运行Compute Shader Kernel进行位置更新、视锥体剔除 // 剔除后更新argsBuffer中的实例数量(args[1]) // cullingComputeShader.SetBuffer(kernelIndex, positions, positionBuffer); // cullingComputeShader.SetMatrix(CameraViewProjection, cam.projectionMatrix * cam.worldToCameraMatrix); // cullingComputeShader.Dispatch(kernelIndex, Mathf.CeilToInt(soldierCount / 64.0f), 1, 1); // 然后从GPU读回args数据或使用AsyncGPUReadback避免阻塞 } void RenderSoldiersIndirect() { // 设置材质的ComputeBuffer sharedSoldierData.material.SetBuffer(_PositionBuffer, positionBuffer); // 间接绘制 Graphics.DrawMeshInstancedIndirect( sharedSoldierData.mesh, 0, sharedSoldierData.material, new Bounds(Vector3.zero, Vector3.one * spawnArea * 2), // 包围盒 argsBuffer ); } void OnDestroy() { positionBuffer?.Release(); argsBuffer?.Release(); } }对应的Shader需要能够从_PositionBuffer中根据SV_InstanceID读取每个实例的变换信息并构建unity_ObjectToWorld矩阵。实操心得从DrawMeshInstanced过渡到DrawMeshInstancedIndirect是性能优化的一大步但复杂度也显著增加。建议项目初期先用前者实现功能在性能分析Profiler中确认渲染成为瓶颈后再着手实现后者。同时GPU驱动剔除如Unity的GPUDrivenRendering需要特定的渲染管线和硬件支持需权衡项目目标平台。4. 性能剖析与避坑指南实现万人同屏系统后必须使用Unity Profiler进行深度性能剖析。关注以下几个关键点4.1 CPU性能瓶颈排查UpdateSoldierLogic循环这是最可能的热点。如果逻辑复杂如寻路、复杂AI1万次的循环将是灾难。优化方案将逻辑迁移到Job System中并行执行。将soldierStates转换为NativeArray使用IJobParallelFor来并行更新位置、状态等。这能充分利用多核CPU。注意Job中不能访问MonoBehaviour或托管对象所有数据需是blittable类型或存在于NativeContainer中。Graphics.DrawMeshInstanced调用虽然它本身是高效的但准备Matrix4x4数组和分批次调用仍有开销。优化方案如前所述升级到DrawMeshInstancedIndirect将矩阵数据和剔除工作转移到GPU。4.2 GPU性能瓶颈排查Overdraw过度绘制即使有1万个实例如果它们层层叠叠GPU仍需要为每个像素计算多次着色。这是同屏大量物体的固有难题。优化方案严格的视锥体剔除确保摄像机看不到的物体绝不提交渲染。DrawMeshInstancedIndirect的GPU剔除是关键。遮挡剔除Occlusion Culling对于静态场景烘焙Occlusion Data。对于动态的万人军队硬件遮挡查询Hardware Occlusion Queries或基于深度的早期剔除Hi-Z等高级技术可能更有效但实现复杂。简化模型与材质使用更低面数的LOD0模型简化Shader复杂度。对于远处的士兵可以切换到更简单的LOD1、LOD2甚至用公告板Billboard替代。带宽与内存每实例传递大量数据如完整的Matrix4x4会消耗显存带宽。优化方案量化数据。例如位置可以用half精度如果世界范围允许旋转可以用更小的四元数表示法或甚至用Y轴旋转角代替。在Shader中解码。4.3 常见问题与解决方案速查表问题现象可能原因排查与解决方案渲染完全消失或闪烁DrawMeshInstanced的批次限制1023处理错误Compute Buffer数据未正确上传Shader不支持Instancing。1. 检查分批次逻辑确保索引未越界。2. 在Frame Debugger中查看绘制命令确认是否有对应的DrawMeshInstanced调用。3. 检查材质Shader是否启用了GPU Instancing。对于自定义Shader检查#pragma multi_compile_instancing和UNITY_MATRIX_M等instancing宏的使用。只有第一个实例被渲染未正确使用SV_InstanceID来索引每实例数据所有实例的变换矩阵相同。1. 在Shader中打印SV_InstanceID确认其值是否从0递增。2. 检查CPU端生成的matricesForRendering数组确认每个矩阵是否不同。3. 对于Indirect Drawing检查Compute Shader中的剔除逻辑是否错误地将所有实例都剔除了。性能提升不明显CPU逻辑更新仍是瓶颈GPU Overdraw严重未启用动态合批/GPU Instancing。1. 使用Profiler的CPU模块找到最耗时的函数。将热点逻辑如寻路、状态机Job化。2. 使用Profiler的GPU模块或RenderDoc工具分析像素着色器的负载。尝试启用LOD和简化远处物体。3. 确保材质球不同实例间的属性差异通过MaterialPropertyBlock设置而不是创建新的Material实例。内存占用过高除了共享的SoldierData每个“士兵”可能仍保留了不必要的独立组件或数据。1. 彻底审查是否还存在为每个士兵生成的GameObject、MonoBehaviour脚本。2. 检查集中存储的外部状态数据结构如ListSoldierExternalState中是否包含了可以进一步共享或压缩的数据。3. 使用Unity的Memory Profiler工具分析托管堆和Native内存的具体分配。5. 与Unity生态的深度整合享元模式和数据驱动的渲染架构可以很好地与Unity的其他高性能特性结合。与ECS实体组件系统结合这是天然搭档。SoldierData可以作为SharedComponentData而每个士兵的SoldierExternalState则是IComponentData。渲染系统可以通过Entities.ForEach或IJobEntityBatch来收集所有需要渲染的实体数据然后调用Graphics.DrawMeshInstancedIndirect。Unity的RenderMeshUtility组件和Hybrid Renderer包正是为此类场景设计。与Addressable资产管理系统结合共享的SoldierDataScriptableObject可以通过Addressables进行异步加载和引用计数管理实现资源的动态加载与卸载非常适合开放世界。与动画系统结合这是万人同屏的另一个难点。解决方案包括GPU动画将骨骼动画数据贴图和计算放到顶点/计算着色器中。每个实例通过SV_InstanceID索引动画贴图中的不同帧。这是目前万人动画的主流高性能方案。动画贴图烘焙将复杂的角色动画预先烘焙到贴图位置、法线贴图在Shader中采样播放。简化的程序化动画对于士兵可以使用简单的正弦波等数学函数模拟待机、行走的起伏完全避免骨骼动画开销。实现一个稳定的万人同屏系统绝非一日之功。它要求开发者对Unity的渲染管线、内存管理、多线程编程和Shader编程都有较深的理解。享元模式提供了清晰的数据管理蓝图而GPU Instancing、Compute Shader、Job System等现代图形与计算API则提供了实现的武器库。从一个小型的、数据驱动的渲染Demo开始逐步引入状态更新、动画、碰撞交互可能需要DOTS Physics等复杂功能是稳妥的推进策略。记住优化的黄金法则是“测量而不是猜测”始终让Profiler数据来指导你的优化方向。当你看到上万个单位在屏幕上流畅运转时那种技术带来的成就感无疑是驱动我们不断深入探索的最佳动力。