call，apply 及 bind 函数的内部实现是什么样的 ? 你能手写模拟实现吗 ?

区别

call，apply，bind都可以改变函数的执行上下文，也就是函数运行时 this 的指向。

区别在于，call 和 apply 改变了函数的执行上下文后会执行该函数，而 bind 不会执行该函数而是返回一个新函数。在参数的处理上，call 和 apply 的第一个参数都是函数运行时的 this 值，区别在于，call 方法接受的是参数列表，apply 接受的是一个参数数组或类数组对象。

call

call 接受一个函数运行时的 this 值和一个参数列表，如果不指定第一个参数时，默认执行上下文为 window，改变 this 指向后，需要让新对象可以执行该函数，并能接受参数：

Function.prototype.call = function(context = window) {
  if (typeof this !== 'function') {
    throw new TypeError('Error')
  }
  context.fn = this  // 给context创建一个临时的fn属性，将值设置为需要调用的函数
  const args = [...arguments].slice(1) // call接受的是一个参数列表，第一个参数是函数执行时的this指向，去掉第一个参数，后面的就是我们需要传递给函数调用的参数
  const result = context.fn(...args)
  delete context.fn // 删除临时属性
  return result
}

apply

apply 接受一个函数运行时的 this 值和一个参数数组或类数组对象，与 call 的区别在于对参数处理不同：

Function.prototype.apply = function(context = window) {
  if (typeof this !== 'function') {
    throw new TypeError('Error')
  }
  context.fn = this
  let result
  if (arguments[1]) {
    result = context.fn(...arguments[1])
  } else {
    result = context.fn()
  }
  delete context.fn
  return result
}

bind

bind 接受一个函数运行时的 this 值和一个参数列表，返回一个新函数：

Function.prototype.bind = function (context) {
  if (typeof this !== 'function') {
    throw new TypeError('Error')
  }
  const _this = this
  const args = [...arguments].slice(1)  // 与call处理方式相同，首先剥离得到bind的调用参数
  return function F() {
    const distArgs = args.concat(...arguments)   // 注意这里的arguments指的是bind返回的新函数的arguments，因为bind可以以 bind(this, ...args)(...args) 的方式调用，也就是说，在bind的时候可以传递参数，返回的新函数也可以传递参数，所以我们需要把两次参数组合起来
    if (this instanceof F) {  // 如果返回的函数以new F()的方式调用，因为new不会被任何方式改变this指向，所以我们需要忽略传入的 this 
      return new _this(...distArgs)
    }
    return _this.apply(context, distArgs)
  }
}

勘误与提问

如果有疑问或者发现错误，可以在相应的 issues 进行提问或勘误

如果喜欢或者有所启发，欢迎 star，对作者也是一种鼓励

（完）

理解 JavaScript 的执行机制需要先了解下面几个概念。

• JavaScript是单线程的
• 执行栈
• 同步任务与异步任务
• 事件循环

JavaScript是单线程的

单线程是 JavaScript 这门语言的一大特点，未来也不会改变。在 JavaScript 中，所有的 “多线程” 都是通过单线程模拟出来的，所以尽管 HTML5 实现了 Web Worker，但是 JavaScript 仍然是单线程的。

执行栈

执行栈本质就是一个栈，只是它存放的是任务。

同步任务与异步任务

单线程就意味着所有的任务都需要排队执行，因为主线程只有一个。任务被划分为同步任务和异步任务。你肯定有疑问，为什么任务会被划分为 “同步任务” 和 “异步任务” ？

原因其实很简单，因为如果有一个任务耗时过长，后面的所有任务都需要等待，但是像加载图片音乐，网络请求之类的占用资源大耗时也长的任务，进入主线程后，就会阻塞后面的任务。

而当我们打开一个网站时，可能更希望看到页面更快地渲染出来而不是一直卡着直到图片完全加载完成，所以任务应该有优先级，于是聪明的程序员便将任务分为两类：同步任务和异步任务。

事件循环

UDP 的全称叫 用户数据报协议（ User Datagram Protocol ），是传输层的一个无连接协议。

我们知道 OSI 的传输层有两个主要的协议，互为补充。其中，面向连接的是 TCP，无连接的是 UDP。

如何理解无连接

通信技术其实大致分为三类：面向连接的电路交换，面向连接的包交换，以及无连接的包交换。

UPD 在这里使用的就是 无连接的包交换，具体来说：

• 通信前发送端和接收端不需要建立和断开连接，也不需要维护连接状态
• 通信过程中，直接把每个带有目的地址的包（报文）送到线路上，由系统自主选定路线进行传输

这也就决定了 UDP 只是 报文的搬运工，不会对报文进行任何拆分和拼接操作。

UDP的报文头

因为 UDP 是无连接的，不需要保证数据不丢失且有序到达，所以其头部开销非常小，只有 8 个字节，

其中，头部信息中包含了以下几个数据：

• Source port & Destination port：两个 16 位的端口号，分别为发送端口和接收端口
• Length：数据报文的长度
• Checksum：数据报文校验以及用于发现头部信息和数据中的错误的 IPV4 可选字段

特性

基于无连接的包交换，我们可以很好地理解 UDP 的以下特性，

不可靠性

UDP 的不可靠性体现在对数据报文的处理上，

• 协议收到什么就传递什么，也不会备份数据，对方能不能收到也不关心
• 没有拥塞控制，一直会以恒定的速度发送数据，所以在网络条件不好的情况下可能会导致丢包

高效性

由于不提供数据传送的保证机制，所以 UDP 的优点就是高效，适合某些实时性要求较高的场景，比如：

• 屏幕上报告股票市场，显示航空信息
• 电话会议，视频会议

总结

UDP 是传输层一个面向报文，无连接的协议，它具有高效但不可靠的特性

写在最后

本文首发于我的 博客，才疏学浅，难免有错误，文章有误之处还望不吝指正！

如果有疑问或者发现错误，可以在评论区进行提问和勘误，

如果喜欢或者有所启发，欢迎 star，对作者也是一种鼓励。

（完）

vscode.

configuration for react

{
    "editor.fontSize": 18,
    "editor.tabSize": 2,
    "editor.suggestSelection": "first",
    "editor.snippetSuggestions": "top",
    "editor.fontFamily": "Monaco",
    "editor.lineHeight": 30,
    "editor.formatOnSave": false,
    "terminal.integrated.fontSize": 18,
    "terminal.integrated.shell.osx": "/bin/zsh",
    "terminal.integrated.fontWeight": "bold",
    "terminal.integrated.rendererType": "dom",
    "prettier.semi": false,
    "prettier.trailingComma": "es5",
    "git.confirmSync": false,
    "git.autofetch": true,
    "git.enableSmartCommit": true,
    "window.zoomLevel": -2,
    "workbench.iconTheme": "vscode-icons",
    "eslint.validate": ["javascript", "javascriptreact"],
    "gitlens.advanced.messages": { "suppressShowKeyBindingsNotice": true },
    "javascript.implicitProjectConfig.experimentalDecorators": true,
    "javascript.format.insertSpaceBeforeFunctionParenthesis": true,
    "[javascript]": { "editor.defaultFormatter": "esbenp.prettier-vscode" },
    "emmet.triggerExpansionOnTab": true,
    "emmet.includeLanguages": { "javascript": "javascriptreact" },
}

目前世界上使用率最高的浏览器是 Chrome，它的核心是 Chromium（Chrome 的开发实验版），微软的 Edge 以及国内的大部分主流浏览器，都是基于 Chromium 二次开发而来，它们都有一个共同的特点：多进程架构。

当我们用 Chrome 打开一个页面时，会同时启动多个进程，

(Chrome 使用了由 Apple 发展来的号称 “地表最快” 的 Webkit 排版引擎，搭载 Google 独家开发的 V8 Javascript 引擎)

高性能的 Web 应用的设计和优化都离不开浏览器的多进程架构，接下来我会以 Chrome 为例，带你了解多进程架构。

进程

介绍多进程架构前，我们先回顾下什么是进程和线程。

首先，我们知道计算机的核心是 CPU，它承担了所有的计算任务，就像一个时刻运行的工厂，

而进程就好比工厂内的车间，它代表 CPU 可以处理的单个任务，

假设工厂电力有限，一次只能给一个车间供电，当这个车间开工时，其他的车间就必须停工，这就好比一个单核 CPU 一次只能处理一个任务。当然，现代的 CPU 通常会使用 时间片轮转调度算法 来实现同时运行多个进程。

进程之间是独立的，在计算机科学领域，一个进程就是一个程序的运行实例。

具体来说，当我们启动一个程序的时候，操作系统会为程序创建一块内存，用来存放代码、运行中的数据和一个执行任务的主线程，我们把这样的一个运行环境就叫做进程。

那什么又是线程呢？

线程

还是以刚才的工厂车间为例，一个车间里，可以有很多工人，他们可以共享车间的资源，协同来完成一个任务，

而线程就好比车间里的工人，一个进程可以包含多个线程，多个线程共享进程的资源。

如果只有一个工人，那么任务的执行效率是很慢的，所以进程中使用多线程并行处理能提高运算效率，

线程不能单独存在，必须由进程来启动和管理，线程和进程有以下一些显著特点，

1. 进程中的任意一线程执行出错，都会导致整个进程的崩溃
2. 线程之间可以共享进程中的数据
3. 当一个进程关闭之后，操作系统会回收进程所占用的内存
4. 进程之间的内容是相互隔离的

了解了进程和线程后，我们来一起看一下浏览器的进程架构。

单进程架构

2007 年以前，市面上的浏览器基本都是单进程的，浏览器所有的功能模块都是运行在同一个进程，

这会导致什么问题呢？

我们知道浏览器的功能模块包括了网络、插件、JavaScript 运行环境、渲染引擎和页面等，如此多的功能模块全部运行在一个进程里，会导致浏览器不稳定、不流畅和不安全。

怎么个不稳定？

我们前文提到过，进程中的任意一线程执行出错，都会导致整个进程的崩溃。

早期的浏览器许多功能（比如 Web 视频，Web 游戏）都需要借助插件来实现，而插件是最容易出问题的模块，并且还运行在浏览器进程之中，可想而知，一个插件的意外崩溃就会引起整个浏览器的崩溃；此外，渲染引擎模块也是很不稳定的，通常一些复杂的 JavaScript 代码就有可能引起渲染引擎模块的崩溃，进而导致浏览器崩溃，所以单进程架构是不稳定的。

为什么不流畅呢？

导致单进程架构不流畅的原因主要有两个，一是所有页面的渲染模块，JavaScript 的执行环境和插件都运行在一个页面线程中，这意味着同一时刻只能有一个模块被执行。想象一下，如果一个耗时的脚本运行在页面线程中，脚本执行时会独占整个线程，导致其他任务都没有机会执行，带来的用户体验就是整个浏览器失去响应，变得卡顿；除此之外，页面的内存泄漏也是单进程变慢的一个原因，我们知道进程关闭时，操作系统会回收进程占用的内存，但是页面是运行在线程中的，当我们运行一个复杂点的页面再关闭页面时，会存在内存不能完全回收的情况。

是什么导致了安全问题呢？

插件和页面脚本是导致安全问题的主要原因。插件可以使用 C/C++ 等代码编写，通过插件可以获取到操作系统的任意资源，这意味着恶意插件的开发成本将大幅降低；此外，页面脚本也可以通过浏览器的漏洞来获取系统权限，引发安全问题。

显然，单进程架构的浏览器由于其不稳定，流畅度差和安全问题，已经逐渐被淘汰，那现代浏览器是如何解决这些问题的呢？

多进程架构

答案就是我们接下来要聊的 “多进程架构” 了。还是以 Chrome 为例，早期的多进程架构第一次出现在 Chrome 中是 2008 年，

为了解决单进程浏览器的问题，Chrome 用独立的渲染进程来运行页面，插件也被放到一个单独的插件进程中执行，浏览器的主线程只负责下载资源，管理进程通信和显示渲染进程生成的页面，我们来简单解释一下多进程架构是如何解决上述问题的，

• 稳定性：进程间相互隔离通过 IPC 机制进行通信，所有页面或插件的崩溃不会影响到主进程和其他页面
• 流畅性：1个页面就是1个进程，关闭页面整个进程也关闭了不存在内存泄漏；JavaScript 运行在渲染进程中只会阻塞当前页面
• 安全性：插件进程和渲染进程被锁进沙箱，进程锁导致即使存在恶意程序也无法突破沙箱去获取系统权限

现代浏览器的发展滚滚向前，Chrome 几乎每六周就会更新一次版本，Chrome 多进程架构相较于之前也有一些新的变化，

演变后的多进程架构将 GPU，网络进程等再次独立出来，不同版本可能会有差异吗，总的来说包括，

• 1 个浏览器主进程(Browser Process)：负责界面显示、用户交互、子进程管理等
• 多个渲染进程(Renderer)：渲染进程负责将 HTML、CSS 和 JavaScript 转换为用户可以与之交互的网页，我们之前提到的 Webkit 排版引擎，JavaScript 引擎都位于渲染进程，默认情况下每打开一个 Tab 页签，Chrome 都会为其创建一个渲染进程
• 1 个GPU 进程(GPU Process)：GPU 最初是为了实现 3D CSS 的效果，现在也用来绘制 UI 界面
• 1 个网络进程(Network Process)：负责页面的网络资源加载
• 多个插件进程(Plugin Process)：主要负责插件的运行，独立是为了防止插件崩溃对浏览器和其他页面造成影响

不过你可能发现，上面的架构和我们开篇用 Chrome 打开一个页面时在 Task Manager 看到的还是不尽相同，拆分后的多进程模型虽然提升了浏览器的稳定性、流畅性和安全性，但还是存在一些问题，

• 资源占用过高，每个进程都包含了公共基础结构的副本（如 JavaScript 运行环境），意味着浏览器会消耗更多的内存资源
• 架构体系复杂，主要体现在浏览器各模块之间耦合性过高、扩展性较差

为了解决这些问题，Chrome 团队在 2016 年提出了 “面向服务的架构”（Services Oriented Architecture，SOA）**，

通过解耦模块，重构为独立的服务（Service），使每个服务都可以在独立的进程中运行，同时约定服务的访问必须使用定义好的接口，通过 IPC 来通信。在最新的 Chrome 版本中，除了浏览器的主进程，渲染进程和插件进程外，UI、数据库、文件、设备、网络等模块基本都已重构为基础服务（Chrome Foundation Service），这样高内聚，低耦合的设计使得多进程的架构更易于维护和扩展。

同时 Chrome 还提供灵活的弹性架构，在强大性能设备上会以上面我们讲到的面向服务的多进程的方式运行基础服务，但如果在资源受限的设备上，Chrome 会将多个服务整合到一个进程中，以节省内存的占用，

参考链接

• Inter-process communication
• Chrome架构：仅仅打开了1个页面，为什么有4个进程？
• 「前端进阶」从多线程到Event Loop全面梳理
• What is "Spare Renderer" Process in Chrome Task Manager?

写在最后

本文首发于我的 博客，才疏学浅，难免有错误，文章有误之处还望不吝指正！

如果有疑问或者发现错误，可以在评论区进行提问和勘误，

如果喜欢或者有所启发，欢迎 star，对作者也是一种鼓励。

（完）

随着 2019 年 2 月 React 稳定版 hooks 在 16.8 版本发布，涌现了越来越多的 “hooks 时代” 的状态管理库（如 zustand、jotai、recoil 等），“class 时代” 的状态管理库（如 redux）也全面拥抱了 hooks。无一例外，它们都聚焦于解决 组件通信 的问题，

• 组件通信的方式有哪些？
• 这么多的状态管理库要怎么选？
• 可变状态 or 不可变状态？

截至目前，React 中组件间的通信方式一共有 5 种，

• props 和 callback
• Context（官方）
• Event Bus（事件总线）
• ref 传递
• 状态管理库（如：redux、mobx、zustand、recoil、valtio、jotai、hox 等）

props & callback

React 组件最基础的通信方式是使用 props 来传递信息，props 是只读的，每个父组件都可以提供 props 给它的子组件，从而将一些信息传递给它，这里的信息可以是，

• JSX 标签信息，如 className、src、alt、width 和 height 等
• 对象或其他任意类型的值
• 父组件中的 state
• children
• ...

我们通常在 “父传子” 的通信场景下使用 props，下面是一个 props 通信的例子，

import React, { useState } from "react";

function Parent() {
  const [count, setCount] = useState<number>(0);

  return (
    <>
      <button type="button" onClick={() => setCount(count + 1)}>Add</button>
      <Child count={count}>Children</Child>
    </>
  );
}

function Child(props) {
  const { count, children } = props;

  return (
    <>
      <p>Received props from parent: {count}</p>
      <p>Received children from parent: {children}</p>
    </>
  );
}

callback 回调函数也可以是 props，利用回调，我们也可以实现简单的 “子传父” 场景，

import React, { useState } from "react";

function Parent() {
  const [count, setCount] = useState<number>(0);

  return (
    <>
      <div>Received from child: {count}</div>
      <Child updateCount={(value: number) => setCount(value)} />
    </>
  );
}

