uniapp プロジェクトの委託方法

1: 下請けに関する考え方

本質的には、プロジェクトのルートを変更し、プロジェクトの各モジュールの起動時間を最適化する最適化手法です。
メインパッケージとサブコンの概念

1). メインパッケージ: このプロジェクトの初期化に必要なページ。

プロジェクトが開始されると、メインパッケージから入力され、ユーザーが入力しないとサブパッケージは読み込まれず、サブパッケージモジュールに入るときにのみ読み込まれます。
モジュール間で共有されるタブバーページとページ。プロジェクトにアカウント制限がある場合 (つまり、登録されていないアカウントはメインインターフェイスに入ることができません)、ログインページもメインパッケージに配置する必要があります。

2). サブパッケージ: メインパッケージを除くすべてのページはサブパッケージに配置する必要があります. 読者の混乱を避けるために, この記事ではサブパッケージをサブパッケージと定義します.

2: なぜ下請けにするのか

プロジェクトの初回起動時のダウンロード時間を最適化します。デフォルトでは、アプレットのパッケージ全体 (メインパッケージ) をダウンロードしますが、これにより、完全にロードされた後にのみプロジェクト全体がユーザーの前に表示されます。ローディングアニメーションは最適化のために使用できますが、ユーザーの損失につながる可能性があるものもあります.
ミニプログラムプロジェクトをパッケージ化した後、プロジェクトがミニプログラムの公式のサイズ制限を超えないようにしてください
.パッケージの場合、プログラム全体の最大制限は 2M を超えることはできません。サブパッケージ化後、プロジェクト全体 (メインパッケージ + サブパッケージを含む) パッケージ) は最大で 16M を超えることはできず、単一のパッケージは 2M を超えることはできません (これにより、プロジェクトが最大 2m を超えることができないという制限)

3: 下請けの基本的なロジック

静的ファイル: 静的などの静的リソースはサブパッケージでサポートされます。つまり、サブパッケージディレクトリに配置された静的リソースは、メインパッケージにパッケージ化されず、メインパッケージで使用することもできません。
js ファイル: js が 1 つのサブパッケージによってのみ参照される場合、js はサブパッケージにパッケージ化されます。 1 つ以上のサブパッケージ)
カスタムコンポーネント: カスタムコンポーネントが 1 つのサブパッケージによってのみ参照され、サブパッケージに配置されていない場合、コンパイル中にプロンプトメッセージが出力されます。

4：下請け手順の詳細説明

PS: 作成者は WeChat アプレットのみを下請けに出すため、以下は WeChat アプレット向けの uniapp プロジェクトに対してのみ有効です。
PS: 作成者は、タブバーページをサブパッケージに単一モジュールとして分割します。

(manifest.json ) サブパッケージの最適化を有効にする

関連フィールドを追加

// "mp-weixin"
"optimization":{
"subPackages":true //是否启用分包优化
}

(pages.json) プロジェクトのサブパッケージ構造を宣言する

ページ：

原則: タブバーページルーティングと各サブパッケージで共有されるページのみをページに格納できます. ログインページがあり、ログインせずにメインページに入ることができない場合は、ログインページルーティングもページルーティングに配置する必要があります

サブパッケージ：

定義: メインパッケージ内のファイルを除く、単一モジュール内のすべてのファイル。
例: タブバーモジュールに元々 3 つのページがあったとします: index (タブバーページ).vue、notice.vue、および about.vue、および index.vue page routing は pages.json の pages 配列に配置され、対応する index.vue はプロジェクトの pages ディレクトリに配置されます
. notice.vue と about.vue が他のタブバーモジュールで使用されていないと仮定するとnotice.vue と about.vue が他のモジュールで使用されている
場合、他のタブバーとの相互作用を防ぐために、ページのメインパッケージにも配置する必要があります。共有ページを保存するために、ページディレクトリに別のディレクトリを作成する必要があります

上記の原則を理解したら、次にそれらを実践できます。

A new subPackages field is added in (pages.json), which is at the same level as pages and is in a array format. ピリオド内の各オブジェクトはタブバー内の各モジュールに対応し、各オブジェクトは (プロジェクトディレクトリ) 内に対応してい
ますプロジェクトで生成する必要があります。ディレクトリ、このディレクトリはページディレクトリと同じレベルにあります

