小程序分包第三方插件 第1篇
原先项目中因为腾讯云 IM SDK 体积过大（接近 500KB），所以不得不将其从主包移动至分包内，白白增加了分包体积。
有了分包异步化能力之后，我们针对此进行了改造，将腾讯云 IM SDK 从分包中移除，在主包异步引入：
至此，在不影响主包体积的情况下，将庞大的第三方库从分包中移除后，也能保证功能的正常使用。优化后的代码在发布后，通过前后对比，分包的下载耗时也得到了提升：
详见下图（出自：小程序开发者后台-统计-性能数据面板）：
本文结合实际业务场景，针对小程序开发中“主包体积不够用”这一大痛点，以“分包异步引入”为话题进行了探索。
在第三方开发框架(uni-app/Taro 等)官方仅能支持插件异步引入的情况下，实现了另一套可行、稳定且更佳的方案，增强了小程序拓展性的同时，也提升了分包页面的载入性能，带来额外项目收益。
通过项目中埋点数据反馈，加入了后续的重试机制，这套分包异步化方案的失败率可达到万分之 ，能放心使用。
小程序分包第三方插件 第2篇
按照官方文档的姿势，使用require关键字就能让主包异步引入分包中的代码。
先注册一个名为external-library-mqtt的分包，并在对应文件夹内放置一个空的和的源码文件：
接下来对着官方文档抄，修改主包内 MQTT 的引入方式：
好了，先编译看看效果再说……
出师未捷身先死，编译报错了。因为我们使用的是第三方开发框架(uni-app)，而不是微信小程序的原生语法，第三方框架大都通过 Webpack 编译，静态产物不支持CommonJS模块，所以require关键字无法编译通过。
继续看官方文档，稍微往下翻翻，还有一招：
通过微信小程序提供的requirePlugin方法，主包也可以异步引入插件中的代码，那么把 放入插件内，一样能够满足需求。
在放手去干之前，我们先来探讨一个话题，在本文的场景下，第三方库是应该放在分包中？还是放在插件中？两者之间有什么区别？
小程序分包第三方插件 第3篇
回到之前编译失败的问题中来，提炼一下目标：编译时跳过require关键字的限制，让它存在于编译产物中。
uni-app 是通过 Webpack 打包的，而 webpack 也提供了编译流程中的各种 hooks，可以利用其中的emit去替换编译产物中的内容。
还是之前的方法，将原先的require关键字替换为customRequire（名称随意即可）。
上述文件是在主包中引入的，经过编译后会被打包入dist/common/中。接着我们新建一个 Webpack plugin，用来把编译产物中的customRequire还原成require：
我们回忆一下分包文件夹，此时的内容并没有被分包中任何文件引用到，所以它不会打包进编译产物中，这里利用copy-webpack-plugin将它复制进dist文件夹对应的分包目录下：
这个时候再次编译一下代码，控制台打印出来的源码了，我们已成功引入了它：
再结合下小程序编译文件的前后对比，我们可以看到即分包 external-library-mqtt 已经从主包中脱离出来，主包体积也相应的减少了 186 KB，说明分包异步化此时已经成功。
大功告……不要大意，好像少了点什么东西。
之前代码中 MQTT 是使用import同步引入，调整之后变为了异步引入，如果在引入完成前，就先调用了 MQTT 提供的方法，那代码就要报错了。设计一个缓存队列来解决它：
至此，分包异步引入完成。
就像“高端的食材往往只需最朴素的烹饪方式”一样，代码功能往往也总会有更为简单粗暴的实现，Webpack 文档中有这么一个好东西：
可以依靠它，来实现我们的目标。
编译后，查看dist/common/文件，Webpack 将 __non_webpack_require__编译成了require，省去了我们自己写 Webpack plugin 的步骤。