Los pozos encontrados en RxJava se actualizan continuamente ...

Pozo encontrado en RxJava

1. Creación ilimitada de hilos

El uso de .subscribeOn (Schedulers.io ()) en una solicitud de sondeo puede provocar la creación ilimitada de hilos.

Schedulers es uno de los componentes principales de RxJava. Responsable de ejecutar operaciones observables en diferentes subprocesos, de modo que las tareas que consumen mucho tiempo se pueden asignar a otros subprocesos.

Aquí debemos comprender las propiedades y el uso de los diferentes Programadores en Programadores:
Uno de los
programadores más comunes de IOScheduler . Se utiliza para operaciones relacionadas con IO. Como solicitudes de red y operaciones de archivos. El programador de E / S es compatible con el grupo de subprocesos.
Primero crea un hilo de trabajo, que se puede reutilizar para otras operaciones. Por supuesto, cuando este hilo de trabajo (en el caso de una tarea larga) no se puede reutilizar, se creará un nuevo hilo para manejar otras operaciones. Este beneficio también trae algunos problemas, porque permite que se creen subprocesos ilimitados, por lo que cuando se crea una gran cantidad de subprocesos, tendrá algún impacto en el rendimiento general.

subscribeOn(Schedulers.io())

ComputationScheduler es
un programador intensivo en computación. Schedulers.computation () se usa para tareas de computación, como bucles de eventos o procesamiento de devolución de llamada, y no debe usarse para operaciones de E / S (use Schedulers.io () para operaciones de E / S); el número de subprocesos de ComputationScheduler está relacionado con la CPU El núcleo está estrechamente relacionado, porque cuando el número de subprocesos supera con creces el número de núcleos de CPU, el tiempo de la CPU se pierde más en el cambio de contexto de los subprocesos. El número predeterminado de subprocesos es igual al número de procesadores

subscribeOn(Schedulers.computation())

Single
es compatible con un hilo. Entonces, no importa cuántos Observables haya, solo se ejecutarán en este hilo.

subscribeOn(Schedulers.single())

Inmediato
Este programador inicia su tarea de forma bloqueada en el hilo actualmente activo (rxjava2 lo ha eliminado), ignorando la tarea que se está ejecutando actualmente. Se puede ignorar el uso de RxJava2.

subscribeOn(Schedulers.immediate())

Trampoline
Este programador se ejecuta en el hilo actual, por lo que si tiene código ejecutándose en el hilo principal, agregará el bloque de código que se ejecutará en la cola del hilo principal. Es muy similar a Immediate, excepto que Immediate bloqueará este hilo y Trampoline esperará a que se complete la tarea actual. Es adecuado para escenarios donde hay más de un Observable y se espera que se ejecuten en secuencia.

subscribeOn(Schedulers.trampoline())
Observable.just(1,2,3,4)
    .subscribeOn(Schedulers.trampoline())
    .subscribe(onNext);
 Observable.just( 5,6, 7,8, 9)
    .subscribeOn(Schedulers.trampoline())
    .subscribe(onNext);
 Output:
    Number = 1
    Number = 2
    Number = 3
    Number = 4
    Number = 5
    Number = 6
    Number = 7
    Number = 8
    Number = 9

Executor Scheduler () es
más como un programador de E / S personalizado. Podemos crear un grupo de subprocesos personalizado especificando el tamaño del grupo de subprocesos. El número de Observables adecuados para su uso en escenarios donde hay demasiados programadores de E / S se utiliza de la siguiente manera:

Scheduler ioOne = Schedulers.from(Executors.newFixedThreadPool(5));
Scheduler fixScheduler = Schedulers.from(ioOne)
subscribeOn(fixScheduler)

El Programador de Android es
proporcionado por la biblioteca rxAndroid, que se usa para cambiar las operaciones al hilo principal para operar la interfaz de usuario, y a menudo se usa en el método observeOn. Úselo de la siguiente manera:

AndroidSchedulers.mainThread()

observeOn(AndroidSchedulers.mainThread())

La razón por la que hay una creación infinita de hilos en el caso de las solicitudes de sondeo está muy relacionada con la implementación de IOScheduler, cuando la tarea se ha ejecutado o es demasiado tarde para liberar el hilo anterior, se creará un nuevo hilo. Entonces la situación extrema es que el tiempo de entrenamiento es demasiado corto para que el hilo anterior no haya completado la tarea de liberar, primero creará un hilo, esta vez debemos usar el programador del Programador del Ejecutor para personalizar la cantidad de grupos de hilos.

Scheduler ioOne = Schedulers.from(Executors.newFixedThreadPool(5));
Scheduler fixScheduler = Schedulers.from(ioOne)
2.El intervalo y el operador se utilizan juntos, una excepción en la operación del operador interrumpirá todo el intervalo
Observable.interval(tripInterval, TimeUnit.SECONDS)
                    .flatMap((Function<Long, ObservableSource<Response<TripResult>>>) aLong ->
                            AppDelegateImpl.getInstance()
                                    .getInfoService()
                                    .getTripInfo())
                    .subscribeOn(SchedulerPoolHelper.getInstance().getIoTrip())
                    .observeOn(AndroidSchedulers.mainThread())
                    .subscribe(new NetConsumer<TripResult>() {
                        @Override
                        public void onSuccess(TripResult result) {
                            processTripState(result);
                        }
                    }, throwable -> {
                        LogUtils.d("Trip: " + throwable.getMessage());
                    });

Por ejemplo: regreso y solicito una interfaz cada tripInterval segundos. Ponemos la interfaz de solicitud en el operador flatMap en el medio. Una vez que la solicitud falla debido a un tiempo de espera de solicitud o datos sucios, todo el intervalo se interrumpirá.
Este problema hizo que nuestra solicitud fallara una vez debido a una red deficiente, y luego no hay más solicitudes.

Entonces, en este caso, anidé la solicitud en el onSuccess del Consumidor para que no se interrumpa.

Observable.interval(tripInterval, TimeUnit.SECONDS)
                .subscribeOn(SchedulerPoolHelper.getInstance().getIoTrip())
                .subscribe(aLong -> {
                    AppDelegateImpl.getInstance().getInfoService()
                            .getTripInfo()
                            .subscribeOn(SchedulerPoolHelper.getInstance().getIoTrip())
                            .observeOn(AndroidSchedulers.mainThread())
                            .subscribe(new NetConsumer<TripResult>() {
                                @Override
                                public void onSuccess(TripResult result) {
                                    processTripState(result);
                                }
                            }, throwable -> LogUtils.d(TAG, "Trip: " + throwable.getMessage()));
                });

Después de consultar algunos materiales, no se encontraron buenas soluciones, si los jefes tienen diferente concisión, pueden dejar un mensaje en el área de mensajes para proponer diferentes soluciones.

referencia

Supongo que te gusta

Origin blog.csdn.net/u011148116/article/details/106788781
Recomendado
Clasificación