@[toc]
前言
众所周知每个应用的开发框架都有其对应的生命周期函数,ReactNative是基于React开发的,所以其生命周期先关函数也和React一样密不可分,为什么文章标题叫“生命周期的进化”呢? 这是有原因的,因为React在React 15和React 16两个版本对生命周期函数做了优化调整,到底进行了那些调整和改进呢? 让我们随着本文一探究竟。
React 15生命周期函数
下面这张图是一个典型的React 15的生命周期函数流程图,也是我们大多数开发者所了解到的。
React 15相关的生命周期函数如下:
constructor()
componentWillReceiveProps()
shouldComponentUpdate()
componentWillMount()
componentWillUpdate()
componentDidUpdate()
componentDidMount()
render()
componentWillUnmount()
Mounting阶段:组件初始化渲染
初始化渲染阶段主要涉及如下几个生命周期函数:
constructor()
componentWillMount()
render()
componentDidMount()
constructor()这个函数只在组件初始化的调用一次,通常开发中主要用于对state的数据初始化。
componentWillMount(),componentDidMount()函数在组件初始化阶段也只调用一次,componentWillMount()在render()函数执行之前被调用,有些同学开发中会在此函数中做网络请求,想想会有哪些风险呀?
之后触发render()方法进行渲染页面,但此时不会去操作真实DOM,只是把要渲染的页面返回处理,真正处理是通过ReactDOM.render方法在页面挂在阶段完成的。
componentDidMount()函数会在真实DOM挂载完成时候调用,通常开发中我们在此函数进行网络请求,消息监听等来操作真实的DOM。
Updating阶段:组件更新
组件的更新分为两种:一种是父组件的更新触发的更新,另一种是组件自身调用this.setState()触发的更新。
组件更新过程中涉及的如下生命周期函数:
componentWillReceiveProps()
shouldComponentUpdate()
componentWillUpdate()
render()
componentDidUpdate()
首先看一下componentWillReceiveProps(nextProps),这个函数参数中nextProps表示接受到的新props,可以用来和this.props进行对比,看是否改变。
关键点:也就是componentWillReceiveProps()函数不是props改变触发的,而是由于父组件更新触发的。
shouldComponentUpdate(nextProps, nextState)函数在组件自身的state发生改变时触发,该函数的返回值决定了组件是否重新render,默认返回“true”,表示只要是state发生更新,就会重新render;实际开发工作中,我们一般会对比函数中的参数来进行业务逻辑判断是否需要重新render。这也是一个React提供给我们的一个性能优化的方向之一。
componentWillUpdate()与componentDidUpdate()是在render前后进行触发的,对应于componentWillMount()和componentDidMount()。componentDidUpdate在组件更新完成之后触发,可以操作真实DOM。
Unmounting阶段:组件卸载
这个阶段就比较简单了,只有一个生命周期函数:
componentWillUnmount()
在组件卸载和销毁之前会触发componentWillUnmount()函数,实际开发中我们通常进行如下操作,比如清除定时器timer, 取消网络请求或者清除在 componentDidMount() 中创建的订阅等。
进化:React 16生命周期函数
上面节选我们回顾了React 15的生命周期函数,那么React 16有那些更新和改进呢? 其中16.3版本和16.4版本的生命周期稍有不同,首先我们一起来16.3版本的流程图React 16.3 Lifecycle
设计到的生命周期函数如下:
constructor()
getDerivedStateFromProps()
getSnapshotBeforeUpdate()
shouldComponentUpdate()
componentDidUpdate()
componentDidMount()
render()
componentWillUnmount()
Mounting阶段:组件初始化阶段(挂载)
在React 16的mounting阶段涉及到的生命周期函数如下:
constructor()
getDerivedStateFromProps()
componentDidMount()
render()
React 16和React 15相比在初始化阶段,多了一个getDerivedStateFromProps()函数,少了一个componentWillMount()函数。
那getDerivedStateFromProps()是用来替换componentWillMount()函数的吗?
首先我们看一下这个函数
static getDerivedStateFromProps(props, state)
这是一个静态的函数,并且需要返回一个对象用来更新state,如果返回null,则不会更新state。
关于此函数需要了解三个关键重要的点。
第一个这是一个静态函数,所以在这个函数中不能访问class的实例,也就是说不能在函数中使用this通过this.props的获取数据。
第二个此函数接受两个参数props和state,props是指父组件传递的props,state指的是自身的state。
第三个此函数需要一个对象格式的返回值,因为需要根据这个返回的数据来更新state,如果不需要更新state,就返回一个null, 如果什么都不返回,就会收到警告,或者干脆不重新这个函数。
Updating阶段:组件更新阶段
在更新阶段涉及到的函数有一下几个:
getDerivedStateFromProps()
shouldComponentUpdate()
render()
getSnapshotBeforeUpdate()
componentDidUpdate()
在更新阶段,16.3和16.4稍微有些不同,来看一下流程图
对比16.3和16.4的流程图我们发现,变化的部分是getDerivedStateFromProps()的触发时机,主要的变化体现在
如下两个方面:
1.React 16.4版本中getDerivedStateFromProps()在父组件更新接受props,组件自身调用setState()函数以及forceUpdate()函数执行时都会被触发
2.React 16.3在更新阶段只有父组件更新才会触发。
对比React 15,我们发现React 16版本少了componentWillReceiveProps()以及componentWillUpdate(),增加了getDerivedStateFromProps()和getSnapshotBeforeUpdate()。
我们知道React 15中父组件发生更新后会触发componentWillReceiveProps()函数,而自身setState的时候不会触发,而在React 16中组件任何更新都会触发getDerivedStateFromProps()函数,这种改进是为什么呢?
对于getDerivedStateFromProps,React给出的解释是:
可以看出这个新函数不仅仅是componentWillReceiveProps的简单替代,其方法被定义成了static,即在方法内部能不能访问this,那么就能够避免错误的操作,比如使用this.fetch进行网络请求,使用this.setSate进行render造成死循环。
因此getDerivedStateFromProps 的存在只有一个目的:让组件在 props 变化时更新 state。
关于此函数的使用,官方也给出了建议:
接下来看getSnapshotBeforeUpdate,React官方的解释:
getSnapshotBeforeUpdate(prevProps, prevState)
getSnapshotBeforeUpdate() 在最近一次渲染输出(提交到 DOM 节点)之前调用。它使得组件能在发生更改之前从 DOM 中捕获一些信息(例如,滚动位置)。此生命周期的任何返回值将作为参数传递给 componentDidUpdate()。
在这个函数里面可以拿到更新前的真实DOM和更新后的最新props和state.
最后看一下componentDidUpdate函数
componentDidUpdate(prevProps, prevState, snapshot)
如果组件实现了 getSnapshotBeforeUpdate() 生命周期(不常用),则它的返回值将作为 componentDidUpdate() 的第三个参数 “snapshot” 参数传递。否则此参数将为 undefined。
Unmounting阶段:组件卸载
在卸载阶段React 16和React 15一样,没有发生变化,都只涉及一个生命周期函数:
componentWillUnmount()
componentWillUnmount() 中不应调用 setState(),因为该组件将永远不会重新渲染。组件实例卸载后,将永远不会再挂载它。
生命周期进化的原因
React 的生命周期发生变化和改进的原因都是因为React 项目使用成为“Fiber”的核心架构重写了React。
Fiber使原来React 15的同步渲染变成了异步渲染,避免阻塞React 主线程。
在React 16之前,我们使用setState更新组件,React都会生成一个新的虚拟DOM,通过与上一次的DOM进行diff对比后,再定向更新真实的DOM。这是一个同步渲染的递归过程,就如同走楼梯一样。
如果页面的布局复杂嵌套很深,那么递归调用的时间就会很长,那么的主线程就会被js一直占用着,任何交互,布局,渲染都会停止,那给用户呈现的画面就是很卡顿。
而使用Fiber重构之后就解决了这个问题,Fiber将漫长的更新任务进行切片成小任务。执行完一个小任务,就将主线程交换回去,看看是否有优先级更高的任务需要处理,这样就避免了同步更新造成UI阻塞的问题。
使用Fiber进行切片后,异步的渲染任务就变成了可打断的,执行过程就变成了如下的模式:
使用Fiber背后的故事
在React 16以后,如下的几个生命周期函数都被标记为不安全的,
componentWillMount
componentWillReceiveProps
componentWillUpdate
现在这几个生命周期函数前都增加了“UNSAFE_”前缀,变成如下模样:
UNSAFE_componentWillMount、
UNSAFE_componentWillReceiveProps
UNSAFE_componentWillUpdate
因为Fiber重构后,渲染变成了异步的,通过查看新的生命周期图谱,这几个方法都处于原来的render阶段,也就是会出现重复调用的问题,比如说不合理的使用setState造成重复渲染死循环等。
总结
总的来说,React生命周期的进化都是为Fiber架构服务的,Fiber带了异步渲染的机制,使生命周期变的更加纯粹和可控,同时也减少了我们书写代码不规范造成的不必要的bug。