Siqi Liu / React 状态与 3D 引擎的高频同步架构

我们做传统的 React 开发时候习惯了数据驱动 UI，state 变了 UI 就变。

但是，当我们的数据源不是用户输入的表单，而是一个每秒钟都在疯狂变化的 3D 引擎（如 Cesium）时，传统的 React 模式会直接导致网页崩溃。

今天我想分享一下，我们是如何给狂奔的 Cesium 引擎“套上缰绳”，让它和 React 和平共处的。

1. 核心冲突：UI 线程 vs 渲染循环

Web 开发中存在两种截然不同的更新模式：

• React (UI Thread)：声明式，按需更新。追求准确性，任何状态变更都会触发 Diff 和 Re-render。
• 3D Engine (Game Loop)：命令式，60FPS 持续刷新。状态变更极其频繁（Loading/Culling/Moving）。

当 3D 场景加载大量模型时，Cesium 会在短时间内发出成百上千个“节点添加”事件。如果采用朴素的 onEvent -> setState 模式，主线程会被瞬间阻塞，导致页面无响应。

2. 抽象模型：场景图投影与同步

为了解决速率不匹配的问题，我们确立了核心观点：React 中的 Tree State 不再是 Source of Truth，它只是 3D 世界的一个低频投影。

我们构建了如下的架构模型：

flowchart LR
  A["3D Engine (Cesium)"] -->|High-frequency events| B["TreeStateManager / StateManager"]

  B --- D[("Node Store: Map(ID -> Node)")]
  B --- E[("Pending Updates Buffer: Dedup + BatchUpdate")]
  B --- F[("View Projection: Graph -> Flat Array")]

  B -->|Low-frequency view updates| C["React UI (Virtual List)"]
  C --- G[("Render viewport only: O(H)")]

我们引入了一个脱离 React 生命周期独立存在的类 TreeStateManager，它不仅仅是一个数据缓存，而是整个系统的可信源 (Source of Truth) 和流量阀。

它承担了三个关键职责：

1. 状态持有与 O(1) 索引 (State Holding)

它在内存中维护了一个完整的节点数据库。

• 利用 Map<ID, Node> 建立全量索引，确保任何一种通过 ID 查找节点的操作（如：根据 Cesium 点击事件反查树节点）都是 O(1) 复杂度。
• 维护节点的持久化状态（Opened/Checked），这些状态独立于 UI 存在，即使组件卸载重装，状态依然保留。

2. 流量整形 (Traffic Shaping)

面对 3D 引擎可能瞬间涌入的成千上万个状态变更事件（Add/Remove/Update），StateManager 充当了防洪堤的角色。

• 去重 (Deduplication)：同一毫秒内对同一个节点的多次修改（如：先变红再变绿）只保留最终态。
• 缓冲 (Buffering)：并不是来一个事件就通知一次 UI。而是维护一个 pendingUpdates 队列，通过 batchUpdate 机制，将高频的细碎更新合并为一次低频的 View Update。

3. 视图投影 (View Projection)

“怎么看数据”由它决定。它根据当前的 SortType（如：按 CAD 结构排序、按实体类型排序），动态地将内存中的非线性数据（Graph），实时计算出当前 UI 所需的那一个线性数组（Flat Array）。

这意味着：底层数据只有一份，但“视图”可以有无数种，且切换视图只是重新计算一次投影，成本极低。

3. 关键实现策略

针对 3D 场景常见的深层嵌套，我放弃了直观的“递归组件”写法。

在早期实验中我发现，当树的深度（Depth）增加且节点数量庞大时，React 的递归组件会带来巨大的性能惩罚：

1. 调用栈溢出风险：过深的组件树会让 JS 引擎的调用栈压力倍增。
2. Diff 开销指数级上升：React 在协调（Reconciliation）层级很深的组件树时，其 Diff 算法的开销会显著增加，导致帧率断崖式下跌。

因此，我们在内存中维护一个扁平数组 flatNodeArray，通过 depth 属性标识层级。

• 优势：虚拟列表（Virtual List）可以直接消费这个数组，React 只需要渲染视口内的几十个 div，渲染复杂度与总数据量（N）彻底解耦，只与视口高度（H）相关 O(H)。
• 操作：节点的展开/折叠，仅涉及数组过滤，不再需要昂贵的 DOM 树重绘。

策略 B：异步时间分片 (Time Slicing)

这是解决“假死”的关键。不仅使用批处理（Batching），还将构建任务拆分为多个微任务。

