转转小程序分包加载实例

微信小程序采用的是类似离线包加载方案，以 转转小程序 为例，当用户第一次打开时会先下载好所有代码，然后再加载页面；当用户再次进入转转小程序时，会直接使用已下载的代码，省去了代码下载的过程，打开速度更快。

看似很美好的设计，但有两个问题：

• 第一次打开转转小程序时白屏时间很长，因为要下载接近2.5M的代码量，也就是说你的代码越多，白屏时间越长，而转转APP采用的网页离线机制体验更佳：在用户打开APP时就下载/更新离线包，这样在用户进入对应的网页时，代码已经下载好了，没有漫长的白屏过程。
• 代码有部分更新时，没办法进行增量更新，导致每次发版后，用户都需要重新下载全部代码

问题看似不大，但对转转有很大影响，例如进行微信广告投放时，用户从点击广告到加载第一个页面之间的流失率竟能到达 40% ，这显然是 FE 无法接受的性能，而小程序分包加载机制能够在一定程度上解决上述问题。

分包加载

小程序的分包加载机制实际上是离线包和 M 页的一种结合机制，即你可以把代码划分成主包 +N 个分包，官方定义：

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

总结如下：

• 打开小程序，默认先加载主包
• 进入分包页面时，再加载对应分包

这样的好处是进入主包页面时，需要下载的代码量小了很多，白屏时间更短，体验更佳。

特性

• 1.7.3 及以上基础库开始支持，不支持的版本默认使用整包的方式
• 整个小程序所有分包大小不超过 4M，单个分包/主包大小不能超过 2M
• 分包数量目前没有限制，也就是说你可以放 N 个分包，甚至每个页面一个分包
• 入口页面 / Tab 页面必须在主包里

• 第一次进入小程序，默认下载主包代码
• 分包以外的所有代码，都会被打入主包
• 分包内代码可以引用主包内代码

关于分包

• 因为存在资源依赖关系，微信的机制是先下载主包，后下载分包
• 分包目录不能在主包目录下面
• 分包可以引用自己包内、主包内的资源，不能引用其他分包内的资源

坑

• 小程序的打包机制仅仅是根据文件目录打包，分包内require/import的任何文件，只要不在同一个目录下面，都不会被打进分包，也就是说，类库及一些公共文件，只能放在主包里面，如果主包分包划分不好的话，主包的大小也很难降下来
• 安卓系统进入分包页面时，会出现一个丑陋的系统级的loading层，这一定程度上影响了安卓的体验

转转的分包加载

转转小程序在使用分包之前，压缩后的代码量大概是2.45M，也就是说，每个新用户第一次都需要下载的2.45M代码才能进入页面，使用分包机制后，主包大小降为1M左右，也就是说，如果是进入主包页面， 下载时间大约降低了60%

文件结构：

├── libs
├── components
├── pages  主包根目录
├────index 首页
├────post  发布页
├────...
├── subPages  分包根目录
├────trade    交易分包
├────mine     我的页面分包
├────...
复制代码

我们根据用户访问的轨迹，分成了 20 个左右的分包。 例如 trade 包，里面包含详情页、下单页、支付页、支付成功页等，这条线的页面，用户可能不需要一进入小程序就使用，但一旦使用可能是使用整个链条，因此可以作为一个分包。

历史入口兼容

一个页面放入分包之后，路径会发生变化，例如详情页由 /pages/detail 变为 /subPages/trade/detail，意味着如果用户访问了以前的 page 则得不到正确的页面响应（例如：分享出去的小程序卡片、二维码、公众号推送消息等），这些静态不可改变的历史入口怎么办？我们目前采用如下方案：

原来主包内的每个页面都保留，但代码只保留跳转逻辑，用户进来后立即跳到对应的分包页面，用户几乎是无感知的

这样也会产生一点小问题：这些跳转页面也占用一定的空间，接下来我们会优化成在 onLaunch、页面跳转时进行判断，直接跳入正确的分包页面。

以上是转转在分包加载方面的实战记录，更多小程序开发内容，请查看本网站，谢谢。

小程序工具提供多类型商城/门店小程序制作，可视化编辑 1秒生成5步上线。通过拖拽、拼接模块布局小程序商城页面，所看即所得，只需要美工就能做出精美商城。更多小程序商店请查看：小程序商店