Firestore大型集合快照监听最佳实践相关问题咨询

场景说明 #

开发Flutter应用使用Firestore服务时，需要对2个集合下合计最多600份文档做变更监听，在文档更新时给应用用户推送通知，初始实现代码如下：

_collectionRef.snapshots(includeMetadataChanges: true).listen((event) {
  event.docChanges.forEach((change) {
    if (change.type == DocumentChangeType.modified) {
      print(change.doc.id);
    }
  });
});

查阅Firestore官方最佳实践文档时，看到如下规则，因此对方案合理性产生疑问：

Limit snapshot listeners per client 100
Keep the number of snapshot listeners per client under 100.

核心疑问共两点：

• 上述限制是指单应用内snapshots().listen的总调用数不能超过100，还是单个监听器可监听的文档量上限为100？
• 监听数百份文档是否属于Firestore常规合理实践，是否需要调整数据结构压缩被监听的文档数量？

具体解答 #

关于100监听器限制的真实含义 #

这个限制约束的是单客户端创建的独立监听器实例总数，和单个监听器覆盖的文档数量没有任何关系：

• 你当前给2个集合各挂1个集合级的snapshot监听，总共只创建了2个监听器实例，距离100的阈值差距极大，完全不会触发这个限制。
• 这条规则的本质是避免开发者的错误用法：比如循环遍历600个文档，给每个文档单独调用docReference.snapshots().listen()创建独立监听，这种场景下监听器数量很快就会突破100，带来不必要的连接开销、内存占用和额外计费。
• 单个集合/查询维度的监听器，哪怕匹配到成百上千甚至更多文档，都只算1个监听器实例，Firestore本身没有给单监听器设置100条文档的硬上限。

监听数百份文档的合理性判断 #

你当前总文档量最高才600份，用2个集合级监听器做监听完全是常规合理用法，不需要特意调整数据结构限制监听文档数，但是有几个细节可以优化，减少不必要的资源消耗：

• 如果你只是需要监听文档内容的实际增删改，不需要感知本地缓存写入、服务端数据确认这类元数据变更，直接把includeMetadataChanges: true删掉就行，这个配置会触发大量无意义的回调，平白增加客户端处理压力。
• 最好给监听的查询增加过滤条件，不要无差别拉取所有文档的变更，比如只监听和当前登录用户相关的文档（例如文档的关联用户字段包含当前用户ID、属于用户所在分组等），避免无关变更触发客户端推送逻辑，也能省流量和设备性能开销。
• 一定要在不需要监听的时机（比如相关页面销毁、用户退出登录）调用监听订阅的cancel()方法取消监听，不要让监听器长期在后台空跑消耗资源。
• 等后续单监听匹配的文档量涨到几万、几十万级别时，再考虑拆分监听粒度、或者用服务端触发器配合消息推送能力做推送即可，当前600的量级完全没必要做过度设计。

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