我的应用程序中有3个活动的Firestore快照侦听器，每个侦听器侦听不同集合(不是文档，而是整个集合)内的更改。
目前，集合的大小很小，但将来可能会变得相当大，所以这是否会影响性能，或者集合的大小无关紧要?
我知道一次不应该有超过100个活动快照，并且频繁地连接和断开侦听器不是一个好主意，但是无法找到侦听器所附加的文档/集合的实际大小的任何内容…
可能导致性能问题的不是查询的大小，而是一段时间内更改的数量。如果你有3个包含1000个文档的集合，每2分钟就会有一些文档发生变化，这不会对性能造成太大影响，但如果你有3个包含100个文档的集合/查询，但每隔几秒钟就会有很多文档更新，你就会注意到。特别是如果你有状态管理，它在Firebase和状态之间同步数据。
我会分离那些经常更新的查询中的监听器，把它们留给那些保持不变但可以更新的查询。例如，在具有下拉列表的应用程序中，这是一个常见的原因。他们经常保持不变，但可以得到更新，所以我们听他们。
也只是为了说清楚。如果它们的尺寸变大，初始加载时间当然会更长，但这应该是显而易见的。因为Firestore的离线工作只会在第一次加载时被注意到，后来用户会从缓存中获取数据，然后从服务器中获取数据，所以他不会注意到它。
目前，集合的大小很小，但将来可能会变得相当大，所以这是否会影响性能，或者集合的大小无关紧要?
集合的大小不一点都不重要。重要的是查询返回的文档数量。在SQL数据库中，查询的速度取决于表中存在的记录的数量，而在Firestore中，情况是不同的。
Firestore中的查询性能取决于您请求的文档数量，而不是您搜索的文档数量。无论您是在包含1000个文档的集合中搜索10个文档，还是在包含100个MIL文档的集合中搜索10个文档，响应时间都是相同的。
也就是说，如果不加限制地查询数据库，并且查询返回的文档数量会增加，那么您可能会得到较慢的查询。在这种情况下，您应该始终考虑以较小的块获取数据。这种技术也称为分页。
我知道一次不应该超过100个活动快照。
没有限制。听众是廉价的。然而，如果你正在监听实时变化，你总是考虑根据你的应用程序的状态删除监听器。
找不到侦听器所附加的文档/集合的实际大小。
正如我已经提到的，在获取数据时，集合的大小并不重要。返回的文档数量很重要。对于文档的大小，一个文档的最大大小为1mib。这在性能方面并不算，因为查询将花费确切的时间，但它将在下载数据方面花费时间。