Optimización de la red de Android

fondo

En la era de Internet, la aplicación sirve como terminal para la interacción del usuario y los servicios son proporcionados por el servidor. La interacción entre la aplicación y el servidor depende de la red, por lo que la optimización de la red es un elemento de optimización indispensable en nuestra optimización de la aplicación. La calidad de la red de aplicaciones es La calidad afecta directamente a la experiencia del usuario.

Descripción general

Las principales direcciones de optimización de la red sonoptimización del tráfico , optimización de la calidad , pruebas fuera de línea y soluciones de monitoreo en línea . Este artículo hace un resumen completo del conocimiento sobre optimización de la red.El contenido principal es el siguiente:

1. Tres puntos clave de optimización de la red

multidimensional

La optimización de la red debe ser multidimensional, incluido el consumo de tráfico y la calidad de la red , no solo un aspecto.

Preciso

Al hacer estadísticas de tráfico de red necesitamos realizar mediciones precisas, si solo obtenemos el valor de consumo específico no nos será de mucha ayuda para localizar y solucionar problemas, porque este valor solo puede indicar cuánto tráfico ha utilizado el usuario. .
Si los usuarios en línea informan que la aplicación consume una gran cantidad de datos, pero no sabemos cuánto tiempo ha usado la aplicación en total, será difícil localizar el problema. Si el usuario ha usado la aplicación durante mucho tiempo , es posible que la App consuma más datos, es normal.
Otro ejemplo es que los usuarios informan que la aplicación consume mucho tráfico en segundo plano, pero solo contamos el valor general, por lo que no podemos determinar cuánto tráfico consume la aplicación cuando se ejecuta en segundo plano.

monitor

Para la optimización de la red, debemos construir un sistema de monitoreo de red integral y completo. No podemos monitorear solo un indicador. Si solo monitoreamos la tasa de éxito de la solicitud de red, entonces solo podemos conocer el uso aproximado de la red por parte del usuario. Este tipo de monitoreo de grano grueso no se puede hacer Ayúdenos a identificar y resolver la causa raíz del problema.
Por ejemplo, un usuario en línea usa una determinada función 1000 veces, luego ocurre una excepción una vez y la función vuelve a la normalidad después de que el usuario hace clic en Reintentar.
A juzgar solo por los datos, la tasa de éxito de las solicitudes de red sigue siendo relativamente alta, pero es imposible conocer la causa de esta excepción utilizando únicamente la tasa de éxito, y es imposible evitar tales excepciones en el futuro.

2. Dos dimensiones de la optimización de la red.

Dimensión de tráfico

La dimensión de tráfico es una medida precisa del consumo de tráfico de la Aplicación dentro de un período de tiempo .
El alto consumo de tráfico no solo afecta a los usuarios, sino que también afecta los costos operativos de la empresa, como el ancho de banda, el número de servidor, CDN, etc. Además, las solicitudes intensivas de red también tienen un cierto impacto en el consumo de energía de los teléfonos móviles.

En la dimensión del tráfico, debemos distinguir tipos, monitorear excepciones e informar registros.

• Distinguir entre tipos

No solo necesitamos conocer el consumo de tráfico específico del usuario dentro de un cierto período de tiempo, sino también conocer el consumo de tráfico del usuario en diferentes tipos de red (tráfico, WiFi) y distinguir el consumo de tráfico cuando la aplicación está en primer plano y en primer plano . fondo .
Sólo acumulando datos de diferentes dimensiones se pueden determinar y resolver rápidamente los problemas.

• Monitoreo de anomalías

Para las estadísticas de tráfico, no solo necesitamos conocer el consumo de tráfico promedio de los usuarios, sino también la tasa anormal de consumo de tráfico de los usuarios en línea.

Aquí hay tres tipos de excepciones:

• Consumo excesivo de datos
• Demasiadas solicitudes
• El archivo de descarga es demasiado grande

Estas tres son anomalías a las que debemos prestar atención.

• Registro de informes

La situación más ideal es que tengamos un seguimiento completo de todas las solicitudes de la red localmente y se registre toda la información relacionada con la Solicitud y Respuesta de cada solicitud.
El servidor puede emitir instrucciones para controlar que el cliente cargue estos datos, y el cliente también puede informar activamente los datos relevantes después de que excedan el umbral .

dimensión de calidad

La calidad de las solicitudes de red afecta directamente la experiencia real del usuario: si la velocidad de las solicitudes de red es lenta o la tasa de éxito de las solicitudes es baja, provocará una mala experiencia de usuario.

Para monitorear la calidad de las solicitudes de red, se puede distinguir de las siguientes dimensiones para que los problemas puedan localizarse y resolverse rápidamente en el futuro.

