查询规模是否会影响Firestore snapshot listeners的性能？

结论：集合整体的总数据规模和监听器性能没有直接关联，只有两类场景会受数据量级影响：

• 监听器首次建立时，如果你没有加任何过滤、限制条件直接监听整个集合，服务端会返回当前集合内全量文档完成本地初始化，此时集合总规模越大，初次加载的耗时、带宽消耗、客户端内存占用就越高
• 监听器保持活跃期间，单次变更涉及的符合查询条件的文档数量越多，单次同步的开销越高，和集合内其他未变更的文档完全无关

如果后续你的集合数据规模会大幅增长，可以通过以下方式规避潜在性能问题：

• 避免无限制监听全集合，结合业务场景添加where条件、limit分页限制，把监听范围缩小到你实际需要用到的文档区间
• 如果你只需要监听监听器建立之后产生的新增数据，可添加基于创建时间的过滤条件，例如where("createAt", ">", 监听器初始化时间戳)，跳过全量历史数据的初始同步
• 可以按需配置字段过滤，只同步业务逻辑用到的字段，减少单条文档的同步开销

你当前仅3个活跃监听器，远低于单客户端最多100个活跃监听器的推荐阈值，只要做好监听范围的限制，即使后续集合总数据量涨到百万级也不会对监听器运行产生负面影响。

内容的提问来源于stack exchange，提问作者CentoKili53