接下来两节某些地方可能会稍微有一点点抽象,但是我会尽可能用简单的方式进行讲解。如果你觉得理解起来有点困难,可以把这几节多读多理解几遍,其实我们一路走来都是符合“逻辑”的,都是发现问题、思考问题、优化代码的过程。所以最好能够用心留意、思考我们每一个提出来的问题。

细心的朋友可以发现,其实我们之前的例子当中是有比较严重的性能问题的。我们在每个渲染函数的开头打一些 Log 看看:

  1. function renderApp (appState) {
  2. console.log('render app...')
  3. renderTitle(appState.title)
  4. renderContent(appState.content)
  5. }
  6.  
  7. function renderTitle (title) {
  8. console.log('render title...')
  9. const titleDOM = document.getElementById('title')
  10. titleDOM.innerHTML = title.text
  11. titleDOM.style.color = title.color
  12. }
  13.  
  14. function renderContent (content) {
  15. console.log('render content...')
  16. const contentDOM = document.getElementById('content')
  17. contentDOM.innerHTML = content.text
  18. contentDOM.style.color = content.color
  19. }

依旧执行一次初始化渲染,和两次更新,这里代码保持不变:

  1. const store = createStore(appState, stateChanger)
  2. store.subscribe(() => renderApp(store.getState())) // 监听数据变化
  3.  
  4. renderApp(store.getState()) // 首次渲染页面
  5. store.dispatch({ type: 'UPDATE_TITLE_TEXT', text: '《React.js 小书》' }) // 修改标题文本
  6. store.dispatch({ type: 'UPDATE_TITLE_COLOR', color: 'blue' }) // 修改标题颜色

可以在控制台看到:

前三个毫无疑问是第一次渲染打印出来的。中间三个是第一次 store.dispatch 导致的,最后三个是第二次 store.dispatch 导致的。可以看到问题就是,每当更新数据就重新渲染整个 App,但其实我们两次更新都没有动到 appState 里面的 content字段的对象,而动的是 title 字段。其实并不需要重新 renderContent,它是一个多余的更新操作,现在我们需要优化它。

这里提出的解决方案是,在每个渲染函数执行渲染操作之前先做个判断,判断传入的新数据和旧的数据是不是相同,相同的话就不渲染了。

  1. function renderApp (newAppState, oldAppState = {}) { // 防止 oldAppState 没有传入,所以加了默认参数 oldAppState = {}
  2. if (newAppState === oldAppState) return // 数据没有变化就不渲染了
  3. console.log('render app...')
  4. renderTitle(newAppState.title, oldAppState.title)
  5. renderContent(newAppState.content, oldAppState.content)
  6. }
  7.  
  8. function renderTitle (newTitle, oldTitle = {}) {
  9. if (newTitle === oldTitle) return // 数据没有变化就不渲染了
  10. console.log('render title...')
  11. const titleDOM = document.getElementById('title')
  12. titleDOM.innerHTML = newTitle.text
  13. titleDOM.style.color = newTitle.color
  14. }
  15.  
  16. function renderContent (newContent, oldContent = {}) {
  17. if (newContent === oldContent) return // 数据没有变化就不渲染了
  18. console.log('render content...')
  19. const contentDOM = document.getElementById('content')
  20. contentDOM.innerHTML = newContent.text
  21. contentDOM.style.color = newContent.color
  22. }

然后我们用一个 oldState 变量保存旧的应用状态,在需要重新渲染的时候把新旧数据传进入去:

  1. const store = createStore(appState, stateChanger)
  2. let oldState = store.getState() // 缓存旧的 state
  3. store.subscribe(() => {
  4. const newState = store.getState() // 数据可能变化,获取新的 state
  5. renderApp(newState, oldState) // 把新旧的 state 传进去渲染
  6. oldState = newState // 渲染完以后,新的 newState 变成了旧的 oldState,等待下一次数据变化重新渲染
  7. })
  8. ...

希望到这里没有把大家忽悠到,上面的代码根本不会达到我们的效果。看看我们的 stateChanger

  1. function stateChanger (state, action) {
  2. switch (action.type) {
  3. case 'UPDATE_TITLE_TEXT':
  4. state.title.text = action.text
  5. break
  6. case 'UPDATE_TITLE_COLOR':
  7. state.title.color = action.color
  8. break
  9. default:
  10. break
  11. }
  12. }

