第 6 题：React 项目中有哪些细节可以优化？实际开发中都做过哪些性能优化 about fe-interview

[BoWang816]

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

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

[Genzhen]

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

[tornoda]

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

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

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

[yaohuangguan]

@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，优化原理一样，不用每次使用都一级一级找下去

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

[xsfxtsxxr]

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

[xsfxtsxxr]

@BoWang816 明白了，感谢！

[cn1001wang]

@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]

解构

解构就不去原型链取了？

[geekftz]

细节本身不用过多计较

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

从而产生最大的性能提升