function Child(props) {
  const { updateCount } = props;
  const [count, setCount] = useState<number>(0);

  return (
    <button
      type="button"
      onClick={() => {
        const newCount: number = count + 1;
        setCount(newCount);
        updateCount(newCount);
      }}
    >
      Add
    </button>
  );
}

此外，如果多个组件需要共享 state，且层级不是太复杂时，我们通常会考虑 状态提升，实现的思路是：将公共 state 向上移动到它们的最近共同父组件中，再使用 props 传递给子组件，你可以点击这个 官方例子 看具体的实现。

通过以上例子我们不难发现，在多级嵌套组件的场景下，使用 props 进行通信是一件成本极高的事情。

Context

为此，React 官方提供了 Context 避免一级级的属性传递，

Context 让父组件可以为它下面的整个组件树提供数据，这在一些特定的场景下非常有用，比如，

• 主题：可以在应用顶层放一个 context provider，并在需要调整其外观的组件中使用该 context
• 全局的共享信息：如当前登录的用户信息，将它放到 context 中可以方便地在树中任何位置读取
• 路由：大多数路由解决方案在内部使用 context 保存当前路由，用于判断链接是否处于活动状态

下面是一个使用 Context 完成主题切换的例子，

import React, { useState, useContext } from "react";

enum Theme {
  Light,
  Dark,
}

interface ThemeContextType {
  theme: Theme;
  toggle?: () => void;
}

const ThemeContext = React.createContext<ThemeContextType>({ theme: Theme.Light });

function ThemeProvider(props) {
  const { children } = props;
  const [theme, setTheme] = useState<Theme>(Theme.Light);

  const toggle = () => {
    setTheme(theme === Theme.Light ? Theme.Dark : Theme.Light);
  };

  return (
    <ThemeContext.Provider value={{ theme, toggle }}>
      {children}
    </ThemeContext.Provider>
  );
}

function App() {
  const context: ThemeContextType = useContext(ThemeContext);
  const { theme, toggle } = context;

  return (
    <ThemeProvider>
      <div>
        <p>Current theme: {theme === Theme.Light ? "light" : "dark"}</p>
        <button type="button" onClick={toggle}>toggle theme</button>
      </div>
    </ThemeProvider>
  );
}

需要注意的是，使用 Context 我们需要考量具体的场景，因为 Context 本身存在以下问题，

• context 的值一旦变化，所有依赖该 context 的组件全部都会 force update
• context 会穿透 React.memo 和 shouldComponentUpdate 的对比

此外，对于异步请求和数据间的联动，Context 也没有提供任何 API 支持，如果使用 Context，需要自己做一些封装。除了上述两个通信方案外，基于发布订阅的全局事件总线也是常见一种组件通信方案。

Event Bus

事件总线的本质就是发布订阅，目前有非常多的开源实现（如 miit、tiny-emitter 等），

我们也可以考虑自己实现一个 EventBus，

type Callback = (...args: any[]) => void;

class EventBus {
  private events: Map<string, Callback[]>;

  constructor() {
    this.events = new Map();
  }

  on(eventName: string, callback: Callback): void {
    if (!this.events.has(eventName)) {
      this.events.set(eventName, []);
    }
    this.events.get(eventName).push(callback);
  }

  off(eventName: string, callback: Callback): void {
    if (this.events.has(eventName)) {
      const callbacks = this.events.get(eventName);
      const index = callbacks.indexOf(callback);
      if (index !== -1) {
        callbacks.splice(index, 1);
      }
    }
  }

  emit(eventName: string, ...args: any[]): void {
    if (this.events.has(eventName)) {
      this.events.get(eventName).forEach((callback) => {
        callback(...args);
      });
    }
  }
}

EventBus 可以实现跨层级的组件通信，但由于事件的订阅和发布都是在运行时动态绑定的，这会增加代码的复杂度和调试难度。此外，我们通常还需要遵循一定的规范和约定，来更好地管理事件，避免事件名重复或滥用等问题。

ref

使用 ref 可以访问到由 React 管理的 DOM 节点，ref 一般适用以下的场景，

• 管理焦点，获取子组件的值，文本选择或媒体播放
• 触发强制动画
• 集成第三方 DOM 库

ref 也是组件通信的一种方案，通过 ref 可以获取子组件的实例，以 input 元素的输入值为例，

import React, { useRef, useState } from "react";

interface ChildProps {
  inputRef: React.RefObject<HTMLInputElement>;
}

const Child: React.FC<ChildProps> = ({ inputRef }) => <input ref={inputRef} />;

const Parent: React.FC = () => {
  const [text, setText] = useState<string>("");
  const inputRef = useRef<HTMLInputElement>(null);

  const handleClick = () => {
    if (inputRef.current) {
      setText(inputRef.current.value);
    }
  };

  return (
    <div>
      <Child inputRef={inputRef} />
      <button type="button" onClick={handleClick}>Get Input Value</button>
      <p>Input Value: {text}</p>
    </div>
  );
};

状态管理库

上述的组件通信方案都有各自的使用场景，如果你的项目庞大，组件状态复杂，你可能需要考虑状态管理库。众所周知，React 的状态管理库一直以来都是 React 生态中非常内卷的一个领域，截至目前比较常见的状态管理库包括，

• redux
• mobx
• zustand
• recoil
• jotai
• valtio
• hox

我们可以在 npmtrends 查看这几个状态管理库 近一年的下载量趋势图，

可以看到，Redux 在下载量上依然遥遥领先其他状态管理库，而往年热度仅次于 Redux 的 Mobx，有逐渐被 zustand 超越的趋势，其他的一些 “hooks 时代” 的状态管理库热度也在逐步上升。我们先从 “class 时代” 走过来的老大哥 Redux 说起。

redux

Redux 是一个基于 Flux 架构的一种实现，遵循“单向数据流”和“不可变状态模型”的设计**，

通过 Action-Reducer-Store 的工作流程实现状态的管理，具有以下的优点，

• 可预测和不可变状态，行为稳定可预测、可运行在不同环境
• 单一 store ，单项数据流集中管理状态，在做 撤销/重做、 状态持久化 等场景有天然优势
• 成熟的开发调试工具，Redux DevTools 可以追踪到应用的状态的改变

使用 Redux 就得遵循他的设计**，包括其中的 “三大原则”，

• 使用单一 store 作为数据源
• state 是只读的，唯一改变 state 的方式就是触发 action
• 使用纯函数来执行修改，接收之前的 state 和 action，并返回新的 state

下面是一个使用 Redux 简单的示例，

import React from "react";
import { createStore, combineReducers } from "redux";
import { Provider, useSelector, useDispatch } from "react-redux";

// 定义 action 类型
const INCREMENT = "INCREMENT";
const DECREMENT = "DECREMENT";

// 定义 action 创建函数
const increment = () => ({ type: INCREMENT });
const decrement = () => ({ type: DECREMENT });

// 定义 reducer
const counter = (state = 0, action: { type: string }) => {
  switch (action.type) {
    case INCREMENT:
      return state + 1;
    case DECREMENT:
      return state - 1;
    default:
      return state;
  }
};

// 创建 store
const rootReducer = combineReducers({ counter });
const store = createStore(rootReducer);

// 定义 Counter 组件
const Counter: React.FC = () => {
  const count = useSelector((state: { counter: number }) => state.counter);
  const dispatch = useDispatch();

  return (
    <div>
      <h2>Counter: {count}</h2>
      <button type="button" onClick={() => dispatch(increment())}>add</button>
      <button type="button" onClick={() => dispatch(decrement())}>dec</button>
    </div>
  );
};

// 使用 Provider 包裹根组件
const App: React.FC = () =>
  <Provider store={store}>
    <Counter />
  </Provider>

可以看到，由于没有规定如何处理异步加上相对约定式的设计，导致 Redux 存在以下的一些问题，

• 陡峭的学习曲线，副作用扔给中间件来处理，导致社区一堆中间件，学习成本陡然增加
• 大量的模版代码，包括 action、action creator 等大量和业务逻辑无关的模板代码
• 性能问题，状态量大的情况下，state 更新会影响所有组件，每个 action 都会调用所有 reducer

虽然 Redux 一致尝试致力解决上述部分问题，比如后面推出的 redux toolkit，但即便如此，对于开发者（尤其是初学者）而言，仍然有比较高的学习成本和心智负担。

mobx

相比之下，Mobx 的心智模型更加简单，Mobx 将应用划分为 3 个概念，

• State（状态）
• Actions（动作）
• Derivations（派生）

其中 Derivations 又分为，

• Computed Values（计算值）, 总是可以通过纯函数从当前的可观测 State 中派生
• Reactions（副作用）, 当 State 改变时需要自动运行的副作用

Mobx 的整个工作流程非常简单，首先创建可观察的状态，然后通过 Actions 修改状态，Mobx 会自动更新所有的派生（Derivations），包括计算值（Computed value）以及副作用（Reactions），

如果你选择将 Mobx 结合 React 来用，那同样可以考虑直接使用 Vue，因为 Mobx 的实现基于 mutable + proxy，导致了与 React 结合使用时有一些额外成本，例如，

• 要给 DOM render 包一层 useObserver/Observer
• 副作用触发需要在 useEffect 里再跑一个 autorun/reaction

尤大在知乎的 这个回答 里也提到，一定程度上，React + Mobx 也可以被认为是更繁琐的 Vue。

zustand

zustand 是一个轻量级的状态管理库，经过 Gzip 压缩后仅 954B 大小，zustand 凭借其函数式的理念，优雅的 API 设计，成为 2021 年 Star 数增长最快的 React 状态管理库，

与 redux 的理念类似，zustand 也是基于不可变状态模型和单向数据流，区别在于，

• redux 需要包装一个全局 / 局部的 Context Provider，而 zustand 不用
• redux 基于 reducers 纯函数更新状态，zustand 通过类原生 useState 的 hooks 语法，更简单灵活
• zustand 中的状态更新是同步的，不需要异步操作或中间件

zustand 的心智模型非常简单，包含一个发布订阅器和渲染层，工作原理如下，

其中 Vanilla 层是发布订阅模式的实现，提供了setState、subscribe 和 getState 方法，React 层是 Zustand 的核心，实现了 reselect 缓存和注册事件的 listener 的功能，并且通过 forceUpdate 对组件进行重渲染，发布订阅相信大家都比较了解了，我们重点介绍下渲染层。

首先思考一个问题，React hooks 语法下，我们如何让当前组件刷新？

是不是只需要利用 useState 或 useReducer 这类 hook 的原生能力即可，调用第二个返回值的 dispatch 函数，就可以让组件重新渲染，这里 zustand 选择的是 useReducer，

const [, forceUpdate] = useReducer((c) => c + 1, 0) as [never, () => void]

有了 forceUpdate 函数，接下来的问题就是什么时候调用 forceUpdate，我们参考源码来看，

// create 函数实现
// api 本质就是就是 createStore 的返回值，也就是 Vanilla 层的发布订阅器
const api: CustomStoreApi = typeof createState === 'function' ? createStore(createState) : createState

// 这里的 useIsomorphicLayoutEffect 是同构框架常用 API 套路，在前端环境是 useLayoutEffect，在 node 环境是 useEffect
useIsomorphicLayoutEffect(() => {
  const listener = () => {
    try {
      // 拿到最新的 state 与上一次的 compare 函数
      const nextState = api.getState()
      const nextStateSlice = selectorRef.current(nextState)
      // 判断前后 state 值是否发生了变化，如果变化调用 forceUpdate 进行一次强制刷新
      if (!equalityFnRef.current(currentSliceRef.current as StateSlice, nextStateSlice)) {
        stateRef.current = nextState
        currentSliceRef.current = nextStateSlice
        forceUpdate()
      }
    } catch (error) {
      erroredRef.current = true
      forceUpdate()
    }
  }
  // 订阅 state 更新
  const unsubscribe = api.subscribe(listener)
  if (api.getState() !== stateBeforeSubscriptionRef.current) {
    listener()
  }
  return unsubscribe
}, [])

我们首先从第 24 行 api.subscribe(listener) 开始，这里先创建了 listener 的订阅，这就使得任何的 setState 调用都会触发 listener 的执行，接着回到 listener 函数的内部，利用 api.getState() 拿到了最新 state，以及上一次的 compare 函数 equalityFnRef，然后执行比较函数后判断值前后是否发生了改变，如果改变则调用 forceUpdate 进行一次强制刷新。

这就是 zustand 渲染层的原理，简单而精巧，zustand 实现状态共享的方式本质是将状态保存在一个对象里，与之相对的是一些原子化的状态管理工具，比如接下来我们要介绍的 recoil。

recoil

recoil 是 React Europe 2020 Conference 上 Facebook 官方推出的一个 React 状态管理库，是对 React 内置的状态管理能力的一个补充，recoil 实现的动机如下，考虑到 React 原生状态管理的一些局限性，

• 组件间状态共享只能通过将 state 提升至它们的公共祖先，可能导致重新渲染一颗巨大的组件树
• Context 只能存储单一值，无法存储多个各自拥有消费者的值的集合

在实现上，recoil 定义了一个有向图 (directed graph)，正交且天然连结于 React 树上，

看着很高级，其实就是定义原子状态，然后通过原子状态在组件中进行自由地组合和订阅。

recoil 中提供了两个核心方法用于定义状态，

• atom: 定义原子状态，即组件的某个状态的最小集
• selector: 定义派生状态，其实就是 Computed Value

消费状态的方式有 useRecoilState、useRecoilValue、useSetRecoilState 等，用法和 react 的 useState 类似，所以几乎没有上手成本，下面是一个简单的示例可以直观感受下，

import React from "react";
import { RecoilRoot, atom, useRecoilState } from "recoil";

// 定义一个原子
const countState = atom({
  key: "countState",
  default: 0,
});

function Counter() {
  // 获取 countState 的值和修改函数
  const [count, setCount] = useRecoilState(countState);

  const handleIncrement = () => setCount(count + 1);
  
  const handleDecrement = () => setCount(count - 1);

  return (
    <div>
      <h1>Count: {count}</h1>
      <button onClick={handleIncrement}>+1</button>
      <button onClick={handleDecrement}>-1</button>
    </div>
  );
}

function DisplayCount() {
  // 组件间共享 countState 原子状态
  const [count] = useRecoilState(countState);

  return <h2>Count: {count}</h2>;
}

function App() {
  return (
    // 使用 RecoilRoot 包裹组件
    <RecoilRoot>
      <Counter />
      <DisplayCount />
    </RecoilRoot>
  );
}

与 recoil 类似的原子状态管理库还有 jotai，它们的设计理念基本相同。

jotai

recoil 最为人诟病的是原子状态（atom）定义时需要一个唯一的键值 key，这一反人类的设计导致键命名本身就是一个繁琐的任务，为了降低开发成本和心智负担，而 jotai 中定义 atom 不需要指定键值，同时也支持非 Provider 包裹的语法，

jotai 在实现上使用了 Context 和订阅机制相结合，核心的概念只有四个，

• atom，定义原子状态，不需要指定唯一键值
• useAtom，消费原子状态，与 useState hook 语法一致
• Store，存储原子状态，可以不使用，默认会使用 getDefaultStore 创建默认 Store
• Provider，为组件子树提供状态，可以不使用

同样是上面的例子，使用 jotai 改写会简单很多，

import React from "react";
import { atom, useAtom } from "jotai";

// 定义原子状态不需要唯一 key
const countAtom = atom(0);

function Counter() {
  const [count, setCount] = useAtom(countAtom);

  const handleIncrement = () => setCount(count + 1);

  const handleDecrement = () => setCount(count - 1);

  return (
    <div>
      <h1>Count: {count}</h1>
      <button onClick={handleIncrement}>+1</button>
      <button onClick={handleDecrement}>-1</button>
    </div>
  );
}

function DisplayCount() {
  const [count] = useAtom(countAtom);

  return <h2>Count: {count}</h2>;
}

function App() {
  return (
    // 不需要 Provider 包裹
    <div>
      <Counter />
      <DisplayCount />
    </div>
  );
}

zustand 和 jotai 都来自同一个组织 pmndrs，包括我们接下来要介绍的 valtio。

valtio

valtio 是一个基于可变状态模型和 Proxy 实现的状态管理库，核心实现非常简洁，只有两个方法，

• proxy，将原始对象包装为一个可观察的状态（observable state）
• useSnapshot，获取 proxy 的快照，可以访问和修改

import React from "react";
import { proxy, useSnapshot } from "valtio";

// 创建一个状态对象
const state = proxy({
  count: 0,
});

function Counter() {
  // 使用 useSnapshot 获取状态快照
  const snapshot = useSnapshot(state);

  return (
    <div>
      <p>Count: {snapshot.count}</p>
      <button onClick={() => state.count++}>Increment</button>
    </div>
  );
}

valtio 和 mobx 都是基于 Proxy 的状态管理库，理念上 valtio 较于 mobx 更为简单和自由。

以上的库都聚焦于状态管理，接下来我们要介绍的是一个专注于 “组件共享状态” 的库。

hox

hox 聚焦于一个痛点：如何在多个组件间共享状态，是一个简单、轻量的状态共享库。

hox 只有一个 API，

• createStore，1.x 版本叫 createModel

createStore 会返回一个数组，包含两个参数，

