首页/资讯中心/详情

Unity开发中List＜T＞与数组的性能对比与实战选择策略

Unity开发中List＜T＞与数组的性能对比与实战选择策略
📅 发布时间：2026/7/9 20:53:18

1. 项目概述：为什么Unity开发者必须精通List 与数组

在Unity游戏开发中，数据集合的管理是代码的基石。无论是管理场景中的敌人列表、玩家的背包物品、技能冷却队列，还是网络消息的缓存，你几乎每天都在和集合打交道。C#提供了两种最核心的线性集合：传统的数组（T[]）和动态列表（List<T>）。很多新手开发者，甚至一些有经验的同行，在面对“用数组还是用List？”这个问题时，常常凭感觉选择，这往往会导致后续的性能瓶颈、内存浪费或代码僵化。

我自己在早期项目里就踩过不少坑：用数组管理动态变化的敌人列表，结果频繁地new数组导致GC（垃圾回收）压力剧增；或者在不必要的地方使用List<T>，因为其自动扩容的特性，在频繁增删的高频循环中带来了不必要的开销。这篇文章，我就结合十多年Unity开发中积累的血泪教训，为你彻底拆解List<T>和数组，并给出在不同场景下的黄金选择法则。这不仅仅是语法学习，更是关乎游戏性能、内存管理和代码架构的实战决策。

2. 核心概念解析：数组与List 的本质区别

要做出正确选择，首先必须理解两者的底层实现和设计哲学。这就像选择交通工具：数组是固定座位的班车，而List<T>是能加挂车厢的火车。

2.1 数组（T[]）：简单、直接、高效的连续内存块

数组是C#中最基础的数据结构。当你声明int[] scores = new int[10];时，你就在托管堆上申请了一块连续的内存空间，足以容纳10个整数。这块空间的大小在创建时就确定了。

核心特性：

  • 固定长度：创建后，其长度（Length）不可改变。这是它最核心的限制，也是其性能优势的来源。
  • 连续内存：所有元素在内存中紧密排列。这意味着通过索引访问元素（如scores[5]）是极其快速的，因为CPU可以通过“基地址 + 索引 * 元素大小”直接计算出内存地址，这是一个O(1)操作。
  • 内存布局紧凑：没有额外的对象开销。一个int[100]的数组，其内存占用基本就是100 * sizeof(int)加上极少的数组头信息。

在Unity中，数组常用于存储那些在生命周期内数量确定的数据。例如，一个关卡中预先设计好的出生点坐标（Vector3[] spawnPoints）、一个角色固定数量的技能槽（Skill[] skillSlots），或者一个网格的顶点数据（Vector3[] vertices）。因为这些数据在运行时通常不会增减，数组的固定性不再是缺点，反而成了保证内存局部性和访问速度的优点。

2.2 List ：基于数组的动态封装器

List<T>本质上是对数组的一个智能包装。查看其源码（或参考官方文档）可知，它内部维护了一个私有数组（private T[] _items）和一个表示当前元素数量的整数（private int _size）。

核心工作机制：

  1. 初始化：当你new List<int>()时，它内部会创建一个默认容量（例如4）的数组。
  2. 添加元素（Add）：检查当前元素数量（_size）是否小于内部数组容量（_items.Length）。如果是，直接放入；如果满了，则触发“扩容”（EnsureCapacity）。
  3. 扩容操作：这是List<T>的关键行为。它会创建一个新的、更大的数组（通常是原容量的2倍），然后将旧数组的所有元素复制到新数组中，最后用新数组替换旧数组。这个操作有性能开销（O(n)）并会产生垃圾（旧的数组对象）。

与ArrayList的对比：List<T>是ArrayList的泛型版本。ArrayList存储的是object类型，这意味着存入值类型（如int）会发生“装箱”（Boxing），读取时发生“拆箱”（Unboxing），带来额外的性能损耗和类型安全隐患。List<T>在编译时即确定类型，完全避免了装箱拆箱，是类型安全且高性能的现代选择。

所以，你可以把List<T>理解为一个“会自己长大的数组”。它提供了类似数组的索引访问（list[5]），但背后多了一层逻辑来管理这个动态大小的数组。

3. 性能与内存深度剖析：微观视角下的成本

选择数据结构，本质是在时间（性能）和空间（内存）之间做权衡。下面我们深入到CPU和内存层面来分析。

3.1 访问速度：数组略胜一筹

