乐趣区

关于css:前端性能优化指南1

jiezi

此文次要形容 html / css / js / react 即时渲染和网络加载优化方面的常识，webpack 罕用优化办法和 HTTP Server 等优化请关注《前端性能优化指南(2)》

如果之后发现有其它要点值得梳理，会持续更新本文 …

目录

  • 目录

  • ➣ HTML/CSS 性能优化方面

    • 1. 网络层面

      • 1）抽离内联款式内联脚本
      • 2）defer 脚本和 async 脚本
      • 3）压缩 HTML/CSS 代码资源
      • 4）压缩图片 / 音视频等多媒体资源
      • 5）应用雪碧图
      • 6）防止空的 src 和 href 值
      • 7）防止应用 @import 来引入 css

    • 2. 渲染层面

      • 1）缩小页面的回流和重绘
      • 2）缩小 DOM 构造的层级
      • 3）尽量不应用 table 布局和 iframe 内联网页
      • 4）CSS 选择器的应用策略
      • 5）flex 布局的性能比 inline-block 和float布局都要好
      • 6）css 的书写程序也会对其解析渲染性能造成影响

  • ➣ Javascript 性能优化方面

    • 1. 网络层面

      • 1）压缩 JS 代码资源

    • 2. 渲染层面

      • 1）应用函数节流和函数去抖解决一些函数的高频触发调用
      • 2）Js 实现动画时应用 requestAnimationFrame 代替定时器
      • 3）应用 IntersectionObserverAPI 来代替scroll 事件实现元素相交检测
      • 4）应用 Web-Workers 在后盾运行 CPU 密集型工作
      • 5）应用事件委托
      • 6）一些编码方面的优化倡议

  • ➣ React 性能优化方面

    • 1. 网络层面

      • 1）React jsx/js 文件压缩
      • 2）应用 React.lazy 和React.Suspense实现代码宰割和懒加载
      • 3）应用 React.Fragment 来防止非必要 DOM 层级的引入

    • 2. 渲染层面

      • 1）应用 shouldComponentUpdate 防止不必要渲染
      • 2）应用 PureComponnet 实现简略展现组件的主动浅比拟
      • 3）应用 React.memo 缓存和复用组件的渲染后果
      • 4）应用 Context 来共享全局数据
      • 5）优化组件宰割策略来解决长列表组件的渲染
      • 6）正确理解组件 key 的应用策略
      • 7）应用虚拟化渲染技术来优化超长列表组件
  • 结语

》思维导图：

     前端性能优化是个很大的概念，波及 HTTP 协定、浏览器渲染原理、操作系统和网络、前端工程化和 Js 底层原理等各个方面。通过建设思维导图能够让咱们很好的将各个优化方面组织和分割起来。
     依照优化原理的不同则能够将其分为 网络层面优化 和渲染层面 的优化，网络层面的优化更多体现在资源加载时的优化，而渲染层的优化更多体现在运行时优化。
     例如优化浏览器缓存策略以缩小 HTTP 申请传输量、图片和其它动态资源的压缩、服务器端启用 Gzip 压缩、应用 CDN、图片懒加载、提早脚本 Defer 和异步脚本 Async 等属于网络层面的优化。另一方面，缩小页面的回流和重绘、应用 React.Fragment 缩小界面 dom 层级、应用骨架屏、函数节流和去抖、React 长列表组件优化、通过事件冒泡机制实现事件委托等就属于渲染层面的优化。

➣ HTML/CSS 性能优化方面

1. 网络层面

1）抽离内联款式内联脚本
  • 内联资源不利于浏览器缓存，造成反复的资源申请
  • 内联资源会造成 HTML 臃肿，不利于 HTTP 传输
  • 内联资源的下载和解析可能会阻塞导致界面渲染，导致界面白屏
  • 内联资源不好治理和保护
2）defer 脚本和 async 脚本

     HTML 在解析时遇到申明的 <script> 脚本会立刻下载和执行，往往会提早界面残余局部的解析，造成界面白屏的状况。比拟古老的优化形式之一就是将脚本放到 HTML 文档开端，这样子解决了白屏的问题，可是在 DOM 文档结构复杂简短时，也会造成肯定的界面脚本下载和执行提早，script 标签新属性 async 和defer能够解决此类问题：

  • defer 脚本

     提早脚本 - 申明 defer 属性的内部 <script> 脚本下载时不会阻塞 HTML 的解析和渲染，并且会在 HTML 渲染实现并且可实际操作之后开始执行 (DOMContentLoaded 事件被触发之前)，各个脚本解析执行程序对应申明时的地位程序，执行实现后会触发页面 DOMContentLoaded 事件。

  • async 脚本

     异步脚本 - 申明 async 属性的内部 <script> 脚本下载时不会阻塞 HTML 的解析和渲染，各个脚本的下载和执行齐全独立，下载实现后即开始执行，所以执行程序不固定，与 DOMContentLoaded 事件的触发没有关联性。

  • 动静脚本加载技术

     在脚本执行时动静运行 loadScript 函数能够实现相似提早脚本和异步脚本的成果：isDefer为真值时脚本的执行程序为脚本地位程序，为假值时成果同于异步脚本。

  function loadScript(src, isDefer) {let script = document.createElement('script');
    script.src = src;
    script.async = !isDefer;
    document.body.append(script);
  }
3）压缩 HTML/CSS 代码资源

     代码资源中存在很多无用的空格和符号等，去除他们带来的效益是可观的，另一方面压缩资源也能起到源代码爱护的作用。古代前端工程化框架个别继承了此类压缩插件，比方 webpack 框架的 uglifyjs 插件。

4）压缩图片 / 音视频等多媒体资源

     其实网页带宽往往被图片等资源大量占用，压缩他们能带来超出预期的优化效益。古代前端工程化框架个别继承了此类压缩插件，如 imagemin-webpack-plugin 插件。

5）应用雪碧图

     应用雪碧图实质上优化了 HTTP 申请的数量，将泛滥图片拼贴为一张作为背景图片援用，而后咱们给一个元素设置固定大小，让它的背景图片地位进行变动，就如同显示出了不同的图片，这就是雪碧图的原理。

6）防止空的 src 和 href 值

     当 link 标签的 href 属性为空、script 标签的 src 属性为空的时候，浏览器渲染的时候会把以后页面的 URL 作为它们的属性值，从而把页面的内容加载进来作为它们的值。

7）防止应用 @import 来引入 css

     这种语法会阻止多个 css 文件的并行下载，被 @import 引入的 css 文件会在引入它的 css 文件下载并渲染好之后才开始下载渲染本身。并且 @import 引入的 css 文件的下载程序会被打乱，排列在 @import 之后的 JS 文件会先于 @import 下载。

2. 渲染层面

1）缩小页面的回流和重绘
  • 应用 CSS3 属性 transform 来实现元素位移
  • 让动画成果利用到 position: fixed/absolute 的元素上，原理是让其脱离文档流
  • 向界面插入大量 dom 节点时先将 dom 元素增加到虚构 dom 操作节点 DocumentFragment 上，最初再将虚构节点理论增加到界面上。
  • 防止间接应用 JS 操作 dom 元素的 style 款式，能够应用 class 一次性扭转 dom 款式类。
  • 将会引起页面回流、重绘的操作尽量放到 DOM 树的前面，缩小级联反馈。
  • 应用 CSS3 动画 Animation 来实现一些简单元素的动画成果，原理是利用了硬件加速

  • 读取一些容易引起回流的元素属性留神应用变量缓存

    <!-- 几何属性相干 -->
