微信小程序包下载耗时 第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
方法,主包也可以异步引入插件中的代码,那么把 放入插件内,一样能够满足需求。
在放手去干之前,我们先来探讨一个话题,在本文的场景下,第三方库是应该放在分包中?还是放在插件中?两者之间有什么区别?