Optimisation de la petite taille du package de programme d'uni-app

Contexte

Dans le processus de développement de l'applet WeChat, à mesure que la logique métier devenait de plus en plus grande, certains problèmes ont été mis en évidence.

Tout d'abord, nous avons constaté qu'en mode développement, la taille du package local a atteint plus de 4 millions. Dans ce cas, il n'est plus possible d'utiliser le débogage réel de la machine en mode développement.

Deuxièmement, à l'heure actuelle, le mini-programme dure environ 1,8 million après sa construction. De plus, de nombreuses exigences commerciales doivent encore être développées à l'avenir, et la taille du package sera certainement plus grande.

À l'heure actuelle, vous souhaitez optimiser la petite taille du package du programme. Permettez-moi de partager mon processus de positionnement et mes idées de solutions ci-dessous. Bien que nous utilisions uni-app pour le développement, les idées sont générales, j'espère que cela pourra vous aider.

Comment réduire la taille du paquet

Analyse du code

Analysez d'abord où se trouve la taille du paquet.

Ouvrez le répertoire de code local pour afficher la taille du fichier. On peut constater que js représente la majorité des composants common/vendor.js et page.

En mode compilation de build, la compression du code a été activée et d'autres méthodes d'optimisation doivent être prises en compte. A ce moment, vous pouvez utiliser le plug-in webpack-bundle-analyzer. Cela peut aider à analyser quels modules js se trouvent dans supplier.js et quels modules sont plus grands, afin que nous puissions optimiser davantage le code

Grâce à ce plug-in, les deux problèmes suivants ont été découverts.

Problème 1 : le tremblement de l'arbre de compilation en mode composant personnalisé uni-app n'est pas valide

Si vous n'utilisez pas uni-app pour le développement, vous pouvez ignorer cette section

Certains modules sont trouvés grâce à l'analyse du code. Cela aurait dû faire trembler les arbres, mais ils ont été emballés. Il est fondamentalement certain que le tremblement des arbres ne produit aucun effet.

La même chose est webpack4 + babel7. En partant du principe de ne pas utiliser uni-app et d'utiliser directement le projet de création vue-cli, il n'y a aucun problème de tremblement d'arbre. Lorsque vous utilisez uni-app pour créer un nouveau projet, le tremblement des arbres est inefficace.

Lorsque j'ai vérifié la configuration de Babel, j'ai découvert qu'elle était causée par les modules de configuration d'Uni-App : 'commonjs' lors de la création du projet. Après modification, le tremblement de l’arbre de la démo est ok. Mais quand je suis revenu au projet pour le compiler, quelque chose s'est encore mal passé. En continuant à le localiser, nous avons découvert qu'il s'agissait d'un problème de compilation en mode composant personnalisé uni-app. À l'heure actuelle, uni-app a corrigé le bug que j'ai mentionné, bien qu'il n'ait pas encore été officiellement publié.

Bien sûr, vous pouvez résoudre le problème sans utiliser la compilation en mode composant personnalisé uni-app. uni-app prend également en charge template模板模式, mais il y aura quelques différences de développement et des écarts de performances. pouvez lire cet article

Problème 2 : Certaines bibliothèques ne prennent pas en charge le tremblement d'arbre

Certaines bibliothèques (telles que lodash) n'utilisent pas elles-mêmes l'importation/exportation, donc webpack ne peut pas les secouer. Nous pouvons optimiser ces bibliothèques en fonction de la situation.

Tout d'abord, vous pouvez savoir s'il existe une version esm correspondante de la bibliothèque sur Internet qui peut être remplacée, comme lodash-es.

Deuxièmement, il ressort de l'analyse du code que si chaque module de la bibliothèque est dans un fichier différent et que le fichier d'entrée n'est qu'une entrée unifiée, alors nous pouvons le charger à la demande en modifiant la méthode d'écriture , comme

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

Nous pouvons également utiliser le plug-in babel-plugin-import pour implémenter le chargement à la demande pour ces bibliothèques. Son essence est de modifier uniformément le chemin de chargement en fonction de la configuration lors de la compilation, sans avoir besoin de le faire. pour modifier manuellement le code.

Si cela ne fonctionne pas au final, alors soit acceptez-le, soit réécrivez-le vous-même et contribuez à la communauté~

Standardiser le développement des modules

Afin d'éviter le problème de ne pas pouvoir secouer les arbres, nous développons des modules npm qui doivent également suivre certaines spécifications pour réduire la taille du module après emballage.

Prend en charge les modules commonjs et es

Notre module doit prendre en charge les modules commonjs et es. De cette façon, nous pouvons non seulement satisfaire les utilisateurs de développement commonjs, mais également prendre en charge le tremblement d'arbre.

Comment y parvenir ? Si votre code est dactylographié, en prenant @sentry/browser comme exemple, vous pouvez compiler les codes standard cjs et esm au moment de la compilation, comme suit

// 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",复制代码

puis spécifier les deux entrées et l'indicateur sans effet secondaire dans package.json

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

De cette façon, lorsque webpack analyse le module (règle d'analyse), il analysera d'abord le répertoire esm si nécessaire. Et effectuez le tremblement des arbres lorsqu’aucun effet secondaire n’est identifié.

Si votre code lui-même est es6, vous pouvez également le faire

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

Composant personnalisé tiers

Si un composant personnalisé WeChat tiers est utilisé, puisque la référence est dans un fichier json, donc webpack ne peut pas analyser les fichiers pertinents via l'entrée lors de la compilation, il ne sera donc pas compilé, compressé, etc. À l’heure actuelle, nous devons nous en occuper nous-mêmes. Et comme webpack ne le gère pas, le tremblement d'arbre ne peut pas être pris en charge, il est donc recommandé d' essayer d'éviter de référencer les composants de cette manière.

Sous-traitance

La sous-traitance mini programme est également une solution d'optimisation classique.

通过分析后，可以将一些较大的页面划分为子包。如果有单页依赖第三方自定义组件，而且第三方组件还挺大，也可以考虑将该页面划分为子包。也因此尽量避免将第三方自定义组件放在 globalStyle，不然没法将它放到子包去。

大图不要打包

小程序中的大图，尽量避免打包进来，应该放到 CDN 通过 url 加载。我们的做法是在开发时加载本地图片，在 CI/CD 环节自动化发布图片，并改写地址。

如何解决真机调试问题

首先还是查看编译后的文件，发现common/vendor.js巨大，足有 1.5M。其次pages和components也有 1.4M，而这其中占了 js 的大小又占了绝大部分。

为什么 js 文件这么大呢？主要是因为在 dev mode 默认并没有压缩，当然也没有 tree shaking。

我的选择是修改编译配置，在 dev mode 压缩 js 代码。本地代码减少到了 2M。预览大小则是减少到了 1.4M。参考配置如下：

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

这看上去并不是个好方案，但确实简单有效。也考虑过分包，但分包并不能解决 common/vendor.js 巨大的问题，预览时包还是很大。如果有其它好的办法也欢迎留言~

更多相关免费学习推荐：微信小程序开发

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!