El plan de optimización del "applet del lado del usuario" de la empresa existente WeChat operada por el usuario

El producto empresarial WeChat "C-end user applet" es una herramienta que sirve a agentes, tiendas y guías de compras fuera de línea en vivo, lo que ayuda a las guías de compras a conectar a los usuarios y comunicarse rápidamente con los usuarios. La cantidad de PU / UV basada en el "subprograma del lado C" es relativamente grande. Para una experiencia de usuario más extrema, es inevitable mejorar el rendimiento del subprograma.

1. Situación empresarial

1.1 "Mini programas cliente" de WeChat existentes operados por el usuario

El "subprograma de cliente" de WeChat, operado por el usuario, es principalmente una herramienta que sirve a agentes en vivo, tiendas fuera de línea y guías de compras, y ayuda a las guías de compras a conectar a los usuarios.

• Grupo de usuarios: usuarios fuera de línea en vivo.
• Funciones principales: preventa de nuevos teléfonos vivo y registro de nuevos usuarios.

Mire las páginas de "registro de nuevo usuario" y "preventa de nueva máquina" del "subprograma de cliente", de la siguiente manera:

Vivo registro de nuevo usuario 

Preventa de máquinas nuevas Vivo

1.2 Datos de rendimiento

Una imagen vale más que mil palabras. Eche un vistazo a las "descargas de paquetes de código, distribución de apertura que consume mucho tiempo, retraso de solicitud de red, tráfico de red" obtenido del "asistente de datos de programa pequeño" antes de la operación de usuario existente "usuario- El subprograma lateral "está optimizado. Consumo" y otros datos. como sigue:

En la figura, podemos ver que la descarga del paquete de código de programa pequeño se concentra principalmente en 2-5 segundos. Además, el retraso de tiempo de algunas interfaces de solicitud http es muy largo, lo que afectará el efecto de representación de la página en general. . Se puede ver que todavía hay mucho espacio para la optimización de los "applets del lado del usuario" operados por los usuarios existentes.

Dos, indicadores de desempeño

2.1 ¿Cómo definir alto rendimiento?

Simplemente ser rápido no es suficiente. No debemos simplemente considerar los indicadores de velocidad e ignorar la experiencia percibida del usuario, sino que debemos medir completamente cada nodo relacionado con la carga de la aplicación que el usuario puede percibir durante el uso.

2.2 Términos clave de los indicadores de desempeño

FCP: Fin de la carga de la pantalla blanca

FMP: representación de la primera pantalla completada

TTI: se carga todo el contenido

2.3 Los indicadores que debemos alcanzar para la optimización

Indicadores oficiales del miniprograma:

1. El tiempo de la primera pantalla no supera los 5 segundos.
2. El tiempo de renderizado no supera los 500 ms.
3. El número de llamadas a setData por segundo no supera las 20 veces.
4. Los datos de setData después de JSON.stringify no superan los 256 kb.
5. Los nodos WXML de la página tienen menos de 1000, la profundidad del árbol de nodos es inferior a 30 niveles y el número de nodos secundarios no supera los 60.
6. Todas las solicitudes de red devuelven resultados en 1 segundo.

Los indicadores que los usuarios existentes necesitan alcanzar en el funcionamiento del "applet cliente":

1. El tiempo de la primera pantalla no supera los 2,5 segundos.
2. El volumen de datos de setData no supera los 100 kb.
3. Todas las solicitudes de red devuelven resultados en 1 segundo.
4. El deslizamiento de componentes y el desplazamiento de listas largas no tienen sensación de retraso.

Tres, algunos conceptos básicos de pequeños programas

3.1 El marco subyacente del applet

El portador de renderizado final del subprograma sigue siendo el kernel del navegador, no el cliente nativo. El modelo de doble subproceso está habilitado:

1. Capa de vista: el hilo de vista web, responsable de habilitar diferentes vistas web para representar diferentes páginas de subprograma.
2. Capa lógica: un subproceso independiente ejecuta código JS, que puede controlar la lógica de la capa de vista.

3.2 Cómo iniciar el subprograma

1. Prepare el entorno operativo.

• Antes de que se inicie el mini programa, WeChat primero iniciará el entorno de doble subproceso y completará la inicialización y ejecución previa de la biblioteca básica del mini programa en el subproceso.

La biblioteca básica de subprogramas incluye la biblioteca básica WebView y la biblioteca básica AppService. La primera se inyecta en la capa de vista y la segunda se inyecta en la capa lógica para proporcionar las capacidades básicas del marco necesarias para su funcionamiento a nivel.

