解读

面试官抛出该题，核心想验证三件事：

1. 你是否真的用Burst跑过性能敏感代码，还是只停留在“听过”；
2. 能否把值类型内存布局与SIMD硬件特征对应起来，说出为什么而不是背结论；
3. 面对国内项目常见的“热更新+Burst”混合场景，能否给出可落地的约束规范，而不是空谈理论。
   答不到“对齐、连续、无托管引用”三要素，基本会被判定为“纸上谈兵”。

知识点

1. Burst 的向量化前提：IL 被转成 LLVM IR 后，只有blittable且布局确定的值类型才能生成 llvm.vector 指令；任何托管引用、接口、自动布局都会直接阻断。
2. 内存布局三兄弟：
   • 对齐：ARM NEON 要求 16 byte，x86 AVX2 要求 32 byte；Burst 会在结构体外层加 AlignAttribute，但字段内部错位仍会导致 pack 失败。
   • 连续：数组必须保证 T[] 或 NativeArray<T> 在物理地址连续；链表、切片、跳跃索引都会让编译器放弃向量化。
   • 无托管引用：字段里一旦出现 string、object、delegate，整个类型被标记为 __managed，SIMD 直接归零。
3. 国内实战坑点：
   • 热更新 DLL 里定义的结构体，因为元数据不在 Burst 编译期可见，会被当成 __managed；必须在主工程里用预编译静态库或生成代码提前固化。
   • 策划配置的 Excel 转 ScriptableObject，经常把 bool 塞成 int，导致位宽不对齐；要在导出管线里强制做4-byte 对齐归一化。
4. 诊断工具链：
   • Burst Inspector（菜单 Jobs > Burst Inspector）可查看是否生成 vector.* 指令；
   • Unity Profiler 的 Burst 标记项能看到 SIMD Width 列，0 即失败；
   • 代码层用 #if ENABLE_UNITY_COLLECTIONS_CHECKS 下的 BurstCompiler.Log 打印 StructLayout 诊断日志。

答案

值类型对 Burst 的 SIMD 向量化起决定性作用，只有同时满足“可 blit、布局显式对齐、无托管字段”的值类型才能生成向量指令。具体而言：

1. 用 struct 并标记 [StructLayout(LayoutKind.Sequential)] 或 LayoutKind.Explicit，配合 [FieldOffset] 保证字段首地址 16/32 byte 对齐；
2. 数组形态必须是 NativeArray<MyStruct> 或 T[]，且 MyStruct 内不含任何引用类型，长度在编译期或 Job 的 Execute(int index) 里连续访问；
3. 避免 bool、byte 混排，采用 uint 位域或 Unity.Mathematics.bool4 对齐到 4 byte；
4. 热更新场景下，把需要向量化的结构体提前放在主工程Assembly-CSharp或玩家程序集，并通过静态只读方式暴露给 Lua/ILRuntime，防止 Burst 编译期无法识别；
5. 在 Burst Inspector 中验证：若出现 vector.load/store 即成功，若回退到 scalar.i32 则需检查对齐或托管引用。
   一句话总结：值类型是 Burst 向量化唯一载体，其内存布局决定 SIMD 能否落地；任何托管引用、错位对齐、非连续访问都会让向量指令瞬间消失。

拓展思考

1. 国内项目常见“配置表驱动战斗数值”，策划在 Excel 里填 float3 却导出成 Vector3（托管），导致 Burst Job 无法向量化；可写导出器强制把 Vector3 转成 Unity.Mathematics.float3，并在 CI 里跑Burst Inspector 断言，失败直接打回。
2. 移动端 GPU Instance 也要用 SIMD，但常量缓冲区对齐规则与 CPU 不同；可统一在 ScriptableRenderPipeline 里做跨 CPU/GPU 的结构体对齐描述表，保证一次定义、两端复用。
3. 未来 Unity 的 ISPC 集成会允许手写 soa 结构，届时值类型需要拆成**结构体数组（SoA）**而非数组结构体（AoS），提前在代码层预留 SoA<T> 包装器，可零成本迁移。