• useStore，订阅和消费 store 中的数据
• StoreProvider，状态容器，底层依赖 React Context

import { useState } from "react";
import { createStore } from "hox";

// 使用 createStore 包装一个自定义 hook
export const [useTaskStore, TaskStoreProvider] = createStore(() => {
  const [tasks, setTasks] = useState([]);

  function addTask(task) {
    setTasks((v) => [...v, task]);
  }

  return {
    tasks,
    addTask,
  };
});

function TaskList() {
  // 消费状态
  const { tasks } = useTaskStore();
  return (
    <>
      {tasks.map((task) => (
        <div key={task.id}>{task}</div>
      ))}
    </>
  );
}

function App() {
  return (
    // Provider 包裹的组件间可以进行状态共享
    <TaskStoreProvider>
      <TaskList />
    </TaskStoreProvider>
  );
}

hox 底层实现是一个基于 React Context 的 singleton 单例，感兴趣的可以点击 这里 上阅读它的源码。

小结

时至 2023 年，对于 React 组件的通信，我们有太多可选的方式，对于选型可以参考以下大致的思路，

• 如果组件间需要共享 state，且层级不是太复杂时，我们通常会考虑状态提升
• Context 更适合存储一些全局的共享信息，如主题，用户登陆信息等
• ref 更适用于管理焦点，获取子组件的值，触发强制动画，第三方 DOM 库集成等场景
• EventBus 可以用于跨层级组件通信，由于本质是发布订阅需要结合一些约定和规范来管理事件
• 如果你习惯了不可变更新，可以考虑生态丰富的 redux 和轻量的 zustand
• 如果你习惯了类 Vue 的响应式可变模型，mobx 和 valtio 可能更适合
• 如果你想尝试原子状态的方案，recoil 和 jotai 是个不错的选择
• 如果你想基于 custom hook 实现状态持久化和共享，hox 可能更适合

写在最后

本文首发于我的 博客，才疏学浅，难免有错误，文章有误之处还望不吝指正！

如果有疑问或者发现错误，可以在评论区进行提问和勘误，

如果喜欢或者有所启发，欢迎 star，对作者也是一种鼓励。

React 高效性能的背后得益于 Virtual DOM 和 Diff 算法，而 Diff 算法要解决的根本问题就是：Virtual DOM 变化时，计算差异部分用于局部更新，而虚拟DOM本质上就是一个树形对象，所以问题转化两棵树的对比。

对比两棵树的差异本就是一个复杂的问题，如果使用传统的 Diff 算法，通过循环递归对树节点依次进行对比，不仅效率低下，算法的时间复杂度更是达到 O(n^3)，其中 n 是树节点的总数。O(n^3) 意味着如果要展示 1000 个节点，需要进行上十亿次的比较，这种指数型的性能消耗对于前端渲染场景来说代价太高了，现今的 CPU 每秒钟能执行大约 30 亿条指令，即便是最高效的实现，也不可能在一秒内计算出差异情况。

所以，如果想要将 Diff **引入 Virtual DOM，就需要降低 Diff 算法的时间复杂度。

React 开发团队针对前端渲染场景和 React 组件化的**，制定了三个大胆的策略，将时间复杂度从 O(n^3) 降到 O(n)。

Diff策略

在保证页面整体构建性能的前提下，React 团队提出了三个 Diff 策略：

1. Web UI 中 DOM 节点跨层级的移动操作特别少，可以忽略不计
2. 拥有相同类的两个组件会生成相似的树形结构，拥有不同类的两个组件将会生成不同的树形结构
3. 同一层级的子节点可以通过唯一的 id 进行区分

Diff粒度

基于上诉的三个 Diff 策略，将Diff算法的执行分为三个维度：Tree Diff、Component Diff，Element Diff。

三个 Diff 的差异在于：粒度不同和执行的顺序不同，执行顺序依次为：Tree Diff, Component Diff, Element Diff。

Tree Diff

由于 DOM 节点跨层级的操作特别少，所以 React 对树的遍历算法进行了优化，通过层级控制进行分层比较，这样只需要一次遍历，就能完成整个 DOM 树的比较。

updateChildren: function(nextNestedChildrenElements, transaction, context) {
  updateDepth++;
  var errorThrown = true;
  try {
    this._updateChildren(nextNestedChildrenElements, transaction, context);
    errorThrown = false;
  } finally {
    updateDepth--;
    if (!updateDepth) {
      if (errorThrown) {
        clearQueue();
      } else {
        processQueue();
      }
    }
  }
}

具体来说，Tree Diff 会对树的每一层进行遍历，如果发现某个节点不存在了，会直接销毁，其对应的子节点也会完全被删除掉：

以上图为例，由于 React 只会简单的考虑同层级节点的位置变换，而对于不同层级的节点，只有创建和删除操作。当根节点发现子节点中 A 消失了，就会直接销毁 A；当 D 发现多了一个子节点 A，则会创建新的 A（包括子节点）作为其子节点。此时，React diff 的执行情况：create A -> create B -> create C -> delete A。

同时我们也注意到，当出现 节点跨层级移动 时，React 不会进行移动操作，而是以 A 为根节点的整个树被重新创建，所以这是影响 React 性能的操作，因此 React 官方建议不要进行 DOM 节点跨层级的操作。

所以在开发组件时，保持一个稳定的 DOM 结构会有助于性能的提升。例如使用 CSS 隐藏或显示节点，而不是真的移除或添加 DOM 节点。

Component Diff

React 基于组件构建用户界面，组件在 Virtual DOM 中体现为一个节点。

对于组件的比较，基于策略二，React 团队采取的方法是：

• 对于同一类型的组件，按照原策略继续比较
• 对于不同类型的组件，直接进行替换

我们先说对于同类型的组件（即拥有相同类的组件），有可能 Virtual DOM 没有任何变化，这个时候其实不需要进行比较，所以 React 允许用户通过 shouldComponentUpdate 方法来判断该组件是否需要进行 Diff，这也是常见的一种优化手段。

对于不同类型的组件，即使它们的结构相似，React 也不会进行比较，而是直接进行替换，以下图为例：

进行 Component Diff 时，React 发现组件 D 和 G 是不同类型的组件，React 会直接删除组件 D 及其子节点，然后重新创建组件 G 及其子节点。此时 Diff 顺序为：delete E -> delete F -> delete D -> create E -> create F -> create G。

你是否有疑问，组件 D 和 G 的结构相似，都有相同的子节点 E 和 F，直接将 D 和 G 进行替换不就行了吗，为什么要删除相同的子节点然后又创建呢？是的，当两个组件是不同类型但结构相似时，React diff 确实会影响性能，但是正如 React 官方博客所言：不同类型的组件是很少存在相似 DOM tree 的机会的，因此这种极端因素很难在实际开发过程中造成重大影响。

Element Diff

我们刚才说，对于同一类型的组件，会继续比较下去，所以 Element Diff 其实就是对于同一层级的兄弟节点的策略。

当节点处于同一层级时，React 提供了三种对于节点的操作：

• INSERT_MARKUP（插入），当节点是全新的节点时，执行插入操作。
• MOVE_EXISTING（移动），节点存在于旧的 Virtual DOM tree，且可复用时，执行移动操作。
• REMOVE_NODE（删除），新的 Virtual DOM tree 不存在该节点，或者虽然存在但是不可复用（对应的 element 不同）时，执行删除操作。

function enqueueInsertMarkup(parentInst, markup, toIndex) {
  updateQueue.push({
    parentInst: parentInst,
    parentNode: null,
    type: ReactMultiChildUpdateTypes.INSERT_MARKUP,
    markupIndex: markupQueue.push(markup) - 1,
    content: null,
    fromIndex: null,
    toIndex: toIndex,
  });
}

function enqueueMove(parentInst, fromIndex, toIndex) {
  updateQueue.push({
    parentInst: parentInst,
    parentNode: null,
    type: ReactMultiChildUpdateTypes.MOVE_EXISTING,
    markupIndex: null,
    content: null,
    fromIndex: fromIndex,
    toIndex: toIndex,
  });
}

function enqueueRemove(parentInst, fromIndex) {
  updateQueue.push({
    parentInst: parentInst,
    parentNode: null,
    type: ReactMultiChildUpdateTypes.REMOVE_NODE,
    markupIndex: null,
    content: null,
    fromIndex: fromIndex,
    toIndex: null,
  });
}

对于同一层级的节点，如下图所示：

老集合中包含节点：A，B，C，D，更新后新集合中包含节点：B，A，D，C，此时新老集合进行 diff 差异化对比，发现 B != A，则创建并插入 B 至新集合，删除老集合 A，以此类推，创建并插入 A、D 和 C，删除 B、C 和 D。

但是 React 团队发现这类操作繁琐冗余，因为这些都是相同的节点，但由于位置发生变化，导致需要进行繁杂低效的删除、创建操作，其实只要对这些节点进行位置移动即可。

针对这一现象，React 提出优化策略：允许开发者对同一层级的同组子节点，添加唯一 key 进行区分，虽然只是小小的改动，性能上却发生了翻天覆地的变化：

React 首先会收集新老集合中的 key，然后对新集合的节点进行遍历，通过唯一的 key 就可以判断新老集合中是否存在相同的节点，如果存在相同节点，则进行移动操作；如果新集合中有新加入的节点，会创建新节点；最后对老集合进行循环遍历，判断是否存在新集合中没有但老集合中仍存在的节点，如果发现这样的节点，删除。

_updateChildren: function(nextNestedChildrenElements, transaction, context) {
  var prevChildren = this._renderedChildren;
  var nextChildren = this._reconcilerUpdateChildren(
    prevChildren, nextNestedChildrenElements, transaction, context
  );
  if (!nextChildren && !prevChildren) {
    return;
  }
  var name;
  var lastIndex = 0;
  var nextIndex = 0;
  for (name in nextChildren) {
    if (!nextChildren.hasOwnProperty(name)) {
      continue;
    }
    var prevChild = prevChildren && prevChildren[name];
    var nextChild = nextChildren[name];
    if (prevChild === nextChild) {
      this.moveChild(prevChild, nextIndex, lastIndex);
      lastIndex = Math.max(prevChild._mountIndex, lastIndex);
      prevChild._mountIndex = nextIndex;
    } else {
      if (prevChild) {
        lastIndex = Math.max(prevChild._mountIndex, lastIndex);
        this._unmountChild(prevChild);
      }
      this._mountChildAtIndex(
        nextChild, nextIndex, transaction, context
      );
    }
    nextIndex++;
  }
  for (name in prevChildren) {
    if (prevChildren.hasOwnProperty(name) &&
        !(nextChildren && nextChildren.hasOwnProperty(name))) {
      this._unmountChild(prevChildren[name]);
    }
  }
  this._renderedChildren = nextChildren;
},

moveChild: function(child, toIndex, lastIndex) {
  if (child._mountIndex < lastIndex) {
    this.prepareToManageChildren();
    enqueueMove(this, child._mountIndex, toIndex);
  }
},

createChild: function(child, mountImage) {
  this.prepareToManageChildren();
  enqueueInsertMarkup(this, mountImage, child._mountIndex);
},

removeChild: function(child) {
  this.prepareToManageChildren();
  enqueueRemove(this, child._mountIndex);
},

_unmountChild: function(child) {
  this.removeChild(child);
  child._mountIndex = null;
},

_mountChildAtIndex: function(
  child,
  index,
  transaction,
  context) {
  var mountImage = ReactReconciler.mountComponent(
    child,
    transaction,
    this,
    this._nativeContainerInfo,
    context
  );
  child._mountIndex = index;
  this.createChild(child, mountImage);
},

行文至此，你应该知道为什么 React 建议在列表组件中使用唯一的 key，而且不建议使用数组下标作为 key。

tips：使用数组下标作为 key 的弊端可以看这篇文章，Index as a key is an anti-pattern。

参考链接

• React Docs
• React 源码剖析系列 － 不可思议的 react diff
• 云栖社区-图解React Diff算法

(完)

“从输入 URL 到页面展示” 是一个极其复杂的过程。

要完整地解释这一过程，你需要了解浏览器的多进程架构，网际协议(Internet Protocol，IP)，数据包协议(User Datagram Protocol，UDP)，传输控制协议(Transmission Control Protocol，TCP)，超文本传输​​协议(HyperText Transfer Protocol，HTTP)，域名系统(Domain Name System，DNS)，HTTP请求流程，导航流程，渲染流程等一系列网络协议、原理和流程。

知识体系的建立是一个循序渐进的过程，没有捷径，更无法一蹴而就，接下来的专栏文章里我将带你完整地探索这一过程。当然，我不打算从数据包和协议开始，因为那太枯燥了，相反，渲染流程是一个很不错的开端。

思考一下，我们编写的 HTML，CSS，JavaScript 文件，是如何转化为下面的页面的？

我们知道，HTML 的内容是由标记和文本组成，标记也称为标签，它是 Web 语义化的基础；CSS 叫做层叠样式表，是由选择器和属性组成，通过它我们可以对 HTML 进行布局，设置样式；而 JavaScript 是一门脚本语言，我们可以用它创建动态更新的内容，控制多媒体，动画等等，

想要将上述的文件最终呈现为页面，浏览器需要经历一系列复杂的处理流程，如果把整个流程看作一个渲染流水线，按照渲染的时间顺序，流水线包括：构建 DOM 树，样式计算，布局，分层，图层绘制，光栅化，合成，

接下来让我们逐一来看。

DOM Tree Building

渲染流程的第一阶段是 DOM Tree 的构建，先来回顾一下，什么是 DOM ？

从网络进程传递给渲染引擎的 HTML 文件字节流是无法直接被引擎理解的，我们需要一个描述 HTML 文档的数据结构，这个结构就是 DOM；当然，从脚本的角度，DOM 也是提供给 JavaScript 脚本操作的一套文档接口。我们以下面的一段 HTML 为例，

<html>
  <body>
    <div>Monch</div>
    <div>Lee</div>
  </body>
</html>

DOM Tree 的构建流程为，

HTML Parser

执行字节流转换为 DOM 这一流程的是渲染引擎内部的 HTML 解析器( HTMLParser )。

解析器接收数据的流程为：网络进程接收到响应头后，根据响应头中的 Content-Type 判断文件类型，如果是 text/html，浏览器会创建一个渲染进程，然后创建一个网络进程和渲染进程之间共享数据的管道，网络进程接收到数据后就会往这个管道里面放，而渲染进程则从管道的另外一端不断地读取数据，并同时将读取的数据传递给 HTML 解析器。

所以HTML 解析器并不是等整个文档加载完成后才开始解析的，而是网络进程加载多少数据，解析器便解析多少数据。

网络进程传递过来的数据是字节流，字节流首先会转换为 Token，这一步由分词器完成。

HTML 解析器维护了一个 Token 栈，用来计算节点间的父子关系，

字节流会被转换为 Tag Token 和 Text Token，其中 Tag Token 又分为 StartTag 和 EndTag，分别代表开始标签和结束标签。

解析的流程为：开始时，HTML 解析器会默认创建一个根为 document 的 DOM 结构并初始化 Token 栈，将第一个 StartTag document 的 Token 压入栈底，然后分词器开始解析；分词器会把解析出来的 Token 依次入栈，每压入一个 Token，渲染引擎都会为其创建一个 DOM 节点，如果是文本 Token，会创建一个文本节点，并将该 Token 添加到 DOM 中，它的父节点就是当前 Token 栈顶元素对应的节点，

如果解析出来的是 EndTag，HTML 解析器会去判断当前栈顶的元素是否是 对应的 StartTag，如果是则从栈顶弹出 StartTag，直到最后所有的 StartTag 全部弹出，此时 Token 栈为空，解析完成，

实际的生产环境中，解析器接受到的 HTML 文件可能还包括脚本标签，

接下来我们介绍一下 JavaScript 阻塞是如何发生的。

JavaScript Pending

我们对上面的示例稍做修改，引入一个外部样式文件，然后插入一个 script 标签，

<html>
  <head>
    <style src="https://xxx/foo.css"></style>
  </head>
  <body>
    <div>Monch</div>
    <script>document.getElementsByTagName('div')[0].innerText = 'Steven'</script>
    <div>Lee</div>
  </body>
</html>

暂停思考一下，此时的解析流程是什么样的呢？🤔

解析到 script 标签时，由于无法判断脚本是否会修改当前已经生成的 DOM 结构，此时 HTML 解析器会暂停 DOM 的解析，接着 JavaScript 引擎会介入执行 script 标签内的脚本；如果这里是外链的脚本，在执行前就需要先下载脚本。引擎在执行 JavaScript 脚本前，类似的，由于不清楚 JavaScript 是否操作了 CSSOM，所以会先执行 CSS 文件的下载和解析，再执行 JavaScript 脚本，而 HTML 解析器会一直等到脚本执行完成后再继续工作，所以 JavaScript 会阻塞 DOM Tree 的构建，

现代浏览器在这里做了很多优化，比如 Chrome 支持预解析：当渲染引擎收到字节流后，会同时开启一个预解析线程，用来分析 HTML 文件中包含的 JavaScript、CSS 等相关文件并提前下载这些文件。

我们也可以通过一些策略来规避或优化脚本对 DOM Tree 构建的阻塞，比如，

