问题
@xmsz 提供多些信息吧,哪些场景下,手机型号,最好有 demo。
@xmsz 提供多些信息吧,哪些场景下,手机型号,最好有 demo。
小程序:京喜
手机型号:z5x 华为p20 华为p30 三星S20
表现:
再iOS上肯定没问题
所以大概率还是跟动态渲染有关,安卓机子支撑不起
有时间我会录屏
有没有其他大一点应用是采用3.0的,我们也想测试一下。
他们使用的是 2.0,而且也不一定接近你的场景,所以还是说你在什么场景遇到什么问题,而且没有 demo,也没法帮助你。
复杂页面(比如电商类型的首页),完全采用taro,微信小程序上在中低端机型上的性能确实是不行的(在支付宝小程序上会好很多)。我们目前的方案,除了常规优化,主要是两点:
1)把一些模块用原生写(比如不满足虚拟列表应用条件的长列表的列表项组件)。
2)对于白屏,我们给每个页面注入了loading的预渲染(类似H5的懒加载路由过渡loading)。
经过这些优化后,整体性能有巨大提升,重渲染时长降低了1.5倍以上,在低端机效果尤为明显。
个人觉得,对于复杂页面,不使用混写的前提下尽量保证性能,需要思考怎么将懒加载和虚拟化应用到一些复杂场景,比如,各模块(不一定是列表)高度不定的场景能否适用虚拟化技术。
如果有什么好的思路,也希望能在这里交流下。
另外,taro目前有个bug #7227,导致很多时候只敢用index作为key,如果这个解决了,能有效减少重渲染,对性能也是有所提升。
他们使用的是 2.0,而且也不一定接近你的场景,所以还是说你在什么场景遇到什么问题,而且没有 demo,也没法帮助你。
居然是2.0 2.0都有这么卡 感觉3.0更难说。我们有项目从2.x版本升到3.x版本。明显吃力太多,毕竟运行时操作变多
我们现在遇到的场景和电商应用很像,就是一些产品 功能模块很多;
而单个页面上,首页上的功能多到不行。这种就导致一个页面上有很多『动态』的东西,包括定时器,用户触发等一些系列会造成视图渲染的操作
这个时候,安卓的用户就惨了,因为安卓传输到视图的操作无论耗时还是性能损耗都很大,所以卡炸掉
复杂页面(比如电商类型的首页),完全采用taro,微信小程序上在中低端机型上的性能确实是不行的(在支付宝小程序上会好很多)。我们目前的方案,除了常规优化,主要是两点:
1)把一些模块用原生写(比如不满足虚拟列表应用条件的长列表的列表项组件)。
2)对于白屏,我们给每个页面注入了loading的预渲染(类似H5的懒加载路由过渡loading)。
经过这些优化后,整体性能有巨大提升,重渲染时长降低了1.5倍以上,在低端机效果尤为明显。
个人觉得,对于复杂页面,不使用混写的前提下尽量保证性能,需要思考怎么将懒加载和虚拟化应用到一些复杂场景,比如,各模块(不一定是列表)高度不定的场景能否适用虚拟化技术。
如果有什么好的思路,也希望能在这里交流下。
嗯 我们暂时用的也是这个方案,虚拟列表 + loading。能解决掉长列表页面的例如粉丝列表页的性能问题。
但确实只能是暂时的方案,而且也是一样基础能优化的都优化了
所以来问问有没有从框架本身或者其他优化的方案
同问对于taro3性能上后续还有什么提升吗,最近用taro3的小程序页面,每次setState在低端机型(如iphone6)上那是一个卡(高端机型还好),但之前用wepy写的完全没有这种卡顿更新慢的问题,希望taro3能进行一些改善,不然后续可能得换框架了(产品不接受的情况下)
同问,中高端机倒是没太大区别,低端机型交互一多必卡,跟taro2差别太明显了
使用 <CustomWrapper> 组件包裹更新卡顿的部分能有效提升低端机的性能。不过引入这个小程序自定义组件会带来一些小问题,详情请看 release 信息。
Most helpful comment
同问对于taro3性能上后续还有什么提升吗,最近用taro3的小程序页面,每次setState在低端机型(如iphone6)上那是一个卡(高端机型还好),但之前用wepy写的完全没有这种卡顿更新慢的问题,希望taro3能进行一些改善,不然后续可能得换框架了(产品不接受的情况下)