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

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

• 第一次翻开转转小程序时白屏时间很长，，由于要下载靠近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步上线。。。。通过拖拽、拼接？？？？？？榻峁剐〕绦蛏坛且趁，，所看即所得，，只需要美工就能做出细腻商城。。。。更多小程序市肆请审查：小程序市肆