1. 项目概述：为什么Unity物理优化是性能攻坚的硬骨头

在Unity里做3D游戏，尤其是那些有大量动态物体、需要实时物理交互的项目，比如开放世界、RTS或者弹幕射击游戏，物理性能往往是第一个瓶颈。Unity内置的PhysX物理引擎虽然功能强大、稳定可靠，但它是一个黑盒，而且是为通用场景设计的。当你的游戏里同时有上千个物体在运动、碰撞时，CPU会瞬间被物理计算吃满，帧率骤降，玩家体验直接崩盘。这时候，很多开发者会本能地想到“换引擎”或者“降画质”，但其实，问题的核心往往在于碰撞检测这个最基础的环节。

传统的碰撞检测，比如Unity自带的Collider组件，每帧都在进行大量的包围盒计算、形状相交测试，这些计算本身就很重。更关键的是，PhysX的调用存在不小的开销，尤其是在大量物体频繁触发碰撞时。所以，我们今天的主题不是简单地调参，而是从底层算法和计算架构入手，进行一次“外科手术式”的优化：用分离轴定理（SAT）算法实现自定义的高精度碰撞检测，再借助Unity的Burst编译器和Job System，将计算并行化、向量化，榨干CPU的每一分性能。这不仅仅是写个算法，而是一套从理论到实践，从单线程到多线程，从通用计算到SIMD指令集优化的完整性能解决方案。如果你正在为游戏中的大量子弹、碎片、NPC的碰撞性能发愁，或者单纯想深入理解高性能物理计算的底层逻辑，那这篇实战总结就是为你准备的。

2. 核心思路拆解：Burst+SAT组合拳的威力与设计考量

为什么是Burst+SAT？这个组合不是凭空想出来的，而是针对Unity环境下高性能碰撞检测的痛点，经过权衡后的最优解之一。

首先看SAT算法。分离轴定理是处理凸多面体（包括AABB、OBB、胶囊体等）碰撞检测的经典算法。它的核心思想非常直观：如果两个凸体没有发生碰撞，那么必然存在一条直线（轴），能够将它们在直线上的投影完全分离开。我们只需要在一组有限的候选轴（通常是每个面的法线以及每条边的叉积方向）上进行投影和重叠测试即可。SAT的优势在于，对于规则几何体（如我们游戏中常见的方块、胶囊），它的计算量是可预测且相对较小的，并且能精确计算出碰撞的法线方向和穿透深度，这对于后续的物理响应（如反弹、滑动）至关重要。相比更复杂的GJK/EPA算法，SAT在实现难度和常见场景的性能上更有优势。

然后是Burst编译器。这是Unity DOTS（面向数据的技术栈）里的王牌。它能把C# Job代码编译成高度优化的原生机器码，特别是能充分利用现代CPU的SIMD（单指令多数据流）指令集。碰撞检测的本质是什么？是对大量顶点、边、面的向量运算（点积、叉积）。这些运算天然具有数据并行性——你可以同时对多个轴进行投影测试。用普通的C#写循环，CPU是一条一条算的；而经过Burst编译后，它可能一次性用一条指令处理四个轴（如果使用float4），性能提升是数量级的。

我们的设计思路就是：将SAT算法的核心计算步骤（投影轴生成、投影计算、重叠判断）封装进一个Burst Compiler Job里。利用Job System将场景中所有需要检测的物体数据（位置、旋转、顶点）转换成NativeArray这样的原生容器，然后调度多个Job并行处理不同物体对的碰撞检测。这样，我们既拥有了自定义算法的灵活性（可以针对游戏特定形状做优化），又获得了接近C++/原生代码的运行时效率，同时还能安全、方便地利用Unity主线程之外的多核CPU。

注意：这套方案主要适用于动态的、形状相对规则的物体间检测。对于静态环境（如地形），使用空间分割结构（如BVH树、网格）进行粗检测，再结合本方案进行精检测，是更完整的解决方案。本文聚焦于核心的碰撞检测算法优化。

3. 工具与准备：搭建Burst开发环境与数据准备

工欲善其事，必先利其器。要玩转Burst，你的Unity版本最好在2021.3 LTS或更新版本，并确保通过Package Manager安装了以下核心包：