• 使用 CDN 来加速 JavaScript 文件的加载，压缩 JavaScript 文件的体积
• 将 script 标签后置，比如放到 body 的底部
• 如果脚本没有操作 DOM，通过 async 或 defer 标记将脚本设置为异步加载

需要注意的是，async 和 defer 虽然都是异步的，但在执行时机上存在差别：使用 async 标记的脚本会在下载完成后立即执行，而 defer 标记的会在 DOMContentLoaded 事件前执行。

接下来我们介绍渲染流程的第二阶段，样式计算（Recalculate Style）。

Recalculate Style

样式计算的流程可以分为三个阶段：构建 StyleSheets，属性值标准化，计算节点样式，

我们知道层叠样式表（Cascading Style Sheets，CSS）描述了 DOM Tree 中节点的布局和样式，和 HTML 文件一样，渲染引擎也是无法直接理解 CSS 文件的，所以渲染引擎在接收到 CSS 文本时，首先会执行一个转换操作：将 CSS 文本转换为 StyleSheets。

什么是 StyleSheets 呢 ？为了直观的理解，可以在浏览器控制台输入，

document.styleSheets

StyleSheets 是一颗具有查询和修改功能的样式树，

转换完成后，渲染引擎会接着对所有的属性值进行标准化处理，

标准化完成后会开始计算 DOM Tree 中每个节点的具体样式，这里的计算涉及到 CSS 的层叠规则和继承规则，我们来简单回顾一下 CSS 的层叠和继承。

Cascade

CSS 的全称为层叠样式表（Cascading Style Sheets），层叠是 CSS 最基础的概念之一，

那么什么是层叠呢 ？

层叠是一个定义了如何合并来自多个源的属性值的算法。我们知道一个元素可以拥有来自不同源的 CSS 声明，这里的源可能是，

• 浏览器默认的 UserAgent 样式表
• 通过 link 引用的外部 CSS 文件
• <style>标记内的 CSS
• 元素的 style 属性内嵌的 CSS

当不同的规则都应用于同一个元素时，就会产生冲突（specificity），简单来说，层叠定义了产生冲突时应该应用的规则。如果来源相同，则会根据层叠样式的优先级，层叠顺序决定到底使用哪个值。

你可能发现有些子元素会默认拥有一些样式，这是因为 CSS 属性值继承导致的。

Inheritance

一些 CSS 属性会默认继承其父元素设置的值，这里具体哪些属性会继承很大程度上是由常识决定的。比如像字体大小（font-size），颜色（color）等属性会继承，但是宽度（width）, 边距（margins, padding）, 边框（border） 等属性就不会被继承。

想象一下，如果 border 可以被继承，我们给父元素设置了边框后，每个子元素和后代元素都会获得一个边框——这太糟糕了！🤔

理解了层叠和继承规则后，回到节点样式的计算流程，这个阶段渲染引擎会遵循 CSS 的层叠和继承规则，计算出 DOM 节点中每个元素的具体样式，最后生成 ComputedStyle，我们可以打开浏览器控制台选择 Element 下的 Computed 标签，查看每个节点的计算样式，

完成 DOM Tree 构建和样式计算后，渲染引擎接下来会进入布局阶段。

布局

怎么理解布局呢？

想象一下，我们现在手里有已经构建好的 DOM Tree 和节点元素的计算样式，但是并不知道元素的几何信息，而且 DOM Tree 中有很多元素（比如 head 标签）是不需要渲染的，所以我们还需要计算出 DOM 树中可见元素的几何位置，这个计算过程就是布局。

布局阶段主要有两个任务：创建布局树和布局计算，

HTML 解析器构建的 DOM Tree 中包含了一些 “特殊” 的节点，比如 head 标签，display 属性为 none 的元素等，它们是不需要被渲染到屏幕上的，所以渲染引擎会额外构建一颗只包含可见元素的布局树，在构建布局树，遍历 DOM 节点的同时，会进行节点几何坐标位置的计算，也就是布局计算，最后这些信息会被保存在**布局树（LayoutTree）**中。

有了布局树后，是不是就可以开始绘制了呢？还是不行 🤔，因为页面往往还包含很多复杂的效果，比如我们常见的3D 变换、页面滚动，层叠上下文的 z 轴排序等等，为了更方便的实现这些效果，渲染引擎会进行分层。

分层

什么是分层呢？

如果大家有用过 PhotoShop，Sketch 这类的设计软件，相信对图层这个概念并不陌生，这里渲染引擎会为特定的节点生成图层，最后构建一颗布局树（LayoutTree）对应的图层树（LayerTree），这个过程就是分层。

为了更直观的理解，我们打开浏览器开发者工具（以腾讯首页为例），选择 Layout 标签，

可以看到，浏览器的页面实际上被分成了很多图层，这些图层叠加后合成了最终的页面。前面我们提到渲染引擎只会为特定的节点生成图层，那哪些是特定的节点呢？渲染引擎会为哪些节点创建图层呢？这里涉及到 CSS 的层叠上下文。

The stacking context

什么是层叠上下文 ？这里可以借 BFC 来辅助理解，

如果你还不了解 BFC，可以阅读我之前的文章可能是最好的 BFC 解析了。

我们知道视觉格式化模型中，BFC 定义了块级盒子在文档流中的布局方式，类似的还有 IFC，FFC，GFC，它们都是针对于二维平面的一些上下文，那么对于三维空间而言，元素在 z 轴上应该怎样排列呢？层叠上下文就是对 HTML 元素的一个三维构想，它定义了元素在 z 轴上的排列方式，简单来说，

• 元素在 z 轴上会按**层叠等级（stacking level）**进行层叠
• 具有层叠上下文的元素会优先于普通元素进行层叠
• 同一个层叠上下文中，层叠等级相同的元素，按它们在文档流中出现的顺序进行层叠
• 同一个层叠上下文中，可以通过 z-index 调整元素的层叠等级

哪些元素会创建层叠上下文呢 ？常见的有，

• 文档根元素（html）
• position 为 absolute 或 relative 且 z-index 不为 auto 的元素
• position 为 fixed 或 sticky 的元素
• flex 容器内，z-index 不为 auto 的子元素
• grid 容器内，z-index 不为 auto 的子元素
• opacity 属性值小于 1 的元素
• transform、filter、clip-path、perspective 值不为 none 的元素
• will-change 设定了任一属性

既然这么多元素都会创建层叠上下文，那么他们之间自然也存在层叠顺序，

浮动元素也会参与层叠计算，会被放置在非定位块与定位块之间，具体可以看层叠与浮动。

了解了层叠上下文后，让我们回到图层创建，通常来说，满足下面的条件之一渲染引擎就会为元素创建图层，

1. 拥有层叠上下文属性的元素
2. 需要**裁剪（clip）**的地方
3. 滚动条

解释一下这里的 clip，以下面的这个 DOM 结构为例，

<div class="box">
  <div class="text">
    腾讯是一家世界领先的互联网科技公司，用创新的产品和服务提升全球各地人们的生活品质。腾讯成立于1998年，总部位于**深圳。公司一直秉承科技向善的宗旨。我们的通信和社交服务连接全球逾10亿人，帮助他们与亲友联系，畅享便捷的出行、支付和娱乐生活。腾讯发行多款风靡全球的电子游戏及其他优质数字内容，为全球用户带来丰富的互动娱乐体验。腾讯还提供云计算、广告、金融科技等一系列企业服务，支持合作伙伴实现数字化转型，促进业务发展。
  </div>
</div>

<style>
  .box {
    width: 200px;
    overflow: auto;
  }

  .text {
    white-space: nowrap;
  }
</style>

当内容超出包含块时就会发生裁剪，这个时候渲染引擎会为原始内容单独创建一个图层，

渲染引擎通过分层完成了图层树（LayerTree）的构建，接下来就可以进行图层绘制。

图层绘制

有了 LayerTree 后，图层的绘制就比较简单了，渲染引擎会遍历 LayerTree，为每一个图层生成一个绘制指令列表，

我们也可以打开浏览器开发者工具 “Layout” 标签，选择一个图层的 Profiler 标签，查看具体的绘制指令和绘制过程，

前面我们介绍的 DOM 树构建，样式计算，布局，分层，绘制指令生成等流程基本都在渲染引擎主线程内完成，而实际上的图层绘制操作是由渲染引擎中的合成线程来完成的，绘制指令列表准备好后，主线程会把列表提交给合成线程，然后执行栅格化流程。

栅格化

介绍栅格化之前，我们来简单看一下上述的两个线程之间的交互关系，

思考一下，这里为什么需要提交（Commit）到另一个线程进行绘制呢？🤔

是不是跟我们之前介绍的 HTML 解析器处理数据的流程有点类似，多线程可以加速图层的绘制，合成线程在接受到图层的绘制指令列表后就可以开始栅格化，而不必等待主线程把完整的绘制指令全部生成。

什么是栅格化呢 ？

合成线程接受到指令列表（一个列表就是一个图层）后，首先会将图层划分为图块（tile），一个图块大小一般为 256 x 256 或 512 x 512，然后根据图块来生成位图，生成位图的操作由栅格化线程完成，所以栅格化就是指将图块转换为位图的过程，

你可能会有疑问，为什么需要分块来合成位图，而不是直接绘制图层 ？

我们来解释一下这里的原因。首先视口（viewport）代表屏幕上页面的可视区域，通常情况下合成线程接收到的图层是大于视口的，为了提高渲染效率，我们没有必要一次性把整个图层全部绘制出来，而是可以选择优先绘制视口附近的位图，所以分块是为了加速图层的绘制，分块后，视口附近的位图会被优先合成。

与前面多线程绘制类似，渲染进程也维护了一个栅格化线程池，用来加速栅格化流程，

现代浏览器一般会通过 GPU 来加速生成位图，这种方式就是我们说的快速栅格化。

合成

栅格化完成后，合成线程会生成一个绘制图块的命令（DrawQuad），然后提交给浏览器进程，浏览器进程接收到 DrawQuad 消息后会将命令对应的页面内容绘制到内存中，然后再将内存显示在屏幕上。最后我们来整体看一下渲染流程，

重排 & 重绘

了解了完整的渲染流程后，Web 性能优化里经常涉及到的 重排（Reflow），重绘（Repaint） 等概念就豁然开朗了。

Reflow

当我们 修改了 DOM 元素的几何位置属性 时，浏览器会触发布局，分层，绘制，栅格化等一系列完整的渲染流程，

所以重排的开销是非常大的，我们应该要尽量避免触发重排，具体哪些情况会触发 Reflow 呢？

(这里不建议大家去死记硬背，配合上面的渲染流程理解就好)

1. 改变 DOM 元素的几何属性：比如盒模型相关的 width、height、padding、margin、border，位置信息 left、top 等
2. 改变 DOM 树结构：比如对 DOM 节点的增减、移动等操作
3. 获取一些计算属性的值：比如偏移量，滚动量，窗口等计算属性值，offsetTop、scrollTop、 clientWidth 等

这里我们解释一下为什么获取一些计算属性会导致重排，前面我们介绍布局阶段，在遍历 DOM 树构建 Layout Tree 时，需要计算可见元素的几何位置，现代浏览器大多都是通过队列机制来批量进行布局计算的，而上述的计算属性是具有即时性的，当我们获取计算属性值的时候，队列中可能有会影响这些属性或方法返回值的操作，为了保证这些即时值的正确性，浏览器可能会清空队列来确保返回正确的值。

Repaint

由渲染流程可以看到，Reflow 一定会触发 Repaint，此外，当我们修改元素的样式时，也会触发重绘，

DOM 元素样式改变导致的重绘虽然会跳过布局和分层阶段，但还是会触发图层绘制，栅格化，合成等流程，所以我们也要尽量避免重绘。修改哪些属性会触发 Repaint 呢？常见的有，

• outline, visibility, color、background-color 等

读到这里，你是否会有疑问 🤔️，如果我更改了一个既不需要布局也不需要绘制的属性，会发生什么呢？

答案是浏览器会跳过主线程中布局和绘制等阶段，只执行后续的合成操作，由于合成是在非主线程进行的，所以相对于 Reflow 和 Repaint，渲染效率是比较高的，常见的有 transform、opacity 等。

最后我们来谈一谈性能优化。

从渲染流程的角度分析，性能优化我们可以考虑减少 Reflow 和 Repaint，有以下的一些常见方案，

• 使用 transform 替代 top
• 使用 visibility 替换 display: none，前者只会引起重绘，后者会引发回流（改变了布局
• 避免使用不稳定的 table 布局，一个小改动都会造成整个 table 的重新布局
• 避免设置多层内联样式，CSS 选择符从右往左匹配查找，避免节点层级过多可以提高效率
• 将动画效果应用到 position 属性为 absolute 或 fixed 的元素上，避免影响其他元素的布局
• 避免使用 CSS 表达式，表达式可能会引发重排

参考链接

• LayoutNG
• 浏览器工作原理与实践
• 深入理解CSS中的层叠上下文和层叠顺序
• The stacking context
• Stacking with floated blocks

写在最后

本文首发于我的 博客，才疏学浅，难免有错误，文章有误之处还望不吝指正！

如果有疑问或者发现错误，可以在评论区进行提问和勘误，

如果喜欢或者有所启发，欢迎 star，对作者也是一种鼓励。

（完）

2011年，Google 发布了 Android 4.0，在经历了 Cupcake，Donut，Froyo 等多个甜品名称版本的迭代后，安卓终结了 Symbian（塞班）的霸主地位，迅速占领了手机市场跃居全球第一。同年，腾讯发布了微信开始进军移动互联网，阿里也在 2013 年宣布 ALL IN 无线，随着智能设备的普及和移动互联网时代的到来，响应式布局这个词开始频繁地出现在 Web 设计和开发领域，作为一名优秀的前端攻城狮，要将极致的用户体验和最佳的工程实践作为探索的目标 ): balabala...

所以，响应式布局，要学。不仅要学，我们还要了解它的前世今生，前置知识，实现手段和原理，以便在实际应用时选取合适的技术方案。

阅读完本文，你将 Get 以下知识点，

• 什么是响应式设计？
• 什么是像素，什么DPR？设备像素与CSS像素的区别是什么？
• EM，REM 的计算规则是什么？实际应用中如何选择？
• 什么是视口 viewport，布局视口，视觉视口，理想视口的区别？
• 百分比单位和视口单位的计算规则是什么？
• 弹性盒与网格
• 设备断点与 CSS 媒体查询
• 响应式布局的一些最佳实践

响应式设计

著名的网页设计师 Ehan Marcotte 在 2010 年 5 月的一篇名为《Responsive Web Design》的个人文章中，首次提到了响应式网站设计。文中讲到响应式的概念源自响应式建筑设计，即房间或者空间会根据其内部人群数量和流动而变化。

最近一门新兴的学科“响应式建筑(responsive architecture)”开始在探讨物理空间根据流动于其中的人进行响应的方法。建筑师们通过把嵌入式机器人与可拉伸材料结合的方法，尝试艺术装置和可弯曲、伸缩和扩展的墙体结构，达到根据接近人群的情况变化的效果。运动传感器与气候控制系统相结合，调整围绕人们周围的房间的温度以及环境照明。已经有公司制造了“智能玻璃技术”，当室内人数达到一定的阀值时，它可以自动变为不透明状态，为人们提供更多隐私保护

Web 响应式设计的理念与之非常相似，只不过在这里，

我们需要适配的不是建筑，而是 Web 页面。

我们期望页面可以根据用户的设备环境，比如系统，分辨率，屏幕尺寸等因素，进行自发式调整，提供更适合当前环境的阅读和操作体验，对已有和未来即将出现的新设备有一定的适应能力。

这就是响应式设计的理念。那么是否有对应的方法论呢？

别急，在谈及实现之前，我们需要了解一些前置知识，比如像素。

像素

什么是像素？

像素是图像中最小的单位，一个不可再分割的点，对应到物理设备上（比如计算机屏幕），就是屏幕上的一个光点。我们常说的分辨率就是长和宽上像素点的个数，比如 IPhone X 的分辨率是 1125×2436，代表屏幕横向和纵向分别有 1125 和 2436 个像素点，这里的像素是设备像素（Device Pixels）。

1px ≠1像素

实际开发中，你可能发现 Iphone X 的设计稿是 375×812，WTF？

这里的 375×812 是 CSS 像素，也叫虚拟像素，逻辑像素。为什么我们不使用设备像素呢？

设备像素对应屏幕上的光点，如今的屏幕分辨率已经达到人眼无法区分单个像素的程度了。试想一下，要在 IPhone X 宽不到 7cm 的屏幕上数出 1125 个像素点，想想就让人头疼。所以我们在实际开发中通常使用 CSS 像素，你眼中的 1px 可能对应多个设备像素，比如上面的 IPhone X，

1 css px = 3 * 3 device px // IPhone X 中，1 个 CSS 像素对应 3*3 的 9 个设备像素点

而上面这个比值 3 就是设备像素比（Device Pixel Ratio，简称 DPR）。

DPR 可以在浏览器中通过 JavaScript 代码获取，

window.devicePixelRatio // IPhone X 中等于 3，IPhone 6/7/8 中等于 2，Web 网页为 1

