小さなプログラムの全体的なサイズは2000万に達する可能性があります

序:(*方法と説明は公式から取られています)

      小さいプログラムは小さすぎるためパッケージ化できません。最新の公式パッケージは20m、シングルファイルパッケージは2mです。

公式エントランス:https:  //developers.weixin.qq.com/miniprogram/dev/framework/subpackages.html

目次:

外注ローディング

下請けを使用する

構成方法

包装の原則

引用の原則

低バージョン互換

サンプルプロジェクト

独立した下請け

構成方法

制限

予防

低バージョン互換

下請け事前ダウンロード

構成方法

制限


外注ローディング

Wechatクライアント6.6.0、基本ライブラリ 1.7.3以降 がサポートされるようになりました。開発者ツールについては、ここからダウンロードできるバージョン1.01.1712150以降を使用してください

場合によっては、開発者はアプレットを異なるサブパッケージに分割する必要があります。これらのサブパッケージは、構築中に異なるサブパッケージにパッケージ化され、ユーザーは使用中に必要に応じてそれらをロードします。

小さなプログラムの下請けプロジェクトをビルドする場合、ビルドは1つ以上の下請けを出力します。各使用サブパッケージアプレットには、メインパッケージが含まれている必要がありますデフォルトのスタートページ/ TabBarページを配置したいわゆるメインパッケージ、および一部のすべての下請け業者は、パブリックリソース/ JSスクリプトに必要であり、下請け業者は開発者の構成に応じて分割されます。

アプレットが起動すると、デフォルトでメインパッケージがダウンロードされ、メインパッケージのページが起動します。ユーザーがサブパッケージにページを入力すると、クライアントは対応するサブパッケージをダウンロードし、その後に表示します。ダウンロードが完了しました。

現在の小さなプログラムのサブパッケージサイズには、次の制限があります。

  • ミニプログラム全体のすべてのサブパッケージのサイズは20Mを超えません
  • 単一の下請け/メインパッケージのサイズは2Mを超えることはできません

アプレットを下請けにすることで、最初の開始時のアプレットのダウンロード時間を最適化できるだけでなく、複数のチームが共同開発されている場合のデカップリングとコラボレーションを向上させることができます。

下請けを使用する

構成方法

下請けをサポートするアプレットのディレクトリ構造が次のとおりであるとします。

├── app.js
├── app.json
├── app.wxss
├── packageA
│   └── pages
│       ├── cat
│       └── dog
├── packageB
│   └── pages
│       ├── apple
│       └── banana
├── pages
│   ├── index
│   └── logs
└── utils

開発者は、app.jsonsubpackages フィールドで プロジェクトの下請け構造を宣言します。

subPackagesとして記述されたものもサポートされています。

{
  "pages":[
    "pages/index",
    "pages/logs"
  ],
  "subpackages": [
    {
      "root": "packageA",
      "pages": [
        "pages/cat",
        "pages/dog"
      ]
    }, {
      "root": "packageB",
      "name": "pack2",
      "pages": [
        "pages/apple",
        "pages/banana"
      ]
    }
  ]
}

subpackages では、各外注先の構成には次の項目があります。

フィールド の種類 説明
ルート ストリング サブパッケージのルートディレクトリ
名前 ストリング サブパッケージエイリアス。サブパッケージの事前ダウンロード時に使用できます。
ページ StringArray サブパッケージのルートディレクトリを基準にしたサブパッケージのページパス
独立 ブール値 下請けが独立した下請けであるかどうか

包装の原則

  • 宣言後、  構成パスsubpackages に従ってsubpackagesパッケージ化され、 構成パスのsubpackages 外側のディレクトリがアプリにパッケージ化されます(メインパッケージ)
  • アプリ(メインパッケージ)は、独自のページ(つまり、最も外側のページフィールド)を持つこともできます
  • subpackage ルートsubpackage ディレクトリを別のディレクトリ内サブディレクトリにすることはできません 
  • tabBar ページはアプリ内にある必要があります(メインパッケージ)

引用の原則

  • packageApackageB JSファイル は必要ありませんがapp、独自のパッケージでJSファイルを必要とする ことはでき ます
  • packageApackageB インポートでき ない テンプレートですがapp、独自のパッケージでテンプレートを要求でき ます
  • packageA 使用packageB できない リソースですがapp、独自のパッケージでリソースを使用でき ます

