RxJava 2.x迁移疑问：Observable与Flowable的选择及资源消耗对比

Great questions—let’s break this down step by step since RxJava 2’s split between Observable and Flowable is one of the most common pain points during migration from RxJava 1.x.

First, let’s get the foundational distinction out of the way:

• Flowable: Designed for streams that need backpressure support. Backpressure is the mechanism that lets downstream consumers signal upstream producers to slow down when they can’t keep up (preventing memory overflow from unprocessed events). It includes built-in queue management and backpressure strategy handling.
• Observable: Built for no-backpressure scenarios. It’s a lightweight stream implementation that skips all backpressure-related logic, making it faster and more efficient for use cases where producers and consumers are already in sync.

This split fixes RxJava 1.x’s biggest flaw: its Observable tried to handle both backpressure and non-backpressure scenarios, leading to inconsistent behavior and hidden bugs.

There are three key reasons to keep using Observable instead of going all-in on Flowable:

• Performance overhead: Flowable carries extra overhead from backpressure checks, queue management, and strategy enforcement—even if you don’t need backpressure. For high-frequency, low-data streams (like UI clicks or scroll events), this overhead adds up and wastes CPU/memory.
• Semantic clarity: Using Observable explicitly signals to other developers that this stream doesn’t require backpressure handling. It makes your code self-documenting, so teammates don’t waste time trying to figure out why backpressure operators are (or aren’t) present.
• Migration simplicity: If you’re porting RxJava 1.x code, most of your existing Observable streams were likely designed for non-backpressure scenarios. Using RxJava 2.x’s Observable keeps the logic aligned with the original intent, avoiding unnecessary refactoring of backpressure strategies.

Yes, there are measurable differences even when using Flowable with the default ON_OVERFLOW_ERROR strategy:

• Memory usage: Flowable maintains an internal buffer (default size: 128 elements) to handle temporary mismatches between producer and consumer speed. Even if you never hit the overflow error, this buffer takes up extra memory. Observable has no such buffer—it passes events directly from producer to consumer, so memory overhead is minimal.
• CPU overhead: Every event in a Flowable stream triggers backpressure checks (e.g., "does the downstream have pending requests?" "is the buffer full?"). These checks add tiny amounts of CPU time per event, which becomes noticeable in high-throughput streams. Observable skips all these checks, making it faster for sync or low-latency use cases.

Only if you misuse it. Here’s the breakdown:

• Safe scenarios for Observable: Use it when:
  • The stream is a cold source with a small, fixed amount of data (e.g., fetching a single API response).
  • The producer and consumer are on the same thread (e.g., UI events like button clicks, where the consumer processes events immediately).
  • The producer’s speed is inherently limited (e.g., user input, which can’t outpace human interaction).
• Risky scenarios: Avoid Observable if your stream is a hot source with high throughput (e.g., real-time sensor data, bulk database reads) where the producer can outpace the consumer. In these cases, missing backpressure will lead to OutOfMemoryError as unprocessed events pile up.

As long as you match the stream type to the use case, Observable is completely safe—and often preferable.

Going all-in on Flowable isn’t catastrophic, but it comes with downsides:

• Unnecessary performance loss: As mentioned earlier, every stream will carry backpressure overhead, even for trivial use cases. In apps with hundreds of small streams (common in Android or reactive web apps), this can lead to measurable slowdowns.
• Ambiguous code semantics: Without Observable, there’s no way to tell at a glance which streams need backpressure handling. This makes maintenance harder, as developers may add unnecessary backpressure operators or overlook actual backpressure risks.
• Extra exception handling: Flowable can throw MissingBackpressureException when the buffer overflows (even with ON_OVERFLOW_ERROR). You’ll need to handle these exceptions everywhere, even in scenarios where they should never occur—adding boilerplate code.

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