• Duración de la solicitud
• Tasa de éxito de la solicitud
• Tasa de cola larga (proporción de interfaces exitosas con solicitudes que duran >3 segundos)
• Tasa de fracaso
• Interfaz de falla superior
• Tasa de transferencia de conexión larga (indicador auxiliar)
• Tasa de conversión httpdns (indicador auxiliar)

Dos malentendidos sobre la optimización de la red

• Centrarse sólo en una dimensión

  Centrarse únicamente en una dimensión, como el consumo de tráfico o la calidad, ignora otras dimensiones.

• Ignorar datos individuales

  Además, cuando realizamos monitoreo de red, solo nos enfocamos en los datos promedio y generales, ignorando los datos individuales.
  Por ejemplo, en el ejemplo de tasa de éxito de la solicitud mencionado anteriormente, la tasa de éxito general es muy alta, pero este tipo de datos no puede ayudarnos a mejorar una sola solicitud.

3. Tres herramientas de prueba fuera de línea

Debemos tener una comprensión correcta del entorno de prueba fuera de línea. Las pruebas fuera de línea consisten en exponer tantos problemas como sea posible antes de conectarse. Durante el proceso de prueba fuera de línea, debemos prestar atención a los siguientes cuatro puntos.

• conmutación de red
• Prueba de red débil/sin red
• ¿La solicitud es incorrecta?
• ¿Hay algún error en la solicitud de la interfaz, como demasiados parámetros o parámetros incorrectos?
• ciclo largo

Una vez que la aplicación del lado C alcanza un período estable, el número de usuarios puede ser de decenas de millones o más. En este momento, las funciones de la aplicación son generalmente muy complejas e incluyen otras funciones, como la supervisión del rendimiento.
Las solicitudes de red para estas funciones a menudo no se informan en tiempo real, por lo que cuando realizamos pruebas de consumo de tráfico, el ciclo suele ser muy largo y no se puede probar simplemente durante 10 minutos.

Necesitamos asegurarnos de que nuestra aplicación haga las dos cosas siguientes al cambiar de red, a redes débiles o sin red .

• El proceso no se puede interrumpir.
  Algunas aplicaciones tienen requisitos de seguridad relativamente altos. Si el estado de la red cambia repentinamente, el estado de inicio de sesión del usuario no será válido, lo que significa que se le pedirá que inicie sesión nuevamente.
  En este momento, debemos prestar atención a si la aplicación volverá al proceso anterior después de iniciar sesión nuevamente y no puede interrumpir el proceso en curso del usuario.
• Cierre la ventana emergente de carga
  y asegúrese de probar si la ventana emergente de carga se detendrá en condiciones de red débil o sin red. Si no tiene cuidado, la solicitud de la aplicación fallará cuando no haya red, pero la ventana emergente de carga- La ventana superior no se cerrará y afecta otras operaciones del usuario.
  Si no presta suficiente atención al estado fuera de línea, no podrá detectar dichos errores.

Echemos un vistazo a tres herramientas de prueba fuera de línea de uso común:

• Network Profiler (Network Inspector en la última versión de Android Studio Flamingo, en App Inspection)
• Charles
• esteto

3.1 Perfilador de red (inspector de red)

Network Profiler (Network Inspector) es una herramienta de análisis de red que viene con AS y puede mostrar actividades de red en tiempo real, como solicitudes de red enviadas, datos recibidos y el número de conexiones.
El autor aquí usa Android Studio Flamingo , por lo que aquí se presenta Network Inspector.
Network Inspector muestra la actividad de la red en tiempo real en una línea de tiempo, incluidos los datos enviados y recibidos. Network Inspector le permite examinar cómo y cuándo su aplicación transmite datos y optimizar el código subyacente de manera adecuada.

1. En la barra de navegación de Android Studio, seleccione Ver > Ventanas de herramientas > Inspección de aplicaciones. Después de que la ventana de inspección de la aplicación se conecte automáticamente al proceso de solicitud, seleccione Network Inspector en la pestaña

Puede ver la Vista de conexión . A la derecha está la información de una determinada conexión, incluido el tiempo de solicitud, la respuesta, la solicitud y la
vista de subprocesos de la pila de llamadas . Muestra la actividad de red de cada subproceso de CPU de la aplicación. Puede verificar qué subprocesos están responsable de cada solicitud de red.
Vista de reglas , Reglas ayuda a probar cómo se comporta la aplicación cuando encuentra respuestas con diferentes códigos de estado, encabezados y cuerpos.
En la sección Respuesta , la respuesta se puede modificar antes de enviarla a la aplicación. Por ejemplo, las reglas se pueden configurar para Una respuesta con un código de estado específico ejecuta y modifica ese código de estado.
Modificar encabezado

En la sección Reglas de encabezado, puede crear varias subreglas para agregar o modificar encabezados en la respuesta.

