记一次rax应用用户体验性能优化

这篇具有很好参考价值的文章主要介绍了记一次rax应用用户体验性能优化。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

前言


对于前端开发攻城狮们来说,性能优化是一个永恒的话题。随着前端需求复杂度的不断升高,在项目中想始终保持着良好的性能也逐渐成为了一个有挑战的事情。本次分享简述我们在 Rax 项目中常用的一些性能优化方式,并将从近期的一个实际业务需求出发,讲述我在 Rax C端应用场景下所遇到性能问题排查时的心路历程。
本次分享的优化内容,主要是指用户滑动屏幕浏览页面过程中所花费的单帧渲染耗时的降低比例。 单帧渲染耗时通过 chrome dev tools 插件以及手淘端app dev tools测得。一般来说浏览器运行帧率为 60hz,因此对于帧率要求非常高的场景如内容输入后的响应、动画等,需要尽可能的将单帧耗时控制在 16.6ms(1s / 60)以内,用户才能完全感知不到系统的卡顿。对于一般性能要求没那么高的应用场景,单帧耗时能达到33.2ms(2s / 60),也能达到一个相对流畅的用户体验。
实际业务现状
接下来我将从近期参与的一个实际业务需求出发,记录下我在这个项目中遇到性能问题时,发现问题、解决问题的心路历程。
从实际业务场景出发,我们发现不少页面在用户滑动浏览页面的过程中存在卡顿,一些情况下卡顿严重,非常影响用户体验,由于多数安卓机的渲染性能不如IOS系统,安卓端的性能问题会尤其明显

那么如何优化这个性能问题?

在 Rax当前的版本中,rax框架使用同步渲染模式(Synchronous Rendering),也就是说,在处理更新时会阻塞整个 UI 线程,直到所有更新完成才会重新渲染视图。这种方式虽然简单易懂,但是在处理大量或复杂数据时存在明显的性能问题,导致应用程序出现卡顿或者无响应等问题。

React18的并发模式(Concurrent Mode),它可以将渲染任务分解成多个小块,并通过 React 的调度器(Scheduler)来优化执行顺序和时间,从而降低了单次渲染所需的计算资源和时间。并发模式可以在渲染过程中及时响应用户的输入和请求,避免出现 UI 卡顿或者无响应的情况,从而提高了整个应用的用户体验。

目前Rax框架在性能优化上虽然不及react18,但仍然有非常好的应用渲染性能基础,站在了巨人的肩膀上,我们所能做的,便是在不添乱的前提下,帮助Rax更快、更高效的完成遍历渲染的过程,使更新链路尽可能的短的走完

排查流程

通过安卓手淘扫码观察app dev tools的性能分析,每帧普遍在 700ms以上,最严重的长达 1847ms

记一次rax应用用户体验性能优化,ux

观察发现最耗时的任务为一个叫appear的函数执行,appear函数出现在trackerLink组件中,是曝光方法,也就是说,每当一个标签需要进行曝光,那么当这个元素出现在浏览器视口,就会触发此appear方法,随着一次又一次的需求迭代,需要曝光的点越来越多,导致每一次元素重新出现在适口,都会有大量的appear方法调用,消耗了大量的性能,在安卓系统性能不够优秀的机型上,用户体验表现就会卡顿。

记一次rax应用用户体验性能优化,ux

当我们滑动页面时,由于大量元素需要进行曝光操作,appear函数长时间执行,对于用户来讲,这段时间界面是卡死且无法交互的。

如果我们把这个例子中的appear函数类比成Rax的更新过程:即setState触发了一次更新,而这次更新耗时非常久,比如1800ms。那么在这1800ms的时间内界面是卡死的,用户无法进行交互,非常影响用户的使用体验。

优化思路

雪中送炭

擒贼先擒王,首先解决最影响性能的,怎么让appear方法的执行不影响主线程的渲染?

1.接入react18?

成本太高。pass

2.使用requestIdleCallback来控制appear方法的执行不影响主线程?

requestIdleCallback 会将任务安排在浏览器的空闲时期执行。在当前页面的生命周期内,也不能保证 requestIdleCallback 中的任务一定会执行。如果浏览器长时间忙于处理高优先级任务,低优先级的空闲回调可能会被推迟,直到有足够的空闲时间来执行它们。如果这种情况一直持续,那么这些任务可能会被无限期地推迟。pass

3.如果任务是关键性的,需要在特定时间内一定要执行,那么使用 setTimeout可能是更好的选择。setTimeout这个API提供了更可靠的方式来计划任务的执行,即使它们没有 requestIdleCallback 提供的执行时机那样灵活。

setTimeout将同步任务变为异步任务,当需要trackertLink组件需要曝光时,将曝光函数异步执行,不阻塞影响主线程渲染,提高用户体验性。

改动TrackerLink组件:

// needAsyncSending控制埋点曝光异步进行,不阻塞主线程
if (needAsyncSending) {
  const sendExpTimer = setTimeout(() => {
    recordExp();
    clearTimeout(sendExpTimer);
  }, 0)
} else {
  recordExp();
}

优化后:

记一次rax应用用户体验性能优化,ux

我们可以看到,当trakcerLink组件异步调用曝光方法时,每帧渲染时间大幅缩减,效果明显,每帧最糟糕的情况从1800ms降低至每帧最糟糕的情况200ms左右,

锦上添花

通过异步发送曝光埋点解决了最大头的性能问题,用户滑动页面时已经不会有明显的延时和滑不动,但是任然有部分顿挫感,由于无法使用react app dev tools工具观察组件的渲染情况,我们使用console.log来判断哪些组件一直在重新渲染,发现在滚动过程中,航班报价列表和报价卡片一直在重新渲染,

