OpenGL顶点批处理：选固定上限Array还是ArrayList？

这问题在游戏渲染优化里太常见了——尤其是处理动态数量的物体时，既要兼顾draw call合并的性能，又不想浪费内存。我来结合实际开发经验给你拆解下：

先明确两种方案的核心Trade-off #

固定大小Array #

• 优势：连续内存布局对GPU缓存极其友好，没有扩容、复制的额外开销，渲染时的性能表现拉满。如果你的场景顶点数波动极小，这绝对是最优解。
• 劣势：内存浪费是硬伤——如果设的上限远大于实际需求（比如你设了10000顶点，但大部分场景只用1000），闲置的内存会在内存紧张的移动平台拖后腿；更糟的是，如果实际顶点数超过上限，你要么被迫拆分draw call（失去批处理意义），要么处理溢出逻辑，反而增加复杂度。

ArrayList（动态数组） #

• 优势：内存利用率高，完全不用预先猜大小，自动扩容机制能适配动态变化的顶点数量。对于procedural生成、随机刷怪这类顶点数完全不可控的场景，灵活性拉满。
• 劣势：扩容时会有性能开销——当数组满了，底层会重新分配一块更大的内存（通常是原大小的1.5-2倍），然后把旧数据复制过去。如果这个过程发生在渲染帧内，频繁扩容可能导致帧时间波动，甚至掉帧。

实际开发中的最优折中方案 #

别纠结二选一，结合场景用混合策略才是王道：

• 预设合理初始容量的动态数组
  先统计你的游戏中90%以上场景的顶点总数，把这个值设为ArrayList的初始容量。比如你统计下来大部分场景批处理顶点在5000左右，就把初始容量设为6000——这样既避免了初始内存浪费，又能大幅减少扩容次数（甚至大部分场景不会触发扩容）。以C#的List<Vector3>为例，初始化时指定new List<Vector3>(6000)就行，性能和固定Array几乎没差别，还保留了动态扩容的兜底能力。

• 渲染前预计算顶点总数
  如果你的物体都缓存了自身的顶点数（比如每个可批处理对象都有VertexCount属性），可以在每帧渲染前先遍历待批处理的物体，把顶点总数加起来，然后创建刚好大小的固定Array。这种方法完全没有内存浪费，也没有ArrayList的扩容开销，唯一的额外成本是一次遍历求和——和渲染的开销比起来，这点计算量几乎可以忽略。

• 顶点数组对象池
  如果你游戏里的批处理场景是重复出现的（比如不同关卡的敌人集群、道具堆），可以预先创建几个不同规格的顶点数组池（比如小容量：1000，中容量：5000，大容量：10000）。每次需要批处理时，根据预估的顶点数从池里取合适的数组，用完放回。这种方法既避免了频繁创建销毁数组的开销，又能灵活适配不同的顶点数量需求。

额外提醒 #

其实很多主流引擎（比如Unity、Unreal）已经内置了成熟的动态批处理机制，如果你是自己实现底层渲染逻辑，还要注意：

• 顶点数据的格式（比如是否使用 interleaved 布局）对性能的影响，比Array/ArrayList的选择更大；
• 移动平台优先考虑内存利用率，PC平台可以适当偏向固定Array的性能优势；
• 如果顶点数波动极大（比如从100到100000），可以考虑分批次处理——超过某个阈值就拆分draw call，避免单个数组过大导致的内存压力。

内容的提问来源于stack exchange，提问作者Vignesh Gunasekaran