即使你修改了 state.title.text,但是 state 还是原来那个 statestate.title还是原来的 state.title,这些引用指向的还是原来的对象,只是对象内的内容发生了改变。所以即使你在每个渲染函数开头加了那个判断又什么用?这就像是下面的代码那样自欺欺人:

  1. let appState = {
  2. title: {
  3. text: 'React.js 小书',
  4. color: 'red',
  5. },
  6. content: {
  7. text: 'React.js 小书内容',
  8. color: 'blue'
  9. }
  10. }
  11. const oldState = appState
  12. appState.title.text = '《React.js 小书》'
  13. oldState !== appState // false,其实两个引用指向的是同一个对象,我们却希望它们不同。

但是,我们接下来就要让这种事情变成可能。

共享结构的对象

希望大家都知道这种 ES6 的语法:

  1. const obj = { a: 1, b: 2}
  2. const obj2 = { ...obj } // => { a: 1, b: 2 }

const obj2 = { ...obj } 其实就是新建一个对象 obj2,然后把 obj 所有的属性都复制到 obj2 里面,相当于对象的浅复制。上面的 obj 里面的内容和 obj2 是完全一样的,但是却是两个不同的对象。除了浅复制对象,还可以覆盖、拓展对象属性:

  1. const obj = { a: 1, b: 2}
  2. const obj2 = { ...obj, b: 3, c: 4} // => { a: 1, b: 3, c: 4 },覆盖了 b,新增了 c

我们可以把这种特性应用在 state 的更新上,我们禁止直接修改原来的对象,一旦你要修改某些东西,你就得把修改路径上的所有对象复制一遍,例如,我们不写下面的修改代码:

  1. appState.title.text = '《React.js 小书》'

取而代之的是,我们新建一个 appState,新建 appState.title,新建 appState.title.text

  1. let newAppState = { // 新建一个 newAppState
  2. ...appState, // 复制 appState 里面的内容
  3. title: { // 用一个新的对象覆盖原来的 title 属性
  4. ...appState.title, // 复制原来 title 对象里面的内容
  5. text: '《React.js 小书》' // 覆盖 text 属性
  6. }
  7. }

如果我们用一个树状的结构来表示对象结构的话:

appState 和 newAppState 其实是两个不同的对象,因为对象浅复制的缘故,其实它们里面的属性 content 指向的是同一个对象;但是因为 title 被一个新的对象覆盖了,所以它们的 title 属性指向的对象是不同的。同样地,修改 appState.title.color

  1. let newAppState1 = { // 新建一个 newAppState1
  2. ...newAppState, // 复制 newAppState1 里面的内容
  3. title: { // 用一个新的对象覆盖原来的 title 属性
  4. ...newAppState.title, // 复制原来 title 对象里面的内容
  5. color: "blue" // 覆盖 color 属性
  6. }
  7. }

我们每次修改某些数据的时候,都不会碰原来的数据,而是把需要修改数据路径上的对象都 copy 一个出来。这样有什么好处?看看我们的目的达到了:

  1. appState !== newAppState // true,两个对象引用不同,数据变化了,重新渲染
  2. appState.title !== newAppState.title // true,两个对象引用不同,数据变化了,重新渲染
  3. appState.content !== appState.content // false,两个对象引用相同,数据没有变化,不需要重新渲染

修改数据的时候就把修改路径都复制一遍,但是保持其他内容不变,最后的所有对象具有某些不变共享的结构(例如上面三个对象都共享 content 对象)。大多数情况下我们可以保持 50% 以上的内容具有共享结构,这种操作具有非常优良的特性,我们可以用它来优化上面的渲染性能。

优化性能

我们修改 stateChanger,让它修改数据的时候,并不会直接修改原来的数据 state,而是产生上述的共享结构的对象:

  1. function stateChanger (state, action) {
  2. switch (action.type) {
  3. case 'UPDATE_TITLE_TEXT':
  4. return { // 构建新的对象并且返回
  5. ...state,
  6. title: {
  7. ...state.title,
  8. text: action.text
  9. }
  10. }
  11. case 'UPDATE_TITLE_COLOR':
  12. return { // 构建新的对象并且返回
  13. ...state,
  14. title: {
  15. ...state.title,
  16. color: action.color
  17. }
  18. }
  19. default:
  20. return state // 没有修改,返回原来的对象
  21. }
  22. }

代码稍微比原来长了一点,但是是值得的。每次需要修改的时候都会产生新的对象,并且返回。而如果没有修改(在 default 语句中)则返回原来的 state 对象。

