Optimización de tamaño de paquete pequeño (uni-app)

 

fondo

En el proceso de desarrollo de los applets de WeChat, a medida que la lógica comercial se hizo más y más grande, surgieron algunos problemas.

En primer lugar, descubrimos que en el modo de desarrollo, el tamaño del paquete local ha alcanzado los 4 m+. En este caso, ya no es posible usar la depuración de dispositivos reales en el modo de desarrollo.

En segundo lugar, en este momento, hay alrededor de 1,8 millones después de que se construya el applet. Además, hay una gran cantidad de requisitos comerciales que se desarrollarán en el futuro, y el tamaño del paquete definitivamente será mayor.

En este momento, desea optimizar el tamaño del paquete pequeño. Permítanme compartir mi proceso de posicionamiento e ideas de solución. Aunque usamos el desarrollo uni-app, pero la idea es general, espero poder brindarle algo de ayuda.

Cómo reducir el tamaño del paquete

análisis de código

Primero analice dónde está el tamaño del paquete.

Abra el directorio de código nativo para ver el tamaño del archivo. Se puede encontrar que js representa la mayoría de common/vendor.js y la página y los componentes.

En el modo de compilación de compilación, se ha habilitado la compresión de código y es necesario considerar otros métodos de optimización. En este momento, puede usar el complemento webpack-bundle-analyzer . Puede ayudar a analizar qué módulos js están en vendor.js, qué módulos son relativamente grandes, para que podamos optimizar aún más el código.

A través de este complemento, se encontraron los siguientes dos problemas.

Problema 1: la compilación del movimiento del árbol en el modo de componente personalizado de una aplicación no es válida

Si no está utilizando el desarrollo uni-app, puede omitir este párrafo

A través del análisis de código, se encuentra que algunos módulos deberían ser sacudidos, pero están empaquetados. Básicamente se determina que la sacudida del árbol no tiene efecto.

Lo mismo es webpack4 + babel7. Con la premisa de usar directamente el proyecto vue-cli create sin usar uni-app, la agitación del árbol no es un problema. Sin embargo, cuando se usa uni-app para crear un nuevo proyecto, la sacudida del árbol no es válida.

Al verificar la configuración de babel, se encontró que uni-app establece módulos: 'commonjs' al crear el proyecto. Después de la modificación, el movimiento del árbol de la demostración está bien. Pero cuando volví al proyecto y lo compilé, ocurrió otro error. Continúe localizando y descubra que se trata de un problema de compilación del modo de componente personalizado de una aplicación . Actualmente, uni-app ha solucionado el error que mencioné, aunque aún no se ha lanzado oficialmente.

Por supuesto, puede resolverlo sin usar la compilación del modo de componente personalizado uni-app. Uni-app también lo admite template模板模式, pero habrá algunas diferencias de desarrollo y brechas de rendimiento. Si está interesado, puede leer este artículo

Problema 2: algunas bibliotecas no admiten la agitación de árboles

Algunas bibliotecas (como lodash) no usan importar/exportar por sí mismas, por lo que el paquete web no puede sacudirlas. Podemos optimizar estas bibliotecas según la situación.

En primer lugar, puede averiguar si existe una versión de esm correspondiente a la biblioteca en Internet que se pueda reemplazar, como lodash-es.

En segundo lugar, se puede ver a partir del análisis del código que si cada módulo de la biblioteca está en un archivo diferente y el archivo de entrada es solo una entrada unificada, podemos cargarlo a pedido modificando el método de escritura, como

import add from "lodash/add";
import Button from 'ant-design-vue/lib/button';
复制代码

También podemos usar babel-plugin-importcomplementos para implementar uniformemente la carga bajo demanda para esas bibliotecas. Su esencia es modificar uniformemente la ruta de carga de acuerdo con la configuración en el momento de la compilación, sin modificar manualmente el código por su cuenta.

