微盟小程序性能优化要分享的内容分为三部分,启动性能加载、首屏加载的体验建议和渲染性能优化。
今天主要讲启动性能加载的性能优化实践,先看启动加载过程的流程:
· 公共库注入
· 资源准备(基础UI创建,代码包下载)
· 业务代码注入和渲染
· 渲染首屏
· 异步请求
优化方案
1、控制代码包大小
· 开启开发者工具中的 “ 上传代码时自动压缩 ”
· 及时清理无用代码和资源文件
· 减少代码包中的图片等资源文件的大小和数量
· 将图片等资源文件放到CND中
· 提取公共样式
· 代码压缩,图片格式,压缩,或者外联
· 公共组件提取,代码复用
2、 分包加载
分包加载过程流程
在开发小程序分包项目时,会有一个或者多个分包,其中没有分包小程序必须包含一个主包,即放置启动页面或者tabBar页面,以及一些分包都需要用到的公共资源脚本。
在小程序启动时,默认会下载主包并且启动主包内页面,如果用户打开分包内的页面,客户端会把分包下载下来,下载完之后再进行展示。
· 分包加载流程
使用分包加载的优点:
· 能够增加小程序更大的代码体积,开发更多的功能
· 对于用户,可以更快地打开小程序,同时不影响启动速度
使用分包加载有哪些限制:
· 整个小程序所有分包不能超过8M
· 单个主包/分包不能超过2M
3、 运行机制优化
· 代码中减少立即执行的代码数量
· 避免高开销和长时间阻塞代码
· 业务代码都写入页面的生命周期中
· 做好缓存策略
4、 数据管理优化
· 首屏请求数量尽量不能超过5个,超过的可以做接口合并(node层,服务端都可以处理)
· 对多次提交的数据可以做合并处理
首屏加载的体验建议和渲染性能优化这两部分的内容,将在下次分享给大家。微盟小程序性能优化实践(下)
很详细
顶,干货。 期待整个后续优化文章,感谢作者分享
发现小程序用得越久,内存占用越多,就算调用api重启小程序也不会使内存占用降到初始值,这方面,不知道楼主有没有好的解决方案?
马克
分包加载,如何对以前的分享链接,推送,二维码的口子做兼容
一个页面放入分包之后,路径会发生变化,例如详情页由/pages/detail变为/subPages/trade/detail,意味着如果用户访问了以前的page则得不到正确的页面响应(例如:分享出去的小程序卡片、二维码、公众号推送消息等),这些静态不可改变的历史入口怎么办?我们目前采用如下方案:
原来主包内的每个页面都保留,但代码只保留跳转逻辑,用户进来后立即跳到对应的分包页面,用户几乎是无感知的
这样也会产生一点小问题:这些跳转页面也占用一定的空间,接下来我们会优化成在onLaunch、页面跳转时进行判断,直接跳入正确的分包页面。
我有个疑问。我看小程序执行的顺序,是限制性APP的onLaunch和onShow方法,才会执行页面路由的注册(register Page),导致有时候在onLaunch和onShow进行判断后再进行页面跳转行不通啊。
举个例子:
我曾想在APP.js的onLaunch和onShow判断缓存中是否有用户ID,如果没有的话则跳转到登录页,发现根本行不通。。。跳不过去。。
如果原来主包内的每个页面都保留,这样分包就没有意义了啊
原来的页面只是保留重定向的代码逻辑,不会占很多体积
封包后A包内的页面跳到B包内的页面 加载过程长大概要多久
这个根据你B包整体的大小来决定,由A包跳转B包的某一个页面,B包将会完整的被下载,成功之后再跳转你的目标页面。
实用,可以参考下
干货,马克
茅塞顿开!感谢作者分享