这是一个相同的问题。
但是发布者的问题在没有实际回答发布的问题的情况下得到了解决-因为问题是由于与分页库如何知道加载更多页面无关的东西。
我想知道用于消耗分页数据源的订阅/收集(Rx/Flow)机制是否是分页数据源知道何时加载更多页面的方式。所以也许订阅/收藏会吸引页面。(但即便如此，初始加载后如何触发页面呢?)数据源可以使用拉事件作为检查是否需要加载更多页面的机会。
我在这里只是猜测，因为我不知道这一切是如何内部工作的。
我希望有人能证实或驳回我的猜测，并提供有关机制的更多细节。特别是，当页面作为Flow或(Rx) Flowable公开时。
显示API的.get(index)调用触发对分页其余部分的项访问。通常，为了将项目绑定到RecyclerView.Adapter，您需要调用此函数，但是leanback和compose的工作原理类似。
在项目访问上，一个名为ViewportHint的内部对象被发送，它包含呈现者状态，包括转换后你可以看到的项目数量和你在列表中的当前位置，这可以从UI的其余部分异步处理。
分页然后基本上触发基于PagingConfig.prefetchDistance的负载，但是有很多逻辑处理竞争条件，访问合并，取消，跟踪负载状态，错误处理等，这些都可以影响最终加载的内容。
如果你想访问，但避免触发负载，有.peek()和.snapshot()api，让你检查演示者的状态，而不需要获取。
分页3库中有很多代码，我非常希望避免过于仔细地查看它。
但是我做了一些肤浅的探索，并找到了一个可能的候选人来解释用户滚动如何触发丢失页面的加载。
正如我在问题中推测的那样，加载不是由页面的订阅/收集(Rx/Flow)活动触发的。
适配器尝试获取要显示的项时触发对PagingDataDiffer<T : Any>.get(@IntRange(from = 0) index: Int): T?的调用。
其Javadoc:
返回指定位置的呈现项，通知Paging项访问以触发完成prefetchDistance所需的任何加载。
参数:index -要返回的显示项的索引，包括占位符。
返回:在位置索引处显示的项，如果是占位符，则为null。
特别感兴趣:... notifying Paging of the item access to trigger any loads necessary to fulfill prefetchDistance.
就这样了。
如果其他人不同意或希望详细说明机制，请提出。