Al crear varias reglas de encabezado, use las flechas hacia arriba y hacia abajo en la parte superior de la tabla de reglas para cambiar el orden de las reglas de encabezado, lo que afecta los encabezados de respuesta modificados porque las reglas de encabezado se aplican en el orden en que aparecen.

Se pueden agregar reglas haciendo clic en + en la sección Reglas de encabezado y luego ingresando el nombre y el valor del encabezado en la sección Agregar nuevo encabezado.
Para modificar el encabezado , puede especificar el nombre o valor del encabezado que se encontrará en la pestaña Editar encabezado existente e ingresar el nombre o valor del encabezado que se reemplazará.
La pila de llamadas
de información de respuesta de solicitud de información Charles y Stetho no se presentará aquí, aquellos que estén interesados ​​pueden aprender sobre ella ellos mismos.

4. Tres puntos clave del seguimiento online

Antes de analizar la obtención del tráfico de red, primero veamos los tres puntos clave del monitoreo en línea: monitoreo del servidor, monitoreo del cliente y monitoreo de excepciones.
2.1 Monitoreo del servidor

1. Dimensión estadística que requiere mucho tiempo

Para el monitoreo del lado del servidor, debemos prestar atención al tiempo que consumen las solicitudes, y el tiempo que requiere distinguirse en múltiples dimensiones.

地域

具体是哪个省、哪个城市的请求速度比较慢；

时间段

版本

机型

2. Tasa de fracaso

El servidor necesita contar la tasa de falla:

请求失败

业务失败

业务相关的失败也是失败，比如网络请求确实成功了，但是用户没有拿到自己需要的数据，对于失败率的统计要全面，这样衡量的指标才能更敏锐地感知线上的异常波动；

3. Interfaz de falla superior

Al mismo tiempo, en el contexto de APM, será mejor que cuentemos las principales interfaces fallidas o interfaces anormales dentro de un período de tiempo, como 1 día o 1 semana, y realicemos estadísticas de vez en cuando, para que podamos saber qué interfaces son inestables, para que podamos llevar a cabo una optimización específica.

4. Tasa de cola larga:
   la proporción de interfaces con una duración de solicitud superior a 3 segundos
5. Tasa de conversión de conexiones largas
   Proporción de interfaces que utilizan conexiones largas
6. Tasa de conversión de httpdns
   Proporción de interfaces que utilizan httpdns

2.2 Monitoreo de clientes

El monitoreo del lado del cliente es más crítico que el monitoreo del lado del servidor, y el monitoreo del lado del cliente es más completo y puede obtener más datos.

Los datos que queremos monitorear en línea incluyen el tiempo de solicitud específico, la tasa de éxito, el código de error y el tiempo necesario para cada paso de carga de la imagen.

Aunque el tiempo de carga de la imagen y la tasa de éxito se pueden medir en el lado del servidor, los datos obtenidos por el servidor están incompletos porque muchas solicitudes fallan antes de llegar al servidor.

Además, los datos transmitidos desde el servidor más el tiempo de retardo del canal de red definitivamente serán más largos que el tiempo contado por el servidor, por lo que también debemos agregar estadísticas sobre el cliente.

1. Monitoreo de API

El cliente puede obtener información sobre cada paso de la solicitud, incluido el tiempo de resolución de DNS, el tiempo de establecimiento de la conexión, el tiempo de solicitud, el tamaño del paquete de red y otra información.

Al mismo tiempo, podemos registrar la operación de cada solicitud de red por parte del usuario, como qué interfaces se solicitaron específicamente, si la solicitud fue exitosa y el motivo del error. Podemos pasar esta información al servidor APM como información básica para Monitoreo. Más adelante presentaremos cómo monitorear la red en cada paso del camino.
2. Monitoreo de imágenes

Al mismo tiempo, preste atención al monitoreo de imágenes: una imagen puede consumir más tráfico que los datos de 5 o más interfaces.
3. Mecanismo de recuperación ante desastres de la red

Si el número de nuestros usuarios aumenta repentinamente un día, es posible que el servidor no pueda soportar la presión. Para el servidor, se puede usar un servidor de respaldo para desviar el tráfico y evitar que el servidor principal caiga.

Y nuestro cliente también puede hacer una estrategia, es decir, si la solicitud de red falla varias veces dentro de un cierto período de tiempo, ya no realizará solicitudes de red.
3.2 Monitoreo anormal

El propósito del monitoreo de anomalías es mejorar nuestra sensibilidad a las anomalías, en lugar de esperar pasivamente los comentarios de los usuarios.

1. Servidor anti-cepillo

En el lado del servidor, debemos determinar si alguien está cepillando nuestro servidor, lo cual es un ataque malicioso. Si detectamos que alguien está cepillando el servidor, podemos bloquear la IP y denegar el acceso a estas IP.
2. Secreto anormal

