Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

是否有大型的应用案例,3.0方案在安卓上不是很流畅,有什么优化的方法 #7400

Closed
xmsz opened this issue Aug 21, 2020 · 13 comments
Assignees
Labels
enhancement New feature or request

Comments

@xmsz
Copy link

xmsz commented Aug 21, 2020

这个特性解决了什么问题?

问题

  1. 3.0是否有大型的应用案例展示,想看看其他应用在安卓上是否会卡顿。官网和issue上的案例都太简单了没什么区别
  2. 3.0方案在安卓上感觉上确实不是很流畅,毕竟改成运行时,所以很依赖用户手机性能,而安卓的数据和视图交互又完全很慢。
  3. 目前看到京喜是大型应用,但是在安卓上也是卡,就是能用而已。手机是中端机,所以确实已经跑不动了。如果用原生写肯定是没问题。但是这完全就没意义了... 需求就是多平台

这个 API 长什么样?

  1. 是否有什么针对安卓的优化方法,常规的已经都做了。
@Chen-jj
Copy link
Contributor

Chen-jj commented Aug 22, 2020

@xmsz 提供多些信息吧,哪些场景下,手机型号,最好有 demo。

@xmsz
Copy link
Author

xmsz commented Aug 24, 2020

@xmsz 提供多些信息吧,哪些场景下,手机型号,最好有 demo。

小程序:京喜
手机型号:z5x 华为p20 华为p30 三星S20
表现:

  • 页面渲染需要一定时间,大部分页面开始会有一小段白屏
  • 长列表滚动并不是很流畅
  • 用不久手机会出现略微发烫
  • 切换页面会有些许卡顿
  • 大概体验感受就是不够流畅,总觉得卡卡的,反应也比较慢

再iOS上肯定没问题

所以大概率还是跟动态渲染有关,安卓机子支撑不起

有时间我会录屏

有没有其他大一点应用是采用3.0的,我们也想测试一下。

@Chen-jj
Copy link
Contributor

Chen-jj commented Aug 24, 2020

他们使用的是 2.0,而且也不一定接近你的场景,所以还是说你在什么场景遇到什么问题,而且没有 demo,也没法帮助你。

@vdfor
Copy link
Contributor

vdfor commented Aug 27, 2020

复杂页面(比如电商类型的首页),完全采用taro,微信小程序上在中低端机型上的性能确实是不行的(在支付宝小程序上会好很多)。我们目前的方案,除了常规优化,主要是两点:
1)把一些模块用原生写(比如不满足虚拟列表应用条件的长列表的列表项组件)。
2)对于白屏,我们给每个页面注入了loading的预渲染(类似H5的懒加载路由过渡loading)。
经过这些优化后,整体性能有巨大提升,重渲染时长降低了1.5倍以上,在低端机效果尤为明显。
个人觉得,对于复杂页面,不使用混写的前提下尽量保证性能,需要思考怎么将懒加载和虚拟化应用到一些复杂场景,比如,各模块(不一定是列表)高度不定的场景能否适用虚拟化技术。
如果有什么好的思路,也希望能在这里交流下。

@vdfor
Copy link
Contributor

vdfor commented Aug 27, 2020

另外,taro目前有个bug #7227,导致很多时候只敢用index作为key,如果这个解决了,能有效减少重渲染,对性能也是有所提升。

@xmsz
Copy link
Author

xmsz commented Aug 28, 2020

他们使用的是 2.0,而且也不一定接近你的场景,所以还是说你在什么场景遇到什么问题,而且没有 demo,也没法帮助你。

居然是2.0 2.0都有这么卡 感觉3.0更难说。我们有项目从2.x版本升到3.x版本。明显吃力太多,毕竟运行时操作变多

我们现在遇到的场景和电商应用很像,就是一些产品 功能模块很多;
而单个页面上,首页上的功能多到不行。这种就导致一个页面上有很多『动态』的东西,包括定时器,用户触发等一些系列会造成视图渲染的操作

这个时候,安卓的用户就惨了,因为安卓传输到视图的操作无论耗时还是性能损耗都很大,所以卡炸掉

@xmsz
Copy link
Author

xmsz commented Aug 28, 2020

复杂页面(比如电商类型的首页),完全采用taro,微信小程序上在中低端机型上的性能确实是不行的(在支付宝小程序上会好很多)。我们目前的方案,除了常规优化,主要是两点:
1)把一些模块用原生写(比如不满足虚拟列表应用条件的长列表的列表项组件)。
2)对于白屏,我们给每个页面注入了loading的预渲染(类似H5的懒加载路由过渡loading)。
经过这些优化后,整体性能有巨大提升,重渲染时长降低了1.5倍以上,在低端机效果尤为明显。
个人觉得,对于复杂页面,不使用混写的前提下尽量保证性能,需要思考怎么将懒加载和虚拟化应用到一些复杂场景,比如,各模块(不一定是列表)高度不定的场景能否适用虚拟化技术。
如果有什么好的思路,也希望能在这里交流下。

嗯 我们暂时用的也是这个方案,虚拟列表 + loading。能解决掉长列表页面的例如粉丝列表页的性能问题。

但确实只能是暂时的方案,而且也是一样基础能优化的都优化了

所以来问问有没有从框架本身或者其他优化的方案

@soulcm
Copy link

soulcm commented Oct 20, 2020

同问对于taro3性能上后续还有什么提升吗,最近用taro3的小程序页面,每次setState在低端机型(如iphone6)上那是一个卡(高端机型还好),但之前用wepy写的完全没有这种卡顿更新慢的问题,希望taro3能进行一些改善,不然后续可能得换框架了(产品不接受的情况下)

@pecopeco
Copy link

pecopeco commented Jan 5, 2021

同问,中高端机倒是没太大区别,低端机型交互一多必卡,跟taro2差别太明显了

@Chen-jj
Copy link
Contributor

Chen-jj commented Jan 5, 2021

使用 <CustomWrapper> 组件包裹更新卡顿的部分能有效提升低端机的性能。不过引入这个小程序自定义组件会带来一些小问题,详情请看 release 信息。

@cmdparkour
Copy link

说一下我们公司的小程序,微信搜索:工地活、鱼泡网、装修招工。用的一套源码,taro3+react的,在低端机上特别卡,在使用空页面的时候,在低端机上的表现,跳转到页面之前,会有明显的1秒白屏,但我们用Uniapp做了相对应的测试,发现直接秒进,想不通,但大概率是动态编译耗时的问题,因为低端机较高端机性能上最大的不同就是在CPU、内存这一块。

@v2-lab
Copy link

v2-lab commented Jul 11, 2022

Taro + Vue3 微信小程序,Android出来是真的卡,肉眼可见的卡顿,准备用 uniapp 重写了

@git-guining
Copy link

Taro + Vue3 微信小程序,Android出来是真的卡,肉眼可见的卡顿,准备用 uniapp 重写了

列表分页加载是真的很卡

@Chen-jj Chen-jj closed this as completed Apr 14, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

9 participants