低バージョン互換

WeChatバックグラウンドは、古いバージョンのクライアントの互換性を処理するためにコンパイルされます。バックグラウンドは、2つのコードパッケージをコンパイルします。1つはサブパッケージコードで、もう1つはパッケージ全体の互換性コードです。新しいクライアントは下請けを使用し、古いクライアントは引き続きパッケージ全体を使用します。完全なパッケージは subpackage 、ページ内のパスをページに配置します。

サンプルプロジェクト

小さなプログラム例のソースコードをダウンロードする(サブパッケージのロードバージョン)

独立した下請け

Wechatクライアント6.7.2、基本ライブラリ 2.3.0以降 がサポートされるようになりました。開発者ツールについては、ここからダウンロードできるバージョン1.02.1808300以降を使用してください

独立外注は、メインパッケージや他の下請けとは独立して実行できる小さなプログラムの特殊なタイプの下請けです。独立したサブパッケージのページからミニプログラムに入るときに、メインパッケージをダウンロードする必要はありません。メインパッケージは、ユーザーが通常のサブパッケージまたはメインパッケージのページに入ったときにのみダウンロードされます。

開発者は、必要に応じて、機能的に独立した特定のページを独立したサブパッケージに構成できます。アプレットを通常のサブパッケージページから起動する場合は、最初にメインパッケージをダウンロードする必要がありますが、独立したサブパッケージは実行するメインパッケージに依存しないため、サブパッケージの起動速度が大幅に向上します。ページ。

小さなプログラムには、複数の独立した下請け契約が存在する可能性があります。

ミニゲームは、基本ライブラリv2.12.2で独立した下請けのサポートを開始します。詳細については、ミニゲームの独立した下請けガイドを参照してください 

構成方法

アプレットのディレクトリ構造は次のとおりであると想定します。

├── app.js
├── app.json
├── app.wxss
├── moduleA
│   └── pages
│       ├── rabbit
│       └── squirrel
├── moduleB
│   └── pages
│       ├── pear
│       └── pineapple
├── pages
│   ├── index
│   └── logs
└── utils

開発者は、対応するサブコントラクトが独立コントラクトであることを宣言する定義することによって、対応する外注構成項目のフィールドをフィールド。app.jsonsubpackagesindependent

{
  "pages": [
    "pages/index",
    "pages/logs"
  ],
  "subpackages": [
    {
      "root": "moduleA",
      "pages": [
        "pages/rabbit",
        "pages/squirrel"
      ]
    }, {
      "root": "moduleB",
      "pages": [
        "pages/pear",
        "pages/pineapple"
      ],
      "independent": true
    }
  ]
}

制限

独立下請けは、下請けの一種です。通常の下請けのすべての制限は、独立した下請けに有効です。独立した外注のプラグインとカスタムコンポーネントは、通常の下請けと同じ方法で処理されます。

さらに、独立した下請けを使用する場合は、次の点に注意してください。

  • 独立したサブパッケージは、メインパッケージや、jsファイル、テンプレート、wxss、カスタムコンポーネント、プラグインなどの他のサブパッケージのコンテンツに依存することはできませんメインパッケージはapp.wxss独立下請けに無効であり、独立下請けページで使用されてapp.wxss いるスタイルは避ける必要があり ます。
  • App メインパッケージでのみ定義でき、独立した下請けApp定義することはできません 。これにより、予期しない動作が発生します。
  • プラグインの使用は、独立した下請けでは一時的にサポートされていません。

予防

(1)について getApp()

通常の下請けとは異なり、独立下請けが実行App されている 場合、必ずしも登録されているとは限らないため、 オブジェクトgetApp() が取得されない場合があります App

  • ユーザーが独立した外注ページからアプレットを起動すると、メインパッケージが存在AppしないgetApp() か、存在しませんundefinedこのときに呼び出す ことで取得されるのは です。ユーザーが一般サブパッケージまたはメインパッケージページに入ると、メインパッケージがダウンロードApp されて登録されます。
  • ユーザーが通常の下請けページまたはメインパッケージページから独立した下請けページにジャンプすると、メインパッケージはすでに存在し、この時点でを呼び出すgetApp() ことで実際のパッケージを 取得できます App