2. Descargue el paquete de código del programa pequeño.

3. Cargue el paquete de código de programa pequeño.

• En esta etapa, todos los archivos JS de página y sus archivos dependientes en el paquete principal se ejecutarán automáticamente.

Durante el proceso de registro de la página, la biblioteca básica llamará al método constructor de la página del archivo JS de la página para registrar la información básica de la página (incluidos los datos iniciales, los métodos, etc.).

4. Inicialice la página de inicio del subprograma. 

• Una vez que se carga el paquete de código del subprograma, la biblioteca básica encontrará la página de inicio de acuerdo con la ruta de inicio, inicializará una instancia de página basada en la información básica de la página de inicio y pasará la información a la capa de vista, que se procesará en combinación con estructura WXML, estilo WXSS e interfaz de datos inicial.

3.3 Mini Auditorías de herramientas de desarrollo de programas, una herramienta de puntuación de experiencias

(PD: Las auditorías de complementos de puntuación de la Mini Program Developer Tool pueden puntuar de forma integral el rendimiento, la experiencia de uso, la práctica, el estilo de la interfaz de usuario, la solicitud http y otras dimensiones del Mini Program. Se recomienda que los desarrolladores de Mini Program lo utilicen en el proyecto. desarrollo.)

4. Solución técnica de optimización de mini programas

4.1 Esquema para un inicio demasiado lento de programas pequeños

Solución 1: Se eliminan los archivos, funciones y estilos wxss inútiles y se cortan las importaciones innecesarias.

Opción 2: reducir los archivos de recursos estáticos en el paquete de código.

Excepto por algunas imágenes que deben colocarse en el paquete de código (como avisos anormales de la red), se recomienda que los desarrolladores coloquen imágenes, videos y otros recursos estáticos en la CDN.

Opción 3: Retroceda la lógica y optimice la lógica empresarial.

Intente escribir la lógica empresarial en el backend. Si hay un problema en línea, Tencent deberá revisar la versión del programa pequeño y el backend podrá liberar el código a tiempo.

Esquema 4: Carga de subpaquetes y predescarga de subpaquetes.

• Consulte el documento de plataforma abierta del miniprograma

• Subcontratación independiente

• Pre-descarga de subcontratos

Opción 5: Parte de la página es h5.

• El subprograma proporciona un componente de vista web, que admite el acceso a h5 en el subprograma. Si el código fuente del subprograma es demasiado grande, lo que afecta el tiempo de descarga, puede considerar degradar y transformar algunas páginas en h5.

• Para obtener más información, consulte el documento de vista web .

4.2 Soluciones para una pantalla blanca demasiado larga para programas pequeños

La etapa de pantalla blanca del subprograma: después de descargar el paquete de código del subprograma (es decir, finaliza la interfaz de inicio), la página completa la primera etapa de representación de pantalla, que es FMP (primer dibujo efectivo).

Dos factores que afectan la pantalla blanca:

• Tiempo de carga de los recursos de la red.
• Tiempo de renderizado.

Opción 1: habilitar el almacenamiento en caché local.

• Los datos obtenidos en la interfaz de solicitud se almacenan en el almacenamiento y no es necesario enviar algunos datos cada vez que se obtiene una solicitud http.

Solución 2: Realice una extracción previa al saltar a la página.

• Generalmente, los datos de la interfaz se obtienen cuando la página está cargada.
• Puede llamar a la interfaz http de la página siguiente antes de llamar a wx.navigateTo para almacenar los datos en la promesa global. Cuando se carga la página siguiente, puede obtener los datos directamente de la promesa.

(pd: cuando la página A está onHide o onUnload, la interfaz http de la página B se solicita a través de una promesa, y los datos se obtienen de la promesa cuando la página B está onload o onShow).

Opción 3: Solicitud de retraso para datos de renderizado no críticos.

• Divida las páginas en módulos principales (esqueleto, lista de datos) y módulos no principales (ventanas emergentes, etc.).
• La solicitud de datos del módulo no principal se puede retrasar en la carga, use setTimeout para solicitar la interfaz.

Solución 4: renderizado de pantalla dividida.

• Renderice módulos no principales en pantallas independientes.
• Como se muestra en la figura siguiente, configuramos el módulo A como la pantalla principal y los módulos B y C como la pantalla no principal. Después de renderizar el módulo A, se renderizan los módulos B y C.

