"Descripción simple de okhttp3 versión 4.9.3

Acerca de okwork.

Observe los datos tal como se transmitirán a través de la red.

Accede a la conexión que aloja la solicitud.

Para resumir, puede deducir la estructura secuencial de toda la cadena. Si toda contiene interceptores personalizados e interceptores de red personalizados, entonces es CustomInterceptor->RetryAndFollowUpInterceptor->BridgeInterceptor->CacheInterceptor->. >CustomNetworkInterceptor->CallServerInterceptor; Entonces, ¿cómo se ejecuta la cadena en orden? okhttp Aquí hay un diseño más sutil. Cuando se utiliza información de índice para construir un objeto RealInterceptorChain, el índice registra la ubicación de una única cadena de interceptor RealInterceptorChain.proceed (solicitud: Solicitud) se incrementa a través de index ++ y la cadena de responsabilidad se ejecuta paso a paso. paso hasta el final de la cadena.

Analicemos brevemente el proceso de avance:

1. El parámetro constructor de RealInterceptorChain lleva información de índice, que se incrementa a través de index++ y se ejecuta continuamente a través del método proceder.

2. El interceptor implementa uniformemente la interfaz del interceptor y la interfaz se divierte (solicitud: Solicitud): la respuesta garantiza la vinculación de la cadena. Por supuesto, el orden de los interceptores se organiza de acuerdo con ciertas reglas, que se analizarán aquí una por una.

1. El interceptor de reintentos especifica que el número predeterminado de reintentos es 20.

2. Con respuesta = realChain.proceed(request) como punto divisorio, incluidos otros interceptores, la responsabilidad El trabajo realizado antes de pasar la cadena es el trabajo del prefacio, y luego la solicitud se envía al siguiente interceptor.

3. La lógica del código después de respuesta = realChain.progress (solicitud) es el trabajo de seguimiento, es decir, obtener el resultado de la respuesta del interceptor anterior, que es un poco recursivo según la ejecución. método de la cadena de responsabilidad, ha sido Los resultados obtenidos por el interceptor anterior se envían hacia arriba a cada interceptor para procesar la respuesta de finalización. Algunos trabajos de posprocesamiento.

4. Por supuesto, no todas las solicitudes pasarán por toda la cadena. Por ejemplo, si CacheInterceptor obtiene una respuesta en caché cuando el almacenamiento en caché está activado (hay un caché), los interceptores posteriores no continuarán. para pasar.

1. El interceptor de puente intercepta principalmente la información solicitada por Hader, incluida la longitud del contenido.

2. Pase la solicitud a la siguiente cadena y espere a que se devuelva la información de respuesta.

3. Las operaciones posteriores al pedido incluyen agregar cookies, información de compresión gzip, User-Agent y otra información.

1. El interceptor de caché no está habilitado de forma predeterminada. El directorio de caché debe especificarse al llamar. El caché del disco interno se implementa en función de DiskLruCache.

2. Después de activar el caché, si se accede al caché, la cadena de llamadas no continuará transmitiéndose (ya tenemos una respuesta en este momento), sino que realizará directamente la operación posterior a la secuencia. .

3. Si falla, continúe pasando a la siguiente cadena, a saber, ConnectInterceptor.

1. Establezca un enlace TCP o TCP-TLS con el servidor de destino.

2. El interceptor anterior tiene una operación de pedido anticipado basado en el método realChain.proceed() antes de llamarlo, pero ConnectInterceptor es diferente. No tiene operación de pedido posterior y, en cambio, se delega al siguiente. interceptador.

1. Esencialmente, es una solicitud y una operación de E/S que escribe los datos solicitados en el socket.

2. Lea los datos de respuesta del puerto correspondiente del Socket TCP/TCP-TLS. Para operaciones de E/S basadas en okio, sin el soporte de okio, no se pueden lograr solicitudes okhttp eficientes.

3. Incluya una operación de posprocesamiento antes de devolver la respuesta de datos al interceptor. A excepción de ConnectInterceptor, ConnectInterceptor no tiene operaciones posteriores.

El diagrama de flujo completo del interceptor es el siguiente:

1. Excepto en casos extremos (System.exit() u otros), no importa si ocurre una excepción o si hay un regresa antes de que finalmente se ejecuten los bloques finalmente.

2. Independientemente de si el bloque de código de prueba contiene un retorno, el bloque de código finalmente siempre se ejecuta antes del retorno.

3. Si hay un retorno en el bloque de código finalmente, entonces el retorno en el bloque de código de prueba y el bloque de código de captura no tendrán oportunidad de ejecutarse.

Consejo: Es muy importante devolver el método ejecutar () en la segunda conclusión. Dispatcher.finished (this) se ejecuta antes de que se devuelva el resultado de respuesta. Consulte la implementación específica de terminado (. ).

1.#1 Método 1, call.remove(call) devuelve verdadero, es decir, la solicitud de sincronización se elimina y se libera de runningSyncCalls, por lo tanto, idleCallback está vacío.

2. #3 Obviamente, el resultado de asyncCall está vacío y no hay ninguna solicitud asincrónica. Veamos la implementación específica del n.° 4. El tamaño de runningSyncCalls es 1, por lo que el resultado de isRunning es verdadero. . idleCallback.run() no se ejecuta y idleCallback es realmente verdadero. Y idleCallback en realidad está vacío.

1. Inicie la tarea de solicitud sincrónica desde OkHttpClient().newCall(request).execute().

2. Obtenga el objeto RealCall como la única clase de implementación de Call, en el que el método sincrónico ejecutar () está bloqueando, y la llamada bloqueará la ejecución hasta que se devuelva el resultado, o call().execute () se ejecutará inmediatamente. Hasta que se devuelva el resultado o se produzca un error y se interrumpa el bloqueo.

3. Ejecute el método de solicitud de ejecución sincrónica () en RealCall y ejecute el despachador de tareas asincrónicas Dispatcher en la instancia de OkHttpClient. Dispatcher agrega la instancia de RealCall solicitada a la deque de runningSyncCalls.

4. Abra la cadena de responsabilidad del interceptor de solicitudes a través del método getResponseWithInterceptorChain() en RealCall, que envía las solicitudes una por una manteniendo presionado el índice e incrementando las operaciones.

Tanto ConnectInterceptor como CallServerInterceptor tienen un chain.proceed(solicitud) como punto de demarcación entre las operaciones de pedido previo y las operaciones posteriores al pedido. Se procesan en orden después de obtener la respuesta.

5. Antes de que finalmente se devuelva la respuesta, la tarea de sincronización en curso se eliminará de la cola en el método finalmente client.dispatcher.finished(this), y el resultado final es client.dispatcher.finished( este) método. Finalmente, en el método, el resultado final, la respuesta, se devolverá al cliente y finalizará todo el proceso de solicitud sincrónica.

Github

Cuadrado.