// 伪代码逻辑
while (queue.length>0) {
  process(queue.splice(0,100)); // 处理一小批
  awaitnextTick();              // 让出主线程，允许 UI 响应交互
}

4. 数据结构带来的功能实现上的性能红利

架构的选择往往不仅解决了当下的性能问题，简化后续功能的实现。最典型的例子就是 Shift+多选 功能。

在旧版本（基于递归的树）中，当我们在一个包含 2万个节点的 4 层深树上执行“范围全选”时，浏览器会直接假死 10 秒左右。因为算法不得不在深层嵌套的 DOM 树中疯狂递归，查找路径和状态。

但在我们的扁平化数组 (Flat Array) 架构下，这道难题迎刃而解：

// 伪代码：在扁平数组中实现范围选择
constrangeSelection= (startId,endId)=> {
conststartIndex=nodePositionMap.get(startId);
constendIndex=nodePositionMap.get(endId);

// 无论树结构多复杂，视觉上的范围就是数组索引的切片
returnflatNodeArray.slice(
Math.min(startIndex,endIndex),
Math.max(startIndex,endIndex)+1
    );
};

另外一个例子是树形控件中最复杂的状态莫过于 Checkbox 的级联更新（全选/反选）。

在传统递归树中，勾选一个包含 2万个子节点的父级，意味着触发 2万次 React 组件的 Re-render，这绝对是性能灾难。而在我们的架构中，这被简化为纯内存操作：

1. 索引查找：利用 Map 瞬间定位所有 26,000 个子节点 ID。
2. 批量修改：直接更新数据 Store，不触碰 DOM。
3. 按需绘制：VirtualList 只重绘屏幕可见的 20 行。结果：无论级联多少节点，渲染开销恒定为 O(1)。

4. 实验数据与性能验证

为了验证架构的可扩展性，我们在中等规模和高负载规模（两种真实场景下进行了性能埋点测试。

测试环境：Chrome / M2 Chip

对比组：中级场景 (7,000 Nodes) vs 高级场景 (68,500 Nodes)

以下是三大场景的实测数据对比：

实验一：视图构建与渲染性能 (Build & Render)

这是最基础的性能指标，衡量这套“扁平化 + 时间分片”架构能否扛住大数据量的冲击。

undefined

实验二：交互响应速度 (Shift+Select Range)

这是对架构设计最极致的考验。我们在 3D 场景中进行“隐藏式全选”测试：用户只选中了可视区域的几十个文件夹，但其内部包含了数万个折叠的 3D 实体。

undefined 解读：在过去，计算两个节点之间的“视觉范围”需要复杂的树遍历递归，极易导致主线程锁死。而在扁平数组中，这退化为一个简单的 Array.slice 操作（以及随后的 ID 收集），即便是处理 8万个对象，也能在 260ms 完成。

实验三：状态级联更新 (Checkbox Cascade)

测试用户点击根节点“全选”时，系统递归更新所有子孙节点状态的性能。

undefined 解读：得益于 Map 索引 (O(1)) 和内存状态操作，我们可以在 70多毫秒内完成 2.6万个组件的状态同步。对用户而言，这就是“即点即亮”的实时反馈。

这三组实验数据足以证明了：当数据规模从 7千 增长到 7万（10倍压力）时，系统的核心性能指标依然保持在线性可控范围内，没有出现指数级的性能崩塌。

5. 总结

在处理 3D 引擎与 React 结合的复杂工程中，我们往往容易陷入怪圈：试图用更复杂的 React 技巧（memo, useMemo）去修补性能漏洞。

但这套架构的实践告诉我们：性能问题的终极解法，往往不在代码层面的修修补补，而在于底层数据逻辑的重构。

通过引入中间层架构，我们将狂暴的 3D 渲染循环与安静的 UI 线程隔离开来；通过数据降维，我们将 O(N) 的 DOM 操作降解为 O(1) 的数组操作。

这不仅解决了 Cesium 场景树的性能瓶颈，也为任何海量即时数据可视化（如股票行情、日志监控、复杂表格）提供了一套通用的架构范式：

1. 脱离框架思考：不要被 React 的声明式模型束缚，敢于在 Side Effect 中管理自己的数据流。
2. 拥抱最终一致性：在人眼无法感知的毫秒级缝隙里，用“批处理”和“时间分片”换取系统的吞吐量。
3. 数据结构致胜：在面对数万级节点时，选择 Flat Array 还是 Recursive Tree，这一个决定可能比写 1000 行优化代码更管用。

希望这套“驯服狂奔引擎”的经验，能为您解决类似的高频同步难题带来一点启发。