因为 stateChanger 不会修改原来对象了,而是返回对象,所以我们需要修改一下 createStore。让它用每次 stateChanger(state, action) 的调用结果覆盖原来的 state

  1. function createStore (state, stateChanger) {
  2. const listeners = []
  3. const subscribe = (listener) => listeners.push(listener)
  4. const getState = () => state
  5. const dispatch = (action) => {
  6. state = stateChanger(state, action) // 覆盖原对象
  7. listeners.forEach((listener) => listener())
  8. }
  9. return { getState, dispatch, subscribe }
  10. }

保持上面的渲染函数开头的对象判断不变,再看看控制台:

前三个是首次渲染。后面的 store.dispatch 导致的重新渲染都没有关于 content 的 Log 了。因为产生共享结构的对象,新旧对象的 content 引用指向的对象是一样的,所以触发了 renderContent 函数开头的:

  1. ...
  2. if (newContent === oldContent) return
  3. ...

我们成功地把不必要的页面渲染优化掉了,问题解决。另外,并不需要担心每次修改都新建共享结构对象会有性能、内存问题,因为构建对象的成本非常低,而且我们最多保存两个对象引用(oldState 和 newState),其余旧的对象都会被垃圾回收掉。

本节完整代码:

  1. function createStore (state, stateChanger) {
  2. const listeners = []
  3. const subscribe = (listener) => listeners.push(listener)
  4. const getState = () => state
  5. const dispatch = (action) => {
  6. state = stateChanger(state, action) // 覆盖原对象
  7. listeners.forEach((listener) => listener())
  8. }
  9. return { getState, dispatch, subscribe }
  10. }
  11.  
  12. function renderApp (newAppState, oldAppState = {}) { // 防止 oldAppState 没有传入,所以加了默认参数 oldAppState = {}
  13. if (newAppState === oldAppState) return // 数据没有变化就不渲染了
  14. console.log('render app...')
  15. renderTitle(newAppState.title, oldAppState.title)
  16. renderContent(newAppState.content, oldAppState.content)
  17. }
  18.  
  19. function renderTitle (newTitle, oldTitle = {}) {
  20. if (newTitle === oldTitle) return // 数据没有变化就不渲染了
  21. console.log('render title...')
  22. const titleDOM = document.getElementById('title')
  23. titleDOM.innerHTML = newTitle.text
  24. titleDOM.style.color = newTitle.color
  25. }
  26.  
  27. function renderContent (newContent, oldContent = {}) {
  28. if (newContent === oldContent) return // 数据没有变化就不渲染了
  29. console.log('render content...')
  30. const contentDOM = document.getElementById('content')
  31. contentDOM.innerHTML = newContent.text
  32. contentDOM.style.color = newContent.color
  33. }
  34.  
  35. let appState = {
  36. title: {
  37. text: 'React.js 小书',
  38. color: 'red',
  39. },
  40. content: {
  41. text: 'React.js 小书内容',
  42. color: 'blue'
  43. }
  44. }
  45.  
  46. function stateChanger (state, action) {
  47. switch (action.type) {
  48. case 'UPDATE_TITLE_TEXT':
  49. return { // 构建新的对象并且返回
  50. ...state,
  51. title: {
  52. ...state.title,
  53. text: action.text
  54. }
  55. }
  56. case 'UPDATE_TITLE_COLOR':
  57. return { // 构建新的对象并且返回
  58. ...state,
  59. title: {
  60. ...state.title,
  61. color: action.color
  62. }
  63. }
  64. default:
  65. return state // 没有修改,返回原来的对象
  66. }
  67. }
  68.  
  69. const store = createStore(appState, stateChanger)
  70. let oldState = store.getState() // 缓存旧的 state
  71. store.subscribe(() => {
  72. const newState = store.getState() // 数据可能变化,获取新的 state
  73. renderApp(newState, oldState) // 把新旧的 state 传进去渲染
  74. oldState = newState // 渲染完以后,新的 newState 变成了旧的 oldState,等待下一次数据变化重新渲染
  75. })
  76.  
  77. renderApp(store.getState()) // 首次渲染页面
  78. store.dispatch({ type: 'UPDATE_TITLE_TEXT', text: '《React.js 小书》' }) // 修改标题文本
  79. store.dispatch({ type: 'UPDATE_TITLE_COLOR', color: 'blue' }) // 修改标题颜色

下一节:动手实现 Redux(五):不要问为什么的 reducer

上一节:动手实现 Redux(三):纯函数(Pure Function)简介

