欢迎在下方发表您的优质见解
Activity
Genzhen commentedon 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来处理;
实际项目中开发过程中还有很多其他的优化点:
xsfxtsxxr commentedon Dec 18, 2020
@Genzhen 请教一下大佬,如果在render里面结构赋值也会影响性能吗?比如 const { page, size } = this.state这种的?
BoWang816 commentedon Dec 18, 2020
其实你在使用的时候在render中需要用到state的时候,你使用的时候肯定是必须要拿state上的值,如果不解构,就要使用this.state.xxx的方式,每次render的时候每一个在state上的值都需要从this上找,再从state上找,这样其实会更慢。所以解构出来的方式比直接使用this.state.xxx的方式是更合适的。
xsfxtsxxr commentedon Dec 18, 2020
@BoWang816 明白了,感谢!
tornoda commentedon Dec 29, 2020
脱离量级谈性能都是耍流氓。能慢多少?把这时间搞点别的不香嘛
cn1001wang commentedon Jan 21, 2021
你好,我想请教下,const {page,size}= this.state 这样的取值方法 与 直接访问this.state.page 性能上的差异是因为每次都要从原型链查找过去吗(这个是叫原型链吗),这一步的优化是否与
const page=this.state.page
,之后都使用这个page,优化原理一样,不用每次使用都一级一级找下去yaohuangguan commentedon May 10, 2021
性能的优化可以抛开不谈吧,差别并没有多少。解构出来更多的其实是简洁和可读性吧。
shendiid commentedon May 17, 2021
解构就不去原型链取了?
geekftz commentedon Jun 19, 2021
细节本身不用过多计较
最重要是如何理解框架并运用
从而产生最大的性能提升