Google实时对象池

Question

这个问题有点“元”，但似乎没有更好的地方来问它……

According to Google，实时协作对象永远不会从模型中删除。因此，在可能的情况下将对象池化是有意义的，而不是真正删除它们并随后创建新的对象，从而防止文件大小和开销的不必要增加。

这就是问题所在:在“撤销”场景中，这意味着从回收站中拉出一个被删除的对象。但是“撤销”只适用于本地用户的操作，如果“已删除”的对象已经被另一个用户声明，我不明白实时引擎如何处理。

我的问题是，我是否遗漏了什么或想法错误，和/或是否有每个用户池的替代方案？

(我还想到，作为一项功能，API可以处理已删除对象的池化，从而自动最小化文件膨胀。)

Answer 1

我认为你必须非常小心地以你所描述的方式重用对象。这真的很难做对。你真的遇到尺寸问题了吗？一般来说，只要你不经常创建和丢弃对象，这应该不是什么大问题。

当collab对象不用于释放空间时，您可以删除该对象的内容。一般来说，这应该足够了。

(请注意，从理论上讲，API可以自动处理此对象清理。事实证明，这是一个非常棘手的问题，要正确地处理像undo这样的功能。如果它对人们来说成为一个真正的问题，它可能会成为未来的一个功能。)

Answer 2

补充谢丽尔的答案，我认为特别具有挑战性(实际上，不可能)的一件事是从池中拉出对象的东西：

假设您有一个对象池，其中(当前)包含单个对象O1。

当客户端需要一个新对象时，它将首先检查池。如果池不是空的，它将从那里拉出一个对象( O1对象)并使用它，对吗？

现在，考虑两个客户端(也称为编辑/合作者)同时需要一个新对象的场景。这些客户端中的每一个都将运行上一段中描述的逻辑。也就是说:两个客户端都将检查池是否为空，并且两个客户端都会将O1从拉出中拉出。

因此，失败的客户端将在一段时间内“认为”它成功了。它将从池中抓取一个对象，并对其执行一些操作。稍后，它将收到一个事件(E)，告诉它该对象实际上是由另一个客户端拉取的。此时，"loosing“客户端将需要创建另一个对象，并将它对第一个对象所做的任何更改重新应用到第二个对象。

假设您不知道(E)事件是否会触发/何时会触发，这实际上意味着每个客户端都需要做好准备，用新的协作对象替换它使用的每个协作对象。这似乎相当困难。更困难的是，您不能从事件处理程序进行模型更改(因为这将胜过重做/撤消堆栈)。因此，对(E)事件的实际反应需要在(E)事件处理程序之外执行。因此，在接收(E)事件和修复模型之间的时间内，您的UI层将不能使用该模型。