像素是一个固定单位，一般我们不会使用固定像素来做响应式布局，但是你需要了解他。相反，响应式布局里经常会用到相对单位，比如 EM。

EM

EM 相对于元素自身的 font-size，

p {
  font-size: 16px;
  padding: 1em; /* 1em = 16px */
}

如果元素没有显式地设置 font-size，那么 1em 等于多少呢？

这个问题其实跟咱说的 em 没啥关系，这里跟 font-size 的计算规则相关，回顾一下。如果元素没有设置 font-size，会继承父元素的 font-size，如果父元素也没有，会沿着 DOM 树一直向上查找，直到根元素 html，根元素的默认字体大小为 16px。

理解了 EM，REM 就很简单了。

REM

REM = Root EM，顾名思义就是相对于根元素的 EM。所以它的计算规则比较简单，

1 rem 就等于根元素 html 的字体大小，

html {
  font-size: 14px;
}

p {
  font-size: 1rem; /* 1rem = 14px */
}

所以，如果我们改变根元素的字体大小，页面上所有使用 rem 的元素都会被重绘。

EM 和 REM 都是相对单位，我们在做响应式布局的时候应该如何选择呢？

根据两者的特性，

• EM 更适合模块化的页面元素，比如 Web Components
• REM 则更加方便，只需要设置 html 的字体大小，所以 REM 的使用更加广泛一些

实际开发中，设计图的单位是 CSS 像素，我们可以借助一些工具将 px 自动转换为 rem，

下面是一个用 PostCSS 插件在基于 Webpack 构建的项目中自动转换的例子，

var px2rem = require('postcss-px2rem');

module.exports = {
  module: {
    loaders: [
      {
        test: /\.css$/,
        loader: "style-loader!css-loader!postcss-loader"
      }
    ]
  },
  postcss: function() {
    return [px2rem({remUnit: 75})];
  }
}

我们已经有响应式单位了，接下来要怎么让页面支持响应式布局呢？

第一步需要先设置页面的 viewport。

Viewport

著名的 JavaScript 专家 Peter-Paul Koch 曾发表过三篇有关 viewport 的文章，

• 《A tale of two viewports — part one》
• 《A tale of two viewports — part two》
• 《Meta viewport》

建议先看完上述文章。viewport 最先由 Apple 引入，用于解决移动端页面的显示问题，通过一个叫 <meta> 的 DOM 标签，允许我们可以定义视口的各种行为，比如宽度，高度，初始缩放比例等，

<!-- 下面的 meta 定义了 viewport 的宽度为屏幕宽度，单位是 CSS 像素，默认不缩放 -->
<meta name="viewport" content="width=device-width, initial-scale=1">

Peter-Paul Koch 在文章中将移动浏览器的视口分为三种。

layout viewport

为了解决早期 Web 页面在手持设备上的显示问题，Apple 在 IOS Safari 中定义了一个 viewport meta 标签，它可以创建一个虚拟的布局视口（layout viewport），这个视口的分辨率接近于 PC 显示器。这样一来，由于两者的宽度趋近，CSS只需要像在PC上那样渲染页面就行，原有的页面结构也基本不会被破坏。

layout viewport 是一个固定的值，由浏览器厂商设定，

• IOS 和 Android 基本都是 980px
• 黑莓（BlackBerry）和 IE10 是 1024px

可以通过 document 获取布局视口的宽度和高度，

var layoutViewportWidth = document.documentElement.clientWidth
var layoutViewportHeight = document.documentElement.clientHeight

visual viewport

视觉视口（visual viewport）可以简单理解为手持设备物理屏幕的可视区域。也就是你的手机屏幕，所以不同设备的视觉视口可能不同，有了 visual viewport，我们就可以实现网页的拖拽和缩放了，为什么？

因为有了一个承载布局视口的容器。

试想一下，假如我们现在有一台 IPhone 6（375×627），它会在宽为 375px 的 visual viewport 上，创建一个宽为 980px 的 layout viewport，于是用户可以在 visual viewport 中拖动或缩放网页来获得更好的浏览体验。

视觉视口可以通过 window 获取，

var visualViewportWidth = window.innerWidth
var visualViewportHeight = window.innerHeight

idea viewport

我们前面一直在讨论 Web 页面在移动浏览器上的适配问题，但是如果网页本来就是为移动端设计的，这个时候布局视口（layout viewport）反而不太适用了，所以我们还需要另一种布局视口，它的宽度和视觉视口相同，用户不需要缩放和拖动网页就能获得良好的浏览体验，这就是理想视口（idea viewport）。

我们可以通过 meta 设置将布局视口转换为理想视口，

<meta name="viewport" content="width=device-width">

meta

视口可以通过 <meta> 进行设置，viewport 元标签的取值有 6 种，

• width，正整数 | device-width，视口宽度，单位是 CSS 像素，如果等于 device-width，则为理想视口的宽度
• height，正整数 | device-width，视口宽度，单位是 CSS 像素，如果等于 device-height，则为理想视口的高度
• initial-scale，0-10，初始缩放比例，允许小数点
• minimum-scale，0-10，最小缩放比例，必须小于等于 maximum-scale
• maximum-scale，0-10，最大缩放比例，必须大于等于 minimum-scale
• user-scalable，yes/no，是否允许用户缩放页面，默认是 yes

了解了视口之后，让我们回到响应式布局，与视口相关的几个单位有：vw，vh，百分比。

vw，vh，百分比

浏览器对于 vw 和 vh 的支持相对较晚，在 Android 4.4 以下的浏览器中可能没办法使用，下面是来自 Can I use 完整的兼容性统计数据，

新生特性往往逃不过兼容性的大坑，但是这并不妨碍我们了解它。

响应式设计里，vw 和 vh 常被用于布局，因为它们是相对于视口的，

• vw，viewport width，视口宽度，所以 1vw = 1% 视口宽度
• vh，viewport height，视口高度，所以 1vh = 1% 视口高度

以 IPhone X 为例，vw 和 CSS 像素的换算如下，

<!-- 假设我们设置视口为完美视口，这时视口宽度就等于设备宽度，CSS 像素为 375px -->
<meta name="viewport" content="width=device-width, initial-scale=1">

<style>
  p {
    width: 10vw; /* 10vw = 1% * 10 * 375px = 37.5px */
  }
</style>

我们说百分比也可以用来设置元素的宽高，它和 vw，vh 的区别是什么？

这里只需要记住一点，百分比是相对于父元素的宽度和高度计算的。

到这里，相信你已经掌握了响应式布局里常用的所有单位。接下来，我们介绍弹性盒和栅格，它们都不是单位，而是一种新的布局方案。

弹性盒

W3C 在 2009 年提出了弹性盒，截止目前浏览器对 FlexBox 的支持已经相对完善，下面是 Can I use FlexBox 完整的兼容性情况，

关于弹性盒模型推荐阅读这篇文章 A Complete Guide to Flexbox。

假设你已经阅读完并了解了弹性盒模型，响应式布局中我们需要关注 FlexBox 里的两个角色：容器和子元素。

container

指定 display 属性为 flex，就可以将一个元素设置为 FlexBox 容器，我们可以通过定义它的属性，决定子元素的排列方式，属性可选值有 6 种，

• flex-direction，主轴方向，也就是子元素排列的方向
• flex-wrap，子元素能否换行展示及换行方式
• flex-flow，flex-direction 和 flex-wrap 的简写形式
• justify-content，子元素在主轴上的对齐方式
• align-items，子元素在垂直于主轴的交叉轴上的排列方式
• align-content，子元素在多条轴线上的对齐方式

items

子元素也支持 6 个属性可选值，

• order，子元素在主轴上的排列顺序
• flex-grow，子元素的放大比例，默认 0
• flex-shrink，子元素的缩小比例，默认 1
• flex-basis，分配剩余空间时，子元素的默认大小，默认 auto
• flex，flex-grow，flex-shrink，flex-basis 的简写
• align-self，覆盖容器的 align-items 属性

弹性盒模型布局非常灵活，属性值也足够应对大部分复杂的场景，但 FlexBox 基于轴线，只能解决一维场景下的布局，作为补充，W3C 在后续提出了网格布局（CSS Grid Layout），网格将容器再度划分为 “行” 和 “列”，产生单元格，项目（子元素）可以在单元格内组合定位，所以网格可以看作二维布局。

网格

关于网格布局推荐阅读这篇文章 A Complete Guide to Grid。

上述文章非常详细地介绍了网格的一些基本概念（比如容器和项目，行和列，单元格和网格线等），使用姿势，注意事项等。作为新兴的布局方案，使用时你需要考虑兼容性是否满足，

不过在标准之外，我们可能也正通过其他的一些姿势在使用网格。如果你关注时下一些比较热门的 UI 库，比如 Ant Desgin，Material UI，Element Plus 等，它们以栅格系统的方式实现了对网格部分特性的支持。

UI 库对 Grid 的实现中，通常会使用到媒体查询，这也是响应式布局的核心技术。

媒体查询

媒体查询（Media Query）是 CSS3 规范中的一部分，媒体查询提供了简单的判断方法，允许开发者根据不同的设备特征应用不同的样式。响应式布局中，常用的设备特征有，

• min-width，数值，视口宽度大于 min-width 时应用样式
• max-width，数值，视口宽度小于 max-width 时应用样式
• orientation，portrait | landscape，当前设备的方向

选择 min-width 和 max-width 取值的过程，称为设备断点选择，它可能取决于产品设计本身，下面是 百度 Web 生态团队 总结的一套比较具有代表性的设备断点，

/* 很小的设备（手机等，小于 600px） */
@media only screen and (max-width: 600px) { }

/* 比较小的设备（竖屏的平板，屏幕较大的手机等, 大于 600px） */
@media only screen and (min-width: 600px) { }

/* 中型大小设备（横屏的平板, 大于 768px） */
@media only screen and (min-width: 768px) { }

/* 大型设备（电脑, 大于 992px） */
@media only screen and (min-width: 992px) { }

/* 超大型设备（大尺寸电脑屏幕, 大于 1200px） */
@media only screen and (min-width: 1200px) { }

如果你需要对细分屏幕大小进行适配，ResponsiveDesign 站点上的这篇文章 Media queries for common device breakpoints 可能会有所帮助。

响应式文字和图片

相信你已经掌握了响应式布局的所有知识，接下来我们介绍一些最佳实践。

文字

大多数用户阅读都是从左到右，如果一行文字太长，阅读下一行时容易出错，或者用户只会读一行文字的前半部分，而略读后半部分。在上世纪就有研究表明，一行 45 ~ 90 个英文字符是最好的，对于汉字来说，一行文字合理的数量应该是 22 ~ 45 个字符。

此外，字体大小对阅读体验同样重要，基本字体一般不小于 16px，行高大于 1.2em。

p {
  font-size: 16px;
  line-height: 1.2em; /* 1.2em = 19.2px */
}

图片

《高性能网站建设指南》的作者 Steve Souders 曾在 2013 年的一篇 博客 中提到：

我的大部分性能优化工作都集中在 JavaScript 和 CSS 上，从早期的 Move Scripts to the Bottom 和 Put Stylesheets at the Top 规则。为了强调这些规则的重要性，我甚至说过，“JS 和 CSS 是页面上最重要的部分”。几个月后，我意识到这是错误的。图片才是页面上最重要的部分。

图片几乎占了网页流量消耗的 60%，雅虎军规和 Google 都将图片优化作为网页优化不可或缺的环节，除了图片性能优化外，响应式图片无疑带来更好的用户体验。

下面是一些响应式图片的最佳实践，

1.确保图片内容不会超出 viewport

试想一下，如果图片固定大小且超出理想视口的宽度，会发生什么？

内容会溢出视口外，导致出现横向滚动条对不对，这在移动端是非常不好的浏览体验，因为用户往往更习惯上下滚动，而不是左右滚动，所以我们需要确保图片内容不要超出 viewport，可以通过设置元素的最大宽度进行限制，

img {
  max-width: 100%;
}

类似的，相同的规则也应该用于一些其他的嵌入式元素，比如 embed，object，video 等。

2. 图片质量支持响应式

这是一种支持优雅降级的方案，现代浏览器已经支持了 srcset 和 sizes 属性，对于兼容性不好的浏览器，会继续使用默认 src 属性中的图片，所以我们可以放心大胆的使用。

• srcset 支持定义几组图片和对应的尺寸
• sizes 支持一组媒体查询条件

<!-- 响应式图片 -->
<img
  srcset="example-320w.jpg 320w,
          example-480w.jpg 480w,
          example-800w.jpg 800w"
  sizes="(max-width: 320px) 280px,
         (max-width: 480px) 440px,
         800px"
  src="example-800w.jpg" alt="An example image">

如果我们书写了上面代码中的图片，浏览器会根据下面的顺序加载图片，

1. 获取设备视口宽度
2. 从上到下找到第一个为真的媒体查询
3. 获取该条件对应的图片尺寸
4. 加载 srcset 中最接近这个尺寸的图片并显示

除了上述方式外，我们也可以使用 HTML5 标准中的 picture 标签实现类似的效果，

<picture>
  <source media="(max-width: 799px)" srcset="example-480w-portrait.jpg">
  <source media="(min-width: 800px)" srcset="example-800w.jpg">
  <img src="example-800w.jpg" alt="An example img">
</picture>

小结

我们从响应式布局的设计角度出发，介绍了响应式的设计理念，前置知识（像素，DPR，视口等），相对单位（em，rem，百分比，vw，vh等），布局方案（FlexBox，Gird）以及媒体查询等技术，其中不乏很多前辈们的最佳实践，作为开发者我们应该用这些经验，以更好地优化不同尺寸大小设备的用户体验。

参考链接

• Ethan Marcotte, Responsive Web Design
• A tale of two viewports — part one
• A tale of two viewports — part two
• Meta viewport
• PWA应用实战，2.5 响应式布局
• 移动前端第一弹：viewport详解

写在最后

本文首发于我的 博客，才疏学浅，难免有错误，文章有误之处还望不吝指正！

如果有疑问或者发现错误，可以在相应的 issues 进行提问或勘误

如果喜欢或者有所启发，欢迎 star，对作者也是一种鼓励

（完）

什么是作用域

几乎所有编程语言最基本的功能之一，就是能够存储变量的值，并且能够在之后对值进行访问和修改，这套对于变量存储和访问控制的规则被称为作用域。

简单的说，作用域就是一套规则，用于确定在何处以及如何查找变量（标识符）。

JavaScript是一门编译语言

尽管通常将 JavaScript 归类为 “动态” 或 “解释执行” 语言，但事实上它是一门编译语言。

传统编译语言流程通常会经历三个步骤：

1. 词法分析：将代码字符串分解成有意义的代码块，这些代码块被称为 词法单元。例如：

var a = 2; // 通常被分解为：var、a、=、2、; 空格是否会被当做词法单元，取决于空格在这门语言中是否有意义。

2. 语法分析：将词法单元流（数组）转换成 抽象语法树（AST）。例如：

var a = 2; // AST是一个由元素逐级嵌套组成的代表程序语法结构的树，转换成AST后，可能有一个叫做 VariableDeclaration 的顶级节点，三个值分别为 a, =, 2 的被叫做 Identifier，AssignmentExpression，NumericLiteral 的子节点

3. 代码生成：将 AST 转换为可执行代码的过程。

JavaScript 引擎的编译过程相较于传统编译流程要复杂的多。包括但不限于：

• 语法分析和代码生成阶段通过特定的步骤对运行性能进行优化，冗余元素优化
• 在代码执行前的几微秒甚至更短的时间内进行编译，而不是在在构建之前

LHS 和 RHS

引擎查找变量的过程会进行两种类型的查询：LHS查询 和 RHS查询，分别代表赋值操作的左侧和右侧查询。
需要注意的是，这里的 “赋值操作的左侧或右侧” 并不一定意味着就是 “=赋值操作符的左侧或右侧”，因为赋值操作有很多形式，从查询的目的上，可以这样理解：

• LHS查询：查询的目的是对变量进行赋值
• RHS查询：查询的目的是获取变量的值（retrieve his source value）

作用域嵌套与作用域链查找

作用域嵌套：一个块或函数嵌套在另一个块或函数中。
作用域查找：引擎在当前作用域无法找到某个变量时，会去外层嵌套的作用域继续查找，直到找到变量或抵达最外层作用域（全局作用域）为止。

ReferenceError 和 TypeError 异常

ReferenceError 与作用域判别失败有关，例如：

• RHS查询失败时，即查询所有嵌套作用域都找不到变量时
• 严格模式下，LHS查询失败时也会抛出 ReferenceError 异常，而在非严格模式下，会导致隐式地创建一个全局变量

TypeError 代表作用域判别成功了，但是对结果操作非法或不合理，例如：

• 对一个非函数类型的值进行调用
• 引用 null，undefined 中的属性

（完）

BFC

全文约 3000 字，阅读完大约需要 6 分钟，配合示例食用更佳

BFC（Block Formatting Contexts），块级格式化上下文，是 CSS 中一个比较晦涩难懂的概念，下面我们尝试以通俗易懂的语言彻底地理解它。

盒模型