elem.offsetLeft, elem.offsetTop, elem.offsetWidth, elem.offsetHeight, elem.offsetParent
elem.clientLeft, elem.clientTop, elem.clientWidth, elem.clientHeight elem.getClientRects(), elem.getBoundingClientRect()
<!-- 滚动相干 -->
elem.scrollBy(), elem.scrollTo()
elem.scrollIntoView(), elem.scrollIntoViewIfNeeded()
elem.scrollWidth, elem.scrollHeight
elem.scrollLeft, elem.scrollTop 除了读取，设置也会触发
...
2）缩小 DOM 构造的层级
3）尽量不应用 table 布局和 iframe 内联网页
/* table 布局 */
table 布局不灵便，不利于 css 款式定制
table 布局渲染性能较低，可能触发多次重绘
table 布局不利于 html 语义化

/* iframe */
iframe 会阻塞主页面的 onload 事件
iframe 和主页面共享 HTTP 连接池，而浏览器对雷同域的连贯有限度，所以会影响页面的并行加载
iframe 不利于网页布局
iframe 对挪动端不敌对
iframe 的重复从新加载可能导致一些浏览器的内存泄露
iframe 中的数据传输简单
iframe 不利于 SEO
4）CSS 选择器的应用策略
浏览器是从选择器的左边到右边读取，选择器最左边的局部被称为要害选择器，与 CSS 选择器规定的效率相干。效率排序如下：内联款式 > ID 选择器 > 类选择器 = 属性选择器 = 伪类选择器 > 标签选择器 = 伪元素选择器

要点：- 要害选择器防止应用通用选择器 *，其查问开销较大
- 应用 ID/Class 选择器时尽量使其独立，因为无用的下层规定 (标签、类名) 只会减少查找时间，ID/Class 曾经具备独自筛选元素的能力
- 防止应用子选择器，尤其是将其与标签、通配符组合应用，性能开销较大
- 利用 CSS 元素属性继承的个性，是多个元素复用多一种规定
- 移除无匹配款式，否则会造成无用的款式解析和匹配，同时增大 CSS 文件体积
5）flex 布局的性能比 inline-block 和float布局都要好
6）css 的书写程序也会对其解析渲染性能造成影响

     浏览器从上到下开始解析一段 css 规定，将容易造成回流、重绘的属性放在上部能够让渲染引擎更高效地工作，能够依照下列程序来进行书写，应用编辑器的 csslint 插件能够辅助实现这一过程：

  • 定位属性

    position  display  float  left  top  right  bottom 
overflow  clear  z-index

  • 几何属性

    width  height  padding  border  margin   background

  • 文字款式

    font-family   font-size   font-style   font-weight   font-varient  color

  • 文本属性

    text-align   vertical-align   text-wrap   text-transform   text-indent    text-decoration   letter-spacing    word-spacing    white-space   text-overflow

  • CSS3 中新增属性

    content   box-shadow   border-radius  transform

➣ Javascript 性能优化方面

1. 网络层面

1）压缩 JS 代码资源

     代码资源中存在很多无用的空格和符号等，去除他们带来的效益是可观的，另一方面压缩资源也能起到源代码爱护的作用。古代前端工程化框架个别继承了此类压缩插件，比方 webpack 框架的 uglifyjs 插件。

2. 渲染层面

1）应用函数节流和函数去抖解决一些函数的高频触发调用

     在面对一些须要进行调用管制的函数高频触发场景时，可能有人会对何时应用节流何时应用去抖产生疑难。这里通过一个个性进行简略辨别：如果你须要保留短时间内高频触发的最初一次后果时，那么应用去抖函数，如果你须要对函数的调用次数进行限度，以最佳的调用间隔时间放弃函数的继续调用而不关怀是否是最初一次调用后果时，请应用节流函数。
     比方 echarts 图经常须要在窗口 resize 之后从新应用数据渲染，然而间接监听 resize 事件可能导致短时间内渲染函数被触发屡次。咱们能够应用函数去抖的思维，监听 resize 事件后在监听器函数里获取参数再应用参数调用当时初始化好了的 throttle 函数，保障 resize 过程完结后能触发一次理论的 echarts 重渲染即可。

  • 节流throttle

    function throttle(fn, time) {
  let canRun = true;

  return function() {if (canRun) {
      canRun = false;
      setTimeout(() => {fn.apply(this, arguments);
        canRun = true;
      }, time);
    }
  };
}

  • 去抖debounce

    function debounce(fn, time) {
  let timer;

  return function() {clearTimeout(timer);
    timer = setTimeout(() => {fn.apply(this, arguments);
    }, time);
  };
}
2）Js 实现动画时应用 requestAnimationFrame 代替定时器

     window.requestAnimationFrame()通知浏览器你心愿执行一个动画，并且要求浏览器在下次重绘之前 (每帧之前) 调用指定的回调函数更新动画。该办法须要传入一个回调函数作为参数，该回调函数会在浏览器下一次重绘之前执行。
     设置的回调函数在被调用时会被传入触发的工夫戳，在同一个帧中的多个回调函数，它们每一个都会承受到一个雷同的工夫戳，即便在计算上一个回调函数的工作负载期间曾经耗费了一些工夫，咱们能够记录前后工夫戳差值来管制元素动画的速度和启停。
     如果换用过定时器 setTimeout/setInterval 来管制帧动画的话，个别咱们采纳 60 帧进行动画绘制，所以设置的定时工夫就应该是 1000 / 60 = 17ms。不过因为定时器自身只是把回调函数放入了 宏工作队列 ，其精确度受到主过程代码执行栈影响，可能导致帧动画的回调函数在浏览器的一次渲染过程中才被触发(现实状况是渲染前调用回调函数取得计算值，渲染时执行计算值绘制)，因而本应在以后帧出现的绘制成果被提早到了下一帧，产生丢帧卡顿的状况。
     这里让咱们应用requestAnimationFrame 来实现一个动画解决类作为例子，应用形式如下：

var anime = new Animation();
anime.setTarget('#animationTarget');
// 右下角挪动 50px
anime.push('#animationTarget', { x: 50, y: 50, duration: 1000, func: 'easeIn'});
// 右上角挪动 50px
anime.push('#animationTarget', { x: -50, y: -50, duration: 500, func: 'linear'});

预览图：

/**
 * [tween 缓动算法]
 * @param {[Number]}  time [动画曾经耗费的工夫]
 * @param {[String]}  start [指标开始的地位]
 * @param {[String]}  distance [指标开始地位和完结地位的间隔]
 * @param {[Number]}  duration [动画总持续时间]
 */
var tween = {linear: function( time, start, distance, duration) {return distance*time/duration + start;},
  easeIn: function(time, start, distance, duration) {return distance * ( time /= duration) * time + start; },
  strongEaseIn: function(time, start, distance, duration) {return distance * ( time /= duration) * time * time * time * time + start; },
  strongEaseOut: function(time, start, distance, duration) {return distance * ( ( time = time / duration - 1) * time * time * time * time + 1 ) + start; },
  sinEaseIn: function(time, start, distance, duration) {return distance * ( time /= duration) * time * time + start; },
  sinEaseOut: function(time,start,distance,duration){return distance * ( ( time = time / duration - 1) * time * time + 1 ) + start; },
};


/* ------------------- 动画管制类 ------------------- */
function Animation() {this.store = {};
};

