Uso básico y análisis de principios de la biblioteca de solicitudes de red de Android [OkHttp4.9.3]

OkHttp es un conjunto de bibliotecas dependientes que se utilizan para manejar solicitudes de red Http. Diseñado y desarrollado por Square y de código abierto, actualmente está disponible en Java y Kotlin. Para las aplicaciones de Android, OkHttp ahora representa casi todas las operaciones de solicitud de red, y renovación + OkHttp parece ser un estándar para implementar solicitudes de red. Por lo tanto, también es una habilidad necesaria para todo ingeniero de desarrollo de Android. Comprender sus principios de implementación internos puede expandir, encapsular y optimizar mejor sus funciones.

La eficiencia de OkHttp se refleja en:

El primer paso: Crear OkHttpClient. Hay dos formas de crear OkHttpClient:

OkHttpClient proporciona métodos de configuración enriquecidos, como agregar interceptores, especificar grupos de conexiones, configurar tiempos de espera de solicitudes, etc.

Paso 2: Crear una solicitud

Utilizar la solicitud. Builder() para construir la instancia de solicitud.

Paso 3: Iniciar una solicitud de red

OkHttp admite solicitudes sincrónicas y asincrónicas.

El uso de OkHttp es muy simple. Se puede iniciar una solicitud sincrónica o asincrónica simple en tres pasos. También podemos configurar fácilmente solicitudes de red, como agregar encabezados de solicitud, configurar modos de solicitud, configurar tiempos de espera de solicitud, etc. Estos parámetros de configuración se describirán en detalle durante el análisis del código fuente.

Ahora que hemos aprendido cómo iniciar una solicitud de red en tres pasos, usaremos estos tres pasos como punto de partida para profundizar en el código fuente y aprender los principios de implementación de OkHttp. , comencemos.

Hay dos formas de crear OkHttpClient. Veamos en qué se diferencian.

El primero usa el constructor predeterminado directamente y aún usa el modo constructor internamente.

El segundo modo es utilizar constructores.

Ambos métodos finalmente llaman al constructor OkHttpClient(builder:builder), y el generador de parámetros es responsable de toda la configuración de parámetros.

OkHttp funciona mejor cuando crea una única instancia de OkHttpClient y la usa para todas las llamadas Http. Esto se debe a que cada OkHttpClient tiene su propio grupo de conexiones y grupo de subprocesos. La reutilización de conexiones e hilos reduce la latencia y ahorra memoria. Por el contrario, crear un cliente para cada solicitud desperdicia recursos en el grupo gratuito.

La solicitud también se crea en modo constructor. Aquí se publican algunos códigos fuente importantes, que no se explicarán de forma sencilla.

OkHttp tiene dos formas de iniciar solicitudes de red: solicitudes sincrónicas y solicitudes asincrónicas. Solo analizamos el proceso de solicitud asincrónica, porque siempre que comprenda el proceso de solicitud asincrónica, básicamente podrá comprender la solicitud sincrónica.

RealCall es un puente que conecta la capa de aplicación y la capa de red, responsable de procesar conexiones, solicitudes, respuestas y flujos de datos.

Dispatcher mantiene un conjunto de estrategias de ejecución de tareas asincrónicas. Antes de analizar la estrategia, introduzcamos varios conceptos importantes:

Client.dispatcher.enqueue (llamada asíncrona (devolución de llamada de respuesta)) realiza los siguientes pasos:

AsyncCall implementa la interfaz Runnable. una vez procesado por un subproceso en el grupo de subprocesos, se llamará a su método run():

Sin más preámbulos, comenzamos a analizar la cadena de responsabilidad del interceptor:

Ejecución del proceso de la cadena de responsabilidad: primero obtenga el interceptor actual y llame a interceptor.intercept (siguiente) para realizar operaciones de interceptor. Lo siguiente aquí representa el objeto de cadena de responsabilidad después del índice + 1. El método intercept () del interceptor llamará al método next.proceed (solicitud) para ingresar a la cadena de responsabilidad nuevamente. Dado que se agregó 1 al índice en este momento, se procesará el siguiente interceptor.

Repita este ciclo hasta que se procese el último interceptor de la cadena de responsabilidad.

Tenga en cuenta que, excepto el último interceptor, CallServerInterceptor, que no llamará al método chain.proceed(request), todos los interceptores deben llamar al método chain.proceed(request) al menos una vez.

Para verificar la conclusión anterior, ingresamos al método intercept() de RetryAndFollowUpInterceptor para buscar:

Puedes ver que el comentario 1 vuelve a ingresar a la cadena de responsabilidad para procesar el próximo interceptor.

Si estás interesado, puedes ver el código fuente del último interceptor CallServerInterceptor. Aquí, solo doy mi conclusión después de leer el código fuente:

Lo anterior es el flujo de trabajo de la cadena de responsabilidad del interceptor. Lo sentiremos cuidadosamente a través del diagrama de flujo.

Después de analizar la cadena de responsabilidad del interceptor, continuamos analizando el método AsyncCall#run():

Podemos ver que si el método getRespondwithInterceptorChain() obtiene con éxito los datos devueltos por el servidor, método de devolución de llamada de respuesta. Llame a onResponse (this @ realcall, Response) para completar la devolución de llamada asincrónica. Si falla la recopilación de datos del servidor (solicitud de excepción), complete la devolución de llamada asincrónica llamando a la devolución de llamada de respuesta. en caso de error (este @ realcall, excepción cancelada).

Cabe señalar que la respuestaCallback se completa en un hilo secundario, por lo que si desea mostrar datos en la interfaz de usuario, debe volver al hilo principal para las operaciones de la interfaz de usuario.

Todo el proceso de OkHttp para iniciar solicitudes de red:

Puntos de conocimiento Principio de OkHttp 8 preguntas consecutivas