Oops Framework-2-框架的原理（Cocos Creator + ECS）

一、笔者前言

首先要澄清的是，oops-framework ECS 是一种「架构型 ECS」，并不是「性能型 ECS」 它完全做不到 DOD-ECS 那种极致 CPU 缓存命中率。

CPU 读取内存极慢（比读缓存慢 100~1000 倍），所以会一次性预读一整段连续内存（64 字节 Cache Line）。

缓存命中 = 快 缓存不命中 = 慢

缓存局部性 = 数据挨得越近，访问越快

复制代码

// 所有 Position 挤在一块连续内存
Position: [x,y,z][x,y,z][x,y,z][x,y,z]...

// 所有 Velocity 挤在另一块连续内存
Velocity: [x,y,z][x,y,z][x,y,z][x,y,z]...

复制代码

System 循环 → 顺序读数组 → CPU 预取满缓存 → 命中率 95%+

这是**原生语言（C++/Rust）**才能做到的事情：

标准 AoS（Array of Structures） + OOP 对象模型

复制代码

Entity 对象（堆分配）
├─ eid、mask、isValid
├─ 一堆 Map 引用
├─ Position 组件 → 指向另一个堆对象
├─ Move 组件   → 指向另一个堆对象
└─ 所有组件都是「指针跳转」

复制代码

this[ctor.compName] = comp;

每个组件都是独立堆对象，内存完全散乱。

复制代码

for (let entity of group.matchEntities) {
  entity.Position.x; 
}

内存访问路径：

复制代码

数组 → 实体对象指针 → 跳 → 组件对象指针 → 跳 → 读数据

两次随机内存访问 = CPU 预取完全失效 = 缓存命中率极低

OOPs框架这样做基本也是最优解，强行在 JS 做 DOD-ECS 缓存优化 = 缘木求鱼 性能提升微乎其微，代码复杂度爆炸。

如果使用WASM可以做到，但这是另外一回事情。

它放弃了无效的缓存追求 ，转而做 JS 环境真正能提升性能的事：

用 Uint32Array 位运算做实体筛选

组合优于继承、数据逻辑分离、系统模块化。