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、Material（Shader使用支持Instancing的）、动画控制器、基础属性（如移动速度、攻击力）等。成千上万的士兵实例都引用这同一个ScriptableObject资产。
• 外部状态：每个士兵独有的数据，如worldMatrix（位置、旋转、缩放）、health、state（闲置、移动、攻击）等。这些数据不能放在共享资产里，需要单独存储。
• FlyweightFactory：一个管理所有共享SoldierData资产的管理器，负责按需加载和提供引用，避免重复加载。
• 客户端（使用享元的对象）：传统模式下，我们可能还会有一个Soldier的MonoBehaviour类。但在追求极致的架构中，这个类会变得极其“瘦”，它只持有对共享SoldierData的引用和一个用于存储外部状态的数据结构（如一个简单的struct）。更好的做法是，直接摒弃每个士兵一个GameObject的传统模式。

2.2 从GameObject到数据驱动：架构演进

传统MonoBehaviour + GameObject的模式，在万人规模下，单是GameObject自身的开销和每帧Update调用就是灾难。我们的架构需要演进：

1. 数据集中化：将所有士兵的外部状态（位置、血量等）存储在集中的数据结构中，比如一个List<SoldierExternalState>或一个NativeArray（如果使用ECS/Burst）。这个数组就是我们的“万人数据表”。
2. 轻量级逻辑更新：使用一个MonoBehaviour（或一个Systemin ECS）来遍历这个数据表，根据游戏逻辑（AI、输入）批量更新所有士兵的外部状态。这个过程可以利用Job System和Burst Compiler进行多线程并行计算，极大提升CPU效率。
3. 渲染分离：渲染系统不直接操作GameObject。它读取这个集中式的“万人数据表”，结合共享的SoldierData（内部状态），通过GPU Instancing或Graphics.DrawMeshInstanced接口，一次性提交所有士兵的渲染命令。这才是Draw Call合并的终极形态。

注意：这里有一个关键抉择点。如果你的士兵需要复杂的、差异化的交互（如被鼠标精确点选、受复杂的物理影响），完全脱离GameObject会比较困难。此时可以采用“Hybrid”模式：为需要交互的少数单位保留GameObject，而将大部分仅用于渲染的“背景”单位采用纯数据驱动渲染。享元模式在这种混合架构中同样能有效管理共享资源。

2.3 与URP/HDRP渲染管线的对接

现代Unity渲染管线（URP/HDRP）对Instancing有很好的支持。你需要确保：

1. Shader支持：士兵材质所使用的Shader必须启用GPU Instancing选项。URP/Lit Shader默认支持。自定义Shader需要在属性块添加[PerRendererData]标签，并在顶点着色器中正确使用unity_ObjectToWorld等内置instancing矩阵。
2. 数据传递：通过MaterialPropertyBlock来传递每个实例独有的外部状态（如颜色、纹理偏移等），避免因为材质属性不同而打断Instancing合批。在万人同屏下，更高效的做法是将所有实例的变换矩阵（Matrix4x4）打包到一个大的ComputeBuffer中，然后在Shader中通过SV_InstanceID来索引获取各自的矩阵。
3. 渲染调用：在负责渲染的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 List<SoldierExternalState> soldierStates; private List<Matrix4x4> matricesForRendering; private MaterialPropertyBlock materialPropertyBlock; private Color[] teamColors; void Start() { InitializeSoldiers(); InitializeMaterialPropertyBlock(); } void InitializeSoldiers() { soldierStates = new List<SoldierExternalState>(soldierCount); matricesForRendering = new List<Matrix4x4>(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。

1. 将数据上传至GPU：在Start中，将soldierStates数据（位置、旋转等）打包到ComputeBuffer中。
2. 使用Compute Shader进行剔除与LOD：编写一个Compute Shader，在GPU端根据摄像机视锥体对ComputeBuffer中的实例进行剔除，并生成一个Args Buffer（参数缓冲区），其中包含实际需要绘制的实例数量。
3. 间接绘制：调用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性能瓶颈排查

1. UpdateSoldierLogic循环：这是最可能的热点。如果逻辑复杂（如寻路、复杂AI），1万次的循环将是灾难。

   • 优化方案：将逻辑迁移到Job System中并行执行。将soldierStates转换为NativeArray，使用IJobParallelFor来并行更新位置、状态等。这能充分利用多核CPU。
   • 注意：Job中不能访问MonoBehaviour或托管对象，所有数据需是blittable类型或存在于NativeContainer中。

2. Graphics.DrawMeshInstanced调用：虽然它本身是高效的，但准备Matrix4x4数组和分批次调用仍有开销。

   • 优化方案：如前所述，升级到DrawMeshInstancedIndirect，将矩阵数据和剔除工作转移到GPU。

4.2 GPU性能瓶颈排查

1. Overdraw（过度绘制）：即使有1万个实例，如果它们层层叠叠，GPU仍需要为每个像素计算多次着色。这是同屏大量物体的固有难题。

   • 优化方案：
     • 严格的视锥体剔除：确保摄像机看不到的物体绝不提交渲染。DrawMeshInstancedIndirect的GPU剔除是关键。
     • 遮挡剔除（Occlusion Culling）：对于静态场景，烘焙Occlusion Data。对于动态的万人军队，硬件遮挡查询（Hardware Occlusion Queries）或基于深度的早期剔除（Hi-Z）等高级技术可能更有效，但实现复杂。
     • 简化模型与材质：使用更低面数的LOD0模型，简化Shader复杂度。对于远处的士兵，可以切换到更简单的LOD1、LOD2，甚至用公告板（Billboard）替代。

2. 带宽与内存：每实例传递大量数据（如完整的Matrix4x4）会消耗显存带宽。

   • 优化方案：量化数据。例如，位置可以用half精度（如果世界范围允许），旋转可以用更小的四元数表示法或甚至用Y轴旋转角代替。在Shader中解码。

4.3 常见问题与解决方案速查表

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数据来指导你的优化方向。当你看到上万个单位在屏幕上流畅运转时，那种技术带来的成就感，无疑是驱动我们不断深入探索的最佳动力。