小程序分包

Loserkeys
1,558 阅读8分钟

事情的起因

最近接手了一个小程序，本项目是使用taro框架开发。由于是第一次接手开始做小程序，碰到了很多问题，在此记录一下。 由于第一次接手小程序，对小程序的开发流程不是很熟悉，在开发过程中突然发现不能在dev模式下进行预览了，报了主包超过2M ，大小超出限制不能进行预览，也不能进行真机调试。需要真机预览时还需要先进行build,并且不能进行真机调试。大大的影响了开发效率和开发体验。

探索原因

查看微信开发者文档发现 微信对于单个包大小有限制,单个分包大小不能超过 2M。 在构建小程序分包项目时，构建会输出一个或多个分包。每个使用分包小程序必定含有一个主包。所谓的主包，即放置默认启动页面/TabBar页面，以及一些所有分包都需用到公共资源/JS 脚本；而分包则是根据开发者的配置进行划分。

在小程序启动时，默认会下载主包并启动主包内页面，当用户进入分包内某个页面时，客户端会把对应分包下载下来，下载完成后再进行展示。

目前小程序分包大小有以下限制：

整个小程序所有分包大小不超过 16M
单个分包/主包大小 不能超过 2M

对小程序进行分包，可以优化小程序首次启动的下载时间，以及在多团队共同开发时可以更好的解耦协作。

分包原则

小程序目录结构如下：

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

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

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

分包配置

打包原则

  • 声明 subpackages 后，将按 subpackages 配置路径进行打包，subpackages 配置路径外的目录将被打包到 app（主包） 中（重要）
  • app（主包）也可以有自己的 pages（即最外层的 pages 字段）
  • subpackage 的根目录不能是另外一个 subpackage 内的子目录
  • tabBar 页面必须在 app（主包）内

引用原则

  • packageA 无法 require packageB JS 文件，但可以 require app、自己 package 内的 JS 文件
  • packageA 无法 import packageB 的 template，但可以 require app、自己 package 内的 template
  • packageA 无法使用 packageB 的资源，但可以使用 app、自己 package 内的资源

特殊的分包——独立分包

独立分包是小程序中一种特殊类型的分包，可以独立于主包和其他分包运行。从独立分包中页面进入小程序时，不需要下载主包。当用户进入普通分包或主包内页面时，主包才会被下载。

开发者可以按需将某些具有一定功能独立性的页面配置到独立分包中。当小程序从普通的分包页面启动时，需要首先下载主包；而独立分包不依赖主包即可运行，可以很大程度上提升分包页面的启动速度。

一个小程序中可以有多个独立分包

独立分包的限制

  • 独立分包中不能依赖主包和其他分包中的内容，包括js文件、template、wxss、自定义组件、插件等。主包中的app.wxss对独立分包无效，应避免在独立分包页面中使用 app.wxss 中的样式；
  • App 只能在主包内定义，独立分包中不能定义 App，会造成无法预期的行为；
  • 独立分包中暂时不支持使用插件。

总而言之，可以这样理解—独立分包就是独立存在的，不能依赖自己文件外的任何类型的文件。

独立分包的注意事项

（1）关于 getApp()

与普通分包不同，独立分包运行时，App 并不一定被注册，因此 getApp() 也不一定可以获得 App 对象：

  • 当用户从独立分包页面启动小程序时，主包不存在，App也不存在，此时调用 getApp() 获取到的是 undefined。 当用户进入普通分包或主包内页面时，主包才会被下载，App 才会被注册。
  • 当用户是从普通分包或主包内页面跳转到独立分包页面时，主包已经存在，此时调用 getApp() 可以获取到真正的 App。

由于这一限制，开发者无法通过 App 对象实现独立分包和小程序其他部分的全局变量共享。

为了在独立分包中满足这一需求，基础库 2.2.4 版本开始 getApp支持 [allowDefault]参数，在 App 未定义时返回一个默认实现。当主包加载，App 被注册时，默认实现中定义的属性会被覆盖合并到真正的 App 中。

const app = getApp({allowDefault: true}) // {}
app.data = 456
app.global = {}

（2）关于 App 生命周期

当从独立分包启动小程序时，主包中 App 的 onLaunch 和首次 onShow 会在从独立分包页面首次进入主包或其他普通分包页面时调用。

由于独立分包中无法定义 App，小程序生命周期的监听可以使用 wx.onAppShow，wx.onAppHide 完成。App 上的其他事件可以使用 wx.onError，wx.onPageNotFound 监听。

分包预下载