En el lado del cliente, podemos agregar capacidades de advertencia activa. Por ejemplo, si descargamos un archivo que excede el valor establecido, el cliente puede informar el resultado al servidor después de la descarga, indicando que se ha encontrado una anomalía y una confirmación adicional por parte de I+D. Se requiere estudiantes.

En algunos escenarios, el servidor puede tener demasiado tráfico y no puede manejarlo. En este caso, el cliente puede adoptar una estrategia de encubrimiento. Si dentro de un cierto período de tiempo, como 30 segundos, la solicitud de interfaz falla 5 veces en una fila, no se permitirá. Sigue accediendo y configura el tiempo de reintento más largo.
3. Seguimiento de problemas de un solo punto

Si los usuarios en línea informan que la aplicación consume demasiado tráfico o consume mucho tráfico en segundo plano, podemos analizar los registros de solicitudes de red del usuario y emitir comandos para verificar el consumo de tráfico en un período de tiempo específico.

5. Tres soluciones de monitoreo en línea

Algunos problemas solo aparecen en línea y no se pueden encontrar sin conexión. Por ejemplo, cuando se prueba una determinada versión sin conexión, es posible que el paquete H5 no sea necesariamente una nueva versión, pero una vez que se conecta, algunos usuarios pueden verse afectados y se lanza una nueva versión. paquete.

Si estos paquetes no están comprimidos, dichas anomalías no se pueden descubrir en el entorno de prueba fuera de línea y solo se pueden descubrir mediante la supervisión en línea.

Echemos un vistazo a tres soluciones de monitoreo en línea:

OkHttp 事件监听器
NetworkStatsManager
TrafficStats

Entre estas tres soluciones, el detector de eventos OkHttp puede obtener los datos más detallados y prácticos, mientras que NetworkStatsManager y TrafficStats se utilizan principalmente para obtener el consumo de tráfico.

5.1 detector de eventos OkHttp

5.1.1 Oyente de eventos personalizado

Combinado con OkHttp para obtener datos de calidad de solicitudes de red, OkHttp nos deja una devolución de llamada de EventListener de escucha de eventos, que podemos implementar nosotros mismos y monitorear cada solicitud.

5.1.2 Personalizar GlideModule

Personalizar GlideModue es monitorear el proceso de carga de imágenes. Veamos cómo monitorear los datos relacionados y que consumen mucho tiempo del proceso de carga de imágenes de Glide.

5.1.3 Número máximo de solicitudes simultáneas de OkHttp

Con respecto a la frecuencia de las solicitudes, podemos observar el grupo de solicitudes predeterminado de OkHttp. En el distribuidor Dispatcher de OkHttp, hay un grupo de subprocesos de ejecución de Servicio. Su tamaño de grupo principal es 0 y el valor máximo es el valor máximo del número entero.

Pero esto no significa que se puedan enviar innumerables solicitudes de red enviadas a través de OkHttp al mismo tiempo. Para tareas con uso intensivo de IO, podemos enviar más, porque dichas tareas no consumen mucha CPU, pero aún debemos prestar atención a la cantidad de subprocesos que una sola App puede crear. También hay un límite superior para el número.

5.1.4 Distinguir entre tráfico delantero y trasero

La razón por la que necesitamos distinguir entre el tráfico frontal y posterior en el registro es porque a muchos usuarios les preocupa que la aplicación haya estado consumiendo tráfico en segundo plano. Si solo obtenemos los datos de tráfico de manera gruesa, no lo sabremos. cuánto tráfico consume la aplicación mientras se ejecuta en segundo plano, sin mencionar la resolución de los problemas informados por los usuarios, ni siquiera el problema de posicionamiento se puede solucionar.

5.1.5 Cuatro pasos para cargar datos

Los siguientes son aproximadamente cuatro pasos para generar informes de registros de rendimiento.

后台任务

在 App 启动时，执行一个后台任务；

间隔统计

这个任务每隔一段时间（如 30 秒内）就获取网络数据；

自定数据

自己维护一份数据统计，给数据加上标志，记住用户在前后台的流量消耗总量；

上报数据

在合适的时机（如用户反馈、达到阈值、处于 WiFi 网络下）把数据上报到 APM 后台，这样对用户的流量就不会造成影响，而且数据也能作为流量治理依据；

5.2 Administrador de estadísticas de red

NetworkStatsManager es un administrador de estadísticas de tráfico después de API 23. Puede obtener información de tráfico durante un cierto período de tiempo y consumo de tráfico en diferentes tipos de red. Su mayor desventaja es que la experiencia del usuario es relativamente pobre y el usuario necesita activar "Ver uso". "permisos.

Los siguientes son algunos escenarios que utilizan la red o consumen mucho tráfico.