Opción 5: pantalla de esqueleto.

• Se puede usar una pantalla de esqueleto con dimensiones estables para ayudar a realizar la ocupación real del módulo y la carga instantánea.

Opción 6: limitar el número de solicitudes http.

• El límite máximo de simultaneidad para wx.request (conexión HTTP) es 10.
• El límite máximo de simultaneidad de wx.connectSocket (conexión WebSocket) es 5.

Opción 7: Optimización de recursos de imagen.

• Utilice el formato WebP.
• Recorte de imágenes, compresión, Sprite
• Carga diferida de imágenes

4.3 Mejorar el rendimiento de la representación

Concepto: Al llamar a wx.navigateTo para abrir una nueva página, el marco del applet completará los siguientes pasos:

• Prepare un nuevo entorno de subprocesos de vista web, incluida la inicialización de la biblioteca básica.
• Comunicación de datos inicial desde la capa lógica a la capa de vista.
• La capa de vista construye un árbol de nodos (que incluye atributos de nodo, enlace de eventos y otra información) basado en los datos de la capa lógica y combinado con fragmentos WXML, y finalmente se combina con WXSS para completar la representación de la página.

La pérdida de renderizado de los applets se produce principalmente en el proceso de comunicación de datos y creación y actualización del árbol de nodos, y la dirección de mejorar la optimización del rendimiento de renderizado:

1. Reducir la frecuencia de comunicación entre hilos.
2. Reducir la cantidad de datos comunicados entre hilos.
3. Reducir el número de nodos WXML.

Opción 1: combinar llamadas setData.

Combine múltiples llamadas setData en una tanto como sea posible.

Solo coloque datos relacionados con la representación de la interfaz en Datos.

Opción 2: eliminar el enlace de eventos innecesario.

Hacer clic, tocar, onPageScroll innecesario no debe activarse.

Opción 3: eliminar atributos de nodo innecesarios.

El nodo de componente admite adjuntar un conjunto de datos de datos personalizado. Cuando se activa un evento de usuario, la capa de visualización transmitirá el objetivo del evento y los datos del conjunto de datos a la capa lógica. El siguiente ejemplo:

<view class="tabbar-item" wx:for="{{list}}" wx:key="index"  item="item">
  <view @tap="tabFn" data-index="{{item}}">
  </view>
</view>

methods = {
  tabFn (e) {
    const item = e.currentTarget.dataset['item'];
    console.log(item);
  }
};

Cuanto mayor sea la cantidad de datos personalizados, mayor será la duración de la comunicación del evento, así que trate de reducir la cantidad de datos personalizados o no utilice datos personalizados.

4.4 Resolver el problema del uso elevado de memoria de programas pequeños

Cuando el mini programa ocupa demasiados recursos del sistema, puede ser destruido por el sistema o reciclado activamente por el cliente WeChat, provocando que el mini programa se cuelgue.

Escenario 1: Recupere los temporizadores setTimeout y setInterval de la página.

Cada página del subprograma tendrá un hilo de vista web independiente, pero la capa lógica es de un solo hilo, es decir, todos los hilos de vista web comparten un hilo JS, de modo que cuando la página salta, el temporizador sigue funcionando.

Borre el temporizador cuando esté en Ocultar o en Descargar.

Opción 2: Evite las operaciones de memoria pesadas en eventos frecuentes.

• La devolución de llamada del evento onPageScroll usa la limitación.
• Evite las operaciones que requieren un uso intensivo de la CPU, como los cálculos complejos.
• Evite llamar a setData o reduzca la cantidad de datos en setData.

Cinco, el resultado optimizado

5.1 Mira el puntaje bajo auditorías

La puntuación antes de la optimización es la siguiente:

Después de la optimización, la puntuación es la siguiente:

Se puede ver que después de optimizar el rendimiento del subprograma de acuerdo con los pasos anteriores, la puntuación integral de las auditorías ha logrado una mejora significativa.

5.2 Después de la optimización, los datos de rendimiento en "Small Program Data Assistant"

Seis, resumen

La optimización del rendimiento del mini programa es lo mismo que la optimización H5. Es un proceso de iteración continua basado en diversos escenarios de usuario. También es un principio y tema que no podemos utilizar en nuestro desarrollo web diario. Este artículo analiza varios escenarios y soluciones para la optimización de mini programas, y espera que en el futuro proceso de desarrollo de proyectos, podamos continuar optimizando y creando mejores productos.

Autor: vivo-Fu Weilang