微信小程序分包方法

特性

• 1.7.3 及以上基础库开始支持，不支持的版本默认使用整包的方式

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

• 分包数量目前没有限制，也就是说你可以放N个分包，甚至每个页面一个分包

• 入口页面/TAB页面必须在主包里

关于主包

• 第一次进入小程序，默认下载主包代码

• 分包以外的所有代码，都会被打入主包

• 分包内代码可以引用主包内代码

关于分包

• 因为存在资源依赖关系，微信的机制是先下载主包，后下载分包

• 分包目录不能在主包目录下面

• 分包可以引用自己包内、主包内的资源，不能引用其他分包内的资源

坑

• 小程序的打包机制仅仅是根据文件目录打包，分包内require/import的任何文件，只要不在同一个目录下面，都不会被打进分包，也就是说，类库及一些公共文件，只能放在主包里面，如果主包分包划分不好的话，主包的大小也很难降下来

• 安卓系统进入分包页面时，会出现一个丑陋的系统级的loading层，这一定程度上影响了安卓的体验

转转的分包加载

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

文件结构：

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

历史入口兼容

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

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

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

微信小程序分包加载更多推荐：

小程序分包加载功能升级，新增性能监控