API 请求

升级包

各种升级的资源包，比如 App 升级包、WebView 使用的 H5 Zip 包、RN 使用到的 bundle 包等；

配置

在 App 做大后，还要用到各种配置信息，比如做 A/B 测试时使用的配置信息、运营活动下发的配置信息；

图片

图片是流量消耗的大户，图片的下载和上传都非常消耗流量；

监控

在 App 做大后，还会做各种监控功能，比如 APM 监控的各种数据都需要网络才能上传到服务端；

5.2.1 Tres puntos clave de la optimización del tráfico

Antes de hablar sobre cómo utilizar NetworkStatsManager para obtener el consumo de tráfico, primero debemos comprender los tres puntos clave de la optimización del tráfico.

1. No te limites a mirar valores absolutos

El valor absoluto no se puede utilizar como único criterio estadístico para un alto consumo de tráfico, no se puede decir que la aplicación consuma 10 millones de tráfico, por lo que debe optimizarse de inmediato.

La comparación de valores absolutos no tiene sentido. Por ejemplo, si usa la aplicación durante 30 minutos y busca muchos productos o videos, entonces 10 millones pueden considerarse muy poco.

2. Comparar productos de la competencia

Entonces, ¿cuál debería ser el estándar? Lo mejor para nosotros es comparar productos de la competencia y comparar el consumo de datos de dos aplicaciones en el mismo escenario.

Por ejemplo, si ejecuta un proceso principal para publicar comentarios con productos de la competencia, debe prestar atención aquí para asegurarse de que los comentarios publicados por las dos aplicaciones sean los mismos y que las imágenes también sean las mismas para garantizar que las variables sean únicas.

En esta comparación, si la brecha en el consumo de tráfico entre nosotros y los productos de la competencia es relativamente grande, entonces deberíamos acelerar el ritmo de optimización del tráfico. Este valor absoluto debe compararse con los productos de la competencia y debe usarse en combinación.

3. Establecer expectativas

Necesitamos juzgar el consumo de tráfico de la nueva función. Por ejemplo, esperamos que después de que el usuario use la nueva función, el consumo de tráfico único sea de aproximadamente 300 K, pero si excede los 300 K después de conectarse, debemos confirmar si El consumo de tráfico es alto.

6. Tres soluciones de optimización del tráfico

6.1 Almacenamiento en caché de datos

6.1.1 Caché OkHttp

Si seguimos cuidadosamente las interfaces en nuestros proyectos, encontraremos que muchas interfaces no tienen requisitos tan altos para el rendimiento en tiempo real. El uso de caché no solo puede ahorrar tráfico, sino que también puede mejorar en gran medida la velocidad de acceso a los datos.

Nuestras bibliotecas de red de uso común, como OkHttp y Volley, tienen mejores prácticas de almacenamiento en caché.

Además, no almacenar en caché no es bueno para la experiencia del usuario. Generalmente, la aplicación mostrará una interfaz sin datos después de abrirla. En comparación con los últimos datos mostrados, esta experiencia del usuario es en realidad relativamente pobre.

6.1.2 Tiempo de caducidad y actualización incremental

1. Vencimiento

Agregue un tiempo de vencimiento a los datos devueltos por el servidor, para que podamos juzgar si han caducado cada vez que los solicitamos, si no ha caducado no es necesario volver a solicitarlos.

2. Actualización incremental

La idea específica de la actualización de datos incremental es agregar el concepto de versión a los datos: cada vez que se reciben datos, se compara la versión y solo se reciben los datos modificados.

De esta forma, la cantidad de datos transmitidos se reducirá considerablemente. Por ejemplo, datos como provincias, ciudades y configuraciones rara vez se actualizan. Si tienes que solicitar datos de provincias, ciudades y ciudades cada vez, esto es un desperdicio. del tráfico.

6.2 Compresión de datos

1. zip

Para las solicitudes de publicación, el cuerpo se comprime con Gzip, es decir, el encabezado de la solicitud Gzip se incluye al realizar la solicitud, y también se agrega compresión Gzip cuando el servidor regresa, para que el flujo de datos se comprima.
2. Comprimir los encabezados de las solicitudes

El encabezado de la solicitud también ocupa un cierto volumen. Cuando el encabezado de la solicitud permanece sin cambios, solo podemos pasarlo una vez. En el futuro, solo necesitamos pasar el valor MD5 del último encabezado de la solicitud. El servidor crea un caché. Cuando algunos de los encabezados de solicitud son necesarios. Cuando se recupera información, se puede recuperar directamente del caché anterior.
3. Fusionar solicitudes de red

Cada solicitud de red tendrá información redundante, como encabezados de solicitud, y la combinación de solicitudes de red puede reducir la transmisión de información redundante;

6.3 Compresión de imágenes

1. miniatura

