一文搞懂 ReactNative 生命周期的进化

用户头像
凌宇之蓝
关注
发布于: 2020 年 10 月 23 日
一文搞懂ReactNative生命周期的进化

前言

众所周知每个应用的开发框架都有其对应的生命周期函数,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。

发布于: 2020 年 10 月 23 日 阅读数: 709
用户头像

凌宇之蓝

关注

代码改变世界 2018.04.24 加入

【君伟说】公众号作者,移动技术开发工作者。

评论

发布
暂无评论
一文搞懂ReactNative生命周期的进化