1. 项目概述：为什么“千人同屏”是手游开发的圣杯与挑战

“千人同屏”这四个字，对于任何一位手游开发者，尤其是使用Unity引擎的同行来说，都像是一个既充满诱惑又令人望而生畏的挑战。它不仅仅是屏幕上数字的堆砌，更代表着一种极致的游戏体验和背后复杂的技术博弈。想象一下，在大型国战、开放世界社交或是MMO团本中，成百上千名玩家在同一片战场上集结、冲锋、释放技能，那种宏大的场面和实时的互动所带来的沉浸感，是任何小规模战斗都无法比拟的。这不仅是提升玩家留存和付费的利器，更是技术实力的直接体现。

然而，理想很丰满，现实很骨感。Unity虽然功能强大、生态繁荣，但其传统的面向对象和基于GameObject的架构，在面对海量实体（尤其是需要同步和逻辑计算的玩家单位）时，性能瓶颈会迅速凸显。CPU的逻辑计算、Draw Call的爆炸式增长、网络同步的庞大数据量、内存的急剧消耗，任何一环处理不当，都会导致帧率骤降、发热严重、甚至直接崩溃。因此，“实现千人同屏”从来不是一个单一的技术点，而是一个贯穿客户端渲染、逻辑、网络、服务器架构乃至工具链的“全链路”系统工程。

我经历过从几十人同屏都卡顿，到最终稳定支撑近千人同屏战斗的项目迭代。这个过程充满了试错、重构和性能攻坚。本文将抛开那些华而不实的理论，直接切入实战，从最根本的技术选型逻辑讲起，拆解每一个核心模块的实现细节与避坑指南，目标是为你提供一份从“想到”到“做到”的可落地路线图。无论你是正在面临性能压力的项目主程，还是对高性能Unity开发感兴趣的技术爱好者，相信这些从泥坑里爬出来的经验，都能给你带来实实在在的启发。

2. 核心架构选型：ECS、DOTS与传统模式的生死抉择

当你决定要挑战千人同屏时，第一个也是最重要的决策就是：选择什么样的底层架构来组织你的游戏逻辑和渲染。这个选择将决定你项目后续开发的天花板和踩坑的深度。目前主流的有三条路：传统的面向对象（OOP）模式、纯ECS架构，以及Unity官方力推的DOTS技术栈。没有银弹，只有最适合你团队和项目阶段的选择。

2.1 传统OOP模式：快速启动与明确的天花板

这是最熟悉、最快速的方式。每个玩家、怪物都是一个MonoBehaviour脚本挂载的GameObject。逻辑写在Update里，移动用Transform，动画用Animator。

为什么初期可能会选它？

• 开发效率高：团队成员无需学习新范式，利用大量现有插件和资源。
• 工具链成熟：Unity编辑器对GameObject的支持是无与伦比的，策划、美术都能快速上手配置。
• 快速原型验证：在项目早期，验证玩法可行性比追求极限性能更重要。

但它为什么无法支撑千人规模？

• CPU缓存不友好：MonoBehaviour数据分散在堆内存中，Update循环遍历成千上万个对象，会造成大量的缓存缺失（Cache Miss）。
• GC（垃圾回收）压力：每帧产生大量临时对象（如向量、队列指令），会频繁触发GC，造成卡顿。
• 主线程瓶颈：所有逻辑都在主线程，上千个单位的寻路、技能计算足以拖垮任何高端手机。

实操心得：如果你的目标同屏人数在100-200人，且战斗逻辑不复杂，通过极致的优化（如对象池、逻辑分帧、动画合并）或许能勉强达到。但一旦设定“千人”目标，传统OOP在项目中期就会成为无法逾越的障碍，推倒重来的成本极高。我曾在一个项目中，用OOP优化到300人同屏时，帧率已极不稳定，CPU耗时占比超过70%，深知其天花板之低。