对于纯粹的随机读取和写入，数组通常比List<T>有微弱的优势，因为List<T>的索引器内部多了一次对数组引用的跳转和边界检查（虽然现代JIT优化后差距极小）。

// 基准测试示例（概念性代码） int[] array = new int[1000000]; List<int> list = new List<int>(array); // 预分配相同大小 // 数组访问 for (int i = 0; i < array.Length; i++) { int value = array[i]; // 直接内存偏移访问 } // List访问 for (int i = 0; i < list.Count; i++) { int value = list[i]; // 内部调用：_items[i]，并检查 i < _size }

在实际Unity项目中，这种差异在绝大多数业务逻辑中可忽略不计。但在每帧执行数万次的核心循环（如粒子系统更新、密集的物理查询、高频网络包处理）中，积少成多，使用数组可能带来可观的性能提升。

3.2 内存占用：数组更紧凑，List有开销

  • 数组：内存占用 ≈数组头信息 + 元素数量 * 每个元素大小。极其紧凑。
  • List：内存占用 ≈List对象头 + 内部数组引用 + _size等字段 + 内部数组本身。内部数组的容量（Capacity）通常大于实际元素数量（Count），这会造成一定的内存浪费。

例如，一个List<int>当前有5个元素（Count=5），但其内部数组容量可能是8（这是典型的扩容策略结果）。那么就有3个int（12字节）的空间被预留但未使用。

关键技巧：使用TrimExcess()如果你确定一个List<T>不会再增加内容，可以调用list.TrimExcess()。这个方法会尝试将内部数组的容量缩减到与实际元素数量接近（并非精确等于，出于性能考虑）。这在处理完一批数据（如加载完所有关卡配置）后调用，可以回收多余的内存。

3.3 扩容成本：List 的主要性能陷阱

List<T>最昂贵的操作就是扩容。每次扩容都涉及：

  1. 分配一块新的、更大的内存。
  2. 将旧数据全部复制到新内存。
  3. 旧数组变为垃圾，等待GC回收。

如果频繁地Add元素导致多次扩容，对性能的冲击是显著的，尤其是在移动设备上。

实战优化：预分配容量（Capacity）这是使用List<T>时最重要的性能优化手段。如果你能预估或大致知道集合最终会包含多少元素，在创建List<T>时或提前设置其Capacity属性。

// 糟糕的做法：让List自己慢慢扩容 List<Enemy> enemies = new List<Enemy>(); for (int i = 0; i < 1000; i++) { enemies.Add(new Enemy()); // 可能触发多次扩容：4 -> 8 -> 16 -> 32 -> ... -> 1024 } // 优秀的做法：预分配 int expectedEnemyCount = 1000; List<Enemy> enemies = new List<Enemy>(expectedEnemyCount); // 一次性分配足够空间 for (int i = 0; i < expectedEnemyCount; i++) { enemies.Add(new Enemy()); // 无扩容，直接赋值 }

在Unity中，很多场景可以预估：一局游戏的最大玩家数、一个UI界面同时显示的最大物品数、从资源文件加载的配置项数量等。养成预分配的习惯，能有效避免运行时卡顿。

3.4 增删元素：List在中间操作的劣势

  • 在末尾添加/删除（Add/RemoveAt(lastIndex)）：List<T>效率很高，接近O(1)。
  • 在开头或中间插入/删除（Insert/RemoveAt）：这是List<T>的弱点。因为数组是连续的，在位置i插入一个元素，需要将i之后的所有元素都向后移动一位。这是一个O(n)操作。删除同理。

如果你的业务需要频繁地在集合头部或中部进行增删（例如一个按优先级实时排序的任务队列），List<T>可能不是最佳选择。这时可以考虑LinkedList<T>（链表），但链表的内存局部性差，遍历慢，需要根据具体访问模式权衡。

4. Unity实战场景下的选择策略

理论结合实践，下面我们看几个Unity开发中的典型场景，并做出具体的选择分析。

4.1 场景一：管理游戏实体（如敌人、子弹）

典型需求：数量动态变化，频繁地生成（Add）和销毁（Remove）。