/* ------------------- 初始化解决元素 ------------------- */
Animation.prototype.setTarget = function (selector) {var element = document.querySelector(selector);

  if (element) {
    // element.style.position = 'relative';
    this.store[selector] = {
      selector: selector,
      element: document.querySelector(selector),
      status: 'pending',
      queue: [],
      timeStart: '',
      positionStart: {x: '', y:''},
      positionEnd: {x: '', y:''},
    };
  }
};

/**
 * [start 开始动画]
 * @param  {[String]} selector [选择器]
 * @param  {[type]} func     [缓动动画]
 */
Animation.prototype.start = function (selector, func) {
  var that = this;
  var target = this.store[selector];
  target.status = 'running';
  // 帧调用函数
  that.update({x: 0, y: 0}, selector);
};

/**
 * [update 更新地位]
 * @param  {[type]} selector [description]
 */
Animation.prototype.update =  function (position, selector) {var target = this.store[selector],
    that = this,
    timeUsed,
    positionX, positionY;
  //
  if (!target || !target.queue.length) {
    target.status = 'pending';
    return;
  };

  // reset position
  target.element.style.left = position.x + 'px';
  target.element.style.top = position.y + 'px';

  // position
  target.positionStart = {x: position.x, y: position.y};
  target.positionEnd = {x: position.x + target.queue[0].x, y: position.y + target.queue[0].y };
  // time
  target.timeStart = null;

  // 递归调用
  var callback = function (time) {if (target.timeStart === null) target.timeStart = time; // 动画开始工夫
    timeUsed = time - target.timeStart;
    // 以后动画实现
    if (timeUsed >= target.queue[0].duration) {target.queue.shift();
      that.step(target.element, target.positionEnd.x, target.positionEnd.y);
      target.status = 'running';
      // var position = target.element.getBoundingClientRect();
      var position = {x: parseInt(target.element.style.left),
        y: parseInt(target.element.style.top),
      };
      // 下一个动画
      that.update(position, selector);
      return;
    }
    positionX = target.queue[0].func(
      timeUsed,
      target.positionStart.x,
      target.positionEnd.x - target.positionStart.x,
      target.queue[0].duration,
    );
    positionY = target.queue[0].func(
      timeUsed,
      target.positionStart.y,
      target.positionEnd.y - target.positionStart.y,
      target.queue[0].duration,
    );
    that.step(target.element, positionX, positionY);

    requestAnimationFrame(callback);
  };

  requestAnimationFrame(callback);
};

/**
 * [step dom 操作]
 * @param  {[DOM]} element [dom 元素]
 * @param  {[Number]} x        [x 坐标]
 * @param  {[Number]} y        [y 坐标]
 */
Animation.prototype.step = function (element, x, y) {
  element.style.left = x + 'px';
  element.style.top = y + 'px';
};

/**
 * [push 退出动画队列]
 * @param  {[String]} selector [dom 选择器]
 * @param  {[Object]} conf     [地位数据]
 */
Animation.prototype.push = function (selector, conf) {if (this.store[selector]) {this.store[selector].queue.push({
      x: conf.x,
      y: conf.y,
      duration: conf.duration || 1000,
      func: tween[conf.func] || tween['linear'],
    });
  }
};

/* ------------------- 动画出队列 ------------------- */
Animation.prototype.pop = function (selector) {if (this.store[selector]) {this.store[selector].queue.pop();}
};

/* ------------------- 清空动画队列 ------------------- */
Animation.prototype.clear = function (selector) {if (this.store[selector]) {this.store[selector].queue.length = 1;
  }
};
3）应用 IntersectionObserverAPI 来代替scroll 事件实现元素相交检测

以下是一些须要用到相交检测的场景：

  • 图片懒加载 — 当图片滚动到可见时才进行加载
  • 内容有限滚动 — 用户滚动到靠近滚动容器底部时间接加载更多数据，而无需用户操作翻页，给用户一种网页能够有限滚动的错觉
  • 检测广告的曝光状况——为了计算广告收益，须要晓得广告元素的曝光状况
  • 在用户看见某个区域时执行工作、播放视频

     以内容有限滚动为例，古老的相交检测计划就是应用 scroll 事件监听滚动容器，在监听器函数中获取滚动元素的几何属性判断元素是否曾经滚动到底部。咱们晓得 scrollTop 等属性的获取和设置都会导致页面回流，并且如果界面须要绑定多个监听函数到 scroll 事件进行相似操作的时候，页面性能会大打折扣：

/* 滚动监听 */
  onScroll = () => {
    const {scrollTop, scrollHeight, clientHeight} = document.querySelector('#target');
    
    /* 曾经滚动到底部 */
    // scrollTop(向上滚动的高度)；clientHeight(容器可视总高度)；scrollHeight(容器的总内容长度)
    if (scrollTop + clientHeight === scrollHeight) {/* do something ... */}
  }

     因而在解决相交检测的问题时咱们应该在思考兼容性的状况下尽可能应用IntersectionObserver API，浏览器会自行优化多个元素的相交治理。IntersectionObserver API 容许你配置一个回调函数，当以下状况产生时会被调用：

  • 每当指标 (target) 元素与设施视窗或者其余指定元素产生交加的时候执行。设施视窗或者其余元素咱们称它为根元素或根(root)。
  • Observer 第一次监听指标元素的时候

     创立一个 IntersectionObserver 对象，并传入相应参数和回调用函数，该回调函数将会在指标 (target) 元素和根 (root) 元素的交加大小超过阈值 (threshold) 规定的大小时候被执行：

let options = {root: document.querySelector('#scrollArea'),
    rootMargin: '0px', // 指定根 (root) 元素的外边距
    threshold: 1.0, // 示意子元素齐全和容器元素相交
}

const observer = new IntersectionObserver(callback, options);
observer.observe(document.querySelector('#scrollTarget'));

     配置项 1： 通常须要关注文档最靠近的可滚动先人元素的交加更改，如果元素不是可滚动元素的后辈，则默认为设施视窗。如果要察看绝对于根 (root) 元素的交加，请指定根 (root) 元素为 null。
     配置项 2： 指标 (target) 元素与根 (root) 元素之间的穿插度是穿插比 (intersection ratio)。这是指标(target) 元素绝对于根 (root) 的交加百分比的示意，它的取值在 0.0 和 1.0 之间。
     配置项 3： 根 (root) 元素的外边距。相似于 CSS 中的 margin 属性，比方 “10px 20px 30px 40px” (top, right, bottom, left)。如果有指定 root 参数，则 rootMargin 也能够应用百分比来取值。该属性值是用作 root 元素和 target 产生交加时候的计算交加的区域范畴，应用该属性能够管制 root 元素每一边的膨胀或者扩张。默认值为 0。
这里咱们再以一个理论案例来进行展现，即图片懒加载计划：

