fondo
Con la continua innovación de la tecnología de Internet y el rápido desarrollo de la industria de la televisión, ver vídeos en línea a través de la televisión se ha convertido gradualmente en un importante método de entretenimiento para el público. Como una de las aplicaciones con mayor actividad de usuario en dispositivos de TV, la aplicación Kiwi ofrece una gran cantidad de servicios de reproducción de contenido para los usuarios. Además, también ofrece operaciones de membresía, eventos especiales y otros servicios que requieren una eficiencia en línea extremadamente alta para el usuario. Para satisfacer las demandas de este último, investigamos las principales tecnologías dinámicas y cross-end actuales: H5, Flutter y React Native, y finalmente elegimos la solución H5 desde la perspectiva de la eficiencia del desarrollo, el costo laboral, las capacidades dinámicas y el rendimiento. la página H5 es responsable de Maneja una gran cantidad de cajeros, actividades operativas, temas especiales y otros negocios en la aplicación Kiwi. Sin embargo, la principal dificultad que enfrentamos es que la página H5 tarda demasiado en cargarse en dispositivos de TV. Cómo mejorar la experiencia del usuario de las páginas H5 en dispositivos de TV es un problema que debemos resolver con urgencia.
Desafíos enfrentados
Desafío 1: El ciclo de reemplazo de los equipos de TV es largo y el problema de fragmentación del sistema es grave. Actualmente, los equipos con un sistema de TV por debajo de 5.0 representan alrededor del 30%, lo cual es una proporción muy alta. Lo primero que enfrenta la optimización es la variedad de versiones, y la compatibilidad con versiones inferiores es la consideración principal. La siguiente figura muestra la proporción de versiones del sistema de TV:
Desafío 2: El rendimiento de los equipos de TV es bajo. Los equipos de TV se dividen principalmente en tres tipos: TV, caja y proyector. La configuración de los equipos anteriores es muy inferior a la configuración de los teléfonos móviles convencionales del mismo período. Clasificación, la CPU es 4. Un dispositivo con una arquitectura central A53 y más de 1,5 G de memoria se puede clasificar como un dispositivo de alto rendimiento. Entre los dispositivos de bajo rendimiento, todavía hay muchos dispositivos con procesadores de arquitectura A7 o 512 M de memoria.
Desafío 3: Las versiones de las aplicaciones están seriamente fragmentadas. Debido a la complejidad de la situación de cooperación actual en la industria de la televisión, hay muchos fabricantes de televisores tradicionales que buscan estabilidad y son más cautelosos con las actualizaciones, y hay muchos dispositivos baratos a la venta; casi no tienen mantenimiento después de la venta; la complejidad del modelo de cooperación genera mucha personalización y dificultad en la actualización, lo que plantea grandes desafíos para la optimización y el lanzamiento a nivel de SDK.
Proceso de optimización
1. Preparación
Antes de la optimización, el trabajo más importante es unificar el calibre del desempeño y formular indicadores estadísticos. A nivel de calibre, no tomamos el tiempo de carga de la página de inicio convencional, sino que adoptamos un escenario que está más en línea con la experiencia real del usuario: desde el momento en que el usuario hace clic en el botón hasta el momento en que es visible para el usuario real. usuario. Aunque esto aumentará el consumo de tiempo general de nuestros indicadores estadísticos, después de la evaluación, este indicador es más propicio para la dirección de nuestro trabajo de optimización posterior. El calibre del indicador se explica a continuación.
1) El tiempo que tarda la página en ser visible: comenzando desde el clic del cliente -> salto de la página del cliente -> inicialización del contenedor web -> la representación DOM del front-end está completa y es visible.
2 ) El tiempo total de interacción: el tiempo visible de la página + el tiempo total que puede responder al botón del control remoto del usuario.
3) La página nativa requiere mucho tiempo: el salto a la página del cliente requiere mucho tiempo.
4) Inicialización de la vista web: la inicialización del contenedor web lleva mucho tiempo.
5) Se necesita tiempo para llamar a h5: se necesita tiempo para ejecutar la primera línea de código desde loadUrl hasta h5.
6) El tiempo que tarda en cargar h5: El tiempo que tarda h5 en comenzar a ejecutar la primera línea de código hasta que sea visible en la página.
7) Se necesita tiempo para que h5 sea interactivo: se necesita tiempo para que la página h5 sea visible y responda.
Una vez unificados los estándares estadísticos, entregaremos los puntos de tiempo anteriores a nivel de webSDK, recopilaremos datos en línea y llevaremos a cabo una optimización específica basada en los problemas que arrojan los indicadores. Sin optimización, la velocidad de carga de H5 es de unos 5,5 segundos en promedio y la experiencia del usuario es muy pobre. A través del análisis de datos en línea, el tiempo de carga de H5 ocupa una gran proporción del total. La optimización del tiempo de carga de H5 es un problema que debemos resolver con urgencia.
2. Optimización del tiempo de carga H5
El tiempo de carga de H5 depende principalmente de la optimización de la parte frontal. Debido a la extensión limitada del artículo, el trabajo de optimización de la página H5 convencional no se describirá en detalle, como por ejemplo:
2) Fusión de solicitud de datos
3) Optimización de la lógica empresarial
4) optimización de la estructura DOM
5) Carga de enrutamiento asíncrono en diferentes modos bajo la misma dirección
3. Optimización SSR
Además de la optimización anterior, tenemos a la vista la tecnología SSR (preprocesamiento del lado del servidor). SSR es una tecnología que optimiza el rendimiento de las aplicaciones web y el SEO. Al generar HTML inicial en el lado del servidor, mejora la velocidad de carga de la página y. Rendimiento del motor de búsqueda y experiencia del usuario. Al elegir el marco apropiado, crear rutas, escribir componentes, configurar el servidor y adquirir datos, los desarrolladores pueden implementar la representación del lado del servidor, brindando así a los usuarios una mejor experiencia de aplicación web y garantizando una representación más rápida de la primera pantalla.
Este método de reducir la presión de procesamiento en el extremo es muy adecuado para escenarios donde el rendimiento del equipo final de TV es deficiente. Aunque SSR también tiene sus propias desventajas, por ejemplo, aunque puede mejorar la velocidad de carga general de la página, no favorece la carga progresiva de la página. Después de repetidos experimentos y datos en línea, todavía creemos que los beneficios generales de la RSS son positivos y hemos iniciado la investigación y el desarrollo. Los experimentos han demostrado que la solución SSR mejora significativamente la velocidad de carga de las páginas H5.
El proceso de carga de la página H5 optimizado a través de SSR se muestra en la siguiente figura:
Después de optimizar las soluciones front-end mencionadas anteriormente, la velocidad de carga de cada versión se ha mejorado significativamente. El tiempo dedicado a la parte de renderizado H5 se redujo de un promedio de 4 segundos a menos de 1,5 segundos, y el tiempo total se redujo a aproximadamente 3,5 segundos. En este momento, continuar optimizando exclusivamente desde la perspectiva del front-end ha encontrado un cuello de botella y la relación entrada-salida también es baja. Es necesario seguir pensando en los métodos de optimización desde la perspectiva general del cliente.
4. Almacenamiento en caché de recursos sin conexión
CDN implementará algunos recursos clave H5 (como css, js, png, ttf, etc.), muchos de los cuales no cambian durante el ciclo de la versión front-end y son grandes, y el cliente los descargará previamente en el momento adecuado. . Al representar la página, podemos usar la devolución de llamada shouldInterceptRequest del kernel WebView para interceptar la solicitud de carga de la URL H5 en línea. Si el recurso no se encuentra en el caché fuera de línea, se cargará a través de la red en línea; encontrado en el caché fuera de línea, se cargará directamente. Lee los recursos del disco local y regresa a WebView. Este método puede mejorar enormemente la velocidad de carga de recursos.
El diagrama de flujo general de la solución de almacenamiento en caché sin conexión es el siguiente:
Al mismo tiempo, durante el proceso, descubrimos que la biblioteca de solicitudes nativa de Android HttpUrlConnection en versiones inferiores todavía se encuentra en la etapa http1.0 y no puede disfrutar de la optimización de http2.0 (como la reutilización de canales), lo que hace que la solicitud durante La precarga consume más tiempo. Actualmente hay una gran cantidad de dispositivos de versión baja en el lado del televisor con versiones inferiores a 5.0, por lo que optamos por cambiar a la biblioteca de red desarrollada independientemente por el lado del televisor. Esta biblioteca de red admite http2.0, mejorando así el rendimiento de las solicitudes. Dispositivos de baja versión. Además, vemos que hay un cierto tiempo de programación del sistema desde el momento en que el usuario hace clic hasta que se abre la página H5. Este tiempo también se puede utilizar para la optimización, es decir, la carga paralela que se menciona a continuación.
5. Carga paralela
Además de las soluciones mencionadas anteriormente para almacenar en caché JS/CSS y otros recursos por adelantado, el almacenamiento en caché de páginas HTML por adelantado también es un método de optimización común en la industria. Antes de que la página sea SSR, este mecanismo de almacenamiento en caché no ha logrado buenos resultados porque. El cuello de botella en el rendimiento no está en la descarga de datos HTML. Después de que la página SSR haya entrado en nuestro campo de visión, este mecanismo de almacenamiento en caché teóricamente puede desempeñar un papel más importante.
Pero al mismo tiempo, encontramos otras dificultades. Dado que los algoritmos personalizados se han utilizado ampliamente en los negocios, el método de almacenar en caché las páginas por adelantado y mantener el contenido sin cambios durante un cierto período de tiempo ha creado un conflicto con el requisito comercial de mantener la página. datos actualizados en tiempo real. Esto requiere que encontremos soluciones técnicas optimizadas que sean más adecuadas para escenarios comerciales.
El sistema Android consumirá tiempo del sistema al realizar el cambio de salto de página de Actividad. Este consumo de tiempo es inversamente proporcional al rendimiento del dispositivo. Interceptamos el clic del usuario en la página web mientras cambia de página para iniciar la tarea por adelantado y cargar el SSR del. Página H5 en paralelo con datos. Luego, se genera un token único basado en la URL y los parámetros de la cookie. Cuando llegue el momento de representar WebView, redirija la URL al caché. Al mismo tiempo, se utilizan mecanismos de tiempo de espera y sincronización de bloqueo de subprocesos múltiples para mejorar aún más la velocidad de carga de H5.
El diagrama de flujo general de la solución de carga paralela es el siguiente:
Después de completar estas optimizaciones, nuestra velocidad de carga continuó optimizándose de 3,5 segundos a aproximadamente 2,8 segundos, un aumento de aproximadamente el 23%. Después de una serie de medidas de optimización mencionadas anteriormente, nuestro tiempo de carga H5 se redujo del promedio inicial de 5,5 segundos a aproximadamente 2,8 segundos. Sin embargo, en comparación con las páginas nativas puras, todavía existe una gran brecha en la velocidad de carga y debemos continuar buscando métodos de optimización más efectivos. Para mejorar aún más la experiencia del usuario, hemos realizado varios intentos técnicos y, a través de la comunicación activa y la cooperación con otros equipos técnicos, tenemos nuevas ideas.
6. Precalentamiento del contenedor
Cuando se inicia la aplicación y el hilo principal está inactivo, podemos precalentar el motor WebView y crear un grupo de caché de WebView, de modo que el contenedor precalentado pueda reutilizarse y mejorar la velocidad de carga de WebView. Esta estrategia de optimización está dirigida principalmente a dispositivos de rendimiento medio a alto y a dispositivos de bajo rendimiento con gran memoria. Cuando el dispositivo está inactivo, precalentamos el contenedor WebView y agregamos el contenedor precalentado al grupo de caché.
En nuestro uso posterior, obtenemos el contenedor WebView precalentado directamente del grupo de caché de WebView. Esto ahorra tiempo al crear contenedores web y jscore.
7. Representación previa de la página
H5 en el lado de la televisión tiene muchas restricciones en escenarios comerciales en tiempo real, especialmente actividades operativas que son muy urgentes, lo que impone ciertas restricciones a nuestra optimización. Sin embargo, hemos encontrado algunos escenarios que se pueden personalizar y optimizar. Por ejemplo, cuando los usuarios que no son miembros ven contenido exclusivo para miembros, generalmente hay un tiempo de prueba gratuito de 6 minutos una vez finalizado el tiempo de prueba, y saltarán automáticamente. a H5. Este tipo de escenario nos brinda ventajas naturales para el renderizado previo. En escenarios similares, el renderizado previo se activa automáticamente cuando comienza la cuenta regresiva, lo que permite cargar el contenido H5 por adelantado y lograr el efecto de apertura instantánea de H5. Como se muestra en el GIF a continuación, la imagen superior es el proceso de carga sin optimización, y puede ver la pantalla negra obvia y el proceso de carga. La imagen inferior es el resultado de la optimización previa al renderizado, logrando un verdadero lanzamiento segundo a segundo;
Después de completar las medidas de optimización anteriores y comparar los datos del mismo período del año pasado, podemos ver en los datos en línea que el tiempo de carga se ha reducido aún más, desde el promedio inicial de 5,5 segundos en escenarios sin SSR y 3,5 segundos en SSR. escenarios al promedio actual de 2 segundos. Ha mejorado significativamente la experiencia del usuario.
Logros
Realizamos experimentos AB sobre la optimización al final. Los datos de prueba después de dividirlos y promediarlos mostraron que nuestras medidas de optimización aumentaron la tasa de conversión de la página de generación de pedidos en aproximadamente un 21% en promedio, y la tasa de conversión de la tasa de éxito del pago también aumentó en un 2,4% en promedio.
Los experimentos han demostrado que mejorar la velocidad de carga y la experiencia del usuario de las páginas comerciales clave tiene un impacto positivo muy directo en el negocio, lo que también nos brinda suficiente confianza y motivación para continuar promoviendo la optimización en el futuro.
plan futuro
En el futuro, esperamos encontrar más formas de reducir aún más los indicadores de rendimiento, controlar el tiempo promedio de página a menos de 2 segundos y controlar la degradación.
Además, hemos notado que los datos promedio no reflejan completamente la experiencia del usuario real. Algunos usuarios de cola aún enfrentan una mala experiencia de usuario. Continuaremos analizando la situación real que encontraron los usuarios después del percentil 90 y realizaremos una optimización específica. Al mismo tiempo, continuaremos realizando optimizaciones personalizadas para escenarios comerciales importantes, como el mostrador de pago, para mejorar aún más la velocidad de carga de negocios clave, mejorando así continuamente la experiencia del usuario y la conversión comercial.
Quizás tú también quieras ver
Este artículo se comparte desde la cuenta pública de WeChat: Equipo de productos de tecnología iQIYI (iQIYI-TP).
Si hay alguna infracción, comuníquese con [email protected] para eliminarla.
Este artículo participa en el " Plan de creación de fuentes OSC ". Los que están leyendo pueden unirse y compartir juntos.