public class EnemyManager : MonoBehaviour { // 选择 List<T> private List<Enemy> _activeEnemies = new List<Enemy>(); void SpawnEnemy() { var enemy = Instantiate(enemyPrefab); _activeEnemies.Add(enemy); // 末尾添加，高效 } void OnEnemyDied(Enemy enemy) { int index = _activeEnemies.IndexOf(enemy); // 查找可能慢，但通常死亡频率低于每帧 if (index >= 0) { _activeEnemies.RemoveAt(index); // 删除，可能需要移动元素 // 优化技巧：如果顺序不重要，可以用“交换后移除末尾法” // _activeEnemies[index] = _activeEnemies[_activeEnemies.Count - 1]; // _activeEnemies.RemoveAt(_activeEnemies.Count - 1); } } void Update() { // 每帧遍历所有敌人 for (int i = 0; i < _activeEnemies.Count; i++) { // 使用Count，而不是遍历内部数组 _activeEnemies[i].UpdateAI(); } } }

选择理由与技巧：

  • 选择List<T>：因为敌人数量动态变化，数组的固定长度是硬伤。
  • 预分配：根据关卡设计，预估最大敌人数量并设置Capacity，避免运行时扩容。
  • 删除优化：如果敌人顺序不重要（例如，不需要按生成顺序渲染或处理），在删除时，可以将要删除的元素与末尾元素交换，然后RemoveAt末尾，这样可以将O(n)操作降为O(1)。但要注意更新任何依赖于索引的引用。

4.2 场景二：配置数据或静态引用

典型需求：在Awake或Start中加载，之后在整个游戏过程中只读，不增删。

public class WeaponDatabase : MonoBehaviour { // 选择数组 T[] [SerializeField] private WeaponConfig[] _allWeaponConfigs; // 在Inspector中直接拖拽赋值 // 或者从Resources加载 void Awake() { _allWeaponConfigs = Resources.LoadAll<WeaponConfig>("Weapons/"); // Resources.LoadAll 返回的就是数组，直接使用即可。 } public WeaponConfig GetWeaponById(string id) { // 线性查找，因为配置量不大。如果量大，应使用Dictionary缓存。 foreach (var config in _allWeaponConfigs) { if (config.Id == id) return config; } return null; } }

选择理由：