(function lazyload() {var imagesToLoad = document.querySelectorAll('image[data-src]');

  function loadImage(image) {image.src = image.getAttribute('data-src');
    image.addEventListener('load', function() {image.removeAttribute('data-src');
    });
  }

  var intersectionObserver = new IntersectionObserver(function(items, observer) {items.forEach(function(item) {
      /* 所有属性：item.boundingClientRect - 指标元素的几何边界信息
        item.intersectionRatio - 相交比 intersectionRect/boundingClientRect
        item.intersectionRect -  形容根和指标元素的相交区域
        item.isIntersecting - true(相交开始)，false(相交完结)
        item.rootBounds - 形容根元素
        item.target - 指标元素
        item.time - 工夫原点 (网页在窗口加载实现时的工夫点) 到穿插被触发的工夫的工夫戳
      */
      if (item.isIntersecting) {loadImage(item.target);
        observer.unobserve(item.target);
      }
    });
  });

  imagesToLoad.forEach(function(image) {intersectionObserver.observe(image);
  });
  
})();
4）应用 Web-Workers 在后盾运行 CPU 密集型工作

     Web Worker 容许你在后盾线程中运行脚本。如果你有一些高强度的工作，能够将它们调配给 Web Worker，这些 WebWorker 能够在不烦扰用户界面的状况下运行它们。创立后，Web Worker 能够将音讯公布到该代码指定的事件处理程序来与 JavaScript 代码通信，反之亦然。
     一个简略的专用 worker 示例，咱们在主过程代码中创立一个 worker 实例，而后向实例发送一个数字，worker 承受到音讯后拿到数字进行一次 斐波那契函数 运算，并发送运算后果给主线程：

/* -------------- main.js -------------- */
var myWorker = new Worker("fibonacci.js");
worker.onmessage = function (e) {console.log('The result of fibonacci.js:', e.data);
};
worker.postMessage(100);

/* -------------- fibonacci.js -------------- */
function fibonacci(n) {if (n > 1)
    return fibonacci(n - 2) + fibonacci(n - 1);
  return n;
}

self.onmessage = function(e) {self.postMessage(fibonacci(Number(e.data)));
}

  • Worker 的常见类型

    • 专用 Worker： 一个专用 worker 仅仅能被生成它的脚本所应用。
    • 共享 Worker： 一个共享 worker 能够被多个脚本应用——即便这些脚本正在被不同的 window、iframe 或者 worker 拜访。
    • Service Workers： 个别作为 web 应用程序、浏览器和网络（如果可用）之前的代理服务器。它们旨在（除开其余方面）创立无效的离线体验，拦挡网络申请，以及依据网络是否可用采取适合的口头并更新驻留在服务器上的资源。他们还将容许拜访推送告诉和后盾同步 API。
    • Chrome Workers： 一种仅实用于 firefox 的 worker。如果您正在开发附加组件，心愿在扩大程序中应用 worker 且有在你的 worker 中拜访 js-ctypes 的权限，你能够应用 Chrome Workers。
    • Audio Workers： 音频 worker 使得在 web worker 上下文中间接实现脚本化音频解决成为可能。

  • Worker 中能够应用的函数和接口
    你能够在 web worker 中应用大多数的规范 javascript 个性，包含：

    • Navigator
    • Location(只读)
    • XMLHttpRequest
    • Array, Date, Math, and String
    • setTimeout/setInterval
    • Cache & IndexedDB
  • 对于线程平安

     Worker 接口会生成真正的操作系统级别的线程，然而，对于 web worker 来说，与其余线程的通信点会被很小心的管制，这意味着你很难引起并发问题。你没有方法去拜访非线程平安的组件或者是 DOM，此外你还须要通过序列化对象来与线程交互特定的数据。所以你要是不费点劲儿，还真搞不出谬误来。

  • 内容安全策略

     有别于创立它的 document 对象，worker 有它本人的执行上下文。因而广泛来说，worker 并不受限于创立它的 document（或者父级 worker）的内容安全策略。举个例子，假如一个 document 有如下头部申明：Content-Security-Policy: script-src 'self'，这个申明有一部分作用在于禁止脚本代码应用 eval()办法。然而，如果脚本代码创立了一个 worker，在 worker 中却是能够应用 eval()的。
     为了给 worker 指定内容安全策略，必须为发送 worker 代码的申请自身加上一个 内容安全策略。有一个例外情况，即 worker 脚本的应用 dataURL 或者 blob 创立的话，worker 会继承创立它的 document 或者 worker 的内容安全策略。

  • 一些应用场景

    • 在一些不采纳 websockets 架构的利用中应用传统的轮询形式定时获取接口数据以供前端脚本实现一些界面和数据自动更新性能
    • 光线追踪：光线追踪是一种通过将光线追踪为像素来生成图像的渲染技术。光线追踪应用 CPU 密集型数学计算来模仿光线门路。这个想法是模仿反射，折射，材质等一些成果。所有这些计算逻辑都能够增加到 Web Worker 中以防止阻塞 UI 线程。
    • 加密：因为对集体和敏感数据的监管日益严格，端到端加密越来越受欢迎。加密可能是一件十分耗时的事件，特地是如果有很多数据必须常常加密（例如在将数据发送到服务器之前）。这是一个十分好的场景，能够应用 Web Worker。
    • 预取数据：为了优化您的网站或 Web 应用程序并缩短数据加载工夫，您能够利用 Web Workers 事后加载和存储一些数据，以便稍后在须要时应用它。
    • PWA 进式 Web 应用程序：这种应用程序中即便网络连接不稳固，它们也必须疾速加载。这意味着数据必须存储在本地浏览器中，这是 IndexDB 或相似的 API 进场的中央。为了在不阻塞 UI 线程的状况下应用，工作必须在 Web Workers 中实现。
5）应用事件委托

     事件委托就是把一个元素响应事件（click、keydown……）的函数委托到另一个元素。一般来讲，会把一个或者一组元素的事件委托到它的父层或者更外层元素上，真正绑定事件的是外层元素，当事件响应到须要绑定的元素上时，会通过事件冒泡机制从而触发它的外层元素的绑定事件上，而后在外层元素下来执行函数。=> 一篇不错的参考文章

     其实咱们相熟的 React 框架也并不是将 click 事件间接绑定在 dom 下面，而是采纳事件冒泡的模式冒泡到 document 下面，这个思路借鉴了事件委托机制。而更老一点的 jQuery 也是容许咱们间接应用它提供的 API 来进行事件委托：