2.2 纯ECS架构：极致的性能与陡峭的学习曲线

Entity-Component-System是一种数据驱动的架构范式。Entity是ID，Component是纯数据（结构体），System是逻辑处理。它强制数据与逻辑分离，并且要求数据按类型连续存储在内存中（Archetype）。

为什么它是千人同屏的终极答案之一？

• 极致的数据局部性：相同类型的数据（如所有单位的PositionComponent）在内存中连续排列，System遍历时缓存命中率极高，这是性能提升的核心。
• 天然的多线程友好：System处理彼此独立的数据，可以很容易地并行化，充分利用多核CPU。
• 无GC开销：Component是结构体，分配在连续内存或堆栈上，避免了托管堆的垃圾回收。

你需要付出的代价：

• 范式转变：开发者需要从“对象思维”转变为“数据思维”，学习成本高。
• 工具链缺失：编辑器原生支持弱，可视化调试困难。你需要自己打造或寻找一套编辑器和调试工具。
• 与渲染层对接复杂：ECS计算出的位置、状态数据，如何高效地驱动GameObject进行渲染，需要设计一套高效的转换机制（如通过MonoBehaviour作为渲染代理）。

一个简单的移动System示意代码：

// 定义组件（纯数据） public struct PositionComponent : IComponentData { public float3 Value; } public struct VelocityComponent : IComponentData { public float3 Value; } // 定义系统（纯逻辑） [UpdateInGroup(typeof(SimulationSystemGroup))] public partial class MovementSystem : SystemBase { protected override void OnUpdate() { float deltaTime = Time.DeltaTime; // 高效地遍历所有同时拥有Position和Velocity的实体 Entities .ForEach((ref PositionComponent position, in VelocityComponent velocity) => { position.Value += velocity.Value * deltaTime; }).ScheduleParallel(); // 关键：并行调度 } }

2.3 Unity DOTS：官方的未来方案与当下的“半成品”

DOTS（Data-Oriented Technology Stack）是Unity官方打造的，包含ECS（实体组件系统）、C# Job System、Burst Compiler的技术集合。它代表了Unity未来的高性能开发方向。

• C# Job System：让你能安全、方便地编写多线程代码。
• Burst Compiler：一个高性能的编译器，能将C#代码编译成高度优化的原生代码，性能堪比C++。
• ECS for Unity：Unity官方实现的ECS框架。

DOTS的优势与现状：

• 性能潜力最大：Burst+Job+ECS的组合，能榨干硬件性能。实测中，单纯的计算密集型逻辑，性能提升可达数十倍。
• 官方背书，生态在成长：Unity持续投入，包管理器中有越来越多DOTS相关的包（如Unity Physics、NetCode for Entities）。

但是，致命的“但是”：

• API不稳定：在2022 LTS及以前版本，DOTS核心API变动频繁，一个版本升级可能导致大量代码需要修改。
• 工作流不完整：特别是网络同步，虽然有了NetCode for Entities，但与成熟的中大型游戏服务器架构（如ET、Skynet等）的整合方案仍在探索中，缺乏大规模线上验证。
• 渲染管线适配：与URP/HDRP的集成需要额外处理，传统的动画系统（Mecanim）不能直接用于ECS实体。

技术选型结论：

1. 追求极致性能、团队技术实力雄厚、项目周期长且愿意承担技术风险：选择Unity DOTS（ECS）。从项目开始就拥抱未来，但要做好持续踩坑和自力更生的准备。
2. 追求高性能，但需要更稳定的框架和社区支持，且不介意自己处理渲染对接：可以选择成熟的第三方ECS框架（如LeoEcs, Svelto.ECS）配合Job System。这是一个折中且相对稳妥的方案。
3. 项目已中期、或团队规模小、急于出 demo/早期版本：可以在传统OOP基础上，局部引入Job System和Burst来优化最耗时的计算（如寻路、技能伤害计算），并为未来向ECS架构迁移预留接口。这被称为“混合架构”，是很多项目的现实选择。