  • 选择数组：数据是静态的、只读的。数组的内存效率更高，访问速度最快，且语义清晰（表示一个固定集合）。
  • Inspector友好：Unity编辑器对数组有很好的序列化支持，方便在Inspector中编辑。
  • 无管理开销：没有List<T>的Capacity和动态扩容的逻辑开销。

4.3 场景三：与Unity API交互（如GetComponents, Physics.SphereCastAll）

许多Unity API返回的是数组，这是出于性能考虑。直接使用这些返回值，还是转换为List<T>，需要判断。

void FindNearbyEnemies() { // Unity API 返回数组 Collider[] hitColliders = Physics.OverlapSphere(transform.position, 10f, enemyLayerMask); // 情况A：仅做一次遍历和读取 foreach (var collider in hitColliders) { // 直接使用数组，避免任何转换开销。这是最佳实践。 } // 情况B：需要对结果集进行频繁的增删改查 // 例如，需要过滤、排序，或后续动态添加新发现的敌人 List<Collider> enemyList = new List<Collider>(hitColliders); // 一次性复制构造 enemyList.RemoveAll(c => !c.GetComponent<Enemy>().IsAlive()); // 使用List的便捷方法 enemyList.Sort((a,b) => ... ); // 排序 // ... 后续操作 }

选择策略：

  • 如果只是遍历和读取：永远直接使用返回的数组。任何ToList()或new List<>(array)都会产生一个全新的集合和内存分配。
  • 如果需要修改集合：将数组转换为List<T>是合理的。使用new List<T>(array)构造函数效率很高，因为它会直接将数组作为内部存储（前提是你后续不会修改原数组）。

4.4 场景四：高频更新循环（如粒子、网格顶点）

典型需求：每帧对大量数据进行完全遍历和计算，数据量基本稳定。

public class ParticleSystemCustom { private Vector3[] _particlePositions; // 使用数组 private const int MAX_PARTICLES = 10000; void Start() { _particlePositions = new Vector3[MAX_PARTICLES]; // 初始化... } void Update() { // 每帧更新所有粒子位置 for (int i = 0; i < _activeParticleCount; i++) { // 手动维护有效数量 _particlePositions[i] += CalculateVelocity(i) * Time.deltaTime; } // 将数组数据直接传递给Mesh或Graphics.DrawProcedural UpdateMesh(_particlePositions); } }

选择理由：

  • 选择数组：在图形、粒子、物理等底层系统中，性能要求极高。数组提供了极致的遍历速度和最小的内存开销。你需要手动维护一个有效计数（_activeParticleCount）来模拟“动态大小”，虽然增加了代码复杂度，但换来了性能的极致优化。

5. 高级技巧与常见陷阱

5.1 使用Span<T>和Memory<T>进行零开销切片

在C# 7.2及以上版本（对应较新的Unity版本和.NET标准），对于数组或List<T>的内部数据，可以使用Span<T>进行安全且高性能的切片操作，避免分配新的数组或列表。

int[] bigArray = new int[1000]; // 获取第100到199个元素的切片（零拷贝） Span<int> slice = bigArray.AsSpan(100, 100); ProcessSlice(slice); // 可以像数组一样使用slice // 对List<T>也可以（但注意，如果List扩容导致内部数组重建，span会失效） List<int> bigList = new List<int>(bigArray); Span<int> listSlice = CollectionsMarshal.AsSpan(bigList).Slice(100, 100);

这在处理大型数据块（如网络包、文件二进制数据）时非常有用，但需注意生命周期管理。

5.2 避免在热循环中使用foreach（对List）

对于List<T>，foreach循环会生成一个枚举器对象，带来微小的GC分配。在每帧运行数万次的循环中，这会导致持续的GC压力。

// 有轻微GC分配 (对于值类型List，如果编译器未优化) foreach (var enemy in enemyList) { enemy.Update(); } // 无GC分配，性能更优 for (int i = 0; i < enemyList.Count; i++) { enemyList[i].Update(); }

对于数组，现代C#编译器通常能优化foreach为简单的for循环，但为了代码风格统一和绝对安全，在性能关键的循环中，我习惯使用for循环。

5.3List<T>.ToArray()的时机

当你需要将List<T>传递给一个只接受数组的API，或者需要一份不会被修改的快照时，需要调用ToArray()。记住，这会创建一个新的数组，并复制所有元素。

List<Player> playerList = GetPlayerList(); // 情景：需要一个固定快照用于序列化或线程安全访问 Player[] playerSnapshot = playerList.ToArray(); // 现在修改playerList不会影响playerSnapshot

不要在每帧或高频调用的代码中随意使用ToArray()，不必要的内存分配和复制是性能杀手。

5.4 容量（Capacity）与计数（Count）的混淆

这是一个常见的错误：

List<int> list = new List<int>(100); // 设置初始容量为100 Debug.Log(list.Count); // 输出 0， 因为还没有添加任何元素！

Capacity是内部数组的大小，Count是实际存储的元素数量。在遍历时，一定要用for (int i = 0; i < list.Count; i++)，而不是i < list.Capacity，否则会访问到未初始化的内存区域，导致未定义行为。

6. 决策流程图与总结

为了让你在项目中能快速做出选择，我总结了一个简单的决策流程图：

开始 | v 集合大小是否在编译时或初始化时就完全确定，且永不改变？ |是 |否 v v 使用数组 T[] 需要频繁在任意位置插入或删除元素？ | |是 |否 | v v | 考虑 LinkedList<T> 或 预估集合的大致最大容量？ | Queue/Stack等专用集合 |是 |否 | v v | 使用 List<T>(capacity) 使用 List<T>() | 进行预分配 | v 结束

最终的个人建议：

  1. 默认首选List<T>：在大多数游戏逻辑开发中，数据的动态性使得List<T>是更安全、更灵活的选择。只要记得用好预分配容量（Capacity），其性能表现对于90%的场景都是足够的。
  2. 当性能是绝对关键时选择数组：在渲染管线、自定义粒子系统、网络层缓冲区、以及任何每帧处理海量数据的底层系统中，优先使用数组，并手动管理生命周期。
  3. 拥抱混合模式：不要非此即彼。一个优秀的系统可能同时使用两者：用List<T>管理动态的游戏对象引用，用数组（或NativeArray）存储需要传递给Job System或GPU的纯数据。
  4. Profile, Profile, Profile!（性能分析）：不要盲目猜测。Unity Profiler是你的最佳伙伴。当你怀疑集合操作成为瓶颈时，用Profiler验证，用数据说话。将List<T>替换为数组是否真的带来了可观的帧率提升？只有分析结果能给你答案。

理解List<T>和数组的差异，并能在具体场景中做出明智的选择，是区分初级和中级C#/Unity开发者的一个重要标志。希望这篇结合了大量实战经验的分析，能帮助你写出更高效、更健壮的代码。记住，没有银弹，只有最合适的工具。