$('.parent').on('click', 'a', function () {console.log('click event on tag a');
}

》对于事件冒泡机制：

》事件模型的 三个阶段：

  • 捕捉阶段：在事件冒泡的模型中，捕捉阶段不会响应任何事件
  • 指标阶段：指标阶段就是指事件响应到触发事件的最底层元素上
  • 冒泡阶段：冒泡阶段就是事件的触发响应会从最底层指标一层层地向外到最外层（根节点），事件代理即是利用

件冒泡的机制把里层所须要响应的事件绑定到外层

》事件委托的 长处：

  • 缩小内存耗费，晋升性能

咱们不须要再为每个列表元素都绑定一个事件，只须要将事件函数绑定到父级 ul 组件：

<ul id="list">
  <li>item 1</li>
  <li>item 2</li>
  <li>item 3</li>
  ......
  <li>item n</li>
</ul>
  • 动静绑定事件

     比方上述的例子中列表项就几个，咱们给每个列表项都绑定了事件。在很多时候，咱们须要通过 AJAX 或者用户操作动静的减少或者去除列表项元素，那么在每一次扭转的时候都须要从新给新增的元素绑定事件，给行将删去的元素解绑事件。
     如果用了事件委托就没有这种麻烦了，因为事件是绑定在父层的，和指标元素的增减是没有关系的，执行到指标元素是在真正响应执行事件函数的过程中去匹配的。所以应用事件在动静绑定事件的状况下是能够缩小很多反复工作的。

》应用Element.matches API 简略实现事件委托：

if (!Element.prototype.matches) {
  Element.prototype.matches =
    Element.prototype.matchesSelector ||
    Element.prototype.mozMatchesSelector ||
    Element.prototype.msMatchesSelector ||
    Element.prototype.oMatchesSelector ||
    Element.prototype.webkitMatchesSelector ||
    function(s) {var matches = (this.document || this.ownerDocument).querySelectorAll(s),
        i = matches.length;
      while (--i >= 0 && matches.item(i) !== this) {}
      return i > -1;            
    };
}

document.getElementById('list').addEventListener('click', function (e) {
  // 兼容性解决
  var event = e || window.event;
  var target = event.target || event.srcElement;
  if (target.matches('li.class-1')) {console.log('the content is:', target.innerHTML);
  }
});

》事件委托的 局限性：

  • 比方 focus、blur 之类的事件自身没有事件冒泡机制，所以无奈委托。
  • mousemove、mouseout 这样的事件，尽管有事件冒泡，然而只能一直通过地位去计算定位，对性能耗费高，因而也是不适宜于事件委托的。
6）一些编码方面的优化倡议
  • 长列表数据的遍历应用 for 循环代替forEach。

     for 循环能通过关键字 break 实现循环中断，forEach 首先性能不如 for，其次在解决一些须要条件断开的循环时比拟麻烦 (能够包裹 try catch，而后 throw error 断开)。如果是数组类型的数据遍历的话，也能够应用array.every(item => { if (...) return false; else do something; }) 来实现条件断开。

  • 尽量不要在全局作用域申明过多变量

     全局变量存在于全局上下文，全局上下文是作用域链的顶端，当通过作用域链进行变量查找的时候，会缩短查找时间。全局执行上下文会始终存在于上下文执行栈，直到程序推出，这样会影响 GC 垃圾回收。如果部分作用域中定义了同名变量，会遮蔽或者净化全局。
     能够应用单例模式来封装一系列逻辑(使用了闭包的原理)，并通过一个专用的变量名裸露给作用域中的其它模块应用，同时也进步了代码的内聚性：

/* bad */
const workData = {};
function workA() { /* do something ... */}
function workB() { /* do something ... */}
function workC() { /* do something ... */}

/* good */
const work = (function (initParams) {const workData = {};
  function workA() { /* do something ... */}
  function workB() { /* do something ... */}
  function workC() { /* do something ... */}

  return {
    doWorkA: workA,
    doWorkB: workB,
    doWorkC: workC,
    workSeries: function() {this.doWorkB();
      this.doWorkC();}
  };
})(initParams);

work.doWorkA();
work.workSeries();
  • 应用 switch 和map的形式解决须要大量逻辑判断的状况

     间断的 if 判断中在达到指标条件之前须要通过多个条件判断，而 map 和 switch 形式都可能通过条件间接找到对应的解决逻辑。

/* bad */
if (condition === 'a')
  // do something
else if (condition === 'b')
  // do something
else
...

/* good */
switch (condition) {
  case 'a':
    // do something ...
  break;
  case 'b':
    // do something ...
  break;
  ...
  default:
    break;
}

const conditionMap = {a: function() {/* do something */},
  b: function() { /* do something */},
  ...
};
conditionMap[condition]();
  • 定义构造函数时应用原型申明对象的专用办法

     咱们在 new 一个对象时，js 所做的就是创立一个空对象，并把此对象作为构造函数的 context 来执行 (参考 call 调用逻辑)，执行后空对象上就被复制了构造函数的的属性和办法，而后 js 会把构造函数的原型绑定到对象的__proto__ 属性上，最初构造函数将对象返回给咱们应用。
     从以上能够看出，如果咱们间接把一些 function 逻辑写入构造函数的话，在对象创立的时候每个 function 都会在新对象上被创立一次，耗费额定的资源，且违反了程序复用准则。倡议将 function 放入构造函数的原型，那么对象就能通过原型链查找来应用这个办法，而不是在对象本身上从新复制一个截然不同的逻辑。

/* bad */
function Structure(attr) {
  this.attr = attr;
  this.getAttr = (function() {return this.attr;}).bind(this);
}
var obj = new Structure('obj1');
obj.getAttr(); // from obj itself

/* good */
function Structure(attr) {this.attr = attr;}
Structure.prototype.getAttr = function() {return this.attr;}
var obj = new Structure('obj1');
obj.getAttr(); // from obj prototype chain

➣ React 性能优化方面

1. 网络层面

1）React jsx/js 文件压缩
2）应用 React.lazy 和React.Suspense实现代码宰割和懒加载

     React 开发的利用通常会借用 webpack 这类我的项目打包器将编写的各个模块代码和引入的依赖库的代码打包成一个独自的 JS 文件，有些未做 CSS 款式拆散优化的我的项目甚至连样式表都和 JS 文件打包在一起，而后在页面加载的 HTML 文件中须要下载了这一整个 JS 文件后之后能力进去到页面构建阶段。对于中小型我的项目还好，简略的首屏优化就能将资源压缩到足够小，然而一些大型项目可能存在很多子项目，如果不对代码做宰割而后按子项目模块加载的话，在首屏咱们浏览器须要下载整个我的项目的依赖文件，导致加载工夫过长。
     应用 React.lazy 能够宰割子项目代码并依据以后页面路由来动静加载页面依赖文件，只管并没有缩小利用整体的代码体积，但你能够防止加载用户永远不须要的代码，并在初始加载的时候缩小所需加载的代码量。

留神：搭配 Babel 进行代码编译时须要装置额定的 babel 插件以提供动静加载性能：

{"presets": [...],
  "plugins": [
    "dynamic-import-webpack",
    ...
  ]
}

  • React.lazy 函数能让你像渲染惯例组件一样解决动静引入的组件：
    它承受一个函数，这个函数须要动静调用 import()。它必须返回一个 Promise，该 Promise 须要 resolve 一个 defalut export 的 React 组件。

    /* 应用前 */
import OtherComponent from './OtherComponent';
/* 应用后，代码将会在组件首次渲染时，主动导入蕴含 OtherComponent 组件的包 */
const OtherComponent = React.lazy(() => import('./OtherComponent'));

/* -------------- OtherComponent.js -------------- */
export default function() { return (<span>other</span>) };

  • 应用 React.Suspense 提供一个组件加载时的占位组件：

    import React, {Suspense} from 'react';

const OtherComponent = React.lazy(() => import('./OtherComponent'));

function mainComponent() {
  return (<Suspense fallback={<div>Loading...</div>}>
      <section>
        <OtherComponent />
        <AnotherComponent />
      </section>
    </Suspense>
  )
}

  • 应用异样捕捉组件防止模块加载失败时让整个利用解体

    /* -------------- mainComponent.js -------------- */
function MyComponent() {
  return (
    <MyErrorBoundary>
      <Suspense fallback={<div>Loading...</div>}>
        <OtherComponent />
      </Suspense>
    </MyErrorBoundary>
  )
}

/* -------------- ErrorBoundary.js -------------- */
class ErrorBoundary extends React.Component {constructor(props) {super(props);
    this.state = {hasError: false};
  }

  static getDerivedStateFromError(error) {
    // 更新 state 使下一次渲染可能显示降级后的 UI
    return {hasError: true};
  }

  componentDidCatch(error, errorInfo) {logErrorToMyService(error, errorInfo); // 能够抉择将谬误日志上报给服务器
  }

  render() {if (this.state.hasError)
      return <h1>Something went wrong.</h1>; // 你能够自定义降级后的 UI 并渲染
    return this.props.children; // 失常渲染子组件
  }
}

  • 代码宰割搭配 React-Router 同样实用

    import React, {Suspense, lazy} from 'react';
import {BrowserRouter as Router, Route, Switch} from 'react-router-dom';

const Home = lazy(() => import('./routes/Home'));

const App = () => (
  <Router>
    <Suspense fallback={<div>Loading...</div>}>
      <Switch>
        <Route exact path="/" component={Home}/>
      </Switch>
    </Suspense>
  </Router>
);
3）应用 React.Fragment 来防止非必要 DOM 层级的引入

     React 通常要求咱们在编写一个组件时返回单个 container 组件包裹的 DOM 构造，而不容许间接返回多个未包裹的子组件，如果不应用 Fragment 就必须额定增加一层 DOM 节点，比方：

/* bad */
class myComponent extends React.Component {render() {
    return (
      <div>
        <td>1</td>
        <td>2</td>
      </div>
    )
  }
}

额定增加的 div 减少了无用的 DOM 层级，且会造成 table 组件无奈正确渲染 (tr/td 之间多了一层 div)。
应用 Fragment 后最终所有 td 标签都会被间接增加到下层的 tr 标签下，同时也不会产生多余层级：

/* good */
class myComponent extends React.Component {render() {
    return (
      <React.Fragment>
        <td>1</td>
        <td>2</td>
      </React.Fragment>
    )
  }
}

2. 渲染层面

1）应用 shouldComponentUpdate 防止不必要渲染

     当一个 React 组件外部 state 或内部传入 props 更新时，会触发组件的从新渲染，开发者能够在 shouldComponentUpdate 生命周期中通过比照传入的行将被更新的 state 和 props 来决定组件是否要从新渲染，函数默认返回 true，即触发渲染：

class CounterButton extends React.Component {constructor(props) {super(props);
    this.state = {count: 1};
  }

  shouldComponentUpdate(nextProps, nextState) {
    if (
      this.props.color !== nextProps.color ||
      this.state.count !== nextState.count
    ) return true;
    
    return false;
  }

  render() {
    return (
      <button
        color={this.props.color}
        onClick={() => this.setState(state => ({count: state.count + 1}))}>
        Count: {this.state.count}
      </button>
    );
  }
}

     实用状况： 以后组件的 props/state 并没有产生扭转，然而因为其父组件的从新渲染，导致以后组件也被迫进入了从新渲染阶段。这时候为组件增加 shouldComponentUpdate 生命周期函数进行数据比拟就显得尤为重要了，特地是当组件的 DOM 结构复杂、嵌套档次很深，从新渲染的性能耗费低廉的时候。
     滥用状况： 并非所有组件都须要被增加此生命周期用于数据比拟，因为比拟这一过程自身也是须要耗费性能的，如果一个组件的 state/props 原本就会常常更新，那么这个组件久无需应用 scp 进行优化
     深比拟函数： 有时候一个组件所需的数据结构很简单，比方用于展现当前目录层级的资源树组件，其依赖的数据采纳树形构造，树形组件个别采纳递归的渲染形式，组件的渲染更新操作低廉。因而咱们能够思考在这类组件的 scp 生命周期中应用深比拟函数来对更新前后的属性数据进行一次递归比拟，以判断以后资源树组件是否须要进行更新：

/**
 * [deepComparison 深比拟]
 * @param  {[type]} data [any]
 * @return {[type]}      [boolean]
 */
function deepComparison(data1, data2) {const { hasOwnProperty} = Object.prototype;
  const {toString} = Object.prototype;

  // 获取变量类型
  const getType = (d) => {if (d === null) return 'null';
    if (d !== d) return 'nan';
    if (typeof d === 'object') {if (toString.call(d) === '[object Date]') return 'date';
      if (toString.call(d) === '[object RegExp]') return 'regexp';
      return 'object';
    }
    return (typeof d).toLowerCase();};

  // 根本类型比拟
  const is = (d1, d2, type) => {if (type === 'nan') return true;
    if (type === 'date' || type === 'regexp') return d1.toString() === d2.toString();
    return (d1 === d2);
  };

  // 递归比拟
  const compare = (d1, d2) => {var type1 = getType(d1);
    var type2 = getType(d2);
    var index;

    if (type1 !== type2) return false;

    if (type1 === 'object') {var keys1 = Object.keys(d1);
      var keys2 = Object.keys(d2);
      if (keys1.length !== keys2.length) {return false;}
      for (let i = 0; i < keys1.length; i += 1) {index = keys2.indexOf(keys1[i]);
        if ((index === -1) ||
          !compare(d1[keys1[i]], d2[keys2[index]])) {return false;}
      }
      return true;
    }

    return is(d1, d2, type1);
  };

  return compare(data1, data2);
}

     最佳实际： 深比拟函数其实耗费的性能很大，特地是当数据层级很深的时候，函数的递归须要创立和销毁多个执行上下文，可能数据比拟自身所耗费的性能就多于一次渲染了。因而大部分状况下应用 immutable 不可变数据结构 (对象每次更新都返回一个全新的对象，对象的援用发生变化) + shallowEqual 做浅比拟是比拟现实的抉择。

2）应用 PureComponnet 实现简略展现组件的主动浅比拟

     上文提到 scu 生命周期中咱们能够通过自定义 prop/state 比拟函数来来管制组件是否须要从新渲染，最初得出了 immutable 不可变数据 +shallowEqual 是最佳实际。其实 React 曾经给咱们提供了一种自带浅比拟函数的组件类型即React.PureComponnet，它实用于一些数据类型简略的展现组件，当咱们给这些 React 组件传入雷同的 props 和 state 时，render() 函数会渲染雷同的内容，那么在这些状况下应用 React.PureComponent 可进步性能：

class SimpleCounter extends React.PureComponnet {state = { count: 0}

  render(props) {
    return (
      <div
        onClick={() => this.setState({ count: (this.state.count+1) })}
        style={{color: this.props.color}}
      >count:${this.state.count}</div>
    )
  }
}

     实用状况 和 滥用状况 与scp 生命周期大致相同，不过须要额定留神：

  • React.PureComponent 仅作对象的浅层比拟，如果对象中蕴含简单的数据结构，则有可能因为无奈查看深层的差异，产生谬误的比对后果。
  • 咱们能够仅仅在 props 和 state 较为简单时，才应用 React.PureComponent。
  • 另一种解决形式就是在深层数据结构发生变化时调用 forceUpdate() 来确保组件被正确地更新。
  • 当然也能够应用 immutable.js 框架来解决数据结构，能够放慢不可变对象减速嵌套数据的比拟。一种简略的解决形式是在 state 数据须要更新时咱们手动进行对象援用的更新：
class SimpleDisplay extends React.PureComponent {
  state = {list: ['a', 'b']
  }

  insertItem = () => {const { list} = this.state;
    /* bad - 组件不会更新 */
    list.push('c');
    this.setState({list});

    /* good - 从新更新 list 变量的援用 */
    this.setState({list: [...list, 'c'] });
    // or
    this.setState({list: a.concat('c') });

  }

  render() {
    return (<div onClick={this.insertItem}>
      {this.state.list.join('/') }
      </div>
    )
  }
}
3）应用 React.memo 缓存和复用组件的渲染后果

     React.memo()为高阶组组件，如果组件在雷同 props 的状况下渲染雷同的后果(state 的更新仍然会导致从新渲染)，那么你能够通过将其包装在 React.memo 中调用，以此通过记忆组件渲染后果的形式来进步组件的性能体现。这意味着在这种状况下，React 将跳过渲染组件的操作并间接复用最近一次渲染的后果。
     默认状况下其只会对简单对象做浅层比照，如果你想要管制比照过程，那么请将自定义的比拟函数通过第二个参数传入来实现：

function MyComponent(props) {/* 应用 props 渲染 */}
function areEqual(prevProps, nextProps) {
  /*
  如果把 nextProps 与 prevProps 的比拟后果统一则返回 true，否则返回 false，这一点与 shoudComponentUpdate 体现相同，且 areEqual
  中无奈对组件外部 state 进行比拟
  */
}
export default React.memo(MyComponent, areEqual);

》不倡议 应用 React.memo() 的状况：

  • 如果组件常常接管不同的属性 props 对象来更新的话，那么缓存上一次渲染后果这一过程毫无意义，且减少了额定的性能收入。
  • 此办法仅作为性能优化的形式而存在，不要依赖它来“阻止”渲染，因为这会产生 bug。

》倡议 应用 React.memo() 的状况：

  • 一个组件常常会以雷同的 props 更新，比方父组件的其它局部更新导致的以后子组件非必要渲染
  • 经常用于将函数组件转变为具备 memorized 缓存个性的组件，组件外部能够应用useStatehook 进行外部状态治理，对组件的自更新没有影响。
  • 如果一个组件蕴含大量简单的 dom 构造，从新渲染的性能耗费较大的话能够思考应用 React.memo 包裹，防止很多不必要的渲染状况，在 props 不变的状况下让 react 能间接复用上次的渲染后果。
4）应用 Context 来共享全局数据

     Context 设计目标是为了共享那些对于一个组件树而言是“全局”的数据，例如以后认证的用户、主题或首选语言，应用 context, 咱们能够防止通过两头元素来逐级传递 props。举个例子，在上面的代码中，咱们通过一个“theme”属性手动调整一个按钮组件的款式：

/* -------------- context.js -------------- */
const theme = {light: { color: 'black', backgroundColor: 'white'},
  dark: {color: 'white', backgroundColor: 'black'}
}

// 为以后的 theme 创立一个 context（“light”为默认值）。export default const ThemeContext = React.createContext(theme.light);

/* -------------- App.js -------------- */
// Context 能够让咱们毋庸明确地传遍每一个组件，就能将值深刻传递进组件树。const ThemeContext = require('./context.js');
class App extends React.Component {render() {
    // 应用一个 Provider 来将以后的 theme 传递给以下的组件树。// 无论多深，任何组件都能读取这个值。// 在这个例子中，咱们将“dark”作为以后的值传递上来，当 Provider 不指定以后值时
    // createContext 中传入的默认值会失效
    return (
      <ThemeContext.Provider value="dark">
        <Toolbar />
      </ThemeContext.Provider>
    );
  }
}

/* -------------- Toolbar.js -------------- */

// 两头的组件再也不用指明往下传递 theme 了。function Toolbar() {
  return (
    <div>
      <ThemedButton />
    </div>
  );
}

