TypedArray 本身不预分配物理内存，关键在于复用固定 ArrayBuffer 的连续内存块以提升 WebGL 与计算性能；需先创建大 ArrayBuffer，再生成多类型视图共享同一内存，配合 GPU 缓冲绑定、零拷贝传输及对齐布局优化吞吐量。

TypedArray 本身不直接“预分配物理内存”，但它能让你高效绑定并复用底层 ArrayBuffer 所映射的连续内存块——这才是提升 WebGL 渲染与计算密集型任务吞吐量的关键。真正起作用的是：固定 ArrayBuffer + 类型化视图 + 零拷贝复用 + GPU 缓冲协同策略。

用 ArrayBuffer 一次性申请大块连续内存

避免反复 new TypedArray 导致内存碎片和 GC 压力。应先创建足够大的 ArrayBuffer，再按需生成视图：

• 例如处理百万级粒子：const ab = new ArrayBuffer(1024 * 1024 * 16); // 16MB 预留空间
• 后续所有 Float32Array、Uint32Array 等视图都基于这个 ab 构建，共享同一段连续字节
• 比逐次 new Float32Array(1e6) 更稳定，尤其在长时间运行的可视化或模拟中可显著减少 V8 内存抖动

为 WebGL 顶点/实例数据做“真预分配”

预分配 ≠ 提前 new 数组，而是让 GPU 缓冲与 JS 内存长期绑定，只更新变化部分：

• 创建顶点缓冲时使用 gl.STATIC_DRAW（静态数据）或 gl.DYNAMIC_DRAW（频繁局部更新），并传入已填充的 TypedArray
• 后续仅调用 gl.bufferSubData 更新某一段（如第 5000–5999 个顶点），偏移量按 byte 计算：offset = startIdx × stride × 4
• 配合 instanced rendering，一个 draw call 渲染数万粒子，CPU 不再成为瓶颈

在 Worker 中复用视图做无拷贝计算

主线程与 Worker 协同时，用 transferable 实现内存零复制：

• 主线程生成 ArrayBuffer 后，通过 postMessage(buffer, [buffer]) 移交所有权
• Worker 收到后 new Float32Array(e.data) 直接获得视图，无需拷贝、无延迟
• 计算完仍可把 buffer 回传，或继续用 subarray() 切出不同逻辑区域（如位置区、速度区、生命周期区）
• 注意：transfer 后原视图 detached，需检查 view.buffer.byteLength 是否为 0 来判断有效性

按用途选类型 + 对齐布局提升缓存效率

类型选择和内存排布直接影响 CPU/GPU 访问速度：

• 粒子位置用 Float32Array（32 位精度够用，比 Float64Array 节省一半带宽）
• 索引或 ID 用 Uint16Array（若 ≤65535）或 Uint32Array（支持更大规模），避免 Int32Array 符号扩展开销
• 顶点结构按 stride 对齐：比如 (x,y,z,nx,ny,nz,u,v) 共 8 float → stride = 32 字节，确保每个顶点起始地址是 32 的倍数，利于 GPU SIMD 加载