ユニアプリの小さなパッケージサイズの最適化

背景

WeChat アプレットの開発過程で、ビジネス ロジックがますます大きくなるにつれて、いくつかの問題が浮き彫りになりました。

まず、開発モードでのローカル パッケージのサイズが 4m に達していることがわかり、この場合、開発モードで実機デバッグを使用することはできなくなります。

第二に、この時点で、ミニ プログラムはビルド後約 1.8M になります。さらに、将来的に開発が必要なビジネス要件もまだかなり多く、パッケージのサイズは確実に大きくなります。

現時点では、小さなプログラム パッケージのサイズを最適化したいと考えています。私のポジショニングプロセスとソリューションのアイデアを以下に共有させてください。開発にはuni-appを使用していますが、考え方は一般的なものですので、少しでもお役に立てれば幸いです。

パッケージ サイズを削減する方法

コード分析

まず、パッケージが大きい箇所を分析します。

ローカル コード ディレクトリを開いてファイル サイズを確認します。 common/vendor.js と page,component の大部分を js が占めていることがわかります。

ビルド コンパイル モードでは、コード圧縮が有効になっているため、他の最適化方法を考慮する必要があります。現時点では、webpack-bundle-analyzer プラグインを使用できます。これは、vendor.js にどの js モジュールが含まれているか、どのモジュールが大きいかを分析するのに役立ち、コードをさらに最適化できるようになります。

このプラグインを通じて、次の 2 つの問題が発見されました。

質問 1: uni-app カスタム コンポーネント モードのコンパイル ツリー シェイクは無効です

開発に uni-app を使用していない場合は、このセクションをスキップしてください

一部のモジュールコード分​​析を通じて発見されました ツリーシェイクであるべきだったのですが、詰め込まれていました。基本的に、木の揺れが効果を発揮しないことは確実です。

webpack4 babel7も同様です。 uni-appを使わず、vue-cli createプロジェクトを直接使う前提ではツリーの揺れは問題ありません。 uni-app を使用して新しいプロジェクトを作成する場合、ツリーシェイキングは効果がありません。

babel 設定を確認したところ、プロジェクト作成時の uni-app 設定モジュール「commonjs」が原因であることがわかりました。修正後、デモのツリーの揺れは問題ありません。しかし、プロジェクトに戻ってコンパイルすると、また問題が発生しました。引き続き検索を続けると、uni-app カスタム コンポーネント モードのコンパイルの問題 であることがわかります。現時点では、uni-app は私が言及したバグを修正していますが、まだ正式にはリリースされていません。

もちろん、uni-app カスタム コンポーネント モードのコンパイルを使用せずに問題を解決することもできます。uni-app は template テンプレート モード もサポートしていますが、開発上の違いやパフォーマンスのギャップがいくつかあります。興味がある場合は、この記事を読んでください。

質問 2: 一部のライブラリはツリーの揺れをサポートしていません

一部のライブラリ (lodash など) は、それ自体がインポート/エクスポートを使用しないため、webpack はインポート/エクスポートを使用できません木がそれらを揺さぶります。これらのライブラリは状況に応じて最適化できます。

まず、インターネット上に、lodash-es など、置き換え可能な対応する esm バージョンのライブラリがあるかどうかを確認します。

第二に、コード分析から、ライブラリの各モジュールが別のファイルにあり、エントリ ファイルが単なる統合されたエントリである場合、書き込みメソッドを変更することでオンデマンドでロードできることがわかります。

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

など babel-plugin-import プラグインを使用して、これらのライブラリのオンデマンド読み込みを実装することもできます。その本質は、次に従って読み込みパスを均一に変更することです。コードを手動で変更する必要がなく、コンパイル中に構成が変更されます。

最終的に、それが機能しない場合は、それを受け入れるか、自分で書き直してコミュニティに貢献することになります~

標準モジュール開発

ツリーシェイキングができないという問題を避けるために、私たちはnpmモジュールを開発していますが、パッケージ化後のモジュールのサイズを減らすために特定の仕様に従う必要もあります。

commonjs モジュールと es モジュールの両方をサポート

私たちのモジュールは、commonjs モジュールと es モジュールの両方をサポートする必要があります。このようにして、commonjs 開発ユーザーを満足させるだけでなく、ツリーシェイクもサポートできます。

それを達成するにはどうすればよいですか?コードが typescript の場合、例として @sentry/browser を使用すると、次のようにコンパイル時に cjs と esm の 2 つの標準コードをコンパイルできます。

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

次に、パッケージに 2 つのエントリと副作用なしフラグを指定します。 .json

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

このように、webpack がモジュールを解析するとき (解析ルール)、必要に応じて最初に esm ディレクトリを解析します。そして、副作用が確認されない場合は、ツリーシェイキングを実行します。

コード自体が es6 の場合は、これも行うことができます。

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

サードパーティのカスタム コンポーネント

サードパーティの WeChat カスタム コンポーネントが使用されている場合は、リファレンスは json ファイル内にあるため、webpack はコンパイル中にエントリを通じて関連ファイルを分析できず、コンパイルや圧縮などが行われません。現時点では、自分たちで対処する必要があります。また、webpack はこれを処理しないため、ツリーの揺れをサポートできません。そのため、 がこの方法でコンポーネントを参照することを避けるようにすることをお勧めします。

下請け

小規模プログラムの下請けも、従来の最適化ソリューションです。

通过分析后，可以将一些较大的页面划分为子包。如果有单页依赖第三方自定义组件，而且第三方组件还挺大，也可以考虑将该页面划分为子包。也因此尽量避免将第三方自定义组件放在 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 巨大的问题，预览时包还是很大。如果有其它好的办法也欢迎留言~

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

以上がユニアプリの小さなパッケージサイズの最適化の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。