/* -------------- ThemedButton.js -------------- */
const ThemeContext = require('./context.js');
class ThemedButton extends React.Component {
  // 指定 contextType 读取以后的 theme context。// React 会往上找到最近的 theme Provider，而后应用它的值。// 在这个例子中，以后的 theme 值为“dark”。static contextType = ThemeContext;
  render() {return <Button theme={this.context} />;
  }
}

     对于不须要订阅 context 更新来从新渲染界面的状况，下面的代码示例曾经足够应酬，如果想要接管动态变化的 context 值来响应式更新界面，则须要应用Context.ConsumerAPI，它外部包裹一个返回 dom 组件的 function 函数，传递给函数的 value 值等价于组件树上方离这个 context 最近的 Provider 提供的 value 值。如果没有对应的 Provider，value 参数等同于传递给 createContext() 的 默认值：

...
render() {
  return (
    <MyContext.Consumer>
      {value => <span>{value}</span>/* 基于 context 值进行渲染 */ }
    </MyContext.Consumer>
  )
}

留神： Context 次要利用场景在于很多不同层级的组件须要拜访同样一些的数据。请审慎应用，因为这会使得组件的复用性变差。

5）优化组件宰割策略来解决长列表组件的渲染

     有时候咱们须要渲染一些领有很多子组件的的列表组件，比方一个展现当前目录下有哪些文件的 FileList 组件，它蕴含很多子组件 FileListItem，如下。设想咱们在应用 input 组件获取输出值更新 state 得时候，同时也不可避免的触发了同一个 render 函数下FileListItem 组件的从新渲染，即便从父级传入的 files 数组未产生任任何扭转：

