微信小程序包下载耗时 第1篇
原先项目中因为腾讯云 IM SDK 体积过大（接近 500KB），所以不得不将其从主包移动至分包内，白白增加了分包体积。
有了分包异步化能力之后，我们针对此进行了改造，将腾讯云 IM SDK 从分包中移除，在主包异步引入：
至此，在不影响主包体积的情况下，将庞大的第三方库从分包中移除后，也能保证功能的正常使用。优化后的代码在发布后，通过前后对比，分包的下载耗时也得到了提升：
详见下图（出自：小程序开发者后台-统计-性能数据面板）：
本文结合实际业务场景，针对小程序开发中“主包体积不够用”这一大痛点，以“分包异步引入”为话题进行了探索。
在第三方开发框架(uni-app/Taro 等)官方仅能支持插件异步引入的情况下，实现了另一套可行、稳定且更佳的方案，增强了小程序拓展性的同时，也提升了分包页面的载入性能，带来额外项目收益。
通过项目中埋点数据反馈，加入了后续的重试机制，这套分包异步化方案的失败率可达到万分之 ，能放心使用。
微信小程序包下载耗时 第2篇
除了上面讲的控制包的大小，对异步请求的优化也很重要。
每调用一次setData, 都是逻辑层向渲染层的一次通讯，这个通信还不是直接传给webView, 而是通过走了native层，通讯的开销很大。
渲染层收到通讯后，还需要重新渲染出来，所以，emmm, 一次setData带来两次开销：通信的开销 + webview更新的开销。
在数据传输时，逻辑层会执行一次来去除掉setData数据中不可传输的部分，之后将数据发送给视图层。同时，逻辑层还会将setData所设置的数据字段与data合并，使开发者可以用读取到变更后的数据。
如果一个数据不能会影响渲染层，则不用放在setData里面
这个很好理解吧
在一个列表中，有n条数据，采用上拉加载更多的方式，假如这个时候想对其中某一个数据进行点赞操作，还能及时看到点赞的效果
此时，可以采用setData全局刷新，点赞完成之后，重新获取数据，再次进行全局重新渲染，这样做的优点是：方便，快捷！缺点是：用户体验极其不好，当用户刷量100多条数据后，重新渲染量大会出现空白期（没有渲染过来）
如果采用布局刷新，将点赞的id传过去，知道点的是那一条数据, 将点赞的id传过去，知道点的是那一条数据。
重新获取数据，查找相对应id的那条数据的下标（index是不会改变的），用setData进行局部刷新
小程序中可能有n个页面，所有的这些页面，虽然都拥有自己的webview(渲染层)， 但是却共享同一个js运行环境。也就是说，当你跳到了另外一个页面（假设是B页面），本页面（假设是A页面）的定时器等js操作仍在进行，并且不会被销毁，并且会抢占B页面的资源。
在h5的环境中，当我们跳转到其他页面，老页面的js环境会被自动销毁，定时器什么都被销毁掉了，因此我们不需要关心老页面中，还有哪些js代码可能还会执行。但是在小程序中，我们必须手动的“清理”掉这样的代码。
pageScroll 事件，也是一次通讯，是webview层向js逻辑层的通讯。这次通讯也是开销较大，如果考虑到这个事件被频繁的调用，回调函数如果有复杂的setData的话，emmmmm， 性能就会很差了。
在h5 中的环境中，为了实现懒加载、下拉加载，我们不得不去获取节点的位置。
为啥说不得不，是因为我们本可以用新的api ——intersectionObject去轻松实现（google等主流浏览器都已经支持了），但是微信的内置X5浏览器很遗憾的不支持。
没想到，在小程序的环境中，微信竟然良心发现，支持intersectionObject api, 因此获取节点的信息，尽量还是用这api 吧。
自定义组件的更新只在组件内部进行，不受页面其他不能分内容的影响；比如一些运营活动的定时模块可以单独抽出来，做成一个定时组件，定时组件的更新并不会影响页面上其他元素的更新；各个组件也将具有各自独立的逻辑空间。每个组件都分别拥有自己的独立的数据、setData调用
相比于上面的优化策略，最重要的是找出小程序中的性能瓶颈。在自己的优化实践中，遇到了下面的问题：
搞微信小程序遇到的这些坑，虽然可以收获满满的填坑经验，但是这些填坑经验并不算是真正的计算机知识，因为这些知识的并不是基于对本质底层的理解，而是依靠经验，而经验是很快就会过时，可能下一次小程序api来一次大的升级，小程序优化手段马上就会换成另外一种。
微信小程序包下载耗时 第3篇
打包原则
引用原则
低版本兼容 由微信后台编译来处理旧版本客户端的兼容，后台会编译两份代码包，一份是分包后代码，另外一份是整包的兼容代码。 新客户端用分包，老客户端还是用的整包，完整包会把各个 subPackages 里面的路径放到 pages 中。
分包入口文件 每个分包的配置中，entry 字段可以指定该分包中的任意一个 JS 文件作为入口文件，该文件会在分包注入时首先被执行。
指定的 JS 文件应该填写相对于分包根目录的路径，例如需要指定 /path/to/subPackage/src/ 作为分包 /path/to/subPackage 的入口文件时，应填写 src/。
调试这个功能需要 或以上版本的微信开发者工具，正式环境没有版本需求。
微信小程序包下载耗时 第4篇
按照官方文档的姿势，使用require关键字就能让主包异步引入分包中的代码。
先注册一个名为external-library-mqtt的分包，并在对应文件夹内放置一个空的和的源码文件：
接下来对着官方文档抄，修改主包内 MQTT 的引入方式：
好了，先编译看看效果再说……
出师未捷身先死，编译报错了。因为我们使用的是第三方开发框架(uni-app)，而不是微信小程序的原生语法，第三方框架大都通过 Webpack 编译，静态产物不支持CommonJS模块，所以require关键字无法编译通过。
继续看官方文档，稍微往下翻翻，还有一招：
通过微信小程序提供的requirePlugin方法，主包也可以异步引入插件中的代码，那么把 放入插件内，一样能够满足需求。
在放手去干之前，我们先来探讨一个话题，在本文的场景下，第三方库是应该放在分包中？还是放在插件中？两者之间有什么区别？