CSS 盒模型描述了通过 文档树中的元素 以及相应的 视觉格式化模型 所生成的矩形盒子。简单来说，盒模型定义了一个 矩形盒子，当我们需要对文档进行布局时，浏览器的渲染引擎就会根据盒模型，将所有元素表示为一个个矩形的盒子，盒子的外观由 CSS 决定。

一个标准的盒子由四个部分组成，由内向外分别为：内容，内边距，边框，外边距：

标准的盒模型中，内容区域的大小可以明确地通过 width，min-width，max-width，height，min-height，max-height 控制，也就是说，通过 CSS 设置的元素宽高只是包含内容区域。你可能听说过 怪异盒模型，这种盒模型最早在 IE 浏览器中出现，也叫 IE盒模型，box-sizing 属性值为 border-box 时，元素会呈现怪异盒模型，此时，元素的宽高包含了内容，内边距和边框。

视觉格式化模型

CSS 视觉格式化模型描述了盒子是怎样生成的，简单来说，它定义了盒子生成的计算规则，通过规则将文档元素转换为一个个盒子。

每一个盒子的布局由尺寸，类型，定位，盒子的子元素或兄弟元素，视口的尺寸和位置等因素决定。

视觉格式化模型的计算，取决于一个矩形的边界，这个矩形边界，就是 包含块( containing block ) ，比如：

<table>
  <tr>
    <td></td>
  </tr>
</table>

上述代码片段中，table 和 tr 都是包含块，table 是 tr 的包含块，同时 tr 又是 td 的包含块。

需要注意的是，盒子不受包含块的限制，当盒子的布局跑到包含块的外面时，就是我们说的溢出（overflow）。

视觉格式化模型定义了盒（Box）的生成，其中的盒主要包括了块级盒,行内盒 和 匿名盒。

块级元素

CSS 属性值 display 为 block，list-item，table 的元素。

块级盒

块级盒具有以下特性：

• CSS 属性值 display 为 block，list-item，table 时，它就是块级元素
• 视觉上，块级盒呈现为竖直排列的块
• 每个块级盒都会参与 BFC 的创建
• 每个块级元素都会至少生成一个块级盒，称为主块级盒；一些元素可能会生成额外的块级盒，比如 <li>，用来存放项目符号

行内级元素

CSS 属性值 display 为 inline，inline-block，inline-table 的元素。

行内盒

行内盒具有以下特性：

• CSS 属性值 display 为 inline，inline-block，inline-table 时，它就是行内级元素
• 视觉上，行内盒与其他行内级元素排列为多行
• 所有的可替换元素（display 值为 inline，如 <img>， <iframe>，<video>，<embed> 等）生成的盒都是行内盒，它们会参与
  IFC（行内格式化上下文） 的创建
• 所有的非可替换行内元素（display 值为 inline-block 或 inline-table）生成的盒称为原子行内级盒，不参与 IFC 创建

匿名盒

匿名盒指不能被 CSS 选择器选中的盒子，比如：

<div>
  匿名盒1
  <p>块盒</p>
  匿名盒2
</div>

上述代码片段中，div 元素和 p 元素都会生成一个块级盒，p 元素的前后会生成两个匿名盒。

匿名盒所有可继承的 CSS 属性值都为 inherit，所有不可继承的 CSS 属性值都为 initial。

定位方案

CSS 页面布局技术允许我们拾取网页中的元素，并且控制它们相对正常布局流（普通流）、周边元素、父容器或者主视口/窗口的位置。技术布局从宏观上来说是受定位方案影响，定位方案包括普通流（Normal Flow，也叫常规流，正常布局流），浮动（Float），定位技术（Position）。

普通流

浏览器默认的 HTML 布局方式，此时浏览器不对页面做任何布局控制，

当 position 为 static 或 relative，并且 float 为 none 时会触发普通流，普通流有以下特性：

• 普通流中，所有的盒一个接一个排列
• BFC 中，盒子会竖着排列
• IFC 中，盒子会横着排列
• 静态定位中（position 为 static），盒的位置就是普通流里布局的位置
• 相对定位中（position 为 relative），盒的偏移位置由 top，right，bottom，left 定义，
  即使有偏移，仍然保留原有的位置，其它普通流不能占用这个位置

浮动

• 浮动定位中，盒称为浮动盒（Floating Box）
• 盒位于当前行的开头或结尾
• 普通流会环绕在浮动盒周围，除非设置 clear 属性

定位技术

定位技术允许我们将一个元素从它在页面的原始位置准确地移动到另外一个位置，有四种：静态定位，相对定位，绝对定位，固定定位。

静态定位

默认的定位方式（position 为 static），此时元素处于普通流中。

相对定位

相对定位通常用来对布局进行微调，position 为 relative 时，元素使用相对定位，此时可以通过 top，right，bottom，left 属性对元素的位置进行微调，设置其相对于自身的偏移量。

绝对定位

绝对定位方案中，盒会从普通流中移除，不会影响其他普通流的布局。绝对定位具有以下特点：

• 元素的属性 position 为 absolute 或 fixed 时，它是绝对定位元素
• 它的定位相对于它的包含块，可以通过 top，right，bottom，left 属性对元素的位置进行微调，设置其相对于包含块的偏移量
• position 为 absolute 的元素，其定位将相对于最近的一个 relative、fixed 或 absolute 的父元素，如果没有则相对于 body

固定定位

与绝对定位方案类似，唯一的区别在于，它的包含块是浏览器视窗。

块级格式化上下文

通过对 CSS 盒模型，定位，布局等知识的了解，我们知道 BFC 这个概念其实来自于视觉格式化模型，

它是页面 CSS 视觉渲染的一部分，用于决定块级盒的布局及浮动相互影响范围的一个区域。

BFC 的创建

以下元素会创建 BFC：

• 根元素（<html>）
• 浮动元素（float 不为 none）
• 绝对定位元素（position 为 absolute 或 fixed）
• 表格的标题和单元格（display 为 table-caption，table-cell）
• 匿名表格单元格元素（display 为 table 或 inline-table）
• 行内块元素（display 为 inline-block）
• overflow 的值不为 visible 的元素
• 弹性元素（display 为 flex 或 inline-flex 的元素的直接子元素）
• 网格元素（display 为 grid 或 inline-grid 的元素的直接子元素）

以上是 CSS2.1 规范定义的 BFC 触发方式，在最新的 CSS3 规范中，弹性元素和网格元素会创建 F(Flex)FC 和 G(Grid)FC。

BFC 的范围

A block formatting context contains everything inside of the element creating it, that is not also inside a descendant element that creates a new block formatting context.

直译过来就是，BFC 包含创建它的元素的所有子元素，但是不包括创建了新的 BFC 的子元素的内部元素。

简单来说，子元素如果又创建了一个新的 BFC，那么它里面的内容就不属于上一个 BFC 了，这体现了 BFC 隔离 的**，我们还是以 table 为例：

<table>
  <tr>
    <td></td>
  </tr>
</table>

假设 table 元素创建的 BFC 我们记为 BFC_table，tr 元素创建的 BFC 记为 BFC_tr，根据规则，两个 BFC 的范围分别为：

• BFC_tr：td 元素
• BFC_table：只有 tr 元素，不包括 tr 里的 td 元素

也就是所说，一个元素不能同时存在于两个 BFC 中。

BFC 的特性

BFC 除了会创建一个隔离的空间外，还具有以下特性，附 CodePen 示例链接地址，可结合示例进行理解：

• BFC 内部的块级盒会在垂直方向上一个接一个排列 ①
• 同一个 BFC 下的相邻块级元素可能发生外边距折叠，创建新的 BFC 可以避免的外边距折叠 ②
• 每个元素的外边距盒（margin box）的左边与包含块边框盒（border box）的左边相接触（从右向左的格式化，则相反），即使存在浮动也是如此 ③
• 浮动盒的区域不会和 BFC 重叠 ④
• 计算 BFC 的高度时，浮动元素也会参与计算 ⑤

BFC 的应用

自适应多栏布局

利用 特性③ 和 特性④，中间栏创建 BFC，左右栏宽度固定后浮动。由于盒子的 margin box 的左边和包含块 border box 的左边相接触，同时浮动盒的区域不会和 BFC 重叠，所以中间栏的宽度会自适应，示例。

防止外边距折叠

利用 特性②，创建新的 BFC ，让相邻的块级盒位于不同 BFC 下可以防止外边距折叠，示例。

清除浮动

利用 特性⑤，BFC 内部的浮动元素也会参与高度计算，可以清除 BFC 内部的浮动，示例。

写在最后

本文首发于我的 博客，才疏学浅，难免有错误，文章有误之处还望不吝指正！

如果有疑问或者发现错误，可以在评论区进行提问和勘误，

如果喜欢或者有所启发，欢迎 star，对作者也是一种鼓励。

（完）

从 React设计理念 和 React架构 中我们知道，在 v15 版本 Reconciler 采用递归的方式更新虚拟 DOM，这会导致什么问题呢？

由于递归过程是不能中断的，如果组件树的层级很深，递归更新时间超过了一帧，用户交互就会卡顿，

为了解决这个问题，v16 将递归的无法中断的更新重构为异步的可中断更新。

由于曾经用于递归的虚拟 DOM 数据结构已经无法满足需要，于是全新的 Fiber 架构应运而生。

那到底什么是 Fiber ？Fiber 只是一个架构吗？为什么说 Fiber 同时也作为静态的数据结构和动态的工作单元？

什么是 Fiber

React 团队的核心成员 Andrew Clark 在 2016 年的一次演讲 What's Next for React — ReactNext 2016 中第一次提到 Fiber，

这次演讲后来被整理为一篇介绍 React Fiber Architecture ，Fiber 作为 React 新版本的一种核心架构被正式提出。

A description of React's new core algorithm, React Fiber

在实现上，Fiber 对应了 DOM 树中的一个节点，我们可以从以下三个角度解读 Fiber：架构、数据结构和工作单元。

Fiber Architecture

作为架构而言，v15 的 Reconciler 采用递归的方式实现，数据保存在递归调用栈中，叫做 Stack Reconciler，

v16 的 Reconciler 基于 Fiber 节点实现，被称为 Fiber Reconciler，支持可中断的异步更新，任务支持切片，

Fiber Data Structure

Fiber 也是一种数据结构，我们可以从源码找到 Fiber节点的属性定义（关键的属性已经添加了注释，可以结合注释来看），

function FiberNode(
  this: $FlowFixMe,
  tag: WorkTag,
  pendingProps: mixed,
  key: null | string,
  mode: TypeOfMode
) {
  // Fiber 对应组件的类型 Function/Class/Host...
  this.tag = tag;
  // Diffing 需要的 key 属性
  this.key = key;
  // 大部分情况同 type，某些情况不同，比如 FunctionComponent 使用 React.memo 包裹
  this.elementType = null;
  // 对于 FunctionComponent，指函数本身，对于 ClassComponent，指 class，对于 HostComponent，指 DOM 节点的 tagName
  this.type = null;
  // Fiber 对应的真实 DOM 节点
  this.stateNode = null;

  // 指向父级 Fiber 节点
  this.return = null;
  // 指向子 Fiber 节点
  this.child = null;
  // 指向兄弟 Fiber 节点
  this.sibling = null;
  this.index = 0;

  this.ref = null;
  this.refCleanup = null;

  // 保存本次更新的状态改变相关信息
  this.pendingProps = pendingProps;
  this.memoizedProps = null;
  this.updateQueue = null;
  this.memoizedState = null;
  this.dependencies = null;

  this.mode = mode;

  // 保存本次更新会造成的DOM操作
  this.flags = NoFlags;
  this.subtreeFlags = NoFlags;
  this.deletions = null;

  // 调度优先级相关
  this.lanes = NoLanes;
  this.childLanes = NoLanes;

  // 指向该 Fiber 在另一次更新时对应的 Fiber
  this.alternate = null;
}

Fiber 作为静态的数据结构，保存了组件的 tag、key、type、stateNode 等相关信息。

Fiber Work Unit

Fiber 同时也是一个动态的工作单元，从 FiberNode 的定义中我们发现，

Fiber 保存了本次更新的状态改变相关信息，会造成的 DOM 操作（副作用 effect）以及调度优先级相关的信息。

Fiber 之所以可以作为 Work Unit，还与其工作原理有关，在正式介绍之前，我们先来了解一个 DOM 更新的技术：双缓存。

双缓存

双缓存（Double Buffering）是一个广泛应用于网络传输，图形渲染和内存读取优化等场景的技术，

我们以大家比较熟悉的渲染场景为例，假设我们需要用 canvas 绘制一个动画，然后显示到屏幕上，通常我们会在显示缓存区进行绘制，绘制每一帧前都会调用 ctx.clearRect 清除上一帧的画面，如果当前帧画面计算量比较大，导致清除上一帧画面到绘制当前帧画面之间有较长间隙，就会出现白屏，

为了解决这个问题，我们可以在自定义缓存区中绘制当前帧动画，绘制完毕后直接用当前帧替换上一帧画面，这样就可以省去了两帧替换间的计算时间，避免白屏到出现画面的闪烁。

这种在内存中构建并直接替换的技术就是双缓存。

React Fiber 就是利用了双缓存技术来完成 “Fiber树” 的创建和替换，从而提高性能，具体是怎么实现的呢？

Alternate

React 中最多会同时存在两颗 Fiber 树，每次状态更新都会产生新的 workInProgress Fiber 树

• currentFiber，当前屏幕上显示内容对应的 Fiber 树
• workInProgressFiber，正在内存中构建的 Fiber 树

它们之间通过 alternate 属性连接，

currentFiber.alternate === workInProgressFiber; // true
workInProgressFiber.alternate === currentFiber; // true

React 应用的根节点通过使 current 指针在不同 Fiber 树的 rootFiber 间切换来完成 currentFiber 树指向的切换，

我们可以以组件 mount/update 的流程为例，了解 Fiber 树的构建和更新过程，考虑如下例子，

function App() {
  const [num, add] = useState(0);
  return (
    <p onClick={() => add(num + 1)}>{num}</p>
  )
}

ReactDOM.render(<App/>, document.getElementById('root'));

mount

首次执行 ReactDOM.render 会创建 fiberRoot 和 rootFiber ，其中，

• fiberRoot 是整个应用的根节点
• rootFiber 是<App/> 所在组件树的根节点

此时，fiberRoot 的 current 指针指向当前的 Fiber 树，

接着会进入 render 阶段，React 会解析组件返回的 JSX 并在内存中依次创建 Fiber 节点连接成 Fiber 树，内存中完成构建的 Fiber 树叫做 workInProgress Fiber 树，这个过程中 React 会尝试复用 current Fiber 树中已有的 Fiber 节点内的属性，

然后是 commit 阶段，右侧已经构建完的 Fiber 树会替换掉当前的 Fiber 树，渲染到页面，

update

我们来接着讨论更新阶段，假设我们点击 p 节点触发状态改变，num 的值从 0 变为 1，

每一次更新 React 都会开启一次新的 render 阶段并构建一棵新的 workInProgress Fiber 树，

和 mount 时一样，workInProgressFiber 的创建会尝试复用 currentFiber 节点，这个过程就是 Diffing 算法，

render 阶段完成后接着会进入 commit 阶段，workInProgressFiber 替换 currentFiber 完成渲染，

小结

Fiber 作为 React 新版本的核心架构，在实现可中断的异步更新中至关重要，

通过上述介绍，我们了解到 Fiber 不止作为架构，同时也是一个静态的数据结构和一个动态的工作单元，

Fiber 架构的核心是双缓存技术，其创建和更新的过程伴随着 DOM 的更新。

参考链接

• Lin Clark - A Cartoon Intro to Fiber - React Conf 2017
• React Fiber Architecture
• React技术揭秘
• Wikipedia, Multiple buffering

写在最后

本文首发于我的 博客，才疏学浅，难免有错误，文章有误之处还望不吝指正！

如果有疑问或者发现错误，可以在评论区进行提问和勘误，

如果喜欢或者有所启发，欢迎 star，对作者也是一种鼓励。

React 作为一个优秀的前端框架，在架构上融合了数据驱动视图、组件化、函数式编程、面向对象、Fiber 等经典设计哲学，在底层技术选型上涉及了 JSX、虚拟 DOM 等经典解决方案，在周边生态上至少涵盖了状态管理和前端路由两大领域的最佳实践，此外，它还自建了状态管理机制与事件系统，创造性地在前端框架中引入了 Hooks **...React 十年如一日的稳定输出背后，有太多值得我们去吸收和借鉴的东西。

最近在读修言的《深入浅出搞定 React》，笔者的文笔和文风都非常有趣，又不乏干货，重读几遍后仍收获满满，这个系列是基于上述读物的笔记和自己一些思考，整理出来后分享给大家。本系列大概有 15 篇，如果觉得有帮助可以给个 star，如果发现问题请不吝在对应文章的评论区指正。

文章列表

• React进阶系列之JSX
• React进阶系列之生命周期
• React进阶系列之数据流
• React进阶系列之Hooks设计动机
• React进阶系列之Why Hooks?

前端模块化中，我们经常使用相对路径和第三方类库名的方式来引入模块：

import foo from './foo.js' // 相对路径
import bar from '@/src/bar.js' // 相对路径，alias也是相对路径
import react from 'react' // 第三方类库名称