记一次rax应用用户体验性能优化,ux

但是业务场景下,此种渲染是不必要的,当没有重新发起请求时,是不需要一直重新渲染ota报价卡片

避免 State 的不必要更新

一些业务场景下,不需要一直更新setState,找到不必要的setState,避免这些更新

防止父组件重新渲染重新声明方法导致子组件不必要的重新渲染

纯函数组件使用 Memo 包裹,纯函数组件的function类型的prop使用useCallback包裹

记一次rax应用用户体验性能优化,ux ===========>>>>>记一次rax应用用户体验性能优化,ux

最终优化效果:

可以看到最终性能分析得到的数据没有明显卡顿的地方,很多帧也达到了16.7ms的理想状态

记一次rax应用用户体验性能优化,ux文章来源地址https://www.toymoban.com/news/detail-831821.html

到了这里,关于记一次rax应用用户体验性能优化的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 数字化时代,如何做好用户体验与应用性能管理​

    随着数字化时代的到来,各个行业的应用系统从传统私有化部署逐渐转向公有云、行业云、微服务,这种变迁给运维部门和应用部门均带来了较大的挑战。基于当前企业 IT 运维均为多部门负责,且使用多种运维工具,因此,当业务出现问题时很难快速定位故障根源。而随着业

    2024年02月16日
    浏览(46)
  • 数字化时代,如何做好用户体验与应用性能管理

    随着数字化时代的到来,各个行业的应用系统从传统私有化部署逐渐转向公有云、行业云、微服务,这种变迁给运维部门和应用部门均带来了较大的挑战。基于当前企业 IT 运维均为多部门负责,且使用多种运维工具,因此,当业务出现问题时很难快速定位故障根源。而随着业

    2024年02月14日
    浏览(47)
  • 性能测试(记一次论坛网站性能测试)

    近期做了一次论坛网站性能测试,记录下来以便总结提高,欢迎大家交流分享,若有不妥之处还请指教; 性能要求 1、服务在3000并发基础上,关键服务响应时间小于等于300ms 2、系统支持快速扩容,支持更大的并发Session,例如并发Session从2000到4000,扩容后关键页面访问、关键

    2024年02月11日
    浏览(41)
  • 记一次Flink遇到性能瓶颈

    这周的主要时间花在Flink上面,做了一个简单的从文本文件中读取数据,然后存入数据库的例子,能够正常的实现功能,但是遇到个问题,我有四台机器,自己搭建了一个standalone的集群,不论我把并行度设置多少,跑起来的耗时都非常接近,实在是百思不得其解。机器多似乎

    2023年04月15日
    浏览(78)
  • 记一次 JMeter 压测 HTTPS 性能问题

    在使用 JMeter 压测时,发现同一后端服务,在单机 500 并发下,HTTP 和 HTTPS 协议压测 RT 差距非常大。同时观测后端服务各监控指标水位都很低,因此怀疑性能瓶颈在 JMeter 施压客户端。 切入点:垃圾回收 首先在施压机观察到 CPU 使用率和内存使用率都很高,详细看下各线程

    2024年01月21日
    浏览(43)
  • 优化记录 -- 记一次搜索引擎(SOLR)优化

    某服务根据用户相关信息,使用搜索引擎进行数据检索 solr 1台:32c 64g 数据10gb左右,版本 7.5.5 应用服务器1台:16c 64g 应用程序 3节点 1、因业务系统因处理能不足,对业务系统硬件平台进行升级,升级变更为 16c64g — 32c64g 增加 16c 2、业务系统升级,处理能力增加,对原搜索引

    2024年02月05日
    浏览(63)
  • 记一次项目内存优化--内存泄漏

    主要是与某个版本作基准进行对比(一般是最新版本的前一个版本作原数据),优化后,PSS有所下降,线上OOM率减少(Bugly版本对比),泄漏点减少(从捉取一些线上上传回来的内存堆栈信息分析,或本地测试后dump下hprof文件分析)。 了解什么是内存泄漏 了解虚拟机中的对象

    2024年02月12日
    浏览(77)
  • 记一次 Oracle 下的 SQL 优化过程

    事情是这样的,UAT 环境的测试小伙伴向我扔来一个小 bug,说是一个放大镜的查询很慢,转几分钟才出数据,我立马上开发环境试了一下,很快啊我说😏,放大镜的数据立马就出来了,然后我登录 UAT 环境一看,诶是有些慢😕 ,于是开始了我的排查之旅... 首先我立马拿到了

    2024年02月05日
    浏览(42)
  • 【PyTorch】记一次卷积神经网络优化过程

    在深度学习的世界中,图像分类任务是一个经典的问题,它涉及到识别给定图像中的对象类别。CIFAR-10数据集是一个常用的基准数据集,包含了10个类别的60000张32x32彩色图像。在上一篇博客中,我们已经探讨如何使用PyTorch框架创建一个简单的卷积神经网络(CNN)来对CIFAR-10数

    2024年01月24日
    浏览(47)
  • 记一次生产慢sql索引优化及思考

    夜黑风高的某一晚,突然收到一条运营后台数据库慢sql的报警,耗时竟然达到了60s。 看了一下,还好不是很频繁,内心会更加从容排查问题,应该是特定条件下没有走到索引导致,如果频繁出现慢查询,可能会将数据库连接池打满,导致数据库不可用,从而导致应用不可用。

    2024年02月04日
    浏览(47)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包