• Burst： 这是主角，负责高性能编译。
• Collections： 提供NativeArray、NativeList等非托管容器，用于在Job中安全高效地传递数据。
• Mathematics： Unity官方的数学库，提供了float3、quaternion、float4x4等类型，它们针对Burst进行了深度优化，并且能生成更好的SIMD代码。务必使用这个库代替System.Numerics或UnityEngine自带的Vector3/Quaternion，这是性能的关键。

安装好后，在Player Settings的Other Settings里，确保Allow ‘unsafe’ Code是勾选的，因为一些底层优化可能会用到。

接下来是数据层面的准备。在传统的MonoBehaviour方式里，我们可能这样存一个立方体的数据：

public class SimpleCube : MonoBehaviour { public Vector3[] localVertices; public Vector3[] worldVertices; // 每帧更新 }

但在我们的高性能架构里，这行不通。我们需要面向数据的设计：

1. 定义组件数据：我们为每个可碰撞实体定义纯粹的数据结构。

   using Unity.Mathematics; public struct ColliderData { public float3 position; public quaternion rotation; public float3 scale; public int vertexStartIndex; // 指向顶点数组的起始位置 public int vertexCount; // 顶点数量 public int colliderType; // 0:立方体，1:胶囊体... }

2. 使用原生容器：在主线程或某个系统里，我们将所有实体的ColliderData收集到一个NativeArray<ColliderData>中。同样，所有实体的顶点数据（模型空间）也存储在一个大的NativeArray<float3>中。这种“数组化”的存储方式，能让CPU缓存命中率大幅提升，也是Burst Job高效处理的前提。
3. 计算世界顶点：在Job中，我们需要根据position,rotation,scale和本地顶点，实时计算世界空间的顶点。这个过程本身也可以并行化。我们会准备另一个NativeArray<float3>用于输出世界顶点。

实操心得：在项目初期，建议用一个MonoBehaviour脚本作为“数据收集器”和“调试查看器”。它负责在Update中从GameObject收集数据并填充到NativeArray，同时在OnDrawGizmos中可视化Job计算出的碰撞结果（比如画出碰撞法线）。这样既能保证性能架构，又不失调试的便利性。

4. SAT算法核心实现详解：从理论到可Burst编译的代码

理论说再多，不如一行代码。我们来实现一个能处理两个凸多面体（以立方体为例）的SAT检测Job。假设我们已经有了物体A和物体B的世界顶点数组。

4.1 生成候选分离轴

对于两个凸多面体，候选轴来自两者所有面的法线，以及所有边向量的两两叉积。对于立方体（由三角形面组成），我们可以简化：一个立方体有6个面，但法线只有3个独特的轴向（右、上、前）及其反向。两个立方体共有6个独特的面法线方向。此外，还需要考虑边叉积轴。立方体有12条边，但方向向量只有3个（右、上、前）。两个立方体的边组合，会产生3x3=9个可能的叉积方向（需归一化并去重）。所以，对于两个盒子，最多有6（面法线）+ 9（边叉积）= 15条候选轴。在实际编码中，我们可以预先计算好一个立方体的本地空间边向量和面法线，然后在Job中根据旋转进行变换。

// 在Job外部预计算一个单位立方体的本地边和面法线 public static readonly float3[] localFaceNormals = new float3[] { new float3(1, 0, 0), new float3(0, 1, 0), new float3(0, 0, 1), new float3(-1, 0, 0), new float3(0, -1, 0), new float3(0, 0, -1) }; public static readonly float3[] localEdges = new float3[] { math.right(), math.up(), math.forward() };

在Job内部，我们需要将本地轴变换到世界空间：

float3x3 rotationMatrix = math.float3x3(rotation); // 从四元数获取3x3旋转矩阵 for (int i = 0; i < localFaceNormals.Length; i++) { candidateAxes[axisIndex++] = math.mul(rotationMatrix, localFaceNormals[i]); } // 边向量同样需要变换

4.2 投影计算与重叠判断

这是SAT的核心循环。对于每一条候选轴：

1. 将物体A的所有顶点投影到该轴上，找出最小和最大投影值（minA,maxA）。
2. 对物体B做同样操作，得到minB,maxB。
3. 判断两个区间是否重叠。如果maxA < minB或maxB < minA，则在此轴上分离，立即返回“未碰撞”。
4. 如果所有轴都未分离，则发生碰撞。在遍历过程中，还可以记录下重叠深度最小的那条轴，作为碰撞法线方向。

投影计算本质是点积：projection = math.dot(vertex, axis)。寻找最小最大值是一个典型的规约操作，非常适合用Burst进行循环展开和SIMD优化。

// 在Job中计算一个物体在某一轴上的投影范围 float minProj = float.MaxValue; float maxProj = float.MinValue; for (int i = 0; i < vertices.Length; i++) { float proj = math.dot(vertices[i], axis); minProj = math.min(minProj, proj); maxProj = math.max(maxProj, proj); }

4.3 整合成Burst Job

现在，我们把上述步骤整合到一个IJobParallelFor中。IJobParallelFor允许我们对一个数组的每个元素并行执行任务。在这里，我们可以把“需要检测的物体对”作为一个数组。例如，我们有N个物体，需要两两检测，那么就有N*(N-1)/2对。我们可以创建一个包含所有物体对索引的NativeArray，然后并行执行SAT检测。

[BurstCompile] public struct SATCollisionJob : IJobParallelFor { [ReadOnly] public NativeArray<float3> allWorldVertices; [ReadOnly] public NativeArray<ColliderData> collidersData; [ReadOnly] public NativeArray<int2> collisionPairs; // 存储需要检测的物体对索引 (indexA, indexB) public NativeArray<CollisionResult> results; // 输出结果，每个物体对一个结果 public void Execute(int index) { int2 pair = collisionPairs[index]; ColliderData aData = collidersData[pair.x]; ColliderData bData = collidersData[pair.y]; // 1. 获取物体A和B的世界顶点切片 // 2. 生成候选轴（基于aData.rotation和bData.rotation） // 3. SAT核心循环 // 4. 将结果（是否碰撞，碰撞法线，穿透深度）写入results[index] } } public struct CollisionResult { public bool isColliding; public float3 normal; public float depth; }

在主线程中，调度这个Job：

// 假设已经填充好了collidersData, allWorldVertices, collisionPairs var job = new SATCollisionJob { ... }; JobHandle handle = job.Schedule(collisionPairs.Length, 64); // 64是每批处理大小 handle.Complete(); // 或者用JobHandle.ScheduleBatchedJobs和依赖关系管理 // 完成后，从results中读取碰撞信息

注意事项：IJobParallelFor要求Job内部是线程安全的，不能写入共享数据。我们的设计让每个Job只写入results中自己独有的索引位置，这是安全的。另外，Schedule时的innerLoopBatchCount参数（这里设为64）需要微调，太小会导致调度开销大，太大会导致负载不均。通常从32或64开始测试。

5. 性能优化进阶：SIMD、批处理与空间分割

基础版本已经能跑了，但追求极致性能，我们还得深挖。

5.1 利用Mathematics库与SIMD

Unity.Mathematics中的float3、float4等类型，在Burst编译下会自动尝试生成SIMD指令。但我们可以更主动一些。例如，在计算投影最小最大值时，可以手动使用float4进行小规模向量化。

假设我们一次处理4个顶点（要求顶点数是4的倍数，不足可以补零）：

int simdLength = vertices.Length / 4 * 4; float4 minProj4 = new float4(float.MaxValue); float4 maxProj4 = new float4(float.MinValue); float4 axis4 = new float4(axis.x, axis.y, axis.z, 0); // 注意对齐 for (int i = 0; i < simdLength; i += 4) { // 假设vertices是float3的数组，需要手动打包成float4x3来模拟SIMD加载 // 这里是一个简化示例，实际加载需要根据内存布局调整 float4x4 vBlock = ... // 从vertices加载4个float3，并补成一个float4x4 // 计算点积（这里需要更复杂的SIMD点积运算，可能需调用math.dot） // ... } // 最后从minProj4和maxProj4中规约出最终的min和max

注意：手动SIMD优化代码会变得复杂且难以维护，除非性能分析器（Profiler）明确显示这里是热点，否则建议优先信任Burst对普通循环的优化。使用Mathematics库和简单的循环，Burst通常已经能做得很好。

5.2 粗检测与批处理（Broad Phase）

对所有物体进行两两检测（O(N²)复杂度）是不可持续的。我们必须引入**粗检测（Broad Phase）**来快速筛选出可能碰撞的物体对，只对这些候选对进行SAT精检测（Narrow Phase）。

最常用的粗检测是基于网格的空间分割（Spatial Grid）或动态包围盒层次结构（Dynamic BVH）。这里以简单的均匀网格为例：

1. 将世界空间划分为固定大小的网格单元。
2. 每一帧，根据物体的包围盒（AABB），将其ID添加到它覆盖的所有网格单元的列表中。
3. 同一个网格单元内的物体，才需要进行两两精检测。

这个“更新网格”和“生成碰撞对”的过程，同样可以用Job并行化。例如，一个Job并行计算所有物体的网格范围，另一个Job并行处理每个网格单元内的物体配对。这能极大减少传入SAT Job的collisionPairs数量。

5.3 数据布局与内存访问优化

对于Burst Job，内存访问模式至关重要。尽量确保Job顺序访问NativeArray，这样可以最大化缓存利用率。避免在Job内部进行随机访问或间接查找。

在我们的设计中，allWorldVertices是一个所有顶点顺序存储的大数组，ColliderData中的vertexStartIndex提供了直接偏移量，这是高效的。如果碰撞检测需要物体的其他属性（如速度、质量），也应该以NativeArray的形式提供，并确保与ColliderData的顺序一致（即相同索引代表同一个实体）。

6. 实战集成与调试：在Unity中组装与验证

理论算法和独立Job都准备好了，现在需要把它们集成到Unity的游戏循环中，并确保结果正确。

6.1 构建一个碰撞检测系统

我们可以创建一个MonoBehaviour（如HighPerformanceCollisionSystem）来管理整个流程：

public class HighPerformanceCollisionSystem : MonoBehaviour { private NativeArray<ColliderData> m_ColliderDataArray; private NativeArray<float3> m_WorldVerticesArray; private NativeList<int2> m_CollisionPairs; // 使用List因为数量可变 private NativeArray<CollisionResult> m_Results; private List<IColliderEntity> m_ManagedEntities = new List<IColliderEntity>(); void Update() { // 1. 从所有IColliderEntity收集数据，填充m_ColliderDataArray和本地顶点缓存 // 2. 调度一个Job（CalculateWorldVerticesJob）计算所有顶点的世界坐标，写入m_WorldVerticesArray // 3. 调度粗检测Job（如SpatialGridJob），生成潜在的碰撞对，填入m_CollisionPairs // 4. 调度SATCollisionJob，传入m_CollisionPairs，输出到m_Results // 5. 等待所有Job完成（使用JobHandle.CombineDependencies和Complete） // 6. 遍历m_Results，将碰撞信息反馈给对应的实体（例如，调用实体上的OnCollision方法） } void OnDestroy() { // 务必释放所有Native容器，避免内存泄漏！ if (m_ColliderDataArray.IsCreated) m_ColliderDataArray.Dispose(); // ... 释放其他容器 } }

6.2 调试与可视化

物理调试，眼见为实。在OnDrawGizmos或OnDrawGizmosSelected中，我们可以绘制：

• 物体的包围盒（AABB）：用于验证粗检测。
• SAT检测出的碰撞点与法线：在发生碰撞的位置画一条红线表示法线方向。
• 候选分离轴（可选）：可以短暂绘制用于理解算法过程。

void OnDrawGizmos() { if (!Application.isPlaying) return; for (int i = 0; i < m_Results.Length; i++) { if (m_Results[i].isColliding) { // 简单起见，取两个物体的中心点连线的中点作为碰撞点 int2 pair = m_CollisionPairs[i]; float3 posA = m_ColliderDataArray[pair.x].position; float3 posB = m_ColliderDataArray[pair.y].position; float3 collisionPoint = (posA + posB) * 0.5f; Gizmos.color = Color.red; Gizmos.DrawLine(collisionPoint, collisionPoint + m_Results[i].normal); } } }

6.3 性能分析与对比

集成完毕后，打开Unity Profiler（特别是Deep Profile模式），观察：

1. 主线程耗时：你的Update中，除了调度和完成Job，应该几乎没有计算开销。
2. Worker线程耗时：你会看到多个线程在执行你的Burst Job。这是性能提升的直接体现。
3. GC Alloc：由于大量使用NativeContainer，每帧的GC分配应该极低（理想情况是0）。
4. 与Physics.Raycast或传统Collider对比：设计一个压力测试场景，生成数千个运动物体。分别用传统物理系统和你的自定义系统跑一下，用Profiler对比CPU耗时和帧率。在物体数量多时，Burst+SAT方案的优势会非常明显。

7. 常见问题、排查与扩展方向

在实际操作中，你肯定会遇到各种问题。这里记录一些典型的坑和解决思路。

7.1 Burst Job编译失败或运行错误

• 错误：“Burst does not support calling methods on reference types”原因：Burst Job中不能直接调用托管对象（非NativeContainer）的方法或访问其字段。解决：将所有需要的数据以值类型（struct）或NativeContainer的形式传入Job。确保Job结构体中的字段都是blittable类型（如基本数值类型、其他结构体、NativeArray等）。

• 错误：访问NativeArray越界原因：vertexStartIndex或vertexCount计算错误，导致在allWorldVertices中访问了无效索引。解决：在填充数据时增加边界检查。在Job内部，虽然为了性能可能不做检查，但在调试阶段可以用[NativeDisableContainerSafetyRestriction]暂时关闭安全检查，配合[Conditional("ENABLE_UNITY_COLLECTIONS_CHECKS")]编写自己的调试断言。

• 性能提升不明显原因1：数据量太小。Burst和Job System的威力在成千上万的实体上才能充分体现。原因2：粗检测缺失或低效。如果仍然进行O(N²)的精检测，SAT再快也扛不住。原因3：Job内部有分支或数据依赖严重，阻碍了SIMD优化。尽量让循环内部逻辑简单、统一。排查：使用Profiler的Burst编译视图，查看生成的汇编代码，分析热点循环。确保关键循环内的代码是“Burst友好”的。

7.2 算法精度与特殊形状处理

• 浮点数精度问题：在判断投影重叠时，使用一个很小的容差（epsilon），例如1e-5f，来避免因浮点误差导致的误判。

  if (maxA < minB - epsilon || maxB < minA - epsilon) { return false; // 分离 }

• 处理非凸形状：SAT只保证对凸多面体有效。对于凹物体，需要先将其分解为多个凸体（凸分解，Convex Decomposition），然后分别检测。这属于更高级的主题，可以考虑使用第三方库或工具进行预处理。

• 扩展其他形状：本文以立方体为例。对于球体、胶囊体，SAT算法可以简化。球体只需要判断中心距离和半径之和。胶囊体可以转化为线段与球体的检测。你需要为每种形状实现一个特定的GetSupportPoint函数（用于在给定方向上获取最远的点），这是实现GJK/EPA算法的通用接口，但用SAT特化实现通常更快。

7.3 系统扩展与生产环境建议

• 与Unity Physics共存：你的自定义系统可以完全替代简单物体的物理，但对于复杂的角色控制器、布料、车辆等，可能仍需依赖PhysX。可以让两者共存，用你的系统处理大量简单动态物（子弹、碎片），用PhysX处理复杂主体。

• 添加碰撞响应：检测到碰撞后，通常需要处理响应（反弹、摩擦、伤害计算）。这部分逻辑可以放在主线程，根据CollisionResult进行计算。更极致的做法是将响应也Job化，但这需要更复杂的数据流设计。

• 对象池与数据重用：对于频繁创建销毁的物体（如子弹），使用对象池管理其ColliderData在NativeArray中的位置，避免每帧都重新分配和整理数组，这能进一步减少开销。

• 使用Entities (ECS)：如果你已经在使用或考虑使用Unity的ECS架构，那么这套思路可以无缝迁移。ColliderData变成IComponentData，Job变成ISystem的一部分，数据管理由EntityManager负责，架构会更加清晰和高效。本文的很多概念（Burst, NativeArray）正是ECS的核心。

这套Burst+SAT的方案，本质上是一种“性能换控制权”的思路。你放弃了PhysX的一些便利性和高级功能（如连续碰撞检测CCD、复杂的关节），换来了对特定场景的、极致优化的计算能力。在需要处理海量单位碰撞的游戏里，这种交换往往是值得的。它要求你对数据、内存、并行计算有更深的理解，但带来的性能提升和解决问题的满足感，也是巨大的。