Observable vs Flowable : Quand utiliser l’un ou l’autre ?

Dans l’univers de RxJava, deux classes principales permettent de gérer les flux de données : Observable et Flowable. Bien que très similaires en apparence, ces deux types répondent à des besoins bien distincts, notamment lorsqu’il s’agit de volumes de données élevés ou de la gestion du backpressure.

Dans cet article, nous allons clarifier les différences entre Observable et Flowable, et expliquer quand utiliser l’un plutôt que l’autre.

Qu’est-ce qu’un Observable ?

Un Observable représente un flux asynchrone pouvant émettre zéro, une ou plusieurs valeurs. C’est le type le plus courant en RxJava pour des cas simples comme :

• des clics utilisateurs,
• des appels réseau,
• des requêtes de base de données à faible charge,
• des timers ou animations.

Par exemple,

Observable<Integer> observable = Observable.just(1, 2, 3);
observable.subscribe(System.out::println); // 1, 2, 3

Points forts :

• Léger et facile à utiliser
• Suffisant pour la plupart des cas simples
• Pas de complexité liée à la gestion de la pression de flux

Et le problème ? Le Backpressure

Le backpressure apparaît quand la vitesse d’émission des données est plus rapide que la capacité de traitement du consommateur. Par exemple : une source de données envoie 10 000 éléments/sec, mais ton système n’en traite que 1 000/sec. Résultat : mémoire saturée, UI gelée, plantages.

Observable ne gère pas le backpressure. Il continue d’émettre sans se soucier de la capacité du subscriber. C’est là qu’entre en jeu le Flowable.

Qu’est-ce qu’un Flowable ?

Flowable est similaire à Observable, mais avec une capacité intégrée de gestion du backpressure. Il est conçu pour les situations où :

• le volume de données est élevé ou infini (ex : flux Kafka, capteurs IoT, lecture de fichiers massifs),
• le traitement des données est lent ou dépend de l’utilisateur (UI, base de données, etc.),
• tu veux éviter les OutOfMemoryError ou ralentissements.

Par exemple,

Flowable.range(1, 1000000)
        .observeOn(Schedulers.computation())
        .subscribe(System.out::println);

Les stratégies de backpressure

Avec Flowable, tu peux définir des stratégies pour gérer la surcharge :

• BackpressureStrategy.BUFFER : met tout en mémoire (risqué)
• BackpressureStrategy.DROP : ignore les éléments excédentaires
• BackpressureStrategy.LATEST : conserve uniquement le plus récent
• BackpressureStrategy.MISSING : à combiner avec un opérateur (onBackpressureXXX)

Flowable.create(emitter -> {
    while (!emitter.isCancelled()) {
        emitter.onNext(System.currentTimeMillis());
    }
}, BackpressureStrategy.DROP)
.subscribe(System.out::println);

Observable vs Flowable : tableau comparatif

Caractéristique	Observable	Flowable
Backpressure	Non géré	Géré via stratégies
Performance	Très rapide	Moins rapide, plus sûr
Cas d’usage	Données légères, UI	Données massives, streaming
Complexité	Faible	Moyenne à élevée
Gestion mémoire	Risque de débordement	Contrôlée

Quand utiliser l’un ou l’autre ?

Utilise Observable si :

• Le flux de données est limité ou contrôlé
• Tu travailles avec des APIs comme Retrofit, Room, ou des interactions utilisateur
• Tu veux un code simple et rapide à écrire

Utilise Flowable si :

• Tu reçois un grand volume de données en continu
• Tu travailles avec Kafka, MQTT, Firebase, ou des capteurs
• Tu veux un contrôle fin sur le flux de données et la mémoire

Astuce : ne passe pas à Flowable par défaut

Beaucoup de développeurs pensent qu’il vaut mieux utiliser Flowable partout « au cas où ». En réalité, cela complexifie inutilement le code et peut ralentir les performances.

Règle simple :

Commence par Observable, passe à Flowable uniquement si tu constates une surcharge ou des exceptions dues au backpressure.

Conclusion

La maîtrise de Observable et Flowable est essentielle pour écrire des applications réactives, robustes et performantes avec RxJava. Savoir quand et pourquoi utiliser l’un ou l’autre permet de mieux gérer la concurrence, la mémoire, et d’assurer une expérience utilisateur fluide.