PlayCanvas引擎中排序组件共享数组问题的分析与解决方案

问题背景

在PlayCanvas引擎的开发过程中，开发团队发现了一个与组件排序相关的断言错误。当运行ReflectionBox示例或Physics Vehicle示例时，控制台会抛出断言错误，这表明引擎在处理组件排序时存在潜在问题。

问题现象

当开发者运行特定示例时，引擎会在处理组件排序过程中触发断言错误。这个错误主要出现在以下场景：

1. 加载ReflectionBox示例时
2. 运行Physics Vehicle示例时

错误表明引擎在尝试使用共享数组作为临时存储时遇到了问题，特别是在处理实体层次结构变化时。

技术分析

经过深入分析，开发团队发现问题的根源在于：

1. 共享数组的使用冲突：引擎试图使用一个共享数组作为临时存储来排序组件，但在实体层次结构变化时，这个共享数组会被多个操作同时访问。

2. 实体启用时的层次结构变化：当实体A被启用时，它通过脚本将实体B添加到层次结构中。此时，系统正在处理实体A的组件，而共享数组中已经包含了实体A的组件数据。当开始处理实体B的组件时，共享数组的内容还未被完全处理，导致数据冲突。

3. 设计局限性：原始设计假设共享数组可以安全地用于临时存储，但实际上在多层次的实体操作中，这种假设不成立。

解决方案探讨

开发团队讨论了多种可能的解决方案：

1. 恢复原始设计：为每个实体实例使用独立的数组，避免共享状态带来的问题。这种方案简单直接，但可能增加内存使用。

2. 动态数组分配：在检测到层次结构状态变化时，在getter中分配新的数组。这种方法可以保持共享数组的优势，但需要更复杂的状态管理。

3. 数组池方案：建立一个数组池管理系统，按需分配和回收临时数组。这种方案结合了前两种方案的优点，既保持了性能又避免了共享状态问题。

最终解决方案

经过权衡，团队倾向于采用数组池方案，因为它提供了良好的平衡：

const pool = [];

const getTempArray = () => {
    return pool.pop() ?? new Array();
}

const releaseTempArray = (a) => {
    pool.push(a);
}

这种实现方式具有以下优势：

• 避免了共享数组的冲突问题
• 通过重用数组对象减少了内存分配开销
• 保持了代码的简洁性和可维护性
• 能够适应复杂的实体层次结构变化场景

经验总结

这个问题的解决过程为PlayCanvas引擎的开发提供了宝贵经验：

1. 共享状态需谨慎：即使是临时存储，在多层次的异步操作中也可能引发问题。

2. 资源池模式的价值：对于频繁创建和销毁的对象，资源池模式能有效平衡性能和内存使用。

3. 断言的重要性：良好的断言机制能帮助开发者及早发现潜在的设计问题。

4. 测试覆盖的必要性：复杂场景如实体层次结构变化需要充分的测试覆盖。

这个问题及其解决方案不仅修复了当前示例中的错误，也为引擎未来处理类似场景提供了可靠的设计模式。