Al final, si no funciona, acéptalo o vuelve a escribirlo tú mismo para contribuir a la comunidad~

Desarrollo de módulos de especificación

Para evitar el problema de no poder sacudir el árbol, también debemos seguir ciertas especificaciones al desarrollar módulos npm, para reducir el tamaño de los módulos empaquetados.

Admite el módulo commonjs y es al mismo tiempo

Nuestro módulo debe ser compatible con los módulos commonjs y es. Solo de esta manera no solo podemos satisfacer a los usuarios desarrollados por commonjs, sino también admitir el movimiento del árbol.

¿Cómo? Si su código es mecanografiado, tome @sentry/browser como ejemplo, puede compilar los códigos de especificación cjs y esm en tiempo de compilación, de la siguiente manera

// package.json
"build": "run-s build:dist build:esm build:bundle",
"build:bundle": "rollup --config",
"build:dist": "tsc -p tsconfig.build.json",
"build:esm": "tsc -p tsconfig.esm.json",
复制代码

Luego especifique dos entradas y ningún efecto secundario en package.json

  "main": "dist/index.js",
  "module": "esm/index.js",
  "sideEffects": false,
复制代码

De esta manera, cuando el paquete web analice los módulos ( reglas de análisis ), priorizará el análisis del directorio esm según sea necesario. Y realice sacudidas de árboles cuando no se identifiquen efectos secundarios.

Si su código en sí es es6, también puede hacer esto

"module": "src/index.js",
复制代码

Componentes personalizados de terceros

Si usa un componente personalizado de WeChat de terceros , dado que la referencia está en el archivo json, el paquete web no puede analizar el archivo relevante a través de la entrada al compilar, por lo que no lo compilará ni lo comprimirá. En este momento, tenemos que lidiar con eso nosotros mismos. Y debido a que webpack no lo maneja, el movimiento del árbol naturalmente no puede admitirlo, por lo que se recomienda evitar hacer referencia a los componentes de esta manera tanto como sea posible.

Subcontratar

La subcontratación de programas pequeños también es una solución de optimización común.

Después del análisis, algunas páginas más grandes se pueden dividir en subpaquetes. Si hay una sola página que depende de un componente personalizado de terceros y el componente de terceros es bastante grande, también puede considerar dividir la página en subpaquetes. Por lo tanto, trate de evitar colocar componentes personalizados de terceros en globalStyle , de lo contrario, no se puede colocar en subpaquetes.

Panorama general, no empacar

Para imágenes grandes en programas pequeños, intente evitar empaquetarlos y colóquelos en CDN para cargarlos a través de url. Nuestro enfoque es cargar imágenes locales durante el desarrollo, publicar imágenes automáticamente en el enlace CI/CD y volver a escribir la dirección.

Cómo resolver el problema de depuración de la máquina real

En primer lugar, verifique el archivo compilado y descubra que common/vendor.jses enorme, de 1,5 millones de tamaño. En segundo lugar pages, componentstambién hay 1,4 M, que representa la mayor parte del tamaño de js.

¿Por qué el archivo js es tan grande? La razón principal es que no hay compresión de forma predeterminada en el modo de desarrollo y, por supuesto, no hay sacudidas de árboles.

Mi elección es modificar la configuración de compilación y comprimir el código js en modo de desarrollo . Código nativo reducido a 2M. El tamaño de la vista previa se reduce a 1,4 M. La configuración de referencia es la siguiente:

// vue.config.js
    configureWebpack: () => {
        if (isDev && isMp) {
            return {
                optimization: {
                    minimize: true,
                },
            }
        }
    }
复制代码

Esto no parece una buena solución, pero es simple y efectivo. También he considerado el subempaquetado, pero el subempaquetado no puede resolver el gran problema de common/vendor.js, y el paquete sigue siendo muy grande cuando se realiza una vista previa. Si hay otras buenas maneras, bienvenido a dejar un mensaje ~