我对来自prefetch的{{1}}参数感到困惑，其基本上听起来像concatMap。
prefetch：从当前Observable预取的元素数
Q1 ：是否需要从MAX_CONCURRENCY预取元素进行映射，然后按顺序一次订阅一个元素？
例如，Observable的文档非常明确：
将上游项目映射到SingleSources并订阅它们 在另一个成功之后，发出他们的成功值或终止 如果这个Observable或当前内部立即 SingleSource失败。
Q2 ：concatMapSingle的文档是否可以重写为：
将上游项目映射到ObservableSources并订阅它们 一个接一个地完成了吗？
concatMap的文档的原始版本：
返回一个新的Observable，它发出应用a产生的项目 您提供给源发出的每个项目的功能 ObservableSource，该函数返回一个ObservableSource，和 然后发出连接结果所产生的项目 ObservableSources。
即，以下几行基本相同（就concatMap而言）？
MAX_CONCURRENCY答案 0 :(得分：1)
Q1：从Observable预取元素进行映射然后按顺序一次订阅一个是不是意味着什么？
在concatMap的当前实现中，上游项目是预取的，但在前一个内部源完成之前不会映射（或者它是第一个项目）。内部资源一个接一个地运行。
Q2：concatMap的doc可以改写为：
我还在第一句中提到错误行为，就像使用concatMapSingle一样。公关欢迎。
一些较旧的javadoc措辞有点令人费解，较新的javadoc更加流畅。那些旧的也惹恼了我，但除非他们需要一些扩张 - 由于StackOverflow问题的增加/对它们的误解 - 我倾向于让他们独自一人。
以下几行基本相同（就MAX_CONCURRENCY而言）？
使用Observable s，没有背压，因此concatMap和flatMap必须排队上游项目，直到它们准备好映射和订阅为止。 concatMap prefetch提示应该更像capacityHint，因为它用于调整包含额外值的内部队列。
答案 1 :(得分：0)
TL; DR：这是真的。找到了答案on GitHub。