动手实现 Redux(四):共享结构的对象提高性能的更多相关文章

  1. 动手实现 Redux(五):不要问为什么的 reducer

    经过了这么多节的优化,我们有了一个很通用的 createStore: function createStore (state, stateChanger) { const listeners = [] ...

  2. 动手实现 Redux(三):纯函数(Pure Function)简介

    我们接下来会继续优化我们的 createStore 的模式,让它使我们的应用程序获得更好的性能. 但在开始之前,我们先用一节的课程来介绍一下一个函数式编程里面非常重要的概念 —— 纯函数(Pure F ...

  3. 动手实现 Redux(六):Redux 总结

    不知不觉地,到这里大家不仅仅已经掌握了 Redux,而且还自己动手写了一个 Redux.我们从一个非常原始的代码开始,不停地在发现问题.解决问题.优化代码的过程中进行推演,最后把 Redux 模式自己 ...

  4. 动手实现 Redux(一):优雅地修改共享状态

    从这节起我们开始学习 Redux,一种新型的前端“架构模式”.经常和 React.js 一并提出,你要用 React.js 基本都要伴随着 Redux 和 React.js 结合的库 React-re ...

  5. Linux进程间通信(四) - 共享内存

    共享内存的优势 采用共享内存通信的一个显而易见的好处是效率高,因为进程可以直接读写内存,而不需要任何数据的拷贝.对于像管道和消息队列等通信方式,则需要在内核和用户空间进行四次的数据拷贝,而共享内存则只 ...

  6. 动手实现 Redux(二):抽离 store 和监控数据变化

    上一节 的我们有了 appState 和 dispatch: let appState = { title: { text: 'React.js 小书', color: 'red', }, conte ...

  7. jvm内存结构及对象漫谈(较全)

    最近想整理一下GC相关的知识和经验,在整理之前先整理一下jvm的内存结构,后续会持续更新. jvm内存结构重要由两部分组成:线程共享区域与线程私有区域,如下图所示: 其中方法区和堆为线程共享区域,栈与 ...

  8. C++结构体对象数组的二进制方式读写

    以一个学生信息的结构体数组为例. #include<iostream>#include<string>#include<fstream>using namespac ...

  9. SQL Server 2008空间数据应用系列四:基础空间对象与函数应用

    原文:SQL Server 2008空间数据应用系列四:基础空间对象与函数应用 友情提示,您阅读本篇博文的先决条件如下: 1.本文示例基于Microsoft SQL Server 2008 R2调测. ...

随机推荐

  1. ABAP range 用法

    转自http://www.sapjx.com/abap-range-table.html 1. Range Table 概述 Range Table 为 SAP R/3系统标准内表的一种,结构与 Se ...

  2. iOS中区分照片的来源

    原理就是通过枚举出每个assets group,然后取得group property,group property是个整数,对应头文件中的一些枚举值.用这个可以判断照片是从哪来的(相机胶卷.照片流.相 ...

  3. YTU 2391: 求素数

    2391: 求素数 时间限制: 1 Sec  内存限制: 128 MB 提交: 116  解决: 3 题目描述 设计一个程序,输出所有小于等于n(n为一个大于2的正整数)的素数. 要求:(1)每行输出 ...

  4. poj 1325 Machine Schedule 解题报告

    题目链接:http://poj.org/problem?id=1325 题目意思:有 k 个作业,机器A有 n 个模式:0 ~ n-1,机器B 有 m 个模式:0~ m-1.每一个作业能运行在 A 的 ...

  5. codeforces 445B. DZY Loves Chemistry 解题报告

    题目链接:http://codeforces.com/problemset/problem/445/B 题目意思:给出 n 种chemicals,当中有 m 对可以发生反应.我们用danger来评估这 ...

  6. 一步一步学Silverlight 2系列(27):使用Brush进行填充

    概述 Silverlight 2 Beta 1版本发布了,无论从Runtime还是Tools都给我们带来了很多的惊喜,如支持框架语言Visual Basic, Visual C#, IronRuby, ...

  7. hiho Mission Impossible 6(模拟 未提交验证。。)

    题意:模拟文本操作 思路:模拟 #include<iostream> #include<stdio.h> #include<string.h> using name ...

  8. centos安装xen虚拟机并且配置bridge

    主要参考的几个官方文档: http://wiki.centos.org/HowTos/Xen/Xen4QuickStart 在centos上安装xen组件并建立dom0 http://wiki.cen ...

  9. 一些好用的Linux命令组合

    1.删除0字节文件 代码如下: find -type f -size 0 -exec rm -rf {} \; 2.查看进程按内存从大到小排列 代码如下: ps -e -o "%C : %p ...

  10. linux中用无名管道进行文件的读写

    1管道是什么: 水管子大家知道,有两端,在此一端用来读一端用来写,其中一端的输出作为另外一端的输入. 2 函数原型 int pipe(int pipefd[2]);//参数中分别代表的两端 3 例子: ...