生命周期共有那几个阶段_一文搞懂ReactNative生命周期的进化

前言
React 15生命周期函数
- Mounting阶段：组件初始化渲染
- Updating阶段：组件更新
- Unmounting阶段：组件卸载

进化：React 16生命周期函数
- Mounting阶段：组件初始化阶段(挂载)
- Updating阶段：组件更新阶段
- Unmounting阶段：组件卸载

生命周期进化的原因
使用Fiber背后的故事
总结

前言

众所周知每个应用的开发框架都有其对应的生命周期函数，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进行对比，看是否改变。

请注意，如果父组件导致组件重新渲染，即使 props 没有更改，也会调用此方法(componentWillReceiveProps)。如果只想处理更改，请确保进行当前值与变更值的比较。 ------ React官方文档

关键点：也就是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给出的解释是：

与 componentDidUpdate 一起，这个新的生命周期涵盖过时componentWillReceiveProps 的所有用例。

可以看出这个新函数不仅仅是componentWillReceiveProps的简单替代，其方法被定义成了static，即在方法内部能不能访问this,那么就能够避免错误的操作，比如使用this.fetch进行网络请求，使用this.setSate进行render造成死循环。因此getDerivedStateFromProps 的存在只有一个目的：让组件在 props 变化时更新 state。关于此函数的使用，官方也给出了建议：

注意：旧的 componentWillReceiveProps 和新的 getDerivedStateFromProps 方法都会给组件增加明显的复杂性。这通常会导致 bug。考虑 派生 state 的简单替代方法 使组件可预测且可维护。

接下来看getSnapshotBeforeUpdate，React官方的解释：

与 componentDidUpdate 一起，这个新的生命周期涵盖过时的 componentWillUpdate 的所有用例。

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。

觉得文章不错的，给我点个赞哇，关注一下呗！技术交流可关注公众号【君伟说】，可留言加我好友一起探讨！