当然，还可以通过绝对路径引入模块，但是这种方式不推荐也不常用，我们暂不讨论。

webpack 中有一个专门的模块 enhanced-resolve 来处理依赖模块路径的解析，从这个模块名称我们大致可以猜到是基于 Node.js 的，没错，其实就是 Node.js 模块解析的增强版，支持更多的自定义配置。

webpack的模块解析规则分为三种，相对路径，绝对路径和模块名。

绝对路径

我们先从最简单但是不常用的绝对路径说起，绝对路径通常是从盘符开始，像下面这样：

C:\hello-world\index.js

webpack处理绝对路径的解析规则就是直接查找对应路径下的模块。

相对路径

相对路径的解析规则略微复杂，大致分为下面几个步骤：

1. 首先查找当前模块的路径下是否有匹配的文件或文件夹
2. 如果文件名匹配直接加载模块
3. 如果是文件夹，查找文件夹下面的package.json文件
4. 如果有package.json文件，查找main字段指定的文件
5. 如果没有package.json文件或者没有main字段，查找index.js文件

模块名

如果是模块名称，webpack会逐次查找当前目录下，父级目录及以上的目录下的node_modules文件夹，如果找到node_modules文件夹，会去node_modules文件夹中查找指定的模块。

相关推荐

• 深入Webpack(二): resolve

勘误与提问

如果有疑问或者发现错误，可以在相应的 issues 进行提问或勘误

如果喜欢或者有所启发，欢迎 star，对作者也是一种鼓励

（完）

惯性滚动（momentum-based scrolling）一词我们并不陌生，从浏览器到桌面应用，再到移动 App，几乎所有涉及到滚动的一些场景，都能见到它的身影。惯性滚动最早出现在 IOS 系统中，当用户的滑动手势结束，手指离开屏幕后，页面滚动不会马上停止而是会根据滑动时的速度，滑动手势的强烈程度，继续保持一段时间的滚动效果，当页面滚动到顶部/底部时，还有可能触发 “惯性回弹” 的效果，

-webkit-overflow-scrolling

IOS 系统的 Safari 浏览器最早支持了这一特性，我们可以为元素设置 -webkit-overflow-scrolling: touch 属性，让其支持惯性滚动，在 Safira 13+ 的版本 中，所有可滚动的框架或设置 overflow 滚动的元素默认支持了惯性滚动，

.view {
  -webkit-overflow-scrolling: touch;
}

遗憾的是在兼容性方面，除了 safari 外其他浏览器基本全军覆没，

此外，-webkit-overflow-scrolling 在 safari 上本身也存在一些问题。

但是你可能发现很多流行的 UI 库，App 的交互都实现了惯性滚动的效果，那么在不支持 -webkit-overflow-scrolling 属性的浏览器上，我们要怎样实现 momentum-based scrolling 的动效呢？

首先我们对惯性滚动做一个简单的建模。

建模

在描述惯性滚动之前，我们先来回顾一下，什么是惯性？牛顿第一定律 表明，一切物体在没有受到外力的作用时，总是保持静止状态或匀速直线运动状态，所以惯性是物体的一种固有属性。那什么是惯性滚动呢？

我们可以把惯性滚动描述为，物体在受到外力的作用下，运动状态改变，但由于物体本身具有惯性，所以会保持原有的运动状态继续运动的过程。试想一下，如果在足够光滑的表面上，物体将一直保持惯性滚动，但实际场景中，物体往往会因为摩擦力，空气阻力等，速度变得越来越慢直到静止。

为了方面理解，这里我们可以用大家熟悉的 滑块模型 的几个阶段来近似描述这一过程，

第一阶段，滑动滑块（F拉 > F摩）使其从静止开始做加速运动，

由于在实际的场景中，我们一般关注的是用户即将释放手指前的一小阶段，而非滚动的全流程（全流程意义不大），所以这一瞬间阶段也可以简单模拟为滑块均衡受力做 匀加速运动。

第二阶段，释放滑块使其在只受摩擦力的作用下继续滑动，

这一阶段，滑块拥有一个初速度，且只受到反向的摩擦力做 匀减速运动。但在实际的场景中，我们一般会将惯性滚动的元素放置在一个容器内，这时滑块可能会滚动到容器边界触发回弹，所以我们还需要考虑回弹过程。

我们可以借助一根弹簧来近似模拟回弹的过程，假设滑块左端与一根弹簧连接，弹簧另一端固定在墙体上。当滑块惯性滚动到达临界点（弹簧即将发生形变）时，滑块会拉动弹簧使其发生形变，此时滑块受到弹簧的反向拉力作减速运动直到停止，

第三阶段，滑块受到弹簧的反向拉力和摩擦力做变减速运动，

此阶段滑块受到弹簧拉力和摩擦力的共同作用，加速度越来越大，最后速度变为 0，此时弹簧的形变量最大。最后弹簧恢复形变，拉动滑块做反向的变加速和变减速运动，

第四阶段，弹簧拉动滑块做变加速和变减速运动，

基于上面的模型，我们可以试着来实现惯性滚动和惯性回弹（这里以小程序代码为例）。

惯性滚动

初始化两个页面元素，容器 (container) 和滑块 (slider)，

<!-- wxml -->
<wxs module="gesture" src="./index.wxs"></wxs>
<view class="container">
  <view
    class="slider"
    bindtouchstart="{{gesture.touchstart}}"
    bindtouchmove="{{gesture.touchmove}}"
    bindtouchend="{{gesture.touchend}}"
    bindtouchcancle="{{gesture.touchcancel}}"
  ></view>
</view>

对于模型的第一阶段，滑块做匀加速运动，假设滑块的滑动距离为 s1，滑动的时间为 t1，手指离开时滑块的速度为 v1，根据 位移公式，

可以计算出惯性滚动的初始速度，

对于第二阶段，滑块受反向摩擦力做匀减速运动，末速度为 0m/s，假设滑块加速度为 a，滑动时间为 t2，滑动距离为 s2，结合加速度公式和位移公式，

可以计算出滑块滑动的距离，

由于匀减速的减速度为负（a < 0），这里我们不妨设一个加速度常量 A，使其满足 A = -2a 的关系，那么滑动距离，

但在实际应用中，我们发现 v1 算平方会导致最终计算计算出的惯性滚动距离太大（即对滚动手势的强度感应过于灵敏），这里我们不妨把平方去掉，

所以，求滑块的滑动距离时，只需要记录用户滚动的距离 s1 和滚动时长 t1，然后设置一个合适的加速度常量 A 即可。经过大量测试，这里加速度常量 A 的取值建议在 0.002 ~ 0.003,

var translateY = 0; // Y 轴的偏移距离
var startTime = 0; // 触发惯性滚动的起始时间
var startY = 0; // 触发惯性滚动的 Y 轴起始坐标
var deceleration = 0.002; // 惯性滚动的加速度常量

function touchstart(e) {
  startTime = e.timeStamp;
  startY = e.detail.changedTouches[0].pageY;
}

需要注意的是，对于实际场景的惯性滚动来说，我们这里讨论的滚动距离和时长是指能够作用于惯性滚动范围内的距离和时长，而非用户滚动页面元素的整个流程，比如下面的这个例子，

用户首先以非常缓慢的速度使元素滚动了一段距离，随后在很短的时间内继续滚动页面然后释放手指，这种情况下我们需要的滚动距离和时长应该是后半段用户在短时间内触发惯性滚动的手指移动距离和停留时长，换成代码描述就是，在 touchmove 事件里，如果用户在滑动的过程中，停留时长大于阈值，说明有可能会触发惯性滚动，此时我们需要更新惯性滚动的起始时间和位置，

function touchmove(e) {
  // ...
  if (e.timeStamp - startTime > momentumTimeThreshold) {
    startTime = e.timestamp;
    startY = e.detail.changedTouches[0].pageY;
  }
}

为什么说是有可能触发惯性滑动呢？因为我们还需要判断用户滚动的距离，所以在触摸时间结束后，惯性滚动的触发条件是，停留时长 duration 小于某个阈值并且最小位移距离 s1 大于某个阈值。经过测试，这里的停留时长阈值设置为 200ms ～ 300ms，最小位移距离设置为 10px ~ 20px 较为合理，

var momentumTimeThreshold = 300; // 触发惯性滚动的最大时长，ms
var momentumYThreshold = 15; // 触发惯性滚动的最小位移距离，ms

function touchend(e) {
  var endY = e.detail.changedTouches[0].pageY;
  var duration = e.timeStamp - startTime;
  var s1 = endY - startY;
  if (duration < momentumTimeThreshold && Math.abs(s1) > momentumYThreshold) {
    // 触发惯性滑动...
  }
}

接下来我们来分析惯性滚动后可能会触发的第三，四阶段的回弹过程。

惯性回弹

对于模型的第三阶段，滑块受弹簧反向拉力和摩擦力的共同作用做变减速运动，滑块的加速度越来越大，速度降为 0m/s 的时间会很短，我们可以用一个近似的缓动曲线去描述这一过程，假设这里滑块触发了第三阶段后的速度曲线就是 ease-out，滚动时长为 t，

我们需要计算滑块触碰容器边界后的滚动距离，也就是曲线在 0 ~ t 时间范围内与 x 轴围成的面积 s，用积分表示为，

我们把 ease-out 函数 $ f(t) = -t^2 + 2t $ 带入，

根据 牛顿-莱布尼茨公式，

要计算上述积分，我们需要找到 ease-out 函数的原函数 F，使函数 F 满足，

原则上，只要我们定义了滑块的滚动时长和滚动曲线，就可以计算出滚动的距离，这里的滚动距离也是模型第四阶段的回弹距离，但是在实际应用中，这里的滚动曲线定义和原函数的计算是很复杂的，我们可以考虑把上述模型做适当的简化。

由于滑块在第三阶段的加速度是大于匀减速运动情况下的加速度的，

所以第三阶段滑块触碰边界后的滚动距离一定小于匀减速运动情况下的滚动距离，假设滑块第三阶段滚动距离为 s3，容器的边界值为 boundY，前面我们分析了滑块在匀速运动情况下的总滑动距离为 s2，那么一定满足，

s3 < s2 - boundY

这里我们不妨设一个回弹的阻力常量 B，使其满足，

s3 = (s2 - boundY) / B

经过测试，这里的阻力常量 B 的取值在 10 ~ 12 较为合适。到此，我们已经完成了对上述模型一些关键指标（滚动距离，滚动时长，启停条件等）的一个简单的实现，接下来我们来关注一下模型各阶段滑块的滚动效果（缓动效果），也就是速度曲线。

缓动

现实生活中，物体并不是突然启动或者停止，或者一直保持匀速移动，在动效设计里，我们经常用缓动来描述物体的变速运动，让整个运动过程更加自然，CSS 提供了过渡和动画配合实现缓动动效。这里缓动我们需要关注两个重要的指标，缓动函数（easing function）和 缓动时长。

我们可以用贝塞尔曲线来描述动画进程随时间的变化关系，接下来我们借助一些开源的在线绘制贝塞尔曲线的工具，如 cubic-bezier，对上述的滑块模型做一个简单的分析，

对于模型的第一、二阶段，也就是触发了惯性滚动，滚动结束后还未到达容器边界的情况，滑块先做加速运动，到达最大速度后触发惯性滚动，最后做减速运动直到停止，

整个过程的缓动曲线可以描述为 cubic-bezier(0, 0.5, 0.2, 1)，

这里的缓动时长我们可以需要考虑根据惯性滚动的距离动态设置，比如定义强、弱两种惯性时长，然后给定一个强弱惯性的分割值，

var inertialThreshold = 100; // 强弱惯性分割值

.weekInertial {
  transition: transform cubic-bezier(0, 0.5, 0.2, 1) 1.5s;
}

.strongInertial {
  transition: transform cubic-bezier(0, 0.5, 0.2, 1) 3.5s;
}

对于模型的的第一、二、三阶段，滑块首先触发了惯性滚动，但惯性滚动的距离超过了容器的边界，超过边界后迅速减速直到最后停止，

整个过程的缓动曲线可以描述为 cubic-bezier(0.25, 0.46, 0.45, 0.94)，

这里需要注意的是，容器除了要设定边界值外，还需要设置允许超过的最大边界，当我们计算出的滑块惯性滚动的距离过大（即用户的滑动手势过于强烈），大到已经超过允许的最大边界时，我们需要重置滚动的距离为最大边界。

对于模型的第四阶段，滑块从超过边界的某个值返回边界，类似于触发了回弹，

这个过程的缓动曲线可以描述为 cubic-bezier(0.16, 0.5, 0.4, 1) ，

这里回弹的触发方式有两种，用户滑动超过边界后回弹 和 惯性滚动超过边界后回弹。前者是比较好监听的，可以在用户触摸事件结束时去做处理，但是对于惯性滚动超过边界后的回弹，我们要怎么知道惯性滚动是否结束了呢？

回弹一定是在惯性滚动之后（滚动我们设置了动画），可以通过 监听缓动动画的结束事件，

function transitionend() {
  var overBounce = translateY > minY || translateY < maxY;
  if (overBounce) {
    if (translateY > minY) translateY = minY;
    if (translateY < maxY) translateY = maxY;
    ins.addClass('rebound');
    setStyle();
  }
}

此外，当惯性滚动未结束，或者正处于回弹过程，用户再次触碰元素时，我们应该要暂停缓动，如何让缓动停止呢？回想一下这里缓动我们是通过 CSS 样式去设置的，那么一个思路就是在用户再次触碰元素的瞬间，获取元素当前的计算样式，然后拿到我们需要的偏移量值进行重设，

function touchstart(e, instance) {
  // ...
  stop();
  // ...
}

function stop() {
  var computedStyle = ins.getComputedStyle(['transform']);
  var matrix = computedStyle.transform;
  var offsetY = +matrix.split(')')[0].split(', ')[5];
  if (matrix.indexOf('matrix') !== -1 && offsetY) {
    translateY = offsetY;
    setStyle();
  }
}

以上是小程序端惯性滚动的一个简单实现，我们也可以用类似的思路去实现其他平台的惯性滚动，可以点击基于上述思路的一个可运行的 代码片段，在微信开发者工具中打开体验。

参考链接

• The Basics of easing
• Choosing the right easing
• 前端也要懂物理 —— 惯性滚动篇
• Understand the mathematics of Bézier curves
• 匀变速直线运动

写在最后

本文首发于我的 博客，才疏学浅，难免有错误，文章有误之处还望不吝指正！

如果有疑问或者发现错误，可以在评论区进行提问和勘误，

如果喜欢或者有所启发，欢迎 star，对作者也是一种鼓励。

（完）

保证一个类仅有一个实例，并提供一个访问它的全局访问点，这样的模式就叫做 单例模式。

实现思路

一般情况下，当我们创建了一个类（本质是构造函数）后，

可以通过new关键字调用构造函数进而生成任意多的实例对象:

class SingleDog {
  show() {
    console.log('I am a single dog.');
  }
}

const s1 = new SingleDog();
const s2 = new SingleDog();

s1 === s2; // false

但是很明显，实例对象之间是相互独立的，各占一块内存空间，而单例模式想要做到的是，不管我们尝试去创建多少次，它都只会给你返回第一次所创建的唯一的那个实例。

要做到这一点，就需要构造函数具备判断自己是否已经创建过一个实例的能力：

class SingleDog {
  show() {
    console.log('I am a single dog.');
  }

  static getInstance() {
    if (!SingleDog.instance) {
      SingleDog.instance = new SingleDog();
    }
    return SingleDog.instance;
  }
}

const s1 = SingleDog.getInstance();
const s2 = SingleDog.getInstance();

s1 === s2; // true

也可以通过闭包实现：

function SingleDog() {}

SingleDog.prototype.show = function() {
  console.log('I am a signle dog.');
};

SingleDog.getInstance = (function() {
  let instance = null;
  return function() {
    if (!instance) {
      instance = new SingleDog();
    }
    return instance;
  };
})();

const s1 = SingleDog.getInstance();
const s2 = SingleDog.getInstance();

s1 === s2; // true

在 getInstance 方法的判断和拦截下，

不管调用多少次，SingleDog 都只会给我们返回一个唯一的实例。

Vuex的数据管理哲学

基于 Flux 的架构中，应用最广泛的要数 Redux 和 Vuex，无论是 Redux 还是 Vuex，它们都实现了一个全局的 Store 用于存储应用的所有状态，而 Store 的实现，正是单例模式的典型应用，以 Vuex 为例：

Vuex 使用单一状态树，用一个对象就包含了全部的应用层级状态。至此它便作为一个 “唯一数据源 (SSOT)” 而存在。这也意味着，每个应用将仅仅包含一个 store 实例。单一状态树让我们能够直接地定位任一特定的状态片段，在调试的过程中也能轻易地取得整个当前应用状态的快照。 -- Vuex官方文档

在 Vue 中，组件之间是独立的，组件间通信最常用的办法是 props,但当组件非常多、组件间关系复杂、且嵌套层级很深的时候，这种原始的通信方式会使我们的逻辑变得复杂难以维护。这时最好的做法是将共享的数据抽出来、放在全局，供组件们按照一定的的规则去存取数据，保证状态以一种可预测的方式发生变化。

