小程序redux性能优化的方法


这篇文章主要介绍“小程序redux性能优化的方法”的相关知识,小编通过实际案例向大家展示操作过程,操作方法简单快捷,实用性强,希望这篇“小程序redux性能优化的方法”文章能帮助大家解决问题。
首先了解小程序的工作原理和性能关键点。
小程序的视图层目前使用 WebView 作为渲染载体,而逻辑层是由独立的 JavascriptCore 作为运行环境。在架构上,WebView 和 JavascriptCore 都是独立的模块,并不具备数据直接共享的通道。当前,视图层和逻辑层的数据传输,实际上通过两边提供的 evaluateJavascript 所实现。即用户传输的数据,需要将其转换为字符串形式传递,同时把转换后的数据内容拼接成一份 JS 脚本,再通过执行 JS 脚本的形式传递到两边独立环境。
而 evaluateJavascript 的执行会受很多方面的影响,数据到达视图层并不是实时的。
频繁的去 setData
在我们分析过的一些案例里,部分小程序会非常频繁(毫秒级)的去setData,其导致了两个后果:
Android 下用户在滑动时会感觉到卡顿,操作反馈延迟严重,因为 JS 线程一直在编译执行渲染,未能及时将用户操作事件传递到逻辑层,逻辑层亦无法及时将操作处理结果及时传递到视图层;
渲染有出现延时,由于 WebView 的 JS 线程一直处于忙碌状态,逻辑层到页面层的通信耗时上升,视图层收到的数据消息时距离发出时间已经过去了几百毫秒,渲染的结果并不实时;
每次 setData 都传递大量新数据
由setData的底层实现可知,我们的数据传输实际是一次 evaluateJavascript 脚本过程,当数据量过大时会增加脚本的编译执行时间,占用 WebView JS 线程,
后台态页面进行 setData
当页面进入后台态(用户不可见),不应该继续去进行setData,后台态页面的渲染用户是无法感受的,另外后台态页面去setData也会抢占前台页面的执行。
我们在优化性能时,指标是非常重要的,没有指标,你没法知道优化的点是否有效。不能单凭感觉去优化,要根据指标反馈,明确优化的成果。同时,优化就像个无底洞,要注意投入产出比。
用户反馈的卡顿,要么就是js执行消耗资源过多导致处理器没响应,要么是UI渲染消耗资源过多,导致UI没法响应用户操作。
通过查看代码,我们并没有消耗大量计算资源的业务逻辑,但是出现了UI反复操作和抢占资源的现象。
可以利用setData的第二个参数,传入callback函数,统计渲染时长。代码如下
案例分析 1、检查点:是否频繁去setData 检查结果:存在 产生原因:redux中监听的是整个store,只要store变化,就会执行setData操作,这就意味着页面无关的数据改变,也会触发该页面执行setData操作,但是这个操作是无意义的。 问题代码:
解决方案:
只监听当前页面用到的store中的部分数据,只有该部分数据变化,才setData。(store没提供单个数据的监听,如果自己修改redux实现,难度较大,同时修改太底层,容易出不可预料的异常。) 判断页面数据与需要更新数据是否相同,如果相同,不做操作。(这个方案成本比较低,就用它吧)
代码实现:
另外一个优化:如果store数据毫秒级变化怎么办,例如更新购物车的同时,还更新了购物数量,能不能把两次变化合并起来?因为store的数据是共享的,最后一次的更新就是最新的数据,可以采用节流器对请求进行合并。
2、检查点:每次 setData 都传递大量新数据 检查结果:存在 产生原因:
页面存在引用没用到的store数据。 后端返回数据直接进入store,后端接口返回冗余字段。
问题代码:
解决方案:
删除页面无用的connect (老业务在使用,修改存在风险,通过后续迭代优化) 请求后端接口后,拿到数据进行优化处理再把数据传入store(成本较高)
3、检查点:后台态页面进行 setData 检查结果:存在 产生原因:redux connect设计与小程序有差异 问题代码:
小程序生命周期中,onUnload会在页面销毁时执行,例如A->B->C->D 的跳转,A页面一直在监听store的变化,如果D页面修改数据,会造成A,B,C页面也执行setData操作,抢占了D的资源,因此造成卡顿。 解决方案:
后台状态的页面在setData时直接return(目前采用该方法) 当页面隐藏时,移除监听。
代码实现:
但是由于在后台的页面数据没法更新,如果D页面修改A引用的数据,就会出现A引用旧数据问题,所以在onShow的时候做一次同步。
指标测试 做了这么多,到底有没用,拿出来溜一溜就清楚了。 测试平台:iphone7、三星s7 、小程序开发工具 测试流程:首页 -> 配送到家 -> 加入购物车 -> 结算 ->查看订单 测试指标:调用setData次数,渲染总耗时,平均单次渲染耗时
优化后setData次数平均下降150次。 渲染耗时越是卡顿的机器,收益越大,三星s7平均每次渲染耗时降低826ms。关于“小程序redux性能优化的方法”的内容就介绍到这里了,感谢大家的阅读。如果想了解更多行业相关的知识,可以关注百云主机行业资讯频道免费云主机域名,小编每天都会为大家更新不同的知识点。

相关推荐: 怎么使用DataBase First模式实现数据库的增删改查

本文小编为大家详细介绍“怎么使用DataBaseFirst模式实现数据库的增删改查”,内容详细,步骤清晰,细节处理妥当,希望这篇“怎么使用DataBaseFirst模式实现数据库的增删改查”文章能帮助大家解决疑惑,下面跟着小编的思路慢慢深入,一起来学习新知识吧…

免责声明:本站发布的图片视频文字,以转载和分享为主,文章观点不代表本站立场,本站不承担相关法律责任;如果涉及侵权请联系邮箱:360163164@qq.com举报,并提供相关证据,经查实将立刻删除涉嫌侵权内容。

(0)
打赏 微信扫一扫 微信扫一扫
上一篇 01/10 16:27
下一篇 01/10 16:27

相关推荐