El primer método de compresión de imágenes es dar prioridad a las miniaturas en la lista, porque mostrar la imagen original aumentará el consumo de memoria y el consumo de tráfico, y no tiene sentido mostrar la imagen original directamente en la lista.

La siguiente es una comparación del tamaño de la imagen original y la miniatura: el tamaño de la miniatura es el 50% de la imagen original y el tamaño es el 10% de la imagen original.

2.WebP

El segundo método de compresión de imágenes es utilizar el formato Webp. La siguiente es una comparación de la misma imagen en formato PNG y formato WebP. El tamaño del formato WebP es el 51% del formato PNG.
3.Luban

Por ejemplo, cuando subimos una imagen, si está comprimida localmente y es una imagen de 2 M, subirla por completo no tiene mucho sentido, solo aumentará nuestro consumo de tráfico, es mejor comprimirla antes de subirla.
El tamaño original de la imagen a continuación es 1,6 M. Después de la compresión, se convierte en 213 KB y el volumen es el 13% del tamaño original.

7. Optimización de la calidad de las solicitudes de red.

Anteriormente aprendimos sobre la optimización del tráfico de solicitudes de red, pero de hecho, lo que más daña la experiencia del usuario es la mala calidad de las solicitudes de red. Muchos estudiantes ignoran esto.

Debido a que generalmente usamos WiFi en la empresa para realizar pruebas durante la fase de desarrollo o prueba, y la calidad de la red es relativamente buena, suponiendo que nuestra aplicación no tenga grandes problemas con el consumo de datos, los usuarios a menudo informan que la interfaz no se puede abrir y es lenta. abre y no puede cargar imágenes, y otros problemas.

En este momento, es probable que los usuarios desinstalen nuestra aplicación y cambien a productos de la competencia. Solo cuando la calidad de la solicitud de red es alta, la experiencia del usuario es buena y continúan usando nuestra aplicación, es probable que los usuarios encuentren problemas de consumo de tráfico, por lo que relación de optimización de la calidad de la red La optimización del tráfico es más crítica.

Dos indicadores para la optimización de la calidad de la red:

网络请求成功率
网络请求速度
(辅助指标：长尾率，长连接转化率，httdns转化率)

Estos dos indicadores afectarán la experiencia del usuario. Antes de introducir la optimización de la calidad de las solicitudes de red, primero veamos el proceso de la siguiente solicitud HTTP.

发出请求

客户端发出一个请求，这个请求到达运营商的 DNS 服务器，然后被解析成对应的 IP 地址；

创建连接

第二步就是创建连接，会走 TCP 三次握手，然后根据 IP 地址找对对应的服务器，发送一个请求；

返回资源

服务器找到对应的资源，然后原路返回给客户端；

Una solicitud de red se puede dividir simplemente en dos partes : conectarse al servidor -> obtener datos .

El proceso de resolución de DNS también se incluye antes de conectarse al servidor , los datos pueden almacenarse .

7.1 Dirección de optimización de la calidad

Estrategia de optimización del servidor de conexión.

7.1.1 HTTPDNS

Primero, veamos cómo optimizar el paso de emisión de solicitudes. La tasa de éxito y la velocidad de las solicitudes de red se ven afectadas por el servidor DNS. Si el proceso de resolución de nuestro DNS a dirección IP es secuestrado o la resolución DNS es lenta, afectar seriamente la experiencia del usuario.

El resultado del secuestro de DNS es que los datos que obtiene el usuario no son los datos que realmente queremos proporcionarle. Si la resolución del DNS es lenta, el usuario tendrá que esperar más tiempo para recibir la solicitud.

Por lo tanto, la optimización DNS es el primer paso en la optimización de la calidad de la red. Usamos HttpDNS para evitar el proceso de resolución de nombres de dominio del operador. HttpDNS no usa el protocolo DNS tradicional para enviar solicitudes al puerto 53 del servidor DNS. En su lugar, usa el protocolo Http protocolo para enviar solicitudes al puerto 53 del servidor. Enviar solicitud al puerto 80.

Hay dos beneficios al hacer esto:

防劫持

降低 Local DNS 劫持，绕过运营商域名解析过程；

提升速度

降低平均访问时长，因为节省了一次解析过程；

Tanto Tencent Cloud como Alibaba Cloud proporcionan servicios HttpDNS. Para una implementación específica, consulte sus documentos oficiales.

1. No se requiere nombre de dominio, conexión directa vía IP

Se omite el proceso de resolución de DNS. El nombre completo de DNS es Sistema de nombres de dominio. La resolución significa obtener la dirección IP correspondiente en función del nombre de dominio.

Por ejemplo, el resultado de la resolución del nombre de dominio de www.codekk.com es 104.236.147.76.

