这个问题对SO来说有点"元"，但似乎没有更好的地方问它…
根据谷歌的说法，实时协作对象永远不会从模型中删除。因此，在可能的情况下对对象进行池化是有意义的，而不是不真正删除它们并随后创建新的对象，从而防止文件大小和开销的不必要增加。
问题是：在"撤消"场景中，这意味着从垃圾池中取出一个已删除的对象。但是"撤消"只适用于本地用户的操作，如果"已删除"的对象已经被另一个用户声明，我看不出实时引擎如何处理。
我的问题是，我是否遗漏了什么或思考错误，和/或是否有按用户池的替代方案？
(我还想到，作为一项功能，API可以处理已删除对象的池化，自动最小化文件浮动。)
我认为在以您描述的方式重用对象时必须非常小心。这真的很难做到正确。你真的遇到尺寸问题了吗？一般来说，只要你不不断地创建和丢弃对象，这应该没什么大不了的。
当collab对象的内容未用于释放空间时，您可以删除该内容。一般来说，这就足够了。
(注意，是的，API理论上可以自动处理此对象清理。这是一个非常棘手的问题，需要正确处理撤销等功能。如果它成为人们真正的问题，它可能会显示为未来的功能。)
除了Cheryl的回答之外，我认为有一件事特别具有挑战性(实际上是不可能的)，那就是从池中提取一个对象：
假设您有一个对象池，其中(当前)包含一个对象O1。
当客户端需要一个新对象时，它将首先检查池。如果池不是空的，它会从那里提取一个对象(O1对象)并使用它，对吗？
现在，考虑两个客户端(也称为编辑器/协作器)同时需要一个新对象的场景。这些客户端中的每一个都将运行上一段中描述的逻辑。也就是说：两个客户端都将检查池是否为空，并且两个客户端将从拉取中拉出O1。
因此，失去的客户会"认为"它成功了一段时间。它将从池中获取一个对象，并对其进行一些操作。稍后，它将接收一个事件(E)，该事件告诉它该对象实际上是由另一个客户端拉取的。此时，"丢失"的客户端将需要创建另一个对象，并将它对第一个对象所做的任何更改重新应用到第二个对象。
假设您不知道(E)事件是否/何时会触发，这实际上意味着每个客户端都需要准备好用新的协作对象替换它使用的每个协作对象。这似乎很难。更困难的是，您不能从事件处理程序中进行模型更改(因为这将胜过重做/撤消堆栈)。因此，对(E)事件的实际反应需要在(E)处理程序之外执行。因此，在接收到(E)事件和修复模型之间的时间内，UI层将无法使用该模型。