class FileList extends Component {
  state = {value: null}

  onChange = (e) => this.setState({value: e.target.value})

  render() {
    return (
      <div>
        <input value={this.state.value} onChange={this.onChange}></input>
        <div>
          {this.props.files.map((file) => {return <FileListItem key={file.name} name={file.name} />;
            })
          }
        </div>
      </div>
    );
  }
}

     这时候咱们就能够思考在设计组件构造时将 files.map()这部分的逻辑齐全抽离到一个残缺的子组件内，否则后面提到的 shouldComponentUpdate、PureComponent、memo 等优化办法都将无奈施展。咱们无奈间接在 FileList 组件内针对 files 数组未扭转的状况下做任何优化，因为 input 组件的每次状态更新都会让 FileList 组件的每一个局部都从新渲染一遍，优化的组件构造如下：

/* -------------- FileList.js -------------- */
class FileList extends Component {state = { value: null}

  onChange = (e) => this.setState({value: e.target.value})

  render() {
    return (
      <>
        <input value={this.state.value} onChange={this.onChange}></input>
        <FileListItemContainer files={this.props.files} />
      </>
    );
  }
}

/* -------------- FileListItemContainer.js -------------- */
export default React.memo(function({ files}) {
  return (
    <div>
      {files.map((file) => {return <FileListItem key={file.name} name={file.name} />;
        });
      }
    </div>
  );
});
6）正确理解组件 key 的应用策略

     要想了解 React 组件 key 的设计理念咱们得先简略理解一下 React 进行 DOM 树 diff 的过程，咱们都晓得 Js 脚本间接操作网页 DOM 元素时会造成重绘和回流等 低效渲染，因而 React 的 DOM 树 diff 过程针对的是更新前后两颗虚构的 DOM 树，虚构 DOM 树并不是实在的 DOM 节点，而是一种形容页面 DOM 元素构造的树形数据结构，每个虚构树节点存储了一个 DOM 元素的属性和款式等信息。React 须要基于这两棵树之间的差异来判断如何有效率的更新 UI 以保障以后 UI 与最新的树放弃同步。为了进步树 diff 的效率，于是 React 在以下两个假如的根底之上提出了一套复杂度为 O(n) 的启发式算法：

  • 两个不同类型的元素会产生出不同的树(比方 img 和 span 被看做齐全不同的两个节点)
  • 开发者能够通过 key 属性来暗示哪些子元素在不同的渲染下能保持稳定

     如果两次渲染同一地位的某个元素的类型扭转，例如从 span 变成了 image，那么不必多说这个组件和其子组件都会先被卸载，同时触发卸载前组件的生命周期componentWillUnmount，而后将新的 DOM 节点渲染增加到页面上，新的组件实例将执行 componentWillMount、componentDidMount 等周期办法，所有跟之前的树所关联的 state 也会被销毁。

     如果两次渲染组件的类型未扭转，React 将更新该组件实例的 props 以跟最新的元素保持一致，并且调用该实例的 componentWillReceiveProps、componentWillUpdate 以及 componentDidUpdate 办法。下一步，React 会调用 render()办法并递归式的比拟其子节点的并收集其产生的差别。设想咱们在子元素列表开端新增元素时：