La resolución del primer nombre de dominio generalmente demora varios cientos de milisegundos. Este tiempo se puede ahorrar solicitando directamente la IP en lugar del nombre de dominio y, al mismo tiempo, se pueden prevenir los riesgos causados ​​por el secuestro de nombres de dominio.

Por supuesto, por razones de seguridad y expansión, esta IP puede ser una lista de IP actualizada dinámicamente y se puede acceder a ella a través del nombre de dominio cuando la IP no está disponible.

2. Implementación razonable del servidor

Los servidores son implementados por múltiples operadores y múltiples ubicaciones, que generalmente incluyen al menos tres operadores principales y se implementan en el sur, el centro y el norte.

Junto con la lista de IP dinámica mencionada anteriormente, admite prioridad y selecciona la IP del servidor óptima para la conexión cada vez según la región, el tipo de red, etc.

Para el lado del servidor, también puede ajustar el tamaño de la ventana de congestión TCP del servidor, el tiempo de espera de retransmisión (RTO), la unidad máxima de transmisión (MTU), etc.

7.1.2 Optimización de la versión del protocolo HTTP

Acabo de mencionar que el segundo paso de la solicitud de red es crear una conexión, lo que implica un protocolo de enlace de tres vías TCP. Este proceso es relativamente largo. Si cada solicitud requiere un protocolo de enlace de tres vías, la eficiencia es relativamente baja.

Por lo tanto, las diferentes versiones de Http tienen muchas optimizaciones en este punto. Las siguientes son las principales diferencias entre las diferentes versiones del protocolo Http.

HTTP 1.0

Es una versión anterior. Es raro ver servicios usando esta versión ahora. Su mayor desventaja es que las conexiones TCP no se reutilizan. Cada conexión TCP solo puede enviar 1 solicitud. Si desea solicitar otros recursos, debe volver a establecer una conexión.

El costo de crear una conexión con TCP es muy alto, requiere tres apretones de manos y la velocidad de envío es relativamente lenta al principio, lo que significa que el rendimiento de HTTP 1.0 es muy pobre.

HTTP 1.1

HTTP 1.1 apareció solo medio año después que 1.0. Su mayor cambio es la introducción de conexiones persistentes. A partir de esta versión, no están cerradas de forma predeterminada y pueden ser reutilizadas por múltiples solicitudes de red, lo que mejora enormemente la eficiencia.

Todavía tiene algunas fallas, es decir, aunque permite la reutilización de TCP, todas las comunicaciones de datos en la misma conexión TCP deben estar en orden, es decir, después de procesar una solicitud, responder a la siguiente solicitud.

Si la solicitud de red anterior es lenta, las solicitudes posteriores tendrán que esperar.

HTTP 2.0

Http 2.0 es un protocolo binario. Su mayor mejora es que el cliente y el servidor pueden enviar múltiples solicitudes y respuestas al mismo tiempo. No es necesario realizar solicitudes secuenciales como Http 1.1. Es una comunicación bidireccional en tiempo real.

Esta es la mayor mejora de Http 2.0 en comparación con Http 1.1. Cuando desee cooperar con el servidor en el futuro, si tiene la opción, intente elegir una versión superior del protocolo Http.

Utilizando el protocolo qiuc
QUIC (Quick UDP Internet Connection) es un conjunto de protocolos de transmisión basados ​​en UDP lanzados por Google que implementa las funciones de TCP + HTTPS + HTTP/2, con el objetivo de garantizar la confiabilidad y reducir la latencia de la red . Debido a que UDP es un protocolo de transmisión simple, UDP puede deshacerse de la confirmación de transmisión TCP, el inicio lento de la retransmisión y otros factores . Solo toma un tiempo de ida y vuelta para establecer una conexión segura. También implementa multiplexación HTTP/2, compresión de encabezados, etc. Función.
Es bien sabido que UDP tiene una velocidad de transmisión más rápida que TCP, TCP es un protocolo confiable, pero el precio es una serie de consumos en los que incurren ambas partes para confirmar los datos. En segundo lugar, TCP es implementado por el kernel del sistema. Si actualiza el protocolo TCP, debe permitir que el usuario actualice el sistema. El umbral para esto es relativamente alto. QUIC es gratuito para ser utilizado por el cliente basado en UDP, siempre y cuando ya que hay un servidor que puede conectarse.

7.1.3 Optimización del capital

La última solución de optimización es gastar dinero: los métodos comunes incluyen la aceleración de CDN, el aumento del ancho de banda y la separación de recursos dinámicos y estáticos.

Todos deben tener en cuenta que después de usar CDN, si es necesario actualizar un recurso, el caché debe borrarse después de que se complete la actualización. Estas optimizaciones no involucran al cliente. Al mismo tiempo, no olvide reducir la transmisión. volumen y preste atención al momento y la frecuencia de las solicitudes. Esto es lo mismo que está relacionado con la optimización del tráfico de la que hablamos anteriormente.

