RxJava: conceptos básicos, ReactiveX y trabajo con flujos de datos

Qué es RxJava y ReactiveX

RxJava es la implementación Java de la especificación ReactiveX, una biblioteca para programación asíncrona mediante flujos observables (Observable). RxJava 2 se lanzó en 2016 con soporte de Reactive Streams (Flowable) y la separación en rx.Observable e io.reactivex.Observable. RxJava 3 (2019) es la versión principal actual con compatibilidad retrospectiva con RxJava 2.

La idea central de RxJava es que todo es un flujo: flujo de datos, flujo de eventos, flujo de estados. Cualquier operación asíncrona puede representarse como un Observable que emite datos, un error o una señal de finalización. Un Observer se suscribe al Observable y recibe notificaciones en tiempo real.

Según Badoo (2024), antes de la transición a corrutinas, el 76% de las aplicaciones Android del top 200 de Google Play usaban RxJava para operaciones asíncronas. La proporción está disminuyendo en favor de las corrutinas, pero RxJava sigue presente en el código de producción de miles de aplicaciones y se considera una tecnología madura y probada. ReactiveX es una especificación multiplataforma implementada también para JavaScript (RxJS), .NET (Rx.NET), Swift (RxSwift) y otros lenguajes.

Patrón Observer en RxJava

ReactiveX extiende el patrón Observer clásico con dos mecanismos: encadenamiento de operadores y gestión de hilos mediante Schedulers. Observable no comienza a emitir datos hasta que un Observer se suscribe (evaluación perezosa). Esto permite construir un pipeline de datos que se activa solo cuando existe una suscripción.

Tipos de Observable: Observable, Flowable, Single, Maybe, Completable

Observable — el tipo base que emite 0..N elementos con onError o onComplete. Adecuado para flujos de datos ilimitados — por ejemplo, eventos de clic o actualizaciones de geolocalización. Observable no soporta backpressure.

Flowable — la versión Reactive Streams de Observable con soporte de backpressure. Se usa cuando la fuente de datos puede generar elementos más rápido de lo que el Observer puede procesar. Flowable soporta las estrategias BACKPRESSURE_BUFFER, DROP, LATEST y ERROR.

Single, Maybe y Completable

Single emite exactamente un elemento o un error — ideal para peticiones de red. Maybe emite 0 o 1 elemento, adecuado para caché donde los datos pueden no existir. Completable emite solo onComplete u onError, sin datos, conveniente para operaciones de escritura o eliminación. Estos tipos simplifican la API al reducir el contrato a un caso específico. Retrofit (un popular cliente HTTP para Android) soporta directamente los cinco tipos de RxJava, permitiendo elegir el tipo de retorno más apropiado para cada endpoint sin código repetitivo adicional.

Operadores de RxJava: transformación y filtrado de flujos

Los operadores son funciones que transforman un Observable en otro. Una cadena de operadores describe el pipeline de datos: cada operador toma el flujo del anterior, lo transforma y lo pasa al siguiente. RxJava contiene más de 200 operadores agrupados en categorías.

• map — transforma cada elemento (Integer → String)
• flatMap — transforma un elemento en un Observable y fusiona todos en un solo flujo
• filter — filtra elementos que cumplen una condición
• zip — combina elementos de N Observables por índice
• merge — fusiona varios Observables en uno, preservando el orden cronológico
• debounce — emite elementos solo si ha transcurrido un intervalo de tiempo específico sin otra emisión

flatMap es uno de los operadores más potentes de RxJava. Permite ejecutar una petición asíncrona para cada elemento y recoger los resultados en un flujo común. Por ejemplo, flatMap se usa para cargar detalles a partir de una lista de IDs: cada ID → petición de red → fusión de resultados. A diferencia de map, que simplemente transforma un elemento, flatMap puede emitir múltiples elementos o cambiar a otro Observable, lo que lo convierte en la base para construir pipelines asíncronos.

Manejo de errores con operadores

onErrorResumeNext — cambia a un Observable de respaldo en caso de error. retry — reintenta la suscripción N veces al ocurrir un error. onErrorReturn — devuelve un valor por defecto en lugar del error. doOnError — realiza una acción secundaria al ocurrir un error sin modificar el flujo (registro o análisis). La combinación de estos operadores permite construir pipelines robustos con una estrategia clara de manejo de errores sin try/catch manual.

Schedulers: gestión de hilos en RxJava