<ul>
  <li>first</li>
  <li>second</li>
</ul>
/* 插入 third */
<ul>
  <li>first</li>
  <li>second</li>
  <li>third</li>
</ul>

React 会先匹配到两颗虚构 DOM 树对应的 first节点，而后匹配到两棵树的 second 节点，最初发现在 second 之后呈现了一个全新的节点，dom 渲染时就会插入第三个元素 <li>third</li> 到 second 之后，其更新开销会比拟小。

     然而也有一种比拟坏的状况，当咱们将 third 节点插入到列表头时，React 在 diff 过程中发现所有子节点都产生了变动 (整体地位产生了绝对扭转)，React 不会意识到应该保留first 和second，而是会重建每一个子元素，这种状况会带来性能问题：

<ul>
  <li>first</li>
  <li>second</li>
</ul>
/* 插入 third */
<ul>
  <li>third</li>
  <li>first</li>
  <li>second</li>
</ul>

     为了解决以上问题，React 反对 key 属性。当子元素领有 key 时，React 应用 key 来匹配原有树上的子元素以及最新树上的子元素，相当于每个子节点都有了 ID，因而可能熟能生巧的判断哪些节点须要重建，而哪些节点只须要进行简略的地位挪动即可。比方上个例子中 React 依据组件的 Key 就能辨认咱们只须要新建 third 节点并将它插入到 first 节点之前就能满足要求，而不须要将列表元素都重建一遍。

》对组件 key 的 误会 和 乱用：

  • 页面中的所有组件 key 都不能反复 => 错！咱们只须要保障同一列表层级的组件 key 不反复即可，当有反复 key 时可能会导致 React 在屡次渲染时后果错乱。
  • 应用 Math.random() 函数来随机产生 key 值 => 大错特错！这样子做了之后，每次渲染 key 值都会变动，会引起所有应用了 key 的组件都会被卸载重建一次，性能优化成果为负。
  • key 值只能用于列表组件 => 错！咱们能够给任意一个组件增加 key 值，比方咱们想让某个组件在 props/state 齐全没扭转的状况下触发其重建更新，那么就能够给予它两个阶段不同的 key 值。一个例子是用于重置 Antd Form 表单状态，让其在某些非凡状况下以之前的默认值从新挂载(触发表单更改后其默认值无奈复原)。
7）应用虚拟化渲染技术来优化超长列表组件

     有时候我的项目中要求咱们在不应用分页的状况下渲染一个超长的列表组件，比方一个文件上传列表外面的每个文件上传工作，咱们同时增加成千上万个上传工作，而后并行上传几个，操作者同时也能通过列表的高低滚动来查看每个上传工作的状态。这种变态数量级的界面元素展现 + 本就不简略的上传流程管制，必然导致咱们的界面会有肯定水平的卡顿。
     一个解决方案就是能够采纳懒加载技术来实现当滚动到工作列表底部时加载其余的一小部分工作列表元素，这样尽管解决了首次渲染时消耗工夫过长的问题，不过随着滚动到底部加载的工作条目越来越多，界面的渲染负载也会越来越大。这种状况下采纳虚拟化滚动技术来进行优化就显得很有必要了。
     虚构列表是一种依据滚动容器元素的可视区域高度来渲染长列表数据中某一个局部数据的技术。这里须要简略理解一下其原理，如果要间接应用的话能够思考这两个热门的虚构滚动库 react-window 和 react-virtualized。

》首先分明虚拟化滚动技术中的几个 要害元素：

  • i. 滚动容器元素：个别状况下，滚动容器元素是 window 对象。然而，咱们能够通过布局的形式，在某个页面中任意指定一个或者多个滚动容器元素。只有某个元素能在外部产生横向或者纵向的滚动，那这个元素就是滚动容器元素。
  • ii. 可滚动区域：滚动容器元素的外部内容区域。假如有 100 条数据，每个列表项的高度是 50，那么可滚动的区域的高度就是 100 * 50。可滚动区域以后的具体高度值个别能够通过 (滚动容器) 元素的 scrollHeight 属性获取。用户能够通过滚动来扭转列表在可视区域的显示局部。
  • iii. 可视区域：滚动容器元素的视觉可见区域。如果容器元素是 window 对象，可视区域就是浏览器的视口大小(即视觉视口)；如果容器元素是某个 div 元素，其高度是 300，右侧有纵向滚动条能够滚动，那么视觉可见的区域就是可视区域。

》如何在只渲染大量可视元素的状况下，还能让滚动条的长度和地位显示正确呢：

  • i. 首先明确滚动容器内容的总高度 =列表元素高度 * 列表元素总个数，容器可视高度固定，通过设置 css overflow: scroll 就能显示滚动条。
  • ii. 滚动容器的可视高度固定，那么可视区域能显示的列表元素个数 =容器可视高度 / 列表元素高度 ，这些大量的元素不足以撑起容器元素的进行滚动，滚动容器滚动条高度依然会为 0。因而咱们通过设置容器元素paddingTop+paddingBottom(startOffset+endOffset) 来让容器元素内容总高度正确显示，这里padding+ 可视高度 = 容器内容总高度。
...
render() {
  return (
    <div
      style={{paddingTop: `${startOffset}px`,
        paddingBottom: `${endOffset}px`
      }}
      className='wrapper'
    >
      {/* render list */}
    </div>
  )
}

  • iii. 容器能正确显示滚动高度了，那么如何让咱们在滚动的时候能晓得应该显示哪些元素呢？一个奇妙的办法就是依据以后滚动条的 scrollTop(滚动容器的固有属性：示意可能向上滚动的高度值，能够间接获取) 计算首个应该渲染的元素的索引 startIndex 以及最初须要渲染的元素的索引endIndex，而后再依据两个索引别离计算 paddingTop 和 paddingBottom 即可：

    • startIndex = Math.ceil(scrollTop / 滚动元素高度)
    • 可视元素个数 = 可视区域高度 / 滚动元素高度
    • endIndex = startIndex + 可视区域元素个数
    • 以后渲染元素 renderItems = data.slice(startIndex, endIndex)
    • paddingTop = startIndex * 滚动元素高度
    • paddingBottom = (this.data.length – this.endIndex) * 滚动元素高度

     以上为虚拟化滚动简化的形容模型，理论实现时还要思考：缓存曾经加载的列表元素的地位信息、列表元素的高度是否可变、减少缓冲元素来缩小白屏状况(缓冲元素就是预加载的几个靠近视口可显示元素的高低局部其它元素)、容器元素 resize 后的解决等。解决状况还是比较复杂，应用成熟的库解决而不是本人造轮子是比拟好的计划，不过个中原理还是要了解。

结语

     学习前端性能优化的方方面面，一方面是对咱们外围基础知识的考查，另一方面也能为咱们遇到的一些理论问题提供解决思路，是每个前端人进阶的的必经之路。

以上就是本篇文章的所有内容，后续有须要还会持续更新 …

退出移动版