Obtenga estrategias de optimización de datos

1. Reutilización de la conexión

Ahorre tiempo de establecimiento de conexión, como activar keep-alive.

Para Android, keep-alive está habilitado de forma predeterminada tanto para HttpURLConnection como para HttpClient. Es solo que antes de 2.2, HttpURLConnection tenía errores que afectaban el grupo de conexiones. Para más detalles, consulte: http://www.trinea.cn/android/android-http-api-compare/

2. Solicitar fusión

Es decir, se combinan varias solicitudes en una sola solicitud, la más común son los Sprites de imágenes CSS en la página web.

Si hay demasiadas solicitudes en una página determinada, también puede considerar fusionar ciertas solicitudes y utilizar el método de solicitud bff .

3. Reducir el tamaño de los datos de la solicitud

(1) Para solicitudes POST, el cuerpo se puede comprimir con Gzip , como registros.

(2) Comprimir encabezados de solicitud

Esto no es compatible con HTTP 1.1, pero sí con SPDY y HTTP 2.0.

Http 1.1 puede almacenar en caché el encabezado de la solicitud anterior a través del servidor, y el mismo encabezado de solicitud en solicitudes posteriores se puede representar mediante una identificación como md5.

4. CDN almacena en caché recursos estáticos

Caché de imágenes comunes, JS, CSS y otros recursos estáticos.

5. Reducir el tamaño de los datos devueltos

(1) Compresión

Generalmente, los datos API utilizan la compresión Gzip. La siguiente imagen es una imagen comparativa antes y después de la compresión Gzip probada antes.

(2) Formato de datos simplificado

Por ejemplo, JSON reemplaza a XML y WebP reemplaza a otros formatos de imagen.

(3) Diferentes redes devuelven contenido diferente para diferentes dispositivos

Como tamaños de imagen de diferentes resoluciones.

(4) Actualización incremental

Cuando se requieren actualizaciones de datos, se pueden considerar actualizaciones incrementales. Por ejemplo, es común que el servidor realice bsdiff y el cliente realice bspatch.

(5) Descarga de archivos grandes

Admite la reanudación del punto de interrupción y almacena en caché el identificador ETag de Http Resonse y lo trae con la siguiente solicitud para determinar si los datos han cambiado. Si no ha cambiado, devolverá directamente 304.

6. caché de datos

Los datos obtenidos del caché se pueden leer directamente del caché cuando se solicitan nuevamente dentro de un cierto período de tiempo.

Con respecto a las reglas de almacenamiento en caché Http, Grumoon tiene una introducción detallada en la charla final sobre el análisis del código fuente de Volley, que se puede ver:

http://codekk.com/blogs/detail/54cfab086c4761e5001b2542

Otros métodos de optimización

Este tipo de método de optimización se ha introducido por completo en la serie de optimización del rendimiento general.

1. Precarga

Incluyendo datos de preconexión y captación previa.

2. Priorizar y retrasar algunas solicitudes

Retrasar solicitudes sin importancia no solo puede reducir la carga máxima y la concurrencia, sino también fusionarla con solicitudes similares posteriores.

3. múltiples conexiones

Para archivos más grandes, como imágenes grandes y descargas de archivos, considere conexiones múltiples.

Es necesario controlar la concurrencia máxima de solicitudes, después de todo, la red móvil es limitada.

4. Divida las etapas de las solicitudes de red que consumen más tiempo y optimice las etapas que consumen más tiempo.
5. Optimice los interceptores de red y optimice los interceptores que consumen mucho tiempo
6. Optimice la interfaz de falla superior
7. Utilice una conexión larga por socket para mejorar la tasa de conversión de una conexión larga a través de la interfaz
8. Mejorar la tasa de conversión de la interfaz httpdns.
9. Optimización de interfaz para servicios específicos.
10. Considere la situación de la interfaz bajo IPV4 e IPV6
11. Considere la tasa de éxito y la latencia de las interfaces front-end y back-end.

Artículos de referencia
para explorar los métodos de optimización de la red de Android.
Puntos de conocimiento que debe conocer sobre la optimización de la red de Android.
Explorar los métodos de optimización de la red de Android
. Exploración en profundidad de la optimización de la red de Android (Parte 2, Conceptos básicos de optimización de la red).
Exploración en profundidad de la optimización de la red de Android. (Parte 3, Optimización de red) en
Android Optimización del rendimiento (7) Optimización de red
Explore los métodos de optimización de red de Android Optimización de red de Android
: optimización de DNS
Utilice Network Inspector para verificar el tráfico de red

Android Studio Flamingo | Lanzado en 2022.2.1, venga y vea qué actualizaciones están disponibles