为了让客户有更好的体验，减少用户的等待时间，因此可以进行分包预加载。

基础库 2.3.0 开始支持，低版本需做兼容处理。 开发者工具请使用 1.02.1808300 及以上版本，可点此下载。

配置方法

预下载分包行为在进入某个页面时触发，通过在 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__"]
    }
  }
}

分包预加载规则

预加载限制

    同一个分包中的页面享有共同的预下载大小限额 2M，限额会在工具中打包时校验。
    如，页面 A 和 B 都在同一个分包中，A 中预下载总大小 0.5M 的分包，B中最多只能预下载总大小 1.5M 的分包。

分包

解决问题

首先对项目进行分析 通过使用 webpack-bundle-analyzer 插件对打包体积进行分析。

安装依赖
$ npm install webpack-bundle-analyzer -D
$ yarn add --dev webpack-bundle-analyzer

随后在 mini.webpackChain 中添加如下配置。

const config = {
  mini: {
    webpackChain (chain, webpack) {
      chain.plugin('analyzer')
        .use(require('webpack-bundle-analyzer').BundleAnalyzerPlugin, [])
    }
  }
}

之后启动项会出现这样的分析图 分包大小分析

可以通过点击左侧导航中 Treemap sizes: 的 Stat 按钮，来查看每一个文件的具体依赖关系及依赖文件的大小。 可以查看自己主包中大概那些文件比较大，可以有针对的进行压缩和迁移。

在我对项目进行分析后，我发现 vendors.js和common.js的大小是占比例最高的。针对这两个进行解决。

在 2.x 中默认会抽离 4 个公共文件，分别为

  • runtime: webpack 运行时入口
  • vendors: node_modules 中文件抽离
  • taro: node_modules 中 Taro 相关依赖抽离
  • common: 项目中业务代码公共文件抽离

缩小vendors.js

由于 vendors 默认是除 Taro 相关依赖之外的所有引用的 node_modules 文件的抽离公共文件，所以如果开发人员自己引入了过多的 npm 包就会导致 vendors.js 过大，解决办法：一是可以是尽量少用 npm 包，二是可以自己配置更细的拆分。 现在对第二种方式进行配置 例如，如果引入了 lodash，由于 lodash 本身比较大，可以再自行配置 mini.webpackChain 来将 lodash 单独拆分出来，示例配置如下


const config = {
  mini: {
    webpackChain (chain, webpack) {
      chain.merge({
        optimization: {
          splitChunks: {
            cacheGroups: {
              lodash: {
                name: 'lodash',
                priority: 1000,
                test (module) {
                  return /node_modules[\\/]lodash/.test(module.context)
                }
              }
            }
          }
        }
      })
    }
  }
}

随后需要再通过 mini.commonChunks 配置来添加 lodash 公共文件

const config = {
  mini: {
    commonChunks (commonChunks) {
      commonChunks.push('lodash')
      return commonChunks
    }
  }
}

这样就能将 lodash 相关依赖单独抽离到 lodash.js 中，以实现对 vendors 的拆分

缩小common.js

common.js 是项目中业务代码公共文件。包括公共组件和全局的utils,静态文件,公共变量定义文件等。如下图 打包文件 这些都会导致主包过大。 因此可以根据业务需求对项目进行模块化处理，每个模块下面有自己用的组件、API、store。尽量的将相关联的模块进行整合，放在一个分包下面，实在是联系紧密的模块或者全局需要使用的模块或组件才放入主包内（包括TabBar页面）。尽可能的减小主包的大小。

对项目结构进行了划分。按关联性进行分包。在每个分包内都有这个分包的放组件的components 的文件夹。如下图 文件分包

这样就保留了扩展性。以后再新增业务需求的话，可以根据业务关联行考虑写入哪个分包内或者新开分包文件夹。但要注意小程序的限制 分包的大小

写在结尾

关于小程序的分包总结：

  1. 在开发项目时就开始进行分包
  2. 把项目进行模块化，将联系紧密的业务和模块放入同一个分包内
  3. 将非全局使用的公共控件放入分包中
  4. 避免将非全局使用的store、API、静态文件放入主包内
  5. 尽量减少npm 包的引用
  6. 使用mini.webpackChain对node_modules内的引用文件进行拆分

至此关于小程序的分包策略的个人见解已经写完了。对小程序的见解还不是很足，如有错误请不吝指出。有更好的解决分包问题欢迎分享。

参考文档

微信文档—分包加载。 Taro的官网

avatar
文章
阅读
粉丝