于是便有了 Vuex，而这个用来存放共享数据的唯一数据源，就是 Store。

确保Store的唯一性

项目中引入 Vuex 的方式为：

Vue.use(Vuex)

new Vue({ /* config here */ })

通过调用 Vue.use() 方法，安装 Vuex 插件，它本质上是一个对象，内部实现了 install 方法：

let Vue
...

export function install (_Vue) {
  if (Vue && _Vue === Vue) {
    if (process.env.NODE_ENV !== 'production') {
      console.error(
        '[vuex] already installed. Vue.use(Vuex) should be called only once.'
      )
    }
    return
  }
  Vue = _Vue
  applyMixin(Vue)
}

install 方法会在插件安装时被调用，从而把 Store 注入到 Vue 实例里面。通过判断传入的 Vue 实例对象是否已经被 install 过 Vuex 插件，如果没有则为 Vue 实例对象 install 一个唯一的 Vuex，再将 Vuex 的初始化逻辑写入。通过这种方式，可以保证一个 Vue 实例（即一个 Vue 应用）只会被 install 一次 Vuex 插件，所以每个 Vue 实例只会拥有一个全局的 Store。

应用

实现一个 Storage，使得该对象为单例，基于 localStorage 实现方法 getItem, setItem.

构造函数版本：

class Storage {
  constructor() {
    if (Storage.instance) {
      return Storage.instance;
    }
    Storage.instance = this;
    return this;
  }

  getItem(key) {
    return window.localStorage.getItem(key);
  }

  setItem(key, value) {
    return window.localStorage.setItem(key, value);
  }
}

const s1 = new Storage();
const s2 = new Storage();

s1 === s2; // true
s1.setItem('storage', 'I am a single object.');
s2.getItem('storage'); // I am a single object.

静态方法版本：

class Storage {
  static getInstance() {
    if (!Storage.instance) {
      Storage.instance = new Storage();
    }
    return Storage.instance;
  }

  getItem(key) {
    return window.localStorage.getItem(key);
  }

  setItem(key, value) {
    return window.localStorage.setItem(key, value);
  }
}

const s1 = Storage.getInstance();
const s2 = Storage.getInstance();

s1 === s2; // true
s1.setItem('storage', 'I am a single object.');
s2.getItem('storage'); // I am a single object.

闭包版本：

function Storage() {}

Storage.getInstance = (function() {
  let instance;
  return function() {
    if (!instance) {
      instance = new Storage();
    }
    return instance;
  };
})();

Storage.prototype.getItem = function(key) {
  return window.localStorage.getItem(key);
};
Storage.prototype.setItem = function(key, value) {
  return window.localStorage.setItem(key, value);
};

const s1 = Storage.getInstance();
const s2 = Storage.getInstance();

s1 === s2; // true
s1.setItem('storage', 'I am a single object.');
s2.getItem('storage'); // I am a single object.

(完)

文字溢出怎么展示，你的需求是什么？单行还是多行？截断，省略，自定义样式，自适应高度？在这里你都能找到答案。接下来我会由浅入深，从原理到实现，带你一步步揭开多行省略的面纱。我们先从最简单的单行溢出省略开始，

热身，单行省略

这是一个全宇宙统一的方案，没有太多的魔法，戳我查看示例

/* 原理：设置文字不换行，溢出后隐藏，截断显示省略符 */
.ellipsis {
  white-space: nowrap;
  text-overflow: ellipsis;
  overflow: hidden;
}

如何实现多行省略呢？先从最简单的 line-clamp 开始吧。

最简单的多行省略，line-clamp

通过 CSS 属性 -webkit-line-clamp 可以把块容器中的内容限制为指定的行数，示例

.ellipsis {
  display: -webkit-box;
  -webkit-line-clamp: 2;
  -webkit-box-orient: vertical;
  overflow: hidden;
}

属性的 -webkit 前缀告诉我们事情似乎并不简单。是的，它只支持基于 webkit 内核的浏览器，这对于移动端是很友好的，在 安卓 2.3+，IOS 5.0+ 的设备上你可以直接将上述代码直接扔进去没啥问题，但如果要在 PC 端使用，需要关注下兼容性问题，

除了 PC 兼容性问题，line-clamp 的方案也不支持自定义省略样式，如果需要在省略符后面加文字，箭头等自定义样式，我们可能就得考虑其他方案了，比如：浮动。

神奇的 float，浮动

什么！浮动也能实现多行省略？是的，下面我们用三个浮动盒子来模拟多行省略。首先准备三个盒子（文字盒，占位盒，自定义样式的省略盒）向右浮动，为了方便理解原理，我们给盒子增加不同的背景色，

<div class="box">
  <!-- 文字盒子 -->
  <div class="box__text">腾讯以技术丰富互联网用户的生活。通过通信及社交软件微信和 QQ 促进用户联系，并助其连接数字内容和生活服务，尽在弹指间。</div>
  <!-- 占位盒子 -->
  <div class="box__placeholder"></div>
  <!-- 自定义省略盒子 -->
  <div class="box__more">...展开</div>
</div>

<style>
  .box__text {
    width: 100%;
    height: 60px;
    line-height: 20px;
    background-color: pink;
    float: right;
  }

  .box__placeholder {
    width: 60px;
    height: 60px;
    background-color: gray;
    opacity: 0.8;
    float: right;
  }

  .box__more {
    width: 60px;
    text-align: right;
    background: yellow;
    float: right;
  }
</style>

接下来开始调整位置，先给文字盒一个负的左外边距，它的值刚好为占位盒的宽度，

.box__text {
  margin-left: -60px;
}

这样一来就给了占位盒子空间，它会浮动到左边，和文字盒排在一排，

上图中，文字盒的高度小于占位盒高度，此时第一排高度为占位盒子高度，第一排没有多余空间，我们自定义的省略盒子只能排在第二排。试想一下，当文字盒的高度大于占位盒高度时（比如文字显示 4 行），会发生什么？

第一排的高度会被文字盒撑开，这个时候第一排有了多余空间，省略盒子能够挤进去。

Awesome 😊，接下来只需要把省略盒子定位到右边和占位盒子同排的位置就可以了，

.box__more {
  position: relative;
  left: 100%;
  transform: translate(-100%, -100%);
}

修饰一下，去掉背景色，容器设置溢出隐藏，然后给省略盒子加个文字颜色和渐变，

.box {
  position: relative;
  overflow: hidden;
}

.box__more {
  color: #1890ff;
  background-image: linear-gradient(to left, white 40%, rgba(255, 255, 255, 0.8) 70%, transparent 100%);
}

效果还不错，想要完整示例，戳我查看。

小结一下，这里其实运用了浮动和 BFC 的原理。（如果你还不了解 BFC 可以去看一下我之前的文章 《可能是最好的BFC解析了...》，里面有非常全面的解析）

外层盒子通过 overflow: hidden 创建一个 BFC，浮动盒子的区域不会和 BFC 重叠，计算 BFC 高度时，浮动元素也会参与计算，浮动盒会浮动到当前行的开头或结尾，再借助一些定位技术，就可以模拟多行省略的效果了。

浮动的方案的优势非常明显，

• 兼容性强，支持所有主流的 PC，移动端浏览器
• 支持自定义带渐变的文字省略样式

由于省略样式区域本质上是一个浮动盒子，所以这里我们需要通过渐变来防止穿帮，对于某些背景颜色比较复杂的区域，或者更强的一些自定义省略样式需求时（比如省略样式定义为一张箭头或图片等），这种方案开始显得力不从心了。

有没有其他方式可以实现省略样式完全的自定义呢？

有，将自定义省略盒子的位置预留出来。

那要怎么预留呢？我们可以借助 line-clamp。由 line-clamp 截断后的省略号 ... 刚好可以帮助我们进行占位，如果我们能通过某种办法将默认的省略号隐藏掉，再替换为我们自定义的浮动盒子，是不是就可以了！这也就是接下来我们要介绍的方案。

完全自定义，浮动 + line-clamp

我们重新整理一下上述的思路，关键的点有三个，

1. 借助 line-clamp 默认的省略号，预留自定义省略盒子的位置
2. 想办法隐藏默认省略号
3. 通过定位技术替换预留位置为我们自定义的省略盒子

逐一来看，首先是预留位置，line-clamp 默认省略号的大小受字号 font-size 的影响，所以调整字号就可以控制预留位置的大小。这里为了保证省略号的大小只受字体大小的影响，我们可以重置行高和文字间距，

.box__text {
  position: relative;
  display: -webkit-box;
  -webkit-line-clamp: 3;
  -webkit-box-orient: vertical;
  font-size: 60px;
  line-height: 0;
  letter-spacing: 0; /* 重置了行高和文字间距，保证省略号占位只受字体大小的影响 */
  color: red; /* 为了方便演示，我们先给省略号一个颜色 */
}

这样就可以通过只调整文字盒子的字号，来控制预留省略盒子位置的大小了。由于 font-size 会继承，所以我们再内嵌一个子盒子来重置字号，

<div class="box__text">
    <div class="box__inner">
      腾讯以技术丰富互联网用户的生活。通过通信及社交软件微信和 QQ 促进用户联系，并助其连接数字内容和生活服务，尽在弹指间。
    </div>
</div>

<style>
  .box__inner {
    font-size: 16px;
    line-height: 20px;
    color: #000;
    vertical-align: top;
    display: inline;
  }
</style>

接下来是想办法隐藏省略号，这个比较简单，可以设置透明度或者颜色透明，

.box__text {
  opacity: 0;
  color: transparent;
}

有了省略号的预留位置后，我们要想办法将自定义省略盒子定位到预留位置，怎么办呢？还是 浮动。由于设置了 -webkit-line-clamp，会导致文字盒子无法撑开完整的高度，为了使用浮动来实现定位，我们可以多渲染一份文案用来撑开高度。

准备一个绝对定位的盒子，作为渲染撑开高度文案的容器，

<div class="box__abs">
    <div class="box__fake-text">
      腾讯以技术丰富互联网用户的生活。通过通信及社交软件微信和 QQ 促进用户联系，并助其连接数字内容和生活服务，尽在弹指间。
    </div>
    <div class="box__placeholder"></div>
    <div class="box__more">... 展开</div>
</div>

<style>
  .box__abs {
    position: absolute;
    top: 0;
    left: 0;
    width: 100%;
  }
</style>

接着用我们前面讲的三个浮动盒子实现多行溢出省略的方式，

.box__fake-text {
  width: 100%;
  margin-left: -60px;
  line-height: 20px;
  float: right;
  color: transparent; /* 文案是为了撑开高度，配合浮动实现多行溢出省略 */
}

.box__placeholder {
  width: 60px;
  height: 60px;
  float: right;
}

.box__more {
  position: relative;
  left: 100%;
  transform: translate(-100%, -100%);
  width: 60px;
  text-align: right;
  color: #1890ff;
  float: right;
}

需要注意的是，这里的文字盒子是为了撑开高度，不需要展示，所以我们设置了颜色透明。好了，最后一步，去掉背景色，外层盒子设置溢出隐藏就是我们的最终效果，

line-clamp + 浮动的方式可以实现省略符完全自定义，我们重置了行高和文字间距，只需要调整外层盒子的字体大小 font-size 就可以控制自定义省略盒子的宽度，你可以将省略盒子替换为任意的箭头，图片，折角或文字，这下再也不用担心 UI 小姐姐提需求了 ):

滑动窗口算法框架，

function slidingWindow(s, t) {
  // 利用哈希表（JavaScript 中可以用 Map 或空对象）记录目标字符串和窗口内字符串中字符的出现次数
  var need = {}, window = {};

  // 初始化哈希表，need 默认从 1 开始计数，window 默认从零开始计数
  for (var char of t) {
    need[char] = need[char] ? need[char] + 1 : 1;
    window[char] = window[char] ? window[char] + 1 : 0;
  }

  // 双指针记录滑动窗口的两端，size 记录窗口中满足 need 条件的字符的个数，然后开始滑动窗口
  var left = 0, right = 0, size = 0;
  while (right < s.length) {
    // c 是将移入窗口的字符
    var c = s[right];
    // 增大窗口
    right++;
    // 进行窗口内数据的一系列更新
    // ...

    // 判断左侧窗口是否需要收缩
    while (window needs shrink) {
      // d 是将移出窗口的字符
      var d = s[left];
      // 缩小窗口
      left--;
      // 进行窗口内数据的一系列更新
      // ...
    }
  }
}

比如力扣 76. 最小覆盖子串，我们可以直接套上面的框架，

function minWindow(s, t) {
    var need = {}, window = {}

    for (var char of t) {
        need[char] = need[char] ? need[char] + 1 : 1
        window[char] = window[char] ? window[char] + 1 : 0
    }

    var left = 0, right = 0, size = 0
    // 最小覆盖子串的起始索引和长度
    var start = 0, len = Infinity

    while (right < s.length) {
        var c = s[right]
        right++
        if (need.hasOwnProperty(c)) {
            window[c]++
            if (window[c] === need[c]) size++
        }

        // 判断左侧窗口是否需要收缩
        while (size === Object.keys(need).length) {
            if (right - left < len) {
                start = left
                len = right - left
            }
            var d = s[left]
            left++
            if (need.hasOwnProperty(d)) {
                if (window[d] === need[d]) size--
                window[d]--
            }
        }
    }

    return len === Infinity ? "" : s.substr(start, len)
};

再比如力扣 567. 字符串的排列，我们也可以直接套用框架，

function checkInclusion(s1, s2) {
    var need = {}, window = {}

    // 初始化哈希表，need = { a: 1, b: 1 }, window = { e: 0, i: 0, d: 0, b: 0, a: 0, o: 2 }
    for (var char of s1) {
        need[char] = need[char] ? need[char] + 1 : 1
        window[char] = window[char] ? window[char] + 1 : 0
    }

    // size 表示窗口中满足 need 条件的字符的个数
    // 比如对于窗口内的字符 a，need 中的出现次数为 1，当窗口中 a 出现次数也刚好为 1 时，我们把 size 加 1
    var left = 0, right = 0, size = 0

    while (right < s2.length) {
        var c = s2[right]
        right++
        // 增大窗口，更新当前元素出现的次数和 size
        if (need.hasOwnProperty(c)) {
            window[c]++
            if (window[c] === need[c]) size++
        }

        // 判断是否需要收缩左侧窗口
        // 什么时候需要收缩呢？题设要我们找的是排列，也就是当窗口长度刚好等于子串 s1 长度时，开始收缩
        while (right - left === s1.length) {
            // 收缩前先判断是否已经找到了子串
            if (size === Object.keys(need).length) {
                return true
            }
            var d = s2[left]
            left++
            if (need.hasOwnProperty(d)) {
                if (window[d] === need[d]) size--
                window[d]--
            }
        }
    }
    return false
};

时下火热的 Vue.js 3.0 从源码、性能和语法 API 三个大的方面对框架进行了优化。其中，在性能的优化中，对于源码体积的优化，主要体现在移除了一些冷门 Feature（比如 filter、inline-template） 并引入了 Tree-Shaking 减少打包体积。自从 rollup 提出这个术语以来，每每谈及打包性能优化，几乎都有 Tree-Shaking 的一席之地，所以了解 Tree-Shaking 的原理是很有必要的。

阅读完本文，你可以 Get 以下问题的答案，

• 什么是 Tree-Shaking？Tree-Shaking 的发展历史？
• Tree-Shaking 的原理是什么？
• 什么是 Dead code？
• ECMAScript 6 的模块机制？
• Webpack 中 Tree-Shaking 的原理？

故事的开始：Rich Harris 和他的 Rollup

业界知名的模块打包器 rollup.js 的作者 Rich Harris 在 2015 年 12 月的一篇博客
《Tree-shaking versus dead code elimination》中首次提到了 Tree-Shaking 的概念，随后 Webpack 2 的正式版本内置支持了 ECMAScript 2015 模块，增加了对 Tree-Shaking 的支持，而在更早前，Google 推出的开发者工具 Closure Compiler 也在做类似的事情。

I’ve been working (albeit sporadically of late, admittedly) on a tool called Rollup, which bundles together JavaScript modules. One of its features is tree-shaking, by which I mean that it only includes the bits of code your bundle actually needs to run.

Rich Harris 在文中提到 Tree-Shaking 是为了 Dead code elimination，这是编译器原理中常见的一种编译优化技术，简单来说就是消除无用代码（Dead code）。那么到底什么是 Dead code 呢？

Dead code

Dead code，也叫死码，无用代码，它的范畴主要包含了以下两点，

1. 不会被运行到的代码（unreachable code）
2. 只会影响道无关程序运行结果的变量（Dead Variables）

我们尝试通过一些 JavaScript 代码片段来理解它。

首先，不会被运行到的代码很好理解，比如在函数 return 语句后的代码，

function foo() {
  return 'foo';
  var bar = 'bar'; // 函数已经返回了，这里的赋值语句永远不会执行
}

或者不会执行的假值条件语句块，

if(0) {
  // 这个条件判断语句块内部的代码永远不会执行
}

而 Dead Variables 常见的像一些未使用的变量，

function add(a, b) {
  let c = 1; // unused variable 在这里可以被看作死码
  return a + b;
}