同一查询上的 N 个快照侦听器的定价是否与单个侦听器或 N 个侦听器相同答案

【问题标题】：Are N snapshot listeners on the same query priced as a single listener or N listeners同一查询上的 N 个快照侦听器的定价是否与单个侦听器或 N 个侦听器相同
【发布时间】：2021-03-18 10:42:50
【问题描述】：

我有多个使用addSnapshotListener 的听众：

db.collection("messages")
   .addSnapshotListener { querySnapshot, error in
      // ...
   }

我了解第一个查询快照包含所有匹配的文档。并且它们是从服务器中检索出来的。

问题：当我再次拨打.addSnapshotListener 时会发生什么？它是否仍然为初始批次调用服务器，从而产生再次读取多个文档的成本？

从逻辑上讲，我认为不需要调用服务器，因为它会主动监控更改，因此缓存的文档不应该过时，但不清楚 Firebase SDK 实际做了什么，而如果我调用成本可能会很高多次（例如，在每个导航的 SwiftUI 中）。

【问题讨论】：

您可以通过查看source 来了解SDK 的作用。
@DougStevenson，是的，我想，对 Obj-C 和 C++ 有相当了解的人可能能够弄清楚这一点：) 你碰巧知道吗？或者知道如何测试？
如果它已经在监听，为什么还要再调用它？我真的不明白这个问题。
@bsod，我在想这种行为会告知如何设计系统。例如，当用户在检索消息的屏幕之间导航时，我应该在每次屏幕加载时调用“addSnapshotListener”，还是需要设计一个不断监听的单例以避免首次获取“惩罚”
我现在明白了——当您在整个应用程序中添加两次相同的侦听器时。如果 Firebase 为同一个侦听器建立单独的连接，我会感到惊讶；如果他们这样做了，那几乎肯定会在未来的更新中改变。当我说便宜时，我的意思是在工程方面，而不是在成本方面——你的应用程序不会被一堆并发的听众所困。当我说多个听众时，我假设他们的意思是分开查询，但 IDK。但是，如果您真的“经常”在整个应用程序中添加相同的侦听器，那么制作一个静态侦听器的决定几乎是为您做出的。

标签： swift google-cloud-firestore

【解决方案1】：

根据documentation on billing，我会说SDK如何做它所做的事情是无关紧要的：

当您收听查询结果时，每次添加或更新结果集中的文档时，您都需要支付一次读取费用。当由于文档已更改而从结果集中删除文档时，您还需要支付读取费用。（相比之下，删除文档后，您无需支付阅读费用。）

因此，即使 SDK 在第二次执行侦听器时可能会调用初始批次中的整个结果集以检查更新，但您只需为添加或更新的每个文档支付一次阅读费用.此外，在初始执行中，您需要为读取结果查询的所有文档付费。

此外，正如@bsod 在问题的 cmets 中所提到的，虽然没有在任何文档中描述，但如果您的代码中有 2 个相同侦听器的实例，您很可能不会被收取两次费用，因为他们将共享与 Firestore 的连接，只执行 1 次侦听器，尽管这必须经过测试。

话虽如此，理想情况下，您可以尝试设置一个静态侦听器以避免任何不必要的计费。

【讨论】：

我的意思是，是我的问题：“成本会翻倍吗？”对于第二个听众，但我不确定引用的文本如何以一种或另一种方式回答它。从我观察网络流量的有限测试来看，似乎只要至少有一个活跃的监听器，后续的监听器就不会进入网络，所以大概不会产生成本。但想得到一个权威的答案
只需重新阅读您所说的内容：“因此，即使 SDK 可能会调用初始批次的整个结果集以检查更新，您只需为每个文档支付一次阅读费用添加或更新。” - 这是真的吗？我没有这么理解。我假设第一批会读取每个文档，然后还会读取每个添加/修改
我想我表达的不是很好，我基本上想说的是，即使 SDK 检查批处理中的每个文档（这是一个读取），在第二次执行时，你也只会为更改的文件收费。将其编辑为答案以使其更清晰，但您的观点对于初次通话确实是正确的。根据您的第一条评论，我无法在任何地方找到此信息，因此可能需要对其进行测试，但正如@bsod 所述，它们很可能没有建立单独的连接。
@NewDev 我编辑了我的答案以反映所制作的 cmets，如果您对此还有任何疑问，请告诉我。
我通过创建多个侦听器并检查仪表板中的读取计数手动尝试了它，看起来即使删除了侦听器然后重新添加它也不收费（这很令人惊讶对我来说）