In certain scenarios, developers may find it necessary to partition the mini program into different sub-packages. During the construction phase, these are bundled into separate packages, which users can then load on an as-needed basis.
When building a mini program with sub-packages, the construction process will yield one or more separate packages. Each mini program using sub-packages will invariably contain a main package. This main package houses the default launch page/TabBar page, along with any common resources/JS scripts required by all sub-packages. The division of sub-packages is determined based on the developer's configuration.
Upon the initiation of the mini program, the main package is downloaded by default and its internal pages are launched. When a user navigates to a page within a sub-package, the client will download the corresponding sub-package. Once the download is complete, the page is then displayed.
The current size limitations for mini program sub-packages are as follows:
The total size of all sub-packages within the mini program must not exceed 24MB.
The size of an individual sub-package or main package must not exceed 2MB.
Sub-packaging a mini program can optimize the initial download time at launch and enhance decoupled collaboration when multiple teams are working together. The following three sub-packaging methods can be considered:
Method 1: Use sub-packages
Configuration Method
Assume the directory structure of a mini program that supports sub-packaging is as follows:
├── app.js
├── app.json
├── app.wxss
├── packageA
│ └── pages
│ ├── cat
│ └── dog
├── packageB
│ └── pages
│ ├── apple
│ └── banana
├── pages
│ ├── index
│ └── logs
└── utils
Developers can declare the project's sub-package structure in the app.json subpackages field (writing it as subPackages is also supported):
{
"pages": ["pages/index", "pages/logs"],
"subpackages": [
{
"root": "packageA",
"pages": ["pages/cat", "pages/dog"]
},
{
"root": "packageB",
"name": "pack2",
"pages": ["pages/apple", "pages/banana"]
}
]
}
In subpackages
, each sub-package configuration includes the following items:
|
root | String | Sub-package Root Directory |
name | StringArray | Sub-package alias, used during sub-package pre-download. If the sub-package is configured into the preloadRule, it must be specified. |
pages | StringArray | Sub-package page path, relative to the sub-package root directory. |
independent | Boolean | |
Packaging Principles
Upon declaring subpackages
, packaging will be conducted according to the subpackages
configuration path. Directories outside the subpackages
configuration path will be packaged into the App (main package).
The App (main package) can also have its own pages (that is, the outermost pages field).
The root directory of a subpackage
cannot be a subdirectory within another subpackage
.
tabBar
pages must reside within the app (main package).
Referencing Principles
packageA
cannot require packageB
JS files, but it can require app and JS files within its own package.
packageA
cannot import packageB
's template, but it can require app and templates within its own package.
packageA
cannot use resources from packageB
, but it can use resources from the App or within its own package.
Backward Compatibility
The compatibility with older client versions is managed by QQ's backend compilation, which compiles two sets of code packages. One is the post-subpackage code, and the other is the full-package compatibility code. The new client uses the subpackage, while the old client still uses the full package. The complete package will place the paths from each subpackage
into the pages.
Method 2: Independent subpackaging
An independent subpackage is a special type of subpackage within a mini program that can operate independently from the main package and other subpackages. When entering the mini program from a page within an independent subpackage, there is no need to download the main package. The main package will only be downloaded when the user enters a page within a regular subpackage or the main package.
Developers can configure certain pages with independent functionality into independent subpackages as needed. When the mini program is launched from a regular subpackage page, the main package must be downloaded first. However, an independent subpackage can operate without relying on the main package, significantly speeding up the startup of the subpackage page.
A mini program can contain multiple independent subpackages.
Limit
Independent subpackaging is a type of subpackaging. All restrictions applicable to regular subpackaging also apply to independent subpackaging. The handling of plugins and custom components in independent subpackaging is the same as in regular subpackaging.
Additionally, when using independent subpackages, it is important to note:
Independent subpackages cannot rely on the content of the main package or other subpackages, including js files, templates, wxss, custom components, plugins, etc. The app.wxss in the main package is ineffective for independent subpackages, so the use of styles from app.wxss in independent subpackage pages should be avoided.
The App can only be defined within the main package; it cannot be defined within an independent subpackage as this would result in unpredictable behavior.
The use of plugins is currently not supported in independent subpackages.
Configuration Method
Assume the directory structure of the mini program is as follows:
├── app.js
├── app.json
├── app.wxss
├── moduleA
│ └── pages
│ ├── rabbit
│ └── squirrel
├── moduleB
│ └── pages
│ ├── pear
│ └── pineapple
├── pages
│ ├── index
│ └── logs
└── utils
Developers declare the corresponding subpackage as an independent subpackage by defining the independent
field in the corresponding subpackage configuration item in the subpackages
field of app.json
.
{
"pages": ["pages/index", "pages/logs"],
"subpackages": [
{
"root": "moduleA",
"pages": ["pages/rabbit", "pages/squirrel"]
},
{
"root": "moduleB",
"pages": ["pages/pear", "pages/pineapple"],
"independent": true
}
]
}
Notes
About getApp()
Unlike regular subpackages, when an independent subpackage is running, the App
may not necessarily be registered, hence getApp() may not necessarily obtain the App object:
When a user launches the mini program from an independent subpackage page, the main package does not exist, nor does the App, hence calling getApp() at this time will yield undefined
. Only when the user enters a page within a regular subpackage or the main package, will the main package be downloaded and the App be registered.
When a user navigates from a page within a regular subpackage or the main package to an independent subpackage page, the main package already exists, hence calling getApp() at this time can get the actual App.
Due to this constraint, developers are unable to implement global variable sharing between the independent subpackage and other parts of the mini program through the App object.
getApp supports the allowDefault parameter, returning a default implementation when the App is undefined. When the main package is loaded and the App is registered, the attributes defined in the default implementation will be overridden and merged into the actual App.
Sample Code
Independent Subpackage:
const app = getApp({allowDefault: true}) // {}
app.data = 456
app.global = {}
Within app.js:
App({
data: 123,
other: 'hello'
})
console.log(getApp()) // {global: {}, data: 456, other: 'hello'}
Regarding the App Lifecycle
When launching the mini program from an independent subpackage, the onLaunch
and initial onShow
of the App in the main package will be invoked when first entering the main package or other common subpackage pages from the independent subpackage page.
Since an App cannot be defined within an independent subpackage, the monitoring of the mini program lifecycle can be accomplished using wx.onAppShow
and wx.onAppHide
. Other events on the App can be monitored using wx.onError and wx.onPageNotFound. Backward Compatibility
Note:
In compatibility mode, the app.wxss in the main package may impact the pages within the independent subpackage. Therefore, it is advisable to avoid using the styles from app.wxss within the pages of the independent subpackage.
Method 3: Subpackage pre-download
Limit
Pages within the same subpackage share a common pre-download size limit of 2MB, which is verified during the packaging process in the tool.
For instance, if pages A and B are both in the same subpackage, and A pre-downloads a total size of 0.5MB of the subpackage, then B can pre-download a maximum total size of 1.5MB of the subpackage.
Configuration Method
The pre-download subpackage behavior is triggered upon entering a certain page, and is controlled by adding a preloadRule
configuration in app.json
.
{
"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__"]
}
}
}
Within the
|
packages | StringArray | Yes | - | Upon entering the page, pre-download the sub-package's root or name. __APP__ denotes the main package. |
network | String | No | wifi | Pre-download under the specified network, the optional values are: All: Network unrestricted Wi-Fi: Pre-download only under Wi-Fi |
Was this page helpful?