この制限により、開発者App は、オブジェクトを介したアプレットの他の部分の独立した下請けおよびグローバル変数共有を実装できません 

独立した下請けでこの要件を満たすために、ベースライブラリ  バージョン2.2.4getAppは[ allowDefault]パラメータの サポートを開始し App 定義されていない場合はデフォルトの実装を返します。メインパッケージがロードおよびApp 登録されると、デフォルトの実装で定義された属性が上書きされ、実際の属性にマージされます App 。

サンプルコード:

  • 独立した下請け
const app = getApp({allowDefault: true}) // {}
app.data = 456
app.global = {}
  • app.js
App({
  data: 123,
  other: 'hello'
})

console.log(getApp()) // {global: {}, data: 456, other: 'hello'}

(2)App ライフサイクルについて 

独立下請けからアプレットを起動する場合、独立 下請けページからメインパッケージまたは他の通常の下請けページに初めて入るときに、メインパッケージApp の onLaunch 合計 が onShow初めて呼び出されます。

独立した外注でApp定義できないため アプレットのライフサイクルの監視は、wx.onAppShowおよびwx.onAppHideを使用して 完了することができます App 上記の他のイベントは、wx.onErrorおよびwx.onPageNotFoundを使用して 監視できます 

低バージョン互換

6.7.2より前のバージョンのWeChatで実行する場合、独立した外注は通常の下請け処理と見なされ、独立した操作の特性はありません。

注:互換モードでは、メインパッケージのコンテンツが app.wxss 独立サブパッケージのページに影響を与える可能性があるため、独立サブパッケージページのapp.wxss スタイルの使用避けてください 

下請け事前ダウンロード

基本ライブラリ2.3.0がサポートされており、下位バージョンは互換性がある必要があります。開発者ツールについては、ここからダウンロードできるバージョン1.02.1808300以降を使用してください

開発者は、アプレットの特定のページに入るときに、フレームワークが後続のサブパッケージページに入るときの起動速度を向上させるために必要なサブパッケージを自動的に事前ダウンロードするように構成できます。以下のための独立した下請け、メインパッケージには、事前にダウンロードすることができます。

サブパッケージの事前ダウンロードは現在、構成メソッドの使用のみをサポートしており、現在APIを呼び出すことによる完了はサポートしていません。

vConsolepreloadSubpackagesの先頭にあるログ情報を使用して、事前ダウンロードを確認できます。

構成方法

ダウンロード前の下請け動作は、特定のページに入るときにトリガー さapp.json 、preloadRule構成追加すること によって制御され ます。

{
  "pages": ["pages/index"],
  "subpackages": [
    {
      "root": "important",
      "pages": ["index"],
    },
    {
      "root": "sub1",
      "pages": ["index"],
    },
    {
      "name": "hello",
      "root": "path/to",
      "pages": ["index"]
    },
    {
      "root": "sub3",
      "pages": ["index"]
    },
    {
      "root": "indep",
      "pages": ["index"],
      "independent": true
    }
  ],
  "preloadRule": {
    "pages/index": {
      "network": "all",
      "packages": ["important"]
    },
    "sub1/index": {
      "packages": ["hello", "sub3"]
    },
    "sub3/index": {
      "packages": ["path/to"]
    },
    "indep/index": {
      "packages": ["__APP__"]
    }
  }
}

preloadRule 真ん中、key はページパス、value はこのページに入るためのダウンロード前の構成であり、各構成には次の項目があります。

フィールド の種類 必須 デフォルト 説明
パッケージ StringArray はい 番号 ページに入った後、サブパッケージroot またはを 事前にダウンロードしてください name__APP__ メインパッケージを表します。
通信網 ストリング 番号 Wi-Fi 指定されたネットワークでの事前ダウンロード、オプションの値は次のとおりです
all::無制限のネットワーク
wifi:wifiでの事前ダウンロードのみ

制限

同じサブパッケージ内のページは、ダウンロード前の共通のサイズ制限である2Mを共有しており、ツールにパッケージ化されたときに制限が確認されます。

たとえば、ページAとBは両方とも同じサブパッケージにあり、合計サイズが0.5MのサブパッケージはAに事前ダウンロードされ、合計サイズが1.5MのサブパッケージはBにのみ事前ダウンロードできます。

 

おすすめ

転載: blog.csdn.net/qq_41619796/article/details/115299223