//pages.json
"pages":[
//这里仅存放tabbar,以及公共页
],
"subPackages":[
//subPackages数组里的每一个对象都代表了对应tabbar模块里的除tabbar中index.vue以外所有的页面，且该数组里每一个对象都在项目目录中与pages目录平级
//举个栗子 这里是首页模块，index.vue由于是tabbar页面，故而被放置在了pages.json中，剩余两个文件并没有被其他tabbar模块使用，因而被放置在了这里
{
"root":"pages_Index", //这里代表根目录的映射，表示在项目中这个模块的根目录也就是上面说的与pages目录平级的目录名
"pages":[ // 这里的pages表示分包内的页面，凡在该子包的pages目录下，均不可被其他子包模块访问
//这里指的是原本从pages页中迁移来的，仅本模块专属的页面，其格式规范遵循tabbar所在pages数组规范
{
// 网上有人说path路径必须由pages_Index根目录开始，但是在实践过程中发现不从根目录开始也可以，原因猜测是root本身已定义了根目录
// 原目录为： /pages_index/packet/notice
path":"packet/notice",
"style": {
"navigationBarTitleText": "我是子包文件"
}
},
]
}
]

ディレクトリ構造は次のとおりです。

pages.json は次のとおりです。

これで、構成の 2 番目のステップが完了します。

各ページのルートを変更する

プロジェクトが WeChat の 2m の制限に達すると、開発者ツールでプロジェクトを実行できなくなる直接的な原因になりますが、下請けはいつでも実行できます。しかし、かかる時間はプロジェクトの進捗に正比例します。つまり、プロジェクトの進捗が終わりに近づくほど、下請けにかかる時間が長くなります。著者はこのことを深く理解しています(流泪 .jpg ) 導入する方法と同様に、これは非常に面倒でエラーや損失が発生しやすいため、開発者はこの手順を実行する前にバックアップを作成することをお勧めします。インポートされたコンポーネントパスを @ で始まる絶対パスに直接置き換えて、将来の変更の可能性を防ぐために、省略ルートが置き換えられた後?こちらをクリックしてください) このプロセスでは、さまざまな参照エラーやジャンプできない問題が発生する可能性があります. このとき、開発者は落ち着いて慎重にチェックする必要があります.

開発者ツールでプロジェクト全体を実行したときにエラーメッセージが表示されない場合は、実機でデバッグできます。

ここで質問があります: ユーザーにこれらの醜い言葉を見せたくないのですが、どうすればよいでしょうか?

これらの言葉の理由は、ユーザーが入力したばかりのインターフェイスはメインパッケージでなければならず、ユーザーがサブパッケージに入ると、サブパッケージリソースがダウンロードされていないため、WeChat の公式はサブパッケージリソースがダウンロードされていることを便利にユーザーに思い出させるためです。ロード済み
作者 : Wechat ありがとうございます! (超大きなビープ音)
次にお話ししたいのは、この種の問題の解決策です: サブパッケージのプリロード

(pages.json) サブパッケージのプリロードを実現

定義: ユーザーが特定のページに入ると、そのページに関連するサブパッケージファイルを同時にダウンロードします. subPackages
と
,ユーザーが特定のページに入ったとき、プリロードする必要があるページパス、
値

//pages.json
//以子包pages_index为例
"subPackages":[
//分包模块
{
"root" : "pages_index",
"pages" : [
{
"path" : "packet/notice",
"style" : { "navigationBarTitleText": "我是子包页面"}
}
]
}
],
"preloadRule" :{
"pages/index/index":{ //要进行预加载时用户要进入的页面路径
"network":"all", // 什么网络下支持允许预加载，默认wifi: wifi/all
"packages":["pages_Index"] // 要进行预加载的子包名
},
}

サブパッケージのプリロード機能を使用すると、
構成が成功すると、開発者コンソールに次の情報が出力されます。

いくつかの原則

メインパッケージはサブパッケージ内のファイルを参照でき、サブパッケージはそれ自身のディレクトリ内のファイルのみを参照でき、サブパッケージとサブパッケージの間のファイルは相互に参照できません。

下請けは最後の手段であり、下請けの前にプロジェクト内の静的リソースが最適化されていること、および大きなコメントや無駄なコードがないことを確認する手段でもあります。