“离线包”的工作原理
微信小程序采用类似于离线软件包的加载计划。 例如，旋转小部件可以在用户第一次打开时下载所有代码，然后加载页面。 当用户再次进入翻转小程序时，下载的代码将保持原样，省去代码下载过程，打开速度更快。
它看起来很漂亮，但有两个问题：
第一次打开APP时，白色画面的时间很长。 因为我要下载近2.5M的代码。 也就是说，你的代码越多，白色屏幕的时间就越长。 查看APP时，下载/更新脱机软件包。 这样，当用户进入相应的页面时，代码已经下载，没有长的白色屏幕过程。
如果部分代码已更新，则无法增量更新，每次发布时用户都必须重新下载所有代码
虽然看起来问题不大，但对绕着周围转有很大的影响。 例如，如果发布微信广告，则用户从单击广告到加载第一页之间的流失率可以达到40%。 这显然是FE无法接受的性能，但小程序的分包加载机制可以在一定程度上解决这些问题。
分包装载
applet的分包加载机制实际上是离线软件包和m页的合并机制。 也就是说，代码可以分成n个主包的分包。 官方定义如下。
启动applet时，默认情况下下载主软件包，并启动主软件包中的页面。 如果用户需要打开分包中的某个页面，客户端将下载相应的分包，并在下载完成后进行展示。
总结如下。
打开applet，默认情况下先加载主包
进入分包页面后，将重新加载相应的分包
这样做的好处是，进入主包页面时，下载的代码量大幅减少，白色屏幕的时间缩短，体验更好。
特性
1.7.3或更高版本的基础库开始支持，不支持的版本默认使用整个软件包的方式
整个小程序的所有分包尺寸不得超过4M，每个分包/主包装的尺寸不得超过2M
分包数量没有限制。 也就是说，可以转包n个，也可以每页转包1个
入口页/制表页必须在主包中
关于主包
第一次进入小程序，默认下载主软件包代码
除分包外的所有电线都将放在主包中
分包内代码可以参照主包内代码
关于分包
由于存在资源依赖关系，微信的工作原理是先下载主包，再下载分包
分包目录不在主软件包目录下
分包只能引用自己包内、主包内的资源，不能引用其他分包内的资源
坑坑
applet的打包机制只是基于文件目录打包，分包中的任何require/import文件都不能分包，除非它们位于同一目录下。 也就是说，类库和某些公共文件只能放在主包中。 如果主包的分包划分不好，也很难降低主包的尺寸
当Android进入分包页面时，会出现丑陋的系统级加载层，在一定程度上影响Android的体验
旋转分包装载
小程序在使用分包之前，压缩的代码量约为2.45M米。 也就是说，新用户需要首次下载的2.45M米代码将进入页面，而分包机制将主软件包的大小降低到1米左右。 也就是说，进入主包页面后，下载时间将减少约60%
文件结构：
我们根据用户访问的轨迹，分成了20个左右的分包。 例如，trade包包含详细页面、订单页面、支付页面、成功支付页面等。 用户进入小程序后可能不需要立即使用此线条页面，但一旦使用，可能会占用整个链条，因此可以将其用作分包。
历史入口是兼容的
有一页被转包后，路径会发生变化。 详细页面从/pages/detail转换为/subPages/trade/detail，这意味着如果用户访问了以前的page，将不能获得正确的页面响应。 例如，共享的小程序的卡、二维码、公众号推送消息等)目前采用以下方案：
将保留原始主包中的每个页面，但代码只保留跳转逻辑，用户进来后立即跳转到相应的分包页面，用户几乎看不到
这样也会产生小问题。 这些跳转页面也占用了空间。 下一步在线，页面跳转时判断，优化为直接跳转到正确的分包页面。