Los Schedulers determinan en qué hilo se ejecutan Observable y Observer. subscribeOn establece el hilo para la fuente, observeOn establece el hilo para el Observer y los operadores posteriores. Esta separación es una ventaja clave de RxJava: fuente en hilo IO, procesamiento en computation, UI en el hilo principal.

Principales Schedulers: Schedulers.io() — para operaciones de E/S (red, disco), pool ilimitado. Schedulers.computation() — para cálculos, pool fijo según el número de núcleos. Schedulers.newThread() — un nuevo hilo para cada tarea. AndroidSchedulers.mainThread() — hilo principal de Android (RxAndroid). También existe Schedulers.trampoline() para ejecutar tareas en el hilo actual con una cola FIFO, útil para pruebas.

Según Google (2025), el uso correcto de los Schedulers es la parte más difícil de RxJava para principiantes. Un error típico es llamar a subscribeOn después de observeOn, lo que no afecta a la fuente. subscribeOn debe ser el primero en la cadena para la fuente, observeOn antes de la suscripción UI. Regla: subscribeOn solo afecta al upstream (fuente), observeOn cambia el downstream (suscriptor y todos los operadores posteriores).

Ejemplos de código RxJava en Android

Consideremos tres escenarios: una petición de red con Single, peticiones paralelas con zip y debounce para un campo de búsqueda con debounce.

Petición de red con Single

Single es perfecto para peticiones Retrofit: una petición — una respuesta. Suscríbete en el hilo principal para actualizaciones de UI.

api.getUser(id)
    .subscribeOn(Schedulers.io())
    .observeOn(AndroidSchedulers.mainThread())
    .subscribe(new SingleObserver<User>() {
        @Override
        public void onSuccess(User user) { showUser(user); }
        @Override
        public void onError(Throwable e) { showError(e); }
    })

Peticiones paralelas con zip

zip combina los resultados de dos Singles independientes en uno. Se ejecutan en paralelo, el resultado se produce después de que ambos finalicen.

Single.zip(
    api.getProfile(),
    api.getSettings(),
    (profile, settings) -> new Dashboard(profile, settings)
)
.subscribeOn(Schedulers.io())
.observeOn(AndroidSchedulers.mainThread())
.subscribe(dashboard -> showDashboard(dashboard), e -> logError(e))

Debounce para campo de búsqueda

debounce ignora cambios rápidos de texto y envía una petición solo después de una pausa de 400 ms. distinctUntilChanged cancela la petición si el texto no ha cambiado.

RxTextView.textChanges(searchView)
    .debounce(400, TimeUnit.MILLISECONDS)
    .filter(text -> text.length() >= 3)
    .distinctUntilChanged()
    .switchMap(query -> api.search(query))
    .observeOn(AndroidSchedulers.mainThread())
    .subscribe(results -> showResults(results))

RxJava vs Kotlin Coroutines: comparación de enfoques

RxJava y Kotlin Coroutines resuelven el mismo problema — programación asíncrona — pero con enfoques fundamentalmente diferentes. RxJava está basado en el patrón Observer y es push-based: la fuente envía datos, el Observer reacciona. Las corrutinas son pull-based: el código solicita datos secuencialmente mediante await.

• RxJava — reactivo, flujo de datos, >200 operadores, push-based, curva de aprendizaje pronunciada
• Coroutines — secuencial, suspend/await, ~40 funciones, pull-based, sintaxis simple
• RxJava — maduro (2016), ecosistema enorme, pero curva de aprendizaje pronunciada
• Coroutines — moderno (2018), opción preferida de Google para código nuevo
• RxJava — backpressure incorporado mediante Flowable, estrategias de búfer probadas
• Coroutines — Flow con backpressure es reciente, pero activamente desarrollado por JetBrains

Según Google I/O 2024, Kotlin Coroutines es el enfoque recomendado para nuevo código asíncrono en Android. RxJava sigue siendo compatible para proyectos existentes. Google proporciona bibliotecas de puente (kotlinx-coroutines-rx3) para una migración gradual. AndroidX (LiveData, Room, Paging 3) soporta ambos enfoques, permitiendo usar RxJava en módulos antiguos y corrutinas en los nuevos sin conflictos de dependencias.

Estrategia de migración de RxJava a corrutinas

Transición gradual: cada nuevo componente se escribe con corrutinas, el código RxJava antiguo no se modifica. RxJava → corrutinas mediante awaitSingle() o awaitFirst(). Corrutinas → RxJava mediante future() o asFlowable(). La migración completa lleva de 6 a 18 meses para proyectos grandes.