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

第 6 题:React 项目中有哪些细节可以优化?实际开发中都做过哪些性能优化 #12

Open
lgwebdream opened this issue Jun 19, 2020 · 9 comments
Labels
React teach_tag 喜马拉雅 company 快手 company 掌门一对一 company 有赞 company 沪江 company 滴滴 company 网易 company 酷家乐 company

Comments

@lgwebdream
Copy link
Owner

lgwebdream commented Jun 19, 2020

欢迎在下方发表您的优质见解

@lgwebdream lgwebdream added React teach_tag 快手 company 滴滴 company 掌门一对一 company 网易 company 有赞 company 沪江 company 喜马拉雅 company 酷家乐 company labels Jun 19, 2020
@Genzhen
Copy link
Collaborator

Genzhen commented Jun 22, 2020

1)对于正常的项目优化,一般都涉及到几个方面,开发过程中上线之后的首屏运行过程的状态

  • 来聊聊上线之后的首屏及运行状态:

    • 首屏优化一般涉及到几个指标FP、FCP、FMP;要有一个良好的体验是尽可能的把FCP提前,需要做一些工程化的处理,去优化资源的加载

    • 方式及分包策略,资源的减少是最有效的加快首屏打开的方式;

    • 对于CSR的应用,FCP的过程一般是首先加载js与css资源,js在本地执行完成,然后加载数据回来,做内容初始化渲染,这中间就有几次的网络反复请求的过程;所以CSR可以考虑使用骨架屏及预渲染(部分结构预渲染)、suspence与lazy做懒加载动态组件的方式

    • 当然还有另外一种方式就是SSR的方式,SSR对于首屏的优化有一定的优势,但是这种瓶颈一般在Node服务端的处理,建议使用stream流的方式来处理,对于体验与node端的内存管理等,都有优势;

    • 不管对于CSR或者SSR,都建议配合使用Service worker,来控制资源的调配及骨架屏秒开的体验

    • react项目上线之后,首先需要保障的是可用性,所以可以通过React.Profiler分析组件的渲染次数及耗时的一些任务,但是Profile记录的是commit阶段的数据,所以对于react的调和阶段就需要结合performance API一起分析;

    • 由于React是父级props改变之后,所有与props不相关子组件在没有添加条件控制的情况之下,也会触发render渲染,这是没有必要的,可以结合React的PureComponent以及React.memo等做浅比较处理,这中间有涉及到不可变数据的处理,当然也可以结合使用ShouldComponentUpdate做深比较处理;

    • 所有的运行状态优化,都是减少不必要的render,React.useMemo与React.useCallback也是可以做很多优化的地方;

    • 在很多应用中,都会涉及到使用redux以及使用context,这两个都可能造成许多不必要的render,所以在使用的时候,也需要谨慎的处理一些数据;

    • 最后就是保证整个应用的可用性,为组件创建错误边界,可以使用componentDidCatch来处理;

  • 实际项目中开发过程中还有很多其他的优化点:

    • 1.保证数据的不可变性
    • 2.使用唯一的键值迭代
    • 3.使用web worker做密集型的任务处理
    • 4.不在render中处理数据
    • 5.不必要的标签,使用React.Fragments

@Genzhen Genzhen closed this as completed Jul 20, 2020
@Genzhen Genzhen reopened this Jul 29, 2020
@xsfxtsxxr
Copy link

@Genzhen 请教一下大佬,如果在render里面结构赋值也会影响性能吗?比如 const { page, size } = this.state这种的?

@BoWang816
Copy link

@Genzhen 请教一下大佬,如果在render里面结构赋值也会影响性能吗?比如 const { page, size } = this.state这种的?

其实你在使用的时候在render中需要用到state的时候,你使用的时候肯定是必须要拿state上的值,如果不解构,就要使用this.state.xxx的方式,每次render的时候每一个在state上的值都需要从this上找,再从state上找,这样其实会更慢。所以解构出来的方式比直接使用this.state.xxx的方式是更合适的。

@xsfxtsxxr
Copy link

@BoWang816 明白了,感谢!

@tornoda
Copy link

tornoda commented Dec 29, 2020

@Genzhen 请教一下大佬,如果在render里面结构赋值也会影响性能吗?比如 const { page, size } = this.state这种的?

其实你在使用的时候在render中需要用到state的时候,你使用的时候肯定是必须要拿state上的值,如果不解构,就要使用this.state.xxx的方式,每次render的时候每一个在state上的值都需要从this上找,再从state上找,这样其实会更慢。所以解构出来的方式比直接使用this.state.xxx的方式是更合适的。

脱离量级谈性能都是耍流氓。能慢多少?把这时间搞点别的不香嘛

@cn1001wang
Copy link

@Genzhen 请教一下大佬,如果在render里面结构赋值也会影响性能吗?比如 const { page, size } = this.state这种的?

其实你在使用的时候在render中需要用到state的时候,你使用的时候肯定是必须要拿state上的值,如果不解构,就要使用this.state.xxx的方式,每次render的时候每一个在state上的值都需要从this上找,再从state上找,这样其实会更慢。所以解构出来的方式比直接使用this.state.xxx的方式是更合适的。

你好,我想请教下,const {page,size}= this.state 这样的取值方法 与 直接访问this.state.page 性能上的差异是因为每次都要从原型链查找过去吗(这个是叫原型链吗),这一步的优化是否与const page=this.state.page ,之后都使用这个page,优化原理一样,不用每次使用都一级一级找下去

@yaohuangguan
Copy link

@Genzhen 请教一下大佬,如果在render里面结构赋值也会影响性能吗?比如 const { page, size } = this.state这种的?

其实你在使用的时候在render中需要用到state的时候,你使用的时候肯定是必须要拿state上的值,如果不解构,就要使用this.state.xxx的方式,每次render的时候每一个在state上的值都需要从this上找,再从state上找,这样其实会更慢。所以解构出来的方式比直接使用this.state.xxx的方式是更合适的。

你好,我想请教下,const {page,size}= this.state 这样的取值方法 与 直接访问this.state.page 性能上的差异是因为每次都要从原型链查找过去吗(这个是叫原型链吗),这一步的优化是否与const page=this.state.page ,之后都使用这个page,优化原理一样,不用每次使用都一级一级找下去

性能的优化可以抛开不谈吧,差别并没有多少。解构出来更多的其实是简洁和可读性吧。

@shendiid
Copy link

解构

解构就不去原型链取了?

@geekftz
Copy link

geekftz commented Jun 19, 2021

细节本身不用过多计较

最重要是如何理解框架并运用

从而产生最大的性能提升

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
React teach_tag 喜马拉雅 company 快手 company 掌门一对一 company 有赞 company 沪江 company 滴滴 company 网易 company 酷家乐 company
Projects
None yet
Development

No branches or pull requests

9 participants