背景

2017.01.09 小程序上线时，我们限制了代码包不能超过1MB 大小，限制大小是出于对小程序启动速度的考虑，我们希望用户在使用任何一款小程序时，都能获得一种“秒开”体验。然而，1MB 的大小也限制了小程序功能的扩展，小程序业务的发展可能需要更大的体积。

随着小游戏的玩法越来越丰富，开发者对于扩大包大小的需求越来越强烈，所以我们推出了小游戏分包加载这一个功能。 所谓的分包加载，即把游戏内容按一定规则拆分这几包，在首次启动时先下载必要的包，这个必要的包我们称为「主包」，开发者可以在主包内触发其它分包的下载，从而把首次启动的下载耗时分散到游戏运行中。

分包加载的介绍

微信 6.6.7 客户端，2.1.0 及以上基础库开始支持，请更新至最新客户端版本，开发者工具请使用 1.02.1806120 及以上版本，可点此下载

大部分小游戏都会由某几个功能组成，通常这几个功能之间是独立的，但会依赖一些公共的逻辑，并且这些功能通常会对应某几个独立的页面。那么小游戏代码的打包，大可不必一定要打成一个，可以按照功能的划分，拆分成几个分包，当需要用到某个功能时，才加载这个功能对应的分包。

对于用户来说，小游戏加载流程变成了：

1.首次启动时，先下载小游戏主包，显示主包内的页面；

2.如果用户进入了某个分包的页面，再下载这个对应分包，下载完毕后，显示分包的页面。

采用分包加载，对开发者而言，能使小游戏有更大的代码体积，承载更多的功能与服务；而对用户而言，可以更快地打开小游戏，同时在不影响启动速度前提下使用更多功能。

分包的划分

在配置前首先需要开发者规划下各个分包需要容纳的内容，我们建议开发者按照功能划分的的原则，将同一个功能下的页面和逻辑放置于同一个目录下，对于一些跨功能之间公共逻辑，将其放置于主包下，这样可以确保在分包引用这部分功能时，这部分的逻辑一定存在。

在分包划分时，应该注意以下事项：

1.避免分包与分包之间引用上的耦合。因为分包的加载是由用户操作触发的，并不能确保某分包加载时，另外一个分包就一定存在，这个时候可能会导致 JS 逻辑异常的情况，例如报「"xxx.js" is not defined」这样的错误；

2.一些公共用到的自定义组件，需要放在主包内。

分包的配置

当理清了分包的划分后，就可以进行分包的配置了，这一步并不复杂。

假设支持分包的小游戏目录结构如下：

├── game.js
├── game.json
├── images
│   ├── a.png
│   ├── b.png
├── stage1
│   └── game.js
│   └── images
│       ├── 1.png
│       ├── 2.png
└── stage2.js

开发者通过在 game.json subPackages 字段声明项目分包结构：

{
  ...
  "subpackages": [
    {
      "name": "stage1",
      "root": "stage1/" // 可以指定一个目录，目录根目录下的 game.js 会作为入口文件，目录下所有资源将会统一打包
    }, {
      "name": "stage2",
      "root": "stage2.js" // 也可以指定一个 JS 文件
    }
  ]
  ...
}

配置在 subpackages 字段内的目录或 js 文件，将按照配置打包成一个个「分包」，没有配置在 subpackages 中的目录和 js，将会被打包到主包中。

注：目前不支持将开放数据域目录（即 openDataContext 配置目录）设置为分包或置于某个分包下。

分包加载的低版本兼容问题

微信 6.6.0 版本开始支持分包加载，而对于低于这个版本的客户端，我们做了兼容处理，开发者不需要对老版本微信客户端做兼容。
对于老版本的客户端，编译后台会将所有的分包打包成一个整包，老版本的客户端依然按照整包的方式进行加载。

所以在老版本的微信客户端下，是依然采取整包加载的方式加载的，建议开发者尽量控制代码包的大小。

目前小游戏分包大小的限制：

• 整个小游戏所有分包大小不超过 8M

• 单个分包/主包大小不能超过 4M

分包加载的详细使用方法、示例项目文档上已有介绍，可查看接口文档：分包加载

如果其他问题，欢迎在评论区留言。