Firebase数据库Query的startAt()方法无效，RecyclerView分页加载异常

你现在的查询逻辑踩了Firebase Realtime Database最常见的匹配规则坑，所以查不到任何数据：

• 你给查询设置的排序规则是orderByChild("programmeName")，意味着整个查询的匹配、排序基准全是programmeName这个字段的值。这种情况下调用startAt()时，括号里必须传入对应位置的programmeName值，但你现在传的是数据库每个子节点的ID（也就是PROGRAMMES下每个条目的key），相当于拿项目名称的排序标尺去匹配节点ID，根本匹配不上，所以查询结果是空集，自然触发不了子节点监听的回调，你加的Toast也就不会弹。
• 只有当你用orderByKey()设置排序规则时，startAt()传入节点ID才是有效的，两者规则不匹配的时候，查询永远不会返回任何数据。

1. 先对齐排序与匹配参数 #

根据你的实际业务需求二选一就行：

• 如果你的列表本来就要按项目名称排序：别存最后一个节点的ID当游标，改成存当前列表最后展示项的programmeName值，加载下一页的时候把这个名称值传给startAt()，查询才能正常触发。
• 如果你不想改现在存节点ID的逻辑：把查询的排序规则改成orderByKey()，这时候把节点ID作为startAt()的参数传进去，就能正常匹配到对应位置之后的数据。

2. 解决分页重复加载的问题 #

就算你把参数匹配改对了，还是会有数据重复的问题——因为startAt()的匹配规则是包含等于传入值本身的节点：

• 首次加载时，直接用limitToFirst(6)拉取第一页6条数据，把这页最后一条的排序游标值（要么是节点ID，要么是项目名）存下来
• 后续加载下一页时，把游标值传给startAt()拉取6条数据，拿到结果后手动跳过第一条（就是和游标重复的那条），把剩下的5条追加到RecyclerView的数据源里，就能实现无重复的分页加载

3. 优化现有监听逻辑避免出bug #

你现在每次滚到底部就新建一个ChildEventListener挂在查询上，很容易出现多个监听同时触发、内存泄漏、数据错乱的问题：

• 分页拉取数据不需要持续监听节点的实时变化，换成addListenerForSingleValueEvent()就行，拉完一次数据监听就自动解绑，不会有内存泄漏
• 追加新数据后别每次都调notifyDataSetChanged()，用notifyItemRangeInserted(原有列表长度, 新加入的数据长度)更新列表，列表滚动不会错位，性能也更好

补充提醒：如果坚持用orderByChild("programmeName")做排序，一定要保证数据库里所有PROGRAMMES节点下的programmeName字段类型统一（比如全是字符串），如果出现类型不统一的情况，查询也会出现匹配失败的问题。

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