我们项目最终选择了“混合架构”：核心战斗单位（玩家、怪物）使用ECS（LeoEcs）管理位置、状态和战斗计算；场景交互元素、UI等仍用传统OOP；两者通过一个“渲染代理”系统进行同步。这平衡了性能与开发效率。

3. 渲染性能攻坚：如何让GPU绘制上千个角色而不卡顿

当逻辑层能处理上千个单位后，渲染层就成了下一个瓶颈。默认情况下，上千个独立的角色模型意味着上千个Draw Call，这对于移动端GPU是不可承受之重。我们的目标是：用尽可能少的Draw Call，绘制出上千个看起来各不相同的角色。

3.1 GPU Instancing：千人一面的高效绘制

这是最基础也是最重要的优化手段。它允许GPU用一次Draw Call绘制多个相同的网格（Mesh），但可以拥有不同的位置、旋转、缩放甚至颜色。

如何实施？

1. 材质支持：确保角色材质球勾选了Enable GPU Instancing选项。
2. 数据准备：在C#端，将所有需要绘制的实例的变换矩阵（Matrix4x4）收集到一个数组中。
3. 批量绘制：调用Graphics.DrawMeshInstanced或Graphics.DrawMeshInstancedProcedural（更灵活）方法。

局限性：

• “千人一面”：所有实例必须使用相同的网格和材质。这意味着你不能直接用它来绘制外形迥异的玩家角色。
• 变通方案：将角色分为几个大类（如战士、法师、弓箭手），每个大类准备一个基础模型。通过动态合批（小范围）或纹理图集（Atlas）来提供不同的贴图变化，模拟外观差异。对于外观差异巨大的需求，需要更高级的方案。

3.2 顶点动画纹理（VAT）与GPU Skinning：将动画计算卸载到GPU

传统的骨骼动画在CPU端计算每一帧的顶点位置，消耗巨大。对于同屏大量播放相同或相似动画的单位（比如一群小兵都在跑步），我们可以把动画“烘焙”到纹理中。

• 原理：在预处理阶段，将角色模型在动画序列中每一帧的顶点位置（或相对于绑定姿势的偏移）记录到一张纹理（RGB通道存储位置XYZ）中。在Shader中，根据当前动画时间和顶点ID，从这张纹理中采样出对应的顶点位置，直接完成变形。
• 优势：
  • Draw Call极低：所有使用同一套VAT的角色可以合并为一个Draw Call。
  • CPU零开销：动画计算完全在GPU的顶点着色器中进行，解放CPU。
  • 支持巨量单位：理论上只受限于GPU的顶点处理能力和显存（存储纹理）。
• 劣势：
  • 内存占用：动画越长、模型顶点越多，所需的纹理越大。
  • 精度损失：纹理存储的是量化后的数据，可能会有细微精度损失。
  • 动画融合复杂：实现两个动画之间的平滑过渡（如从跑到停）比传统骨骼动画复杂。

实施步骤简述：

1. 在DCC工具（如Maya）或Unity编辑器工具中，将角色动画烘焙到顶点位置序列。
2. 将序列数据编码（如位置压缩到0-1范围）并存入一张Texture2D。
3. 编写自定义Shader，在顶点着色器中根据时间采样纹理，重建顶点位置。
4. 在脚本中，只需为每个实例设置一个包含动画开始时间、播放速度等信息的Per-Instance数据块即可。

3.3 细节层级（LOD）与视锥体剔除：看不见的就不画

这是开放世界游戏的标配，在千人同屏场景中同样关键。

• LOD（Level of Detail）：为同一个模型准备多个细节程度的版本（如高模、中模、低模、广告牌）。根据物体与摄像机的距离，动态切换不同的模型。对于远处的上千名玩家，可能仅仅渲染为一个带颜色的四边形（广告牌），Draw Call和顶点数大幅下降。

  • Unity实现：使用LOD Group组件，或自行根据距离管理模型切换。
  • 注意事项：LOD切换时避免“跳变”，可以结合淡入淡出（dithering）或几何着色器进行平滑过渡。

• 视锥体剔除（Frustum Culling）：Unity摄像机默认会进行视锥体剔除，不渲染视野外的物体。但在千人场景中，手动管理可以更高效。

  • 优化点1：动态网格合批的剔除：如果你自己管理GPU Instancing的绘制列表，在提交矩阵数组前，应该先进行一轮视锥体剔除，只提交可见的实例。
  • 优化点2：基于网格的剔除：对于超大规模单位，可以使用四叉树（2D）或八叉树（3D）等空间划分数据结构，快速定位潜在可见集，减少遍历数量。

3.4 实战中的渲染架构设计

在我们的项目中，渲染层采用了分层混合的策略：

1. 近处高优先级单位（主角、主要敌人）：使用传统的骨骼动画+GPU Instancing（小批量），保证最高画质和动作细节。
2. 中距离单位：使用GPU Skinning（计算骨骼动画在GPU）或简化的VAT，模型使用LOD1或LOD2。
3. 远处及大量杂兵单位：使用广告牌（Billboard）或极简模型，动画用最简化的VAT或甚至只是位置移动。这些单位可以被合并到一个或少数几个大的Draw Call中。

关键代码片段（管理Instancing绘制与剔除）：

public class MassUnitRenderer : MonoBehaviour { public Mesh unitMesh; public Material unitMaterial; private List<Matrix4x4> _visibleMatrices = new List<Matrix4x4>(1024); private const int MAX_INSTANCE_PER_BATCH = 1023; // 某些平台限制 void Update() { _visibleMatrices.Clear(); // 1. 从ECS或逻辑系统获取所有单位的数据 var allUnits = UnitManager.GetAllUnits(); Plane[] cameraFrustumPlanes = GeometryUtility.CalculateFrustumPlanes(Camera.main); // 2. 遍历并进行视锥体剔除 foreach (var unit in allUnits) { // 计算单位的包围球或包围盒 Bounds unitBounds = new Bounds(unit.Position, Vector3.one * unit.Radius); if (GeometryUtility.TestPlanesAABB(cameraFrustumPlanes, unitBounds)) { _visibleMatrices.Add(Matrix4x4.TRS(unit.Position, unit.Rotation, Vector3.one)); } } // 3. 分批次绘制 for (int i = 0; i < _visibleMatrices.Count; i += MAX_INSTANCE_PER_BATCH) { int count = Mathf.Min(MAX_INSTANCE_PER_BATCH, _visibleMatrices.Count - i); Graphics.DrawMeshInstanced(unitMesh, 0, unitMaterial, _visibleMatrices.GetRange(i, count).ToArray(), count); } } }

4. 网络同步策略：在带宽与实时性间走钢丝

千人同屏不仅是客户端的挑战，更是服务器的噩梦。网络同步的目标是在有限的带宽下，让所有客户端看到一个尽可能一致的世界。这里没有完美方案，只有权衡。

4.1 同步什么？状态同步 vs. 帧同步

• 状态同步（快照插值）：

  • 原理：服务器权威地计算所有单位的完整状态（位置、血量、状态等），以一定的频率（如10-20Hz）将整个场景的快照（Snapshot）广播给所有客户端。客户端收到快照后，在两帧快照之间进行插值（Lerp），实现平滑显示。
  • 优点：逻辑简单，反外挂能力强（逻辑在服务器），客户端表现稳定。
  • 缺点：带宽消耗大。千人场景下，每帧快照的数据量惊人。需要极高的压缩技巧。
  • 适用场景：MMORPG、MOBA等，对实时性要求不是极端高，且单位属性复杂的游戏。

• 帧同步（Lockstep）：

  • 原理：服务器只转发玩家的操作指令（Input）。所有客户端在相同的初始状态下，按相同的顺序执行这些指令，从而得到确定性的结果。客户端需要完整的逻辑模拟。
  • 优点：带宽消耗极低（只同步操作），理论上可以支持无限多单位。
  • 缺点：实现复杂，需要逻辑的确定性（不能有浮点数误差、随机数需要同步种子），反外挂困难，且网络延迟会直接影响操作响应。
  • 适用场景：RTS（如《星际争霸》）、一些卡牌和棋牌游戏。

对于“千人同屏战斗”，状态同步的变体——兴趣域（AOI）同步是更主流的选择。

4.2 兴趣域（AOI）管理：我只关心我周围的

服务器不会把全地图1000人的状态都发给每个客户端。每个客户端只同步其“兴趣范围”内的单位。

• 常见AOI算法：

  • 十字链表：经典算法，将地图划分为网格，每个格子维护一个单位链表。单位移动时，更新所在格子，并通知新旧格子视野内的玩家。实现相对简单，效率不错。
  • 九宫格：玩家视野是其所在格子及周围八个格子。适用于格子化地图。
  • 灯塔法：更高效的算法，但实现复杂。

• 同步内容的优化：

  • 优先级同步：对于视野内的单位，也不是每帧同步所有数据。根据距离、是否在战斗、是否是队友等因素，设置不同的同步频率和精度。远处的单位可能只同步位置（低频、低精度），近处的战斗单位同步所有状态（高频、高精度）。
  • 差值同步：不发送完整状态，只发送自上次同步以来发生变化的部分（Delta Compression）。
  • 数据压缩：
    • 位压缩：用1个bit表示布尔值，用几个bit表示枚举状态。
    • 量化：将世界坐标从浮点数转换为相对于某个原点的定点数或短整数。比如，用ushort表示0-65535，对应地图0-655.35米，精度为0.01米，足够用。
    • 哈夫曼编码/算术编码：对频繁出现的值（如静止状态）用短码表示。

4.3 移动预测与客户端插值：掩盖网络的延迟

即使服务器同步频率达到20Hz，直接显示服务器状态也会显得卡顿。需要客户端做平滑处理。

1. 客户端预测：对于本地玩家操作（移动），客户端不等待服务器确认，立即在本地模拟移动，给予玩家即时反馈。之后收到服务器的权威位置时，再进行纠正（ Reconciliation）。如果纠正幅度不大，可以平滑地拉回；如果差异很大（可能是外挂或严重丢包），则可能需要强行纠正或特殊处理。
2. 服务器状态插值：对于其他玩家，客户端收到的是离散的快照。需要在两个快照之间进行插值。例如，在t1时刻收到位置P1，在t2时刻收到位置P2，那么在t1到t2之间，显示的位置应该是P1 + (P2 - P1) * ((currentTime - t1) / (t2 - t1))。为了对抗网络抖动，通常会引入一个小的延迟缓冲区（如100ms），让数据来得更平稳后再渲染，但这会增加显示延迟。

网络同步数据包结构示例（极度简化）：

// 一个单位的状态更新包 public struct UnitStateUpdate : INetworkMessage { public ushort UnitId; // 单位ID，2字节 public ushort X; // 量化后的X坐标，2字节 public ushort Y; // 量化后的Z坐标（Y通常为高度），2字节 public byte State; // 状态（低4位：移动/静止/攻击等，高4位：血量百分比），1字节 // 总计 7 字节/单位，相比发送三个float（12字节）和一堆状态，压缩了近一半。 }

5. 实战工程化：从Demo到稳定上线的完整链路

技术方案选好了，Demo也跑通了，但这距离一个能上线的稳定项目还差十万八千里。工程化是将技术落地为产品的关键。

5.1 性能分析与监控体系搭建

你不能优化你无法测量的东西。

• Unity Profiler是生命线：必须熟练掌握CPU、GPU、内存、渲染各模块的分析。重点关注：
  • CPU:MonoBehaviour.Update耗时、GC触发频率、物理计算、动画计算。
  • GPU: Draw Call数量、SetPass Calls、三角形数量、填充率、Shader处理耗时。
  • 内存: 纹理内存、网格内存、动画剪辑内存、托管堆大小。
• 自定义性能计数器：在代码关键路径（如ECS System、网络消息处理、渲染批次）插入计时器，将数据输出到屏幕或日志文件，形成内部的性能仪表盘。
• 线上监控：上线后，需要收集关键性能指标（FPS、发热、耗电、内存峰值）并上报。这能帮你发现特定机型或场景下的问题。

5.2 资源管理与内存控制

千人场景意味着海量的模型、纹理、动画资源。如何加载和卸载是门艺术。

• AssetBundle管理与分包策略：
  • 不能把所有角色资源打在一个AB包里。需要按职业、按品质、按功能进行精细拆分。
  • 实现资源的依赖分析和引用计数，确保无用的资源能被及时卸载。
  • 使用Addressable Assets System可以更优雅地管理异步加载和依赖。
• 对象池的极致使用：不仅仅是GameObject，包括网络消息对象、计算中间体（如List、数组）都应使用对象池，避免每帧分配。
• 纹理与网格的优化：
  • 纹理图集：将小纹理（如UI图标、角色头像）打包成图集，减少纹理切换。
  • 纹理压缩格式：针对Android（ASTC, ETC2）和iOS（PVRTC, ASTC）选择最优压缩格式。
  • 网格优化：减少面数，合理设置Mesh的Read/Write权限（关闭不必要的CPU读写）。

5.3 工具链支持：策划与美术的赋能

高性能架构往往对策划和美术不友好。你需要搭建工具链来弥合这个鸿沟。

• ECS/Data Authoring Tools：开发编辑器工具，让策划能在Inspector界面以类似配置GameObject的方式配置ECS实体的初始数据和Archetype。
• VAT烘焙工具：开发一键式工具，让美术提交FBX动画后，能自动烘焙生成顶点动画纹理和对应的Shader材质球。
• LOD生成工具：使用Unity的LOD Group或第三方工具（如Simplygon、Mesh Baker）自动生成模型的LOD层级和广告牌。
• 性能预算与检查工具：制定规则（如单个角色模型面数不超过3000三角面，骨骼数不超过30根），并开发自动化检查工具，在资源导入或打包时进行校验。

5.4 多线程与Job System的实战应用

即使不用完整的ECS，C# Job System也能大幅提升性能。

经典案例：群体移动与寻路传统方式是在Update中循环调用每个单位的NavMeshAgent的SetDestination和计算。在千人规模下这是灾难。 优化方案：

1. 将所有单位的目标位置收集到一个NativeArray中。
2. 将所有单位的当前位置和引用NavMeshAgent的NavMeshQuery所需数据准备好。
3. 创建一个IJobParallelFor作业，在子线程中并行执行寻路查询，将结果（路径角点或下一帧位置）输出到另一个NativeArray。
4. 在主线程中，将计算好的位置一次性应用给所有单位的Transform或ECS中的PositionComponent。

// 简化版并行位置更新Job示例 public struct UpdatePositionsJob : IJobParallelFor { public NativeArray<float3> Positions; public NativeArray<float3> Velocities; public float DeltaTime; public void Execute(int index) { Positions[index] += Velocities[index] * DeltaTime; } } // 主线程调度 void Update() { var job = new UpdatePositionsJob { Positions = _unitPositions, Velocities = _unitVelocities, DeltaTime = Time.deltaTime }; JobHandle handle = job.Schedule(_unitPositions.Length, 64); handle.Complete(); // 等待作业完成，或使用ScheduleBatchedJobs进行更复杂的调度 // 现在_positions中的数据已经更新 }

6. 常见“坑点”与排查实录

这条路布满荆棘，以下是我们趟过的一些典型深坑。

问题1：ECS中渲染代理同步导致GC Alloc。

• 现象：虽然ECS逻辑端没有GC，但帧分析器显示每帧仍有几KB的GC Alloc，来源不明。
• 排查：逐帧追踪，发现是在将ECS组件数据（如位置float3）复制到GameObject渲染代理的Transform.position（Vector3）时，发生了值类型到引用类型的装箱？不对，float3到Vector3是隐式转换，不产生GC。继续查，发现是用于管理代理关系的Dictionary的索引操作？最终发现，是在一个List<RenderProxy>.Add()操作中，因为List容量不足导致底层数组扩容，产生了GC Alloc。
• 解决：预先初始化足够大的List容量，或使用NativeArray/NativeList来管理代理索引关系。

问题2：GPU Instancing在部分Android机型上失效或闪烁。

• 现象：在Editor和iOS上正常，但在某些Android手机（特别是中低端机）上，实例化绘制不出来或闪烁。
• 排查：首先检查Shader是否支持移动端（#pragma target 3.0或更高）。然后检查单次提交的实例数量是否超过了该GPU的限制（通常是1023）。最后，发现是Shader中使用了UNITY_INSTANCING_BUFFER_START等宏，但在某些GLES2.0或特性集不全的设备上支持不好。
• 解决：编写Fallback Shader，在不支持GPU Instancing的设备上，回退到传统的多Draw Call绘制。通过SystemInfo.supportsInstancing进行运行时判断。

问题3：网络同步时，远处单位“抖动”或“闪现”。

• 现象：远处的非关键单位，移动时不是平滑的，而是隔一段时间“跳”一下。
• 排查：检查服务器同步频率和客户端插值算法。发现为了节省带宽，服务器对低优先级单位的同步频率降到了2Hz（每0.5秒一次）。而客户端的插值时间缓冲区设置过小（50ms），导致经常收不到足够新的数据来进行插值，只能在收到新数据时直接“跳变”。
• 解决：动态调整插值延迟。对于同步频率低的单位，适当增加客户端的插值延迟时间（例如增加到同步间隔的1.5倍），让插值有更充足的数据缓冲区，实现平滑。同时，在单位静止时，服务器可以停止同步其位置，由客户端保持静止状态。

问题4：千人同屏时手机发热严重，帧率随时间下降。

• 现象：场景刚加载时帧率尚可，运行几分钟后帧率明显下降，手机后背发烫。
• 排查：使用Profiler的Deep Profile模式，发现是每帧都有大量的MeshCollider的更新开销（虽然我们没用到物理碰撞）。原来是为了方便，很多角色模型都默认带了MeshCollider组件，且Cooking Options设置不当。Unity每帧会为激活的MeshCollider准备物理数据，即使你不进行物理模拟。
• 解决：
  1. 彻底检查场景中所有不必要的Collider，特别是MeshCollider，将其移除或替换为简单的BoxCollider。
  2. 对于大量单位，使用分层级的碰撞检测。例如，只对玩家和其附近的敌人启用精确碰撞（如胶囊体），对于远处的单位，仅使用简单的距离检测或格子检测。
  3. 在Unity Player Settings中，关闭不必要的物理模块更新。

实现千人同屏是一场持久战，它没有一劳永逸的解决方案，而是需要你在渲染、逻辑、网络、资源、工具等每一个环节持续地打磨和权衡。从选择正确的架构开始，到每一行代码的性能意识，再到面对真机时层出不穷的诡异问题，每一步都是对开发者综合能力的考验。但当你最终看到上千名玩家在手机屏幕上流畅激战的那一刻，所有的付出都是值得的。这条路，虽然艰难，但风景独好。