基础知识

基础知识主要包含以下几个方面：

• 基础：计算机原理、编译原理、数据结构、算法、设计模式、编程范式等基本知识了解


• 语法：JavaScript、ECMAScript、CSS、TypeScript、HTML、Node.js 等语法的了解和使用


• 框架：React、Vue、Egg、Koa、Express、Webpack 等原理的了解和使用


• 工程：编译工具、格式工具、Git、NPM、单元测试、Nginx、PM2、CI / CD 了解和使用


• 网络：HTTP、TCP、UDP、WebSocket、Cookie、Session、跨域、缓存、协议的了解


• 性能：编译性能、监控、白屏检测、SEO、Service Worker 等了解


• 插件：Chrome 、Vue CLI 、Webpack 等插件设计思路的理解


• 系统：Mac、Windows、Linux 系统配置的实践


• 后端：Redis 缓存、数据库、Graphql、SSR、模板引擎等了解和使用

基础

1、列举你所了解的计算机存储设备类型？

现代计算机以存储器为中心，主要由 CPU、I / O 设备以及主存储器三大部分组成。各个部分之间通过总线进行连接通信，具体如下图所示：

上图是一种多总线结构的示意图，CPU、主存以及 I / O 设备之间的所有数据都是通过总线进行并行传输，使用局部总线是为了提高 CPU 的吞吐量（CPU 不需要直接跟 I / O 设备通信），而使用高速总线（更贴近 CPU）和 DMA 总线则是为了提升高速 I / O 设备（外设存储器、局域网以及多媒体等）的执行效率。

主存包括随机存储器 RAM 和只读存储器 ROM，其中 ROM 又可以分为 MROM（一次性）、PROM、EPROM、EEPROM 。ROM 中存储的程序（例如启动程序、固化程序）和数据（例如常量数据）在断电后不会丢失。RAM 主要分为静态 RAM（SRAM） 和动态 RAM（DRAM） 两种类型（DRAM 种类很多，包括 SDRAM、RDRAM、CDRAM 等），断电后数据会丢失，主要用于存储临时程序或者临时变量数据。 DRAM 一般访问速度相对较慢。由于现代 CPU 读取速度要求相对较高，因此在 CPU 内核中都会设计 L1、L2 以及 L3 级别的多级高速缓存，这些缓存基本是由 SRAM 构成，一般访问速度较快。

2、一般代码存储在计算机的哪个设备中？代码在 CPU 中是如何运行的？

高级程序设计语言不能直接被计算机理解并执行，需要通过翻译程序将其转换成特定处理器上可执行的指令，计算机 CPU 的简单工作原理如下所示：

CPU 主要由控制单元、运算单元和存储单元组成（注意忽略了中断系统），各自的作用如下：

• 控制单元：在节拍脉冲的作用下，将程序计数器（Program Counter，PC）指向的主存或者多级高速缓存中的指令地址送到地址总线，接着获取指令地址所对应的指令并放入指令寄存器 （Instruction Register，IR）中，然后通过指令译码器（Instruction Decoder，ID）分析指令需要进行的操作，最后通过操作控制器（Operation Controller，OC）向其他设备发出微操作控制信号。


• 运算单元：如果控制单元发出的控制信号存在算术运算（加、减、乘、除、增 1、减 1、取反等）或者逻辑运算（与、或、非、异或），那么需要通过运算单元获取存储单元的计算数据进行处理。


• 存储单元：包括片内缓存和寄存器组，是 CPU 中临时数据的存储地方。CPU 直接访问主存数据大概需要花费数百个机器周期，而访问寄存器或者片内缓存只需要若干个或者几十个机器周期，因此会使用内部寄存器或缓存来存储和获取临时数据（即将被运算或者运算之后的数据），从而提高 CPU 的运行效率。

除此之外，计算机系统执行程序指令时需要花费时间，其中取出一条指令并执行这条指令的时间叫指令周期。指令周期可以分为若干个阶段（取指周期、间址周期、执行周期和中断周期），每个阶段主要完成一项基本操作，完成基本操作的时间叫机器周期。机器周期是时钟周期的分频，例如最经典的 8051 单片机的机器周期为 12 个时钟周期。时钟周期是 CPU 工作的基本时间单位，也可以称为节拍脉冲或 T 周期（CPU 主频的倒数） 。假设 CPU 的主频是 1 GHz（1 Hz 表示每秒运行 1 次），那么表示时钟周期为 1 / 109 s。理论上 CPU 的主频越高，程序指令执行的速度越快。

3、什么是指令和指令集？

上图右侧主存中的指令是 CPU 可以支持的处理命令，一般包含算术指令（加和减）、逻辑指令（与、或和非）、数据指令（移动、输入、删除、加载和存储）、流程控制指令以及程序结束指令等，由于 CPU 只能识别二进制码，因此指令是由二进制码组成。除此之外，指令的集合称为指令集（例如汇编语言就是指令集的一种表现形式），常见的指令集有精简指令集（ARM）和复杂指令集（Inter X86）。一般指令集决定了 CPU 处理器的硬件架构，规定了处理器的相应操作。

4、复杂指令集和精简指令集有什么区别？

5、JavaScript 是如何运行的？解释型语言和编译型语言的差异是什么？

早期的计算机只有机器语言时，程序设计必须用二进制数（0 和 1）来编写程序，并且要求程序员对计算机硬件和指令集非常了解，编程的难度较大，操作极易出错。为了解决机器语言的编程问题，慢慢开始出现了符号式的汇编语言（采用 ADD、SUB、MUL、DIV 等符号代表加减乘除）。为了使得计算机可以识别汇编语言，需要将汇编语言翻译成机器能够识别的机器语言（处理器的指令集）：

由于每一种机器的指令系统不同，需要不同的汇编语言程序与之匹配，因此程序员往往需要针对不同的机器了解其硬件结构和指令系统。为了可以抹平不同机器的指令系统，使得程序员可以更加关注程序设计本身，先后出现了各种面向问题的高级程序设计语言，例如 BASIC 和 C，具体过程如下图所示：

高级程序语言会先翻译成汇编语言或者其他中间语言，然后再根据不同的机器翻译成机器语言进行执行。除此之外，汇编语言虚拟机和机器语言机器之间还存在一层操作系统虚拟机，主要用于控制和管理操作系统的全部硬件和软件资源（随着超大规模集成电路技术的不断发展，一些操作系统的软件功能逐步由硬件来替换，例如目前的操作系统已经实现了部分程序的固化，简称固件，将程序永久性的存储在 ROM 中）。机器语言机器还可以继续分解成微程序机器，将每一条机器指令翻译成一组微指令（微程序）进行执行。

上述虚拟机所提供的语言转换程序被称为编译器，主要作用是将某种语言编写的源程序转换成一个等价的机器语言程序，编译器的作用如下图所示：

例如 C 语言，可以先通过 gcc 编译器生成 Linux 和 Windows 下的目标 .o 和 .obj 文件（object 文件，即目标文件），然后将目标文件与底层系统库文件、应用程序库文件以及启动文件链接成可执行文件在目标机器上执行。

温馨提示：感兴趣的同学可以了解一下 ARM 芯片的程序运行原理，包括使用 IDE 进行程序的编译（IDE 内置编译器，主流编译器包含 ARMCC、IAR 以及 GCC FOR ARM 等，其中一些编译器仅仅随着 IDE 进行捆绑发布，不提供独立使用的能力，而一些编译器则随着 IDE 进行发布的同时，还提供命令行接口的独立使用方式）、通过串口进行程序下载（下载到芯片的代码区初始启动地址映射的存储空间地址）、启动的存储空间地址映射（包括系统存储器、闪存 FLASH、内置 SRAM 等）、芯片的程序启动模式引脚 BOOT 的设置（例如调试代码时常常选择内置 SRAM、真正程序运行的时候选择闪存 FLASH）等。

如果某种高级语言或者应用语言（例如用于人工智能的计算机设计语言）转换的目标语言不是特定计算机的汇编语言，而是面向另一种高级程序语言（很多研究性的编译器将 C 作为目标语言），那么还需要将目标高级程序语言再进行一次额外的编译才能得到最终的目标程序，这种编译器可称为源到源的转换器。

除此之外，有些程序设计语言将编译的过程和最终转换成目标程序进行执行的过程混合在一起，这种语言转换程序通常被称为解释器，主要作用是将某种语言编写的源程序作为输入，将该源程序执行的结果作为输出，解释器的作用如下图所示：

解释器和编译器有很多相似之处，都需要对源程序进行分析，并转换成目标机器可识别的机器语言进行执行。只是解释器是在转换源程序的同时立马执行对应的机器语言（转换和执行的过程不分离），而编译器得先把源程序全部转换成机器语言并产生目标文件，然后将目标文件写入相应的程序存储器进行执行（转换和执行的过程分离）。例如 Perl、Scheme、APL 使用解释器进行转换， C、C++ 则使用编译器进行转换，而 Java 和 JavaScript 的转换既包含了编译过程，也包含了解释过程。

6、简单描述一下 Babel 的编译过程？

7、JavaScript 中的数组和函数在内存中是如何存储的？

JavaScript 中的数组存储大致需要分为两种情况：

• 同种类型数据的数组分配连续的内存空间


• 存在非同种类型数据的数组使用哈希映射分配内存空间

温馨提示：可以想象一下连续的内存空间只需要根据索引（指针）直接计算存储位置即可。如果是哈希映射那么首先需要计算索引值，然后如果索引值有冲突的场景下还需要进行二次查找（需要知道哈希的存储方式）。

8、浏览器和 Node.js 中的事件循环机制有什么区别？

阅读链接：面试分享：两年工作经验成功面试阿里P6总结 - 了解 Event Loop 吗？

9、ES6 Modules 相对于 CommonJS 的优势是什么？

10、高级程序设计语言是如何编译成机器语言的？

11、编译器一般由哪几个阶段组成？数据类型检查一般在什么阶段进行？

12、编译过程中虚拟机的作用是什么？

13、什么是中间代码（IR），它的作用是什么？

14、什么是交叉编译？

编译器的设计是一个非常庞大和复杂的软件系统设计，在真正设计的时候需要解决两个相对重要的问题：

• 如何分析不同高级程序语言设计的源程序


• 如何将源程序的功能等价映射到不同指令系统的目标机器

为了解决上述两项问题，编译器的设计最终被分解成前端（注意这里所说的不是 Web 前端）和后端两个编译阶段，前端用于解决第一个问题，而后端用于解决第二个问题，具体如下图所示：

上图中的中间表示（Intermediate Representation，IR）是程序结构的一种表现方式，它会比 AST（后续讲解）更加接近汇编语言或者指令集，同时也会保留源程序中的一些高级信息，除此之外 ，它的种类很多，包括三地址码（Three Address Code, TAC）、静态单赋值形式（Static Single Assignment Form, SSA）以及基于栈的 IR 等，具体作用包括：

• 靠近前端部分主要适配不同的源程序，靠近后端部分主要适配不同的指令集，更易于编译器的错误调试，容易识别是 IR 之前还是之后出问题


• 如下左图所示，如果没有 IR，那么源程序到指令集之间需要进行一一适配，而有了中间表示，则可以使得编译器的职责更加分离，源程序的编译更多关注如何转换成 IR，而不是去适配不同的指令集


• IR 本身可以做到多趟迭代从而优化源程序，在每一趟迭代的过程中可以研究代码并记录优化的细节，方便后续的迭代查找并利用这些优化信息，最终可以高效输出更优的目标程序

由于 IR 可以进行多趟迭代进行程序优化，因此在编译器中可插入一个新的优化阶段，如下图所示：

优化器可以对 IR 处理一遍或者多遍，从而生成更快执行速度（例如找到循环中不变的计算并对其进行优化从而减少运算次数）或者更小体积的目标程序，也可能用于产生更少异常或者更低功耗的目标程序。除此之外，前端和后端内部还可以细分为多个处理步骤，具体如下图所示：

优化器中的每一遍优化处理都可以使用一个或多个优化技术来改进代码，每一趟处理最终都是读写 IR 的操作，这样不仅仅可以使得优化可以更加高效，同时也可以降低优化的复杂度，还提高了优化的灵活性，可以使得编译器配置不同的优化选项，达到组合优化的效果。

15、发布 / 订阅模式和观察者模式的区别是什么？

阅读链接：基于Vue实现一个简易MVVM - 观察者模式和发布/订阅模式

16、装饰器模式一般会在什么场合使用？

17、谈谈你对大型项目的代码解耦设计理解？什么是 Ioc？一般 DI 采用什么设计模式实现？

18、列举你所了解的编程范式？

编程范式（Programming paradigm）是指计算机编程的基本风格或者典型模式，可以简单理解为编程学科中实践出来的具有哲学和理论依据的一些经典原型。常见的编程范式有：

• 面向过程（Process Oriented Programming，POP）


• 面向对象（Object Oriented Programming，OOP）


• 面向接口（Interface Oriented Programming， IOP）


• 面向切面（Aspect Oriented Programming，AOP）


• 函数式（Funtional Programming，FP）


• 响应式（Reactive Programming，RP）


• 函数响应式（Functional Reactive Programming，FRP）

阅读链接：：如果你对于编程范式的定义相对模糊，可以继续阅读 What is the precise definition of programming paradigm? 了解更多。

不同的语言可以支持多种不同的编程范式，例如 C 语言支持 POP 范式，C++ 和 Java 语言支持 OOP 范式，Swift 语言则可以支持 FP 范式，而 Web 前端中的 JavaScript 可以支持上述列出的所有编程范式。

19、什么是面向切面（AOP）的编程？

20、什么是函数式编程？

顾名思义，函数式编程是使用函数来进行高效处理数据或数据流的一种编程方式。在数学中，函数的三要素是定义域、值域和**对应关系。假设 A、B 是非空数集，对于集合 A 中的任意一个数 x，在集合 B 中都有唯一确定的数 f(x) 和它对应，那么可以将 f 称为从 A 到 B 的一个函数，记作：y = f(x)。在函数式编程中函数的概念和数学函数的概念类似，主要是描述形参 x 和返回值 y 之间的对应关系，**如下图所示：

温馨提示：图片来自于简明 JavaScript 函数式编程——入门篇。

在实际的编程中，可以将各种明确对应关系的函数进行传递、组合从而达到处理数据的最终目的。在此过程中，我们的关注点不在于如何去实现**对应关系，**而在于如何将各种已有的对应关系进行高效联动，从而可快速进行数据转换，达到最终的数据处理目的，提供开发效率。

简单示例

尽管你对函数式编程的概念有所了解，但是你仍然不知道函数式编程到底有什么特点。这里我们仍然拿 OOP 编程范式来举例，假设希望通过 OOP 编程来解决数学的加减乘除问题：

class MathObject {

  constructor(private value: number) {}

  public add(num: number): MathObject {

    this.value += num;

    return this;

  }

  public multiply(num: number): MathObject {

    this.value *= num;

    return this;

  }

  public getValue(): number {

    return this.value;

  }

}



const a = new MathObject(1);

a.add(1).multiply(2).add(a.multiply(2).getValue()); 

我们希望通过上述程序来解决 (1 + 2) * 2 + 1 * 2 的问题，但实际上计算出来的结果是 24，因为在代码内部有一个 this.value 的状态值需要跟踪，这会使得结果不符合预期。 接下来我们采用函数式编程的方式：

function add(a: number, b: number): number {

  return a + b;

}



function multiply(a: number, b: number): number {

  return a * b;

}



const a: number = 1;

const b: number = 2;



add(multiply(add(a, b), b), multiply(a, b));

以上程序计算的结果是 8，完全符合预期。我们知道了 add 和 multiply 两个函数的实际对应关系，通过将对应关系进行有效的组合和传递，达到了最终的计算结果。除此之外，这两个函数还可以根据数学定律得出更优雅的组合方式：

add(multiply(add(a, b), b), multiply(a, b));



// 根据数学定律分配律：a * b  +  a * c = a * (b + c)，得出：

// (a + b) * b + a * b = (2a + b) * b



// 简化上述函数的组合方式

multiply(add(add(a, a), b), b);

我们完全不需要追踪类似于 OOP 编程范式中可能存在的内部状态数据，事实上对于数学定律中的结合律、交换律、同一律以及分配律，上述的函数式编程代码足可以胜任。

原则

通过上述简单的例子可以发现，要实现高可复用的函数**（对应关系）**，一定要遵循某些特定的原则，否则在使用的时候可能无法进行高效的传递和组合，例如

• 高内聚低耦合


• 最小意外原则


• 单一职责原则


• ...

如果你之前经常进行无原则性的代码设计，那么在设计过程中可能会出现各种出乎意料的问题（这是为什么新手老是出现一些稀奇古怪问题的主要原因）。函数式编程可以有效的通过一些原则性的约束使你设计出更加健壮和优雅的代码，并且在不断的实践过程中进行经验式叠加，从而提高开发效率。

特点

虽然我们在使用函数的过程中更多的不再关注函数如何实现（对应关系），但是真正在使用和设计函数的时候需要注意以下一些特点：

• 声明式（Declarative Programming）


• 一等公民（First Class Function）


• 纯函数（Pure Function）


• 无状态和数据不可变（Statelessness and Immutable Data）


• ...

声明式

我们以前设计的代码通常是命令式编程方式，这种编程方式往往注重具体的实现的过程（对应关系），而函数式编程则采用声明式的编程方式，往往注重如何去组合已有的**对应关系。**简单举个例子：

// 命令式

const array = [0.8, 1.7, 2.5, 3.4];

const filterArray = [];



for (let i = 0; i < array.length; i++) {

  const integer = Math.floor(array[i]);

  if (integer < 2) {

    continue;

  }

  filterArray.push(integer);

}



// 声明式

// map 和 filter 不会修改原有数组，而是产生新的数组返回

[0.8, 1.7, 2.5, 3.4].map((item) => Math.floor(item)).filter((item) => item > 1);

命令式代码一步一步的告诉计算机需要执行哪些语句，需要关心变量的实例化情况、循环的具体过程以及跟踪变量状态的变化过程。声明式代码更多的不再关心代码的具体执行过程，而是采用表达式的组合变换去处理问题，不再强调怎么做，而是指明**做什么。**声明式编程方式可以将我们设计代码的关注点彻底从过程式解放出来，从而提高开发效率。

一等公民

在 JavaScript 中，函数的使用非常灵活，例如可以对函数进行以下操作：

interface IHello {

  (name: string): string;

  key?: string;

  arr?: number[];

  fn?(name: string): string;

}



// 函数声明提升

console.log(hello instanceof Object); // true



// 函数声明提升

// hello 和其他引用类型的对象一样，都有属性和方法

hello.key = 'key';

hello.arr = [1, 2];

hello.fn = function (name: string) {

  return `hello.fn, ${name}`;

};



// 函数声明提升

// 注意函数表达式不能在声明前执行，例如不能在这里使用 helloCopy('world')

hello('world'); 



// 函数

// 创建新的函数对象，将函数的引用指向变量 hello

// hello 仅仅是变量的名称

function hello(name: string): string {

  return `hello, ${name}`;

}



console.log(hello.key); // key

console.log(hello.arr); // [1,2]

console.log(hello.name); // hello



// 函数表达式

const helloCopy: IHello = hello;

helloCopy('world');



function transferHello(name: string, hello: Hello) {

  return hello('world');

}



// 把函数对象当作实参传递

transferHello('world', helloCopy);



// 把匿名函数当作实参传递

transferHello('world', function (name: string) {

  return `hello, ${name}`;

});

通过以上示例可以看出，函数继承至对象并拥有对象的特性。在 JavaScript 中可以对函数进行参数传递、变量赋值或数组操作等等，因此把函数称为一等公民。函数式编程的核心就是对函数进行组合或传递，JavaScript 中函数这种灵活的特性是满足函数式编程的重要条件。

纯函数

纯函数是是指在相同的参数调用下，函数的返回值唯一不变。这跟数学中函数的映射关系类似，同样的 x 不可能映射多个不同的 y。使用函数式编程会使得函数的调用非常稳定，从而降低 Bug 产生的机率。当然要实现纯函数的这种特性，需要函数不能包含以下一些副作用：

• 操作 Http 请求


• 可变数据（包括在函数内部改变输入参数）


• DOM 操作


• 打印日志


• 访问系统状态


• 操作文件系统


• 操作数据库


• ...

从以上常见的一些副作用可以看出，纯函数的实现需要遵循最小意外原则，为了确保函数的稳定唯一的输入和输出，尽量应该避免与函数外部的环境进行任何交互行为，从而防止外部环境对函数内部产生无法预料的影响。纯函数的实现应该自给自足，举几个例子：

// 如果使用 const 声明 min 变量（基本数据类型），则可以保证以下函数的纯粹性

let min: number = 1;



// 非纯函数

// 依赖外部环境变量 min，一旦 min 发生变化则输入和返回不唯一

function isEqual(num: number): boolean {

  return num === min;

}



// 纯函数

function isEqual(num: number): boolean {

  return num === 1;

}



// 非纯函数

function request<T, S>(url: string, params: T): Promise<S> {

  // 会产生请求成功和请求失败两种结果，返回的结果可能不唯一

  return $.getJson(url, params);

}



// 纯函数

function request<T, S>(url: string, params: T) : () => Promise<S> {

  return function() {

    return $.getJson(url, params);

  }

}

纯函数的特性使得函数式编程具备以下特性：

• 可缓存性（Cacheable）


• 可移植性（Portable）


• 可测试性（Testable）

可缓存性和可测试性基于纯函数输入输出唯一不变的特性，可移植性则主要基于纯函数不依赖外部环境的特性。这里举一个可缓存的例子：

interface ICache<T> {

  [arg: string]: T;

}



interface ISquare<T> {

  (x: T): T;

}



// 简单的缓存函数（忽略通用性和健壮性）

function memoize<T>(fn: ISquare<T>): ISquare<T> {

  const cache: ICache<T> = {};

  return function (x: T) {

    const arg: string = JSON.stringify(x);

    cache[arg] = cache[arg] || fn.call(fn, x);

    return cache[arg];

  };

}



// 纯函数

function square(x: number): number {

  return x * x;

}



const memoSquare = memoize<number>(square);

memoSquare(4);



// 不会再次调用纯函数 square，而是直接从缓存中获取值

// 由于输入和输出的唯一性，获取缓存结果可靠稳定

// 提升代码的运行效率

memoSquare(4);

无状态和数据不可变

在函数式编程的简单示例中已经可以清晰的感受到函数式编程绝对不能依赖内部状态，而在纯函数中则说明了函数式编程不能依赖外部的环境或状态，因为一旦依赖的状态变化，不能保证函数根据对应关系所计算的返回值因为状态的变化仍然保持不变。

这里单独讲解一下数据不可变，在 JavaScript 中有很多数组操作的方法，举个例子：

const arr = [1, 2, 3];



console.log(arr.slice(0, 2)); // [1, 2]

console.log(arr); // [1, 2, 3]

console.log(arr.slice(0, 2)); // [1, 2]

console.log(arr); // [1, 2, 3]



console.log(arr.splice(0, 1)); // [1]

console.log(arr); // [2, 3]

console.log(arr.splice(0, 1)); // [2]

console.log(arr); // [3]

这里的 slice 方法多次调用都不会改变原有数组，且会产生相同的输出。而 splice 每次调用都在修改原数组，且产生的输出也不相同。 在函数式编程中，这种会改变原有数据的函数已经不再是纯函数，应该尽量避免使用。

阅读链接：如果想要了解更深入的函数式编程知识点，可以额外阅读函数式编程指北。

21、响应式编程的使用场景有哪些？

响应式编程是一种基于观察者（发布 / 订阅）模式并且面向异步（Asynchronous）数据流（Data Stream）和变化传播的声明式编程范式。响应式编程主要适用的场景包含：

• 用户和系统发起的连续事件处理，例如鼠标的点击、键盘的按键或者通信设备发起的信号等


• 非可靠的网络或者通信处理（例如 HTTP 网络的请求重试）


• 连续的异步 IO 处理


• 复杂的继发事务处理（例如一次事件涉及到多个继发的网络请求）


• 高并发的消息处理（例如 IM 聊天）


• ...

起因

很多项目历史悠久，其中很多 文件或是 export 出去的变量 已经不再使用，非常影响维护迭代。
举个例子来说，后端问你：“某某接口统计一下某接口是否还有使用？”你在项目里一搜，好家伙，还有好几处使用呢，结果那些定义或文件是从未被引入的，这就会误导你们去继续维护这个文件或接口，影响迭代效率。

先从删除废弃的 exports 讲起，后文会讲删除废弃文件。

删除 exports，有几个难点：

1. 
   

   怎么样稳定的 找出 export 出去，但是其他文件未 import 的变量 ？

   
   


2. 
   

   如何确定步骤 1 中变量在 本文件内部没有用到 （作用域分析）？

   
   


3. 
   

   如何稳定的 删除这些变量 ？

   
   

整体思路

先给出整体的思路，公司内的小伙伴推荐了 pzavolinsky/ts-unused-exports 这个开源库，并且已经在项目中稳定使用了一段时间，这个库可以搞定上述第一步的诉求，也就是找出 export 出去，但是其他文件未 import 的变量。
但下面两步依然很棘手，先给出我的结论：

1. 如何确定步骤 1 中变量在本文件内部没有用到（作用域分析）？

对分析出的文件调用 ESLint 的 API，no-unused-vars 这个 ESLint rule 天生就可以分析出文件内部某个变量是否使用，但默认情况下它是不支持对 export 出去的变量进行分析的，因为既然你 export 了这个变量，那其实 ESLint 就认为你这个变量会被外部使用。对于这个限制，其实只需要 fork 下来稍微改写即可。

2. 如何稳定的删除这些变量？

自己编写 rule fixer 删除掉分析出来的无用变量，之后就是格式化，由于 ESLint 删除代码后格式会乱掉，所以手动调用 prettier API 让代码恢复美观即可。

接下来我会对上述每一步详细讲解。

导出导入分析

使用测试下来， pzavolinsky/ts-unused-exports 确实可以靠谱的分析出 未使用的 export 变量 ，但是这种分析 import、export 关系的工具，只是局限于此，不会分析 export 出去的这个变量 在代码内部是否有使用到 。

文件内部使用分析

第二步的问题比较复杂，这里最终选用 ESLint 配合自己 fork 改写 no-unused-vars 这个 rule ，并且自己提供规则对应的修复方案 fixer 来实现。

为什么是 ESLint？

1. 
   

   社区广泛使用，经过无数项目验证。

   
   


2. 
   

   基于 作用域分析 ，准确的找出未使用的变量。

   
   


3. 
   

   提供的 AST 符合 estree/estree 的通用标准，易于维护拓展。

   
   


4. 
   

   ESLint 可以解决 删除之后引入新的无用变量的问题 ，最典型的就是删除了某个函数，这个函数内部的某个函数也可能会变成无效代码。ESLint 会 重复执行 fix 函数，直到不再有新的可修复错误为止。

   
   

为什么要 fork 下来改写它？

1. 
   

   官方的 no-unused-vars 默认是不考虑 export 出去的变量的，而经过我对源码的阅读发现，仅仅 修改少量的代码 就可以打破这个限制，让 export 出去的变量也可以被分析，在模块内部是否使用。

   
   


2. 
   

   第一步的改写后，很多 export 出去的变量 被其他模块引用 ，但由于在 模块内部未使用 ，也会 被分析为未使用变量 。所以需要给 rule 提供一个 varsPattern 的选项，把分析范围限定在 ts-unused-exports 给出的 导出未使用变量 中，如 varsPattern: '^foo$|^bar$' 。

   
   


3. 
   

   官方的 no-unused-vars 只给出提示，没有提供 自动修复 的方案，需要自己编写，下面详细讲解。

   
   

如何删除变量

当我们在 IDE 中编写代码时，有时会发现保存之后一些 ESLint 飘红的部分被自动修复了，但另一部分却没有反应。
这其实是 ESLint 的 rule fixer 的作用。
参考官方文档的 Apply Fixer 章节，每个 ESLint Rule 的编写者都可以决定自己的这条规则 是否可以自动修复，以及如何修复。
修复不是凭空产生的，需要作者自己对相应的 AST 节点做分析、删除等操作，好在 ESLint 提供了一个 fixer 工具包，里面封装了很多好用的节点操作方法，比如 fixer.remove() ， fixer.replaceText() 。
官方的 no-unused-vars 由于稳定性等原因未提供代码的自动修复方案，需要自己对这个 rule 写对应的 fixer 。官方给出的解释在 Add fix/suggestions to no-unused-vars rule · Issue #14585 · eslint/eslint 。

核心改动

把 ESLint Plugin 单独拆分到一个目录中，结构如下：

packages/eslint-plugin-deadvars

├── ast-utils.js

├── eslint-plugin.js

├── eslint-rule-typescript-unused-vars.js

├── eslint-rule-unused-vars.js

├── eslint-rule.js

└── package.json

• 
  

  eslint-plugin.js : 插件入口，外部引入后才可以使用 rule

  
  


• 
  

  eslint-rule-unused-vars.js : ESLint 官方的 eslint/no-unused-vars 代码，主要的核心代码都在里面。

  
  


• 
  

  eslint-rule-typescript-unused-vars : typescript-eslint/no-unused-vars 内部的代码，继承了 eslint/no-unused-vars ，增加了一些 TypeScript AST 节点的分析。

  
  


• 
  

  eslint-rule.js ：规则入口，引入了 typescript rule ，并且利用 eslint-rule-composer 给这个规则增加了自动修复的逻辑。

  
  

ESLint Rule 改动

我们的分析涉及到删除，所以必须有一个严格的限定范围，就是 exports 出去 且被 ts-unused-exports 认定为 外部未使用 的变量。
所以考虑增加一个配置 varsPattern ，把 ts-unused-exports 分析出的未使用变量名传入进去，限定在这个名称范围内。
主要改动逻辑是在 collectUnusedVariables 这个函数中，这个函数的作用是 收集作用域中没有使用到的变量 ，这里把 exports 且不符合变量名范围 的全部跳过不处理。

else if (

  config.varsIgnorePattern &&

  config.varsIgnorePattern.test(def.name.name)

) {

  // skip ignored variables

  continue;

+ } else if (

+  isExported(variable) &&

+  config.varsPattern &&

+  !config.varsPattern.test(def.name.name)

+) {

+  // 符合 varsPattern

+  continue;

+ }

这样外部就可以这样使用这样的方式来限定分析范围：

rules: {

  '@deadvars/no-unused-vars': [

    'error',

    { varsPattern: '^foo$|^bar$' },

  ]

}

接着删除掉原版中 收集未使用变量时 对 isExported 的判断，把 exports 出去但文件内部未使用 的变量也收集起来。由于上一步已经限定了变量名，所以这里只会收集到 ts-unused-exports 分析出来的变量。

if (

  !isUsedVariable(variable) &&

- !isExported(variable) &&

  !hasRestSpreadSibling(variable)

) {

  unusedVars.push(variable);

}

ESLint Rule Fixer

接下来主要就是增加自动修复，这部分的逻辑在 eslint-rule.js 中，简单来说就是对上一步分析出来的各种未使用变量的 AST 节点进行判断和删除。
贴一下简化的函数处理代码：

module.exports = ruleComposer.mapReports(rule, (problem, context) => {

  problem.fix = fixer => {

    const { node } = problem;

    const { parent } = node;



    // 函数节点

    switch (parent.type) {

      case 'FunctionExpression':

      case 'FunctionDeclaration':

      case 'ArrowFunctionExpression':

        // 调用 fixer 进行删除

        return fixer.remove(parent);

      ...

      ...

      default:

        return null;

    }

  };

  return problem;

});

目前会对以下几种节点类型进行删除：

• 
  

  FunctionExpression

  
  


• 
  

  FunctionDeclaration

  
  


• 
  

  ArrowFunctionExpression

  
  


• 
  

  ImportSpecifier

  
  


• 
  

  ImportDefaultSpecifier

  
  


• 
  

  ImportNamespaceSpecifier

  
  


• 
  

  VariableDeclarator

  
  


• 
  

  TSEnumDeclaration

  
  

后续新增节点的删除逻辑，只需要维护这个文件即可。

无用文件删除

之前基于 webpack-deadcode-plugin 做了一版无用代码删除，但是在实际使用的过程中，发现一些问题。

首先是 速度太慢 ，这个插件会基于 webpack 编译的结果来分析哪些文件是无用的，每次使用都需要编译一遍项目。

而且前几天加入了 fork-ts-checker-webpack-plugin 进行类型检查之后， 这个删除方案突然失效了 ，检测出来的只有 .less 类型的无用文件，经过和排查后发现是这个插件的锅，它会把 src 目录下的所有 ts 文件 都加入到 webpack 的依赖中，也就是 compilation.fileDependencies （可以尝试开启这个插件，在开发环境试着手动改一个完全未导入的 ts 文件，一样会触发重新编译）

而 deadcode-plugin 就是依赖 compilation.fileDependencies 这个变量来判断哪些文件未被使用，所有 ts 文件都在这个变量中的话，扫描出来的无用文件自然就只有其他类型了。

这个行为应该是插件的官方有意而为之，考虑如下情况：

// 直接导入一个 TS 类型

import { IProps } from "./type.ts";



// use IProps

在使用旧版的 fork-ts-checker-webpack-plugin 时，如果此时改动了 IProps 造成了类型错误，是不会触发 webpack 的编译报错的。

经过排查，目前官方的行为好像是把 tsconfig 中的 include 里的所有 ts 文件加入到依赖中，方便改动触发编译，而我们项目中的 include 是 ["src/**/*.ts"] ，所以……

具体讨论可以查看这个 Issue： Files that provide only type dependencies for main entry and unused files are not being checked for

方案

首先尝试在 deadcode 模式中手动删除 fork-ts-checker-webpack-plugin，这样可以扫描出无用依赖，但是上文中那样从文件中只导入类型的情况，还是会被认为是无用的文件而误删。

考虑到现实场景中单独建一个 type.ts 文件书写接口或类型的情况比较多，只好先放弃这个方案。

转而一想， pzavolinsky/ts-unused-exports 这个工具既然都能分析出
所有文件的 导入导出变量的依赖关系 ，那分析出未使用的文件应该也是小意思才对。

经过源码调试，大概梳理出了这个工具的原理：

1. 通过 TypeScript 内置的 ts.parseJsonConfigFileContent API 扫描出项目内完整的 ts 文件路径。

 {

    "path": "src/component/A",

    "fullPath": "/Users/admin/works/test/src/component/A.tsx",

  {

    "path": "src/component/B",

    "fullPath": "/Users/admin/works/test/apps/app/src/component/B.tsx",

  }

  ...

2. 通过 TypeScript 内置的一些 compile API 分析出文件之间的 exports 和 imports 关系。

{

  "path": "src/component/A",

  "fullPath": "/Users/admin/works/test/src/component/A.tsx",

  "imports": {

    "styled-components": ["default"],

    "react": ["default"],

    "src/components/B": ["TestComponentB"]

  },

  "exports": ["TestComponentA"]

}

3. 根据上述信息来分析出每个文件中每个变量的使用次数，筛选出未使用的变量并且输出。

到此思路也就有了，把所有文件中的 imports 信息取一个合集，然后从第一步的文件集合中找出未出现在 imports 里的文件即可。

一些值得一提的改造

循环删除文件

在第一次检测出无用文件并删除后，很可能会暴露出一些新的无用文件。
比如以下这样的例子：

[

  {

    "path": "a",

    "imports": "b"

  },

  {

    "path": "b",

    "imports": "c"

  },

  {

    "path": "c"

  }

]

文件 a 引入了文件 b，文件 b 引入了文件 c。

第一轮扫描的时候，没有任何文件引入 a，所以会把 a 视作无用文件。

由于 a 引入了 b，所以不会把 b 视作无用的文件，同理 c 也不会视作无用文件。

所以 第一轮删除只会删掉 a 文件 。

只要在每次删除后，把 files 范围缩小，比如第一次删除了 a 以后，files 只留下：

[

  {

    path: "b",

    imports: "c",

  },

  {

    path: "c",

  },

];

此时会发现没有文件再引入 b 了，b 也会被加入无用文件的列表，再重复此步骤，即可删除 c 文件。

支持 Monorepo

原项目只考虑到了单个项目和单个 tsconfig 的处理，而如今 monorepo 已经非常流行了，monorepo 中每个项目都有自己的 tsconfig，形成一个自己的 project，而经常有项目 A 里的文件或变量被项目 B 所依赖使用的情况。

而如果单独扫描单个项目内的文件，就会把很多被子项目使用的文件误删掉。

这里的思路也很简单：

1. 
   

   增加 --deps 参数，允许传入多个子项目的 tsconfig 路径。

   
   


2. 
   

   过滤子项目扫描出的 imports 部分，找出从别名为 @main的主项目中引入的依赖（比如 import { Button } from '@main/components'）

   
   


3. 
   

   把这部分 imports 合并到主项目的依赖集合中，共同进行接下来的扫描步骤。

   
   

支持自定义文件扫描

TypeScript 提供的 API，默认只会扫描 .ts, .tsx 后缀的文件，在开启 allowJS 选项后也会扫描 .js, .jsx 后缀的文件。
而项目中很多的 .less, .svg 的文件也都未被使用，但它们都被忽略掉了。

这里我断点跟进 ts.parseJsonConfigFileContent 函数内部，发现有一些比较隐蔽的参数和逻辑，用比较 hack 的方式支持了自定义后缀。

当然，这里还涉及到了一些比较麻烦的改造，比如这个库原本是没有考虑 index.ts, index.less 同时存在这种情况的，通过源码的一些改造最终绕过了这个限制。

目前默认支持了 .less, .sass, .scss 这些类型文件的扫描 ，只要你确保该后缀的引入都是通过 import 语法，那么就可以通过增加的 extraFileExtensions 配置来增加自定义后缀。

import * as ts from "typescript";



const result = ts.parseJsonConfigFileContent(

  parseJsonResult.config,

  ts.sys,

  basePath,

  undefined,

  undefined,

  undefined,

  extraFileExtensions?.map((extension) => ({

    extension,

    isMixedContent: false,

    // hack ways to scan all files

    scriptKind: ts.ScriptKind.Deferred,

  }))

);

其他方案：ts-prune

ts-prune 是完全基于 TypeScript 服务实现的一个 dead exports 检测方案。

背景

TypeScript 服务提供了一个实用的 API： findAllReferences ，我们平时在 VSCode 里右键点击一个变量，选择 “Find All References” 时，就会调用这个底层 API 找出所有的引用。

ts-morph 这个库封装了包括 findAllReferences 在内的一些底层 API，提供更加简洁易用的调用方式。

ts-prune 就是基于 ts-morph 封装而成。

一段最简化的基于 ts-morph 的检测 dead exports 的代码如下：

// this could be improved... (ex. ignore interfaces/type aliases that describe a parameter type in the same file)

import { Project, TypeGuards, Node } from "ts-morph";



const project = new Project({ tsConfigFilePath: "tsconfig.json" });



for (const file of project.getSourceFiles()) {

  file.forEachChild((child) => {

    if (TypeGuards.isVariableStatement(child)) {

      if (isExported(child)) child.getDeclarations().forEach(checkNode);

    } else if (isExported(child)) checkNode(child);

  });

}



function isExported(node: Node) {

  return TypeGuards.isExportableNode(node) && node.isExported();

}



function checkNode(node: Node) {

  if (!TypeGuards.isReferenceFindableNode(node)) return;



  const file = node.getSourceFile();

  if (

    node.findReferencesAsNodes().filter((n) => n.getSourceFile() !== file)

      .length === 0

  )

    console.log(

      `[${file.getFilePath()}:${node.getStartLineNumber()}: ${

        TypeGuards.hasName(node) ? node.getName() : node.getText()

      }`

    );

}

优点

1. 
   

   TS 的服务被各种 IDE 集成，经过无数大型项目检测，可靠性不用多说。

   
   


2. 
   

   不需要像 ESLint 方案那样，额外检测变量在文件内是否使用， findAllReferences 的检测范围包括文件内部，开箱即用。

   
   

缺点

1. 
   

   速度慢 ，TSProgram 的初始化，以及 findAllReferences 的调用，在大型项目中速度还是有点慢。

   
   


2. 
   

   文档和规范比较差 ，ts-morph 的文档还是太简陋了，挺多核心的方法没有文档描述，不利于维护。

   
   


3. 
   

   模块语法不一致 ，TypeScript 的 findAllReferences 并不识别 Dynamic Import 语法，需要额外处理 import() 形式导入的模块。

   
   


4. 
   

   删除方案难做 ，ts-prune 封装了相对完善的 dead exports 检测方案，但作者似乎没有做自动删除方案的意思。这时 第二点的劣势就出来了，按照文档来探索删除方案非常艰难。看起来有个德国的小哥 好不容易说服作者 提了一个自动删除的 MR：Add a fix mode that automatically fixes unused exports (revival) ，但是最后因为内存溢出没通过 GithubCI，不了了之了。我个人把这套代码 fork 下来在公司内部的大型项目中跑了一下，也确实是内存溢出 ，看了下自动修复方案的代码，也都是很常规的基于 ts-morph 的 API 调用，猜测是底层 API 的性能问题？

   
   

所以综合评估下来，最后还是选择了 ts-unused-exports + ESLint 的方案。

网上性能优化的文章太多了，都说如何如何请求优化代码优化之类的，所有人都知道的事，而且实际工作中根本不可能每个项目都用到那些全部，而是应该对我们的项目有针对性的优化，你说是吗？

比如

说一下前端性能优化？

你平时是怎么做性能优化的？

等等类似这样的问题，不过就是换汤不换药罢了

好吧，先上药

这性能优化呢，它是一个特别大的方向，因为每个项目可能优化的点都不一样，每一种框架或者每一种客户端可以优化的点也都不一样

总的来说，现在B/S架构下都是前端向后端请求，后端整理好数据给客户端返回，然后客户端再进行数据处理、到渲染将界面展示出来，这么一个大致流程

那我们优化就是要基于这一过程，说白了我们能够优化的点，就只有两个大的方向

一是更快的网络通信，就是客户端和服务端之间，请求或响应时 数据在路上的时间让它更快

二是更快的数据处理，指的是

• 服务器接到请求之后，更快的整理出客户端需要的数据


• 客户端收到响应的数据后，更快的给用户展示 以及 交互时更快的处理

然后！开始blablabla.....

更快网络通信方面比如：CDN做全局负载均衡、CDN缓存、域名分片、资源合并、雪碧图、字体图标、http缓存，以减少请求；还有gzip/br压缩、代码压缩、减少头信息、减少Cookie、使用http2、用jpg/webp、去除元数据等等，blablabla.....

更快数据处理方面比如：SSR、SSG、预解析、懒加载、按需引入、按需加载、CSS放上面、JS放下面、语义化标签、动画能用CSS就不用JS、事件委托、减少重排、等等代码优化，blablabla.....

.....

请直接把上面的总结成一句话 给面试官

请求优化、代码优化、打包优化都是常规操作，像雅虎34条军规，都知道的事就不用说了

因为每个项目优化的点可能都不一样，所以优化主要 还是根据自己的项目来

要么跟人家聊一下框架优化，深入原理也很不错

具体要优化什么主要还是看浏览器(Chrome为例)开发者工具里的 Lighthouse 和 Performance

Lighthouse 是生成性能分析报告。可以看到每一项的数据和评分和建议优化的点，比如哪里图片过大

Performance 是运行时数据，可以看到更多细节数据。比如阻塞啊，重排重绘啊，都会体现出来，够不够细节

然后再去根据这些报告和性能指标体现出来的情况，有针对性的去不断优化我们的项目

Lighthouse

直接在Chrome开发者工具中打开

或者 Node 12.x或以上的版本可以直接安装在本地

npm install -g lighthouse

安装好后，比如生成掘金的性能分析报告，一句代码就够了，然后就会生成一个html文件

lighthouse https://juejin.cn/

不管是浏览器还是安装本地的，生成好的报告都是长的一模一样的，一个英文的html文件，翻译了一张给大家看看，如图

如图，分析报告内容一共五个大项，每一项满分100分，然后下面是再把每项分别展开说明

还是看一下英文版吧，一个程序员必须要养成这个习惯

如图，五项分别是：

• Performance：这个又分为三块性能指标、可优化的项、和手动诊断，看这一块就可以我们就可以优化很多东西了


• Accessibility：无障碍功能分析。比如前景色和背景色没有足够对比度、图片有没有alt属性、a链接有没有可识别名称等等


• Best Practices：最佳实践策略。比如图片纵横比不正确，控制台有没有报错信息等


• SEO：有没有SEO搜索引擎优化的一些东西


• PWA：官方说法是衡量站点是否快速、可靠和可安装。在国内浏览器内核不统一，小程序又这么火，所以好像没什么落地的场景

然后我们知道了这么多信息，是不是就可以对我们的项目诊断和针对性的优化了呢

是不是很棒

Performance

如果说 Lighthouse 是开胃菜，那 Performance 就是正餐了

它记录了网站运行过程中性能数据。我们回放整个页面执行过程的话，就可以定位和诊断每个时间段内页面运行情况，不过它没有性能评分，也没有优化建议，只是将采集到的数据按时间线的方式展现

打开 Performance，勾选 Memory，点击左边的 Record 开始录制，然后执行操作或者刷新页面，然后再点一下(Stop)就结束录制，生成数据

如图

概况面板

里面有页面帧速(FPS)、白屏时间、CPU资源消耗、网络加载情况、V8内存使用量(堆)等等，按时间顺序展示。

那么怎么看这个图表找到可能存在问题的地方呢

• 
  

  如果FPS(看图右上角)图表上出现红色块，就表示红色块附近渲染出一帧的时间太长了，就有可能导致卡顿

  
  


• 
  

  如果CPU图形占用面积太大，表示CPU使用率高，就可能是因为某个JS占用太多主线程时间，阻塞其他任务执行

  
  


• 
  

  如果V8的内存使用量一直在增加，就可能因为某种原因导致内存泄露

  
  
  
  
  • 一次查看内存占用情况后，看当前内存占用趋势图，走势呈上升趋势，可以认为存在内存泄露
  
  
  • 多次查看内存占用情况后截图对比，比较每次内存占用情况，如果呈上升趋势，也可以认为存在内存泄露
  
  
  
  

通过概览面板定位到可能存在问题的时间节点后，怎么拿到更进一步的数据来分析导致该问题的直接原因呢

就是点击时间线上有问题的地方，然后这一块详细内容就会显示在性能面板中

性能面板

比如我们点击时间线上的某个位置(如红色块)，性能面板就会显示该时间节点内的性能数据，如图

性能面板上会列出很多性能指标的项，图中左边，比如

• Main 指标：是渲染主线程的任务执行记录


• Timings 指标：记录如FP、FCP、LCP等产生一些关键时间点的数据信息(下面有介绍)


• Interactions 指标：记录用户交互操作


• Network 指标：是页面每个请求所耗时间


• Compositor 指标：是合成线程的任务执行记录


• GPU 指标：是GPU进程的主线程的任务执行记录


• Chrome_ChildIOThread 指标：是IO线程的任务执行记录，里面有用户输入事件，网络事件，设备相关等事件


• Frames 指标：记录每一帧的时间、图层构造等信息


• .......

Main 指标

性能指标项有很多，而我使用的时候多数时间都是分析Main指标，如图

上面第一行灰色的，写着 Task 的，一个 Task 就是一个任务

下面黄色紫色的都是啥呢，那是一个任务里面的子任务

我们放大，举个例子

Task 是一个任务，下面的就是 Task 里面的子任务，这个图用代码表示就是

function A(){

    A1()

    A2()

}

function Task(){

    A()

    B()

}

Task()

是不是就好理解得多了

所以我们就可以选中有问题的，比如标红的 Task ，然后放大(滑动鼠标就可放大)，看里面具体的耗时点

比如都做了哪些操作，哪些函数耗时了多少，代码有压缩的话看到的就是压缩后的函数名。然后我们点击一下某个函数，在面板最下面，就会出现代码的信息，是哪个函数，耗时多少，在哪个文件上的第几行等。这样我们就很方便地定位到耗时函数了

还可以横向切换 tab ，看它的调用栈等情况，更方便地找到对应代码

具体大家可以试试～

Timings 指标

Timings 指标也需要注意，如图

它上面的FP、FCP、DCL、L、LCP这些都是个啥呢

别着急

上面说了 Timings 表示一些关键时间点的数据信息，那么表示哪些时间呢，怎么表示的呢？

• 
  

  FP： 表示首次绘制。记录页面第一次绘制像素的时间

  
  


• 
  

  FCP：表示首次内容绘制（只有文本、图片(包括背景图)、非白色的canvas或SVG时才被算作FCP）

  
  


• 
  

  LCP：最大内容绘制，是代表页面的速度指标。记录视口内最大元素绘制时间，这个会随着页面渲染变化而变化

  
  


• 
  

  FID：首次输入延迟，代表页面交互体验的指标。记录FCP和TTI之间用户首次交互的时间到浏览器实际能够回应这种互动的时间

  
  


• 
  

  CLS：累计位移偏移，代表页面稳定的指标。记录页面非预期的位移，比如渲染过程中插入一张图片或者点击按钮动态插入一段内容等，这时候就会触发位移

  
  


• 
  

  TTI：首次可交互时间。指在视觉上已经渲染了，完全可以响应用户的输入了。是衡量应用加载所需时间并能够快速响应用户交互的指标。与FMP一样，很难规范化适用于所有网页的TTI指标定义

  
  


• 
  

  DCL: 表示HTML加载完成时间

  
  

  注意：DCL和L表示的时间在 Performance 和 NetWork 中是不同的，因为 Performance 的起点是点击录制的时间，Network中起点时间是 fetchStart 时间(检查缓存之前，浏览器准备好使用http请求页面文档的时间)

  
  


• 
  

  L：表示页面所有资源加载完成时间

  
  


• 
  

  TBT：阻塞总时间。记录FCP到TTI之间所有长任务的阻塞时间总和

  
  


• 
  

  FPS：每秒帧率。表示每秒钟画面更新次数，现在大多数设备是60帧/秒

  
  


• 
  

  FMP：首次有意义的绘制。是页面主要内容出现在屏幕上的时间，这是用户感知加载体验的主要指标。有点抽象，因为目前没有标准化的定义。因为很难用通用的方式来确定各种类型的页面的关键内容

  
  


• 
  

  FCI：首次CPU空闲时间。表示网页已经满足了最小程度的与用户发生交互行为的时间

  
  

好了，然后根据指标体现出来的问题，有针对性的优化就好

结语

点赞支持、手留余香、与有荣焉

感谢你能看到这里，加油哦！

wxs文件是小程序中的逻辑文件，它和wxml结合使用。

不同于js， wxs可以直接作用到视图层，而不需要进行视图层和逻辑层的setData数据交互；

因为这个特性，wxs非常适合应用于优化小程序的频繁交互操作中；

应用

过滤器

在IOS环境中wxs的运行速度要远高于js，在android中两者表现相当。

使用wxs作为过滤器也可以一定幅度提升性能；让我们来看一个过滤器来了解其语法。

wxs文件:

var toDecimal2 = function (x) {

  var f = parseFloat(x);

  if (isNaN(f)) {

    return '0.00'

  }

  var f = Math.round(x * 100) / 100;

  var s = f.toString();

  var rs = s.indexOf('.');

  if (rs < 0) {

    rs = s.length;

    s += '.';

  }

  while (s.length <= rs + 2) {

    s += '0';

  }

  return s;

}

module.exports = toDecimal2

上面的代码实现了数字保留两位小数的功能。

wxml文件：

<wxs src="./filter.wxs" module="filter"></wxs>

<text>{{filter(1)}}</text>

基本语法：在视图文件中通过wxs标签引入，module值是自定义命名，之后在wxml中可以通过filter调用方法

上面的代码展示了 wxs的运行逻辑，让我们可以像函数一样调用wxs中的方法；

下面再看一下wxs针对wxml页面事件中的表现。

拖拽

使用交互时（拖拽、上下滑动、左右侧滑等）如果依靠js逻辑层，会需要大量、频繁的数据通信。卡顿是不可避免的；

使用wxs文件替代交互，不需要频繁使用setData导致实时大量的数据通信,从而节省性能。

下面展示一个拖拽例子

wxs文件：

function touchstart(event) {

  var touch = event.touches[0] || event.changedTouches[0]

  startX = touch.pageX

  startY = touch.pageY

}

事件参数event和js中的事件event内容中touches和changedTouches属性一致

function touchmove(event, ins) {

  var touch = event.touches[0] || event.changedTouches[0]

  ins.selectComponent('.div').setStyle({

    left: startX - touch.pageX + 'px',

    top: startY - touch.pageY  + 'px'

  })

}

ins(第二个参数)为触发事件的视图层wxml上下文。可以查找页面所有元素并设置style,class(足够完成交互效果)

注意：在参数event中同样有一个上下文实例instance；

event中的实例instance作用范围是触发事件的元素内，而事件的ins参数作用范围是触发事件的组件内。

module.exports = {

  touchstart: touchstart,

  touchmove: touchmove,

}

最后将方法抛出去，给wxml文件引用。

wxml文件

<wxs module="action" src="./movable.wxs"></wxs> 

<view class="div" bindtouchstart="{{action.touchstart}}" bindtouchmove="{{action.touchmove}}"></view>

上面的例子，解释了事件的基本交互用法。

文件之中相互传参

在事件交互中，少不了需要各个文件之中传递参数。 下面是比较常用的几种

wxs传参到js逻辑层

wxs文件中：

var dragStart = function (e, ins) {

	ins.callMethod('callback','sldkfj')

}

js文件中：

callback(e){

	console.log(e)

}

// sldkfj

使用callMethod方法，可以执行js中的callback方法。也可以实现传参；

js逻辑层传参到wxs文件

js文件中：

handler(e){

	this.setData({a:1})

}

wxml文件：

<wxs module="action" src="./movable.wxs"></wxs> 

<view change:prop="{{action.change}}" prop="{{a}}"></view>

wxs文件中：

change(newValue,oldValue){}

js文件中的参数传递到wxs需要通过wxml文件中转。

js文件触发handler事件，改变a的值之后，最新的a传递到wxml中。

wxml中prop改变会触发wxs中的change事件。change中则会接收到最新prop值

wxs中获取dataset(wxs中获取wxml数据）

wxs中代码

var dragStart = function (e) {

  var index = e.currentTarget.dataset.index;

  var index = e.instance.getDataset().index;

}

上面有提到e.instance是当前触发事件的元素实例。

所以e.instance.getDataset()获取的是当前触发事件的dataset数据集

注意点

wxs和js为不同的两个脚本语言。但是语法和es5基本相同，确又不支持es6语法；
getState 在多元素交互中非常实用，欢迎探索。

不知道是否是支持的语法可以跳转官网文档；
wxs运算符、语句、基础类库、数据类型

介绍

Electron，官方简介：使用 JavaScript，HTML 和 CSS 构建跨平台的桌面应用程序。

出于个人爱好，接触到了Electron，并开始尝试开发一些本地小工具。

以下是对开发过程做的一个经验总结，便于回顾和交流。

使用

下面来构建一个简单的electron应用。

应用源码地址：github.com/zhuxingmin/…

1. 项目初始化

项目基于 create-react-app@3.3.0 搭建，执行命令生成项目

// 全局安装 create-react-app

npm install -g create-react-app



// 执行命令生成项目

create-react-app electronApp



// 安装依赖并启动项目

yarn && yarn start

此时启动的只是一个react应用，下一步安装 electron electron-updater electron-builder electron-is-dev等库

yarn add electron electron-updater electron-builder electron-is-dev

2. 配置package.json

安装完项目依赖后，在package.json中添加electron应用相关配置。

"version": "0.0.1"              // 设置应用版本号 

"productName": "appName"        // 设置应用名称

"main": "main.js"               // 设置应用入口文件

"homepage": "."                 // 设置应用根路径

在scripts中添加应用命令，启动以及打包。

"estart": "electron ."              // 启动

"package-win": "electron-builder"   // 打包 （此处以windows平台为例，故命名为package-win）

新增build配置项，添加打包相关配置。

主要有以下几个配置：

"build": {

    // 自定义appId 一般以安装路径作为id windows下可以在 PowerShell中输入Get-StartApps查看应用id

    "appId": "org.develar.zhuxingmin",

    // 打包压缩 "store" | "normal"| "maximum" 

    "compression": "store",

    // nsis安装配置

    "nsis": {

        "oneClick": false, // 一键安装

        "allowToChangeInstallationDirectory": true, // 允许修改安装目录

        // 下面这些配置不常用

        "guid": "haha",    // 注册表名字

        "perMachine": true, // 是否开启安装时权限限制（此电脑或当前用户）

        "allowElevation": true, // 允许请求提升。 如果为false，则用户必须使用提升的权限重新启动安装程序。

        "installerIcon": "xxx.ico", // 安装图标

        "uninstallerIcon": "xxx.ico", //卸载图标

        "installerHeaderIcon": "xxx.ico", // 安装时头部图标

        "createDesktopShortcut": true, // 创建桌面图标

        "createStartMenuShortcut": true, // 创建开始菜单图标

        "shortcutName": "lalala" // 图标名称

    },

    // 应用打包所包含文件

    "files": [

        "build/**/*",

        "main.js",

        "source/*",

        "service/*",

        "static/*",

        "commands/*"

    ],

    // 应用打包地址和输出地址

    "directories": {

        "app": "./",

        "output": "dist"

    },

    // 发布配置  用于配合自动更新

    "publish": [

        {

            // "generic" | "github"

            "provider": "generic", // 静态资源服务器

            "url": "http://你的服务器目录/latest.yml"

        }

    ],

    // 自定义协议  用于唤醒应用

    "protocols": [

        {

            "name": "myProtocol",

            "schemes": [

                "myProtocol"

            ]

        }

    ],

    // windows打包配置

    "win": {

        "icon": "build/fav.ico",

        // 运行权限 

        // "requireAdministrator" | "获取管理员权"

        // "highestAvailable"  | "最高可用权限"

        "requestedExecutionLevel": "highestAvailable",

        "target": [

            {

                "target": "nsis"

            }

        ]

    },

},

3. 编写入口文件 main.js

众所周知，基于react脚手架搭建的项目，入口文件为index.js，因此在上面配置完成后，我们想要启动electron应用，需要修改项目入口为main.js

1. 首先在目录下新建main.js文件，并在package.json文件中，修改应用入口字段main的值为main.js


2. 通过electron提供的BrowserWindow，创建一个窗口实例mainWindow


3. 通过mainWindow实例方法loadURL, 加载静态资源


4. 静态资源分两种加载方式：开发和生产；需要通过electron-is-dev判断当前环境；若是开发环境，可以开启调试入口，通过http://localhost:3000/加载本地资源（react项目启动默认地址）；若是生产环境，则要关闭调试入口，并通过本地路径找到项目入口文件index.html

大体代码如下

const { BrowserWindow } = require("electron");

const url = require("url");

const isDev = require('electron-is-dev');

mainWindow = new BrowserWindow({

    width: 1200,              // 初始宽度

    height: 800,              // 初始高度

    minWidth: 1200,

    minHeight: 675,

    autoHideMenuBar: true,    // 隐藏应用自带菜单栏

    titleBarStyle: false,     // 隐藏应用自带标题栏

    resizable: true,          // 允许窗口拉伸

    frame: false,             // 隐藏边框

    transparent: true,        // 背景透明

    backgroundColor: "none",  // 无背景色

    show: false,              // 默认不显示

    hasShadow: false,         // 应用无阴影

    modal: true,              // 该窗口是否为禁用父窗口的子窗口

    webPreferences: {

      devTools: isDev,     // 是否开启调试功能

      nodeIntegration: true,  // 默认集成node环境

    },

});



const config = dev

    ? "http://localhost:3000/"

    : url.format({

        pathname: path.join(__dirname, "./build/index.html"),

        protocol: "file:",

        slashes: true,

      });



mainWindow.loadURL(config);

4. 项目启动

项目前置操作完成，运行上面配置的命令来启动electron应用

   // 启动react应用，此时应用运行在"http://localhost:3000/"

   yarn start 

   // 再启动electron应用，electron应用会在入口文件`main.js`中通过 mainWindow.loadURL(config) 来加载react应用

   yarn estart 

文件目录

至此，一个简单的electron应用已经启动，效果图如下（这是示例项目的截图）。

作为一个客户端应用，它的更新与我们的网页开发相比要显得稍微复杂一些，具体将会通过下面一个应用更新的例子来说明。

5. 应用更新

electron客户端的更新与网页不同，它需要先下载更新包到本地，然后通过覆盖源文件来达到更新效果。

首先第一步，安装依赖

yarn add electron-updater electron-builder

复制代码

应用通过electron-updater提供的api，去上文配置的服务器地址寻找并对比latest.yml文件，如果版本号有更新，则开始下载资源，并返回下载进度相关信息。下载完成后可以自动也可以手动提示用户，应用有更新，请重启以完成更新 （更新是可以做到无感的，下载完更新包之后，可以不提示，下次启动客户端时会自动更新）

// 主进程

const { autoUpdater } = require("electron-updater");

const updateUrl = "应用所在的远程服务器目录"

const message = {

    error: "检查更新出错",

    checking: "正在检查更新……",

    updateAva: "检测到新版本，正在下载……",

    updateNotAva: "现在使用的就是最新版本，不用更新",

};

autoUpdater.setFeedURL(updateUrl);

autoUpdater.on("error", (error) => {

    sendUpdateMessage("error", message.error);

});

autoUpdater.on("checking-for-update", () => {

    sendUpdateMessage("checking-for-update", message.checking);

});

autoUpdater.on("update-available", (info) => {

    sendUpdateMessage("update-available", message.updateAva);

});

autoUpdater.on("update-not-available", (info) => {

    sendUpdateMessage("update-not-available", message.updateNotAva);

});

// 更新下载进度事件

autoUpdater.on("download-progress", (progressObj) => {

    mainWindow.webContents.send("downloadProgress", progressObj);

});

autoUpdater.on("update-downloaded", function (

    event,

    releaseNotes,

    releaseName,

    releaseDate,

    updateUrl,

    quitAndUpdate

) {

    ipcMain.on("isUpdateNow", (e, arg) => {

        // 接收渲染进程的确认消息  退出应用并更新

        autoUpdater.quitAndInstall();

    });

    //询问是否立即更新

    mainWindow.webContents.send("isUpdateNow");

});

ipcMain.on("checkForUpdate", () => {

    //检查是否有更新

    autoUpdater.checkForUpdates();

});



function sendUpdateMessage(type, text) {

  // 将更新的消息事件通知到渲染进程

  mainWindow.webContents.send("message", { text, type });

}

// 渲染进程

const { ipcRenderer } = window.require("electron");



// 发送检查更新的请求

ipcRenderer.send("checkForUpdate");



// 设置检查更新的监听频道



// 监听检查更新事件

ipcRenderer.on("message", (event, data) => {

  console.log(data)

});



// 监听下载进度

ipcRenderer.on("downloadProgress", (event, data) => {

  console.log("downloadProgress: ", data);

});



// 监听是否可以开始更新

ipcRenderer.on("isUpdateNow", (event, data) => {

   // 用户点击确定更新后，回传给主进程

   ipcRenderer.send("isUpdateNow");

});

应用更新的主要步骤

1. 在主进程中，通过api获取远程服务器上是否有更新包


2. 对比更新包的版本号来确定是否更新


3. 对比结果如需更新，则开始下载更新包并返回当前下载进度


4. 下载完成后，开发者可选择自动提示还是手动提示或者不提醒（应用在下次启动时会自动更新）

上文演示了在页面上（渲染进程），是如何与主进程进行通信，让主进程去检查更新。

在实际使用中，如果我们需要用到后台的能力或者原生功能时，主进程与渲染进程的交互必不可少。

那么他们有哪些交互方式呢？

在看下面的代码片段之前，可以先了解一下electron主进程与渲染进程
简单来说就是，通过main.js来执行的都属于主进程，其余皆为渲染进程。

6. 主进程与渲染进程间的常用交互方式

// 主进程中使用

const { ipcMain } = require("electron");



// 渲染进程中使用

const { ipcRenderer } = window.require("electron");

方式一

渲染进程 发送请求并监听回调频道

ipcRenderer.send(channel, someRequestParams)；

ipcRenderer.on(`${channel}-reply`, (event, result)=>{

    // 接收到主进程返回的result

})

主进程 监听请求并返回结果

ipcMain.on(channel, (event, someRequestParams) => {

    // 根据someRequestParams，经过操作后得到result

    event.reply(`${channel}-reply`, result)

})

方式二

渲染进程

const result = await ipcRenderer.invoke(channel, someRequestParams);

主进程：

ipcMain.handle(channel, (event, someRequestParams) => {

    // 根据someRequestParams，经过操作后得到result

    return result

});

方式三
以上两种方式均为渲染进程通知主进程， 第三种是主进程通知渲染进程

主进程

/*

 * 使用`BrowserWindow`初始化的实例`mainWindow`

 */ 

mainWindow.webContents.send(channel, something)

渲染进程

ipcRenderer.on(channel, (event, something) => {

    // do something

})

上文的应用更新用的就是方式一。

还有其它通讯方式postMessage, sendTo等，可以根据具体场景决定使用何种方式。

7. 应用唤醒（与其他应用联动）

electron应用除了双击图标运行之外，还可以通过协议链接启动（浏览器地址栏或者命令行）。这使得我们可以在网页或者其他应用中，以链接的形式唤醒该应用。链接可以携带参数 例：zhuxingmin://?a=1&b=2&c=3 ‘自定义协议名：zhuxingmin’ ‘参数：a=1&b=2&c=3’。

我们可以通过参数，来使应用跳转到某一页或者让应用做一些功能性动作等等。

const path = require('path');

const { app } = require('electron');



// 获取单实例锁

const gotTheLock = app.requestSingleInstanceLock();



// 如果获取失败，证明已有实例在运行，直接退出

if (!gotTheLock) {

  app.quit();

}



const args = [];

// 如果是开发环境，需要脚本的绝对路径加入参数中

if (!app.isPackaged) {

  args.push(path.resolve(process.argv[1]));

}

// 加一个 `--` 以确保后面的参数不被 Electron 处理

args.push('--');

const PROTOCOL = 'zhuxingmin';

// 设置自定义协议

app.setAsDefaultProtocolClient(PROTOCOL, process.execPath, args);



// 如果打开协议时，没有其他实例，则当前实例当做主实例，处理参数

handleArgv(process.argv);



// 其他实例启动时，主实例会通过 second-instance 事件接收其他实例的启动参数 `argv`

app.on('second-instance', (event, argv) => {

  if (process.platform === 'win32') {

    // Windows 下通过协议URL启动时，URL会作为参数，所以需要在这个事件里处理

    handleArgv(argv);

  }

});



// macOS 下通过协议URL启动时，主实例会通过 open-url 事件接收这个 URL

app.on('open-url', (event, urlStr) => {

  handleUrl(urlStr);

});



function handleArgv(argv) {

  const prefix = `${PROTOCOL}:`;

  const offset = app.isPackaged ? 1 : 2;

  const url = argv.find((arg, i) => i >= offset && arg.startsWith(prefix));

  if (url) handleUrl(url);

}



function handleUrl(urlStr) {

  // myapp://?a=1&b=2

  let paramArr = urlStr.split("?")[1].split("&");

  const params = {};

  paramArr.forEach((item) => {

      if (item) {

        const [key, value] = item.split("=");

        params[key] = value;

      }

  });

  /**

  {

    a: 1,

    b: 2

  }

  */ 

}

项目背景

H5 项目是企鹅辅导的核心项目，已迭代四年多，包括了课程详情页/老师详情页/报名页/支付页面等页面，构建产物用于企鹅辅导 APP/H5（微信/QQ/浏览器），迭代过程中了也累积了一些性能问题导致页面加载、渲染速度变慢， 为了提升用户体验，近期启动了“H5 性能优化”项目，针对页面加载速度，渲染速度做了专项优化，下面是对本次优化的总结，包括以下几部分内容。

1. 性能优化效果展示


2. 性能指标及数据采集


3. 性能分析方法及环境准备


4. 性能优化具体实践

一、性能指标及数据采集

企鹅辅导 H5 采用的性能指标包括：

1.页面加载时间：页面以多快的速度加载和渲染元素到页面上。

• First contentful paint (FCP)： 测量页面开始加载到某一块内容显示在页面上的时间。


• Largest contentful paint (LCP)： 测量页面开始加载到最大文本块内容或图片显示在页面中的时间。


• DomContentLoaded Event：DOM解析完成时间


• OnLoad Event：页面资源加载完成时间

2.加载后响应时间：页面加载和执行js代码后多久能响应用户交互。

• First input delay (FID)： 测量用户首次与网站进行交互(例如点击一个链接、按钮、js自定义控件)到浏览器真正进行响应的时间。

3.视觉稳定性：页面元素是否会以用户不期望的方式移动，并干扰用户的交互。

• Cumulative layout shift (CLS)： 测量从页面开始加载到状态变为隐藏过程中，发生不可预期的layout shifts的累积分数。

项目使用了 IMLOG 进行数据上报，ELK 体系进行现网数据监控，Grafana 配置视图，观察现网情况。

根据指标的数据分布，能及时发现页面数据异常采取措施。

二、性能分析及环境准备

现网页面情况：

可以看到进度条在页面已经展示后还在持续 loading，加载时间长达十几秒，比较影响了用户体验。

根据 Google 开发文档 对浏览器架构的解释：

当导航提交完成后，渲染进程开始着手加载资源以及渲染页面。一旦渲染进程“完成”（finished）渲染，它会通过IPC告知浏览器进程（注意这发生在页面上所有帧（frames）的 onload 事件都已经被触发了而且对应的处理函数已经执行完成了的时候），然后UI线程就会停止导航栏上旋转的圈圈

我们可以知道，进度条的加载时长和 onload 时间密切相关，要想进度条尽快结束就要 减少 onload时长。

根据现状，使用ChromeDevTool作为基础的性能分析工具，观察页面性能情况

Network：观察网络资源加载耗时及顺序

Performace：观察页面渲染表现及JS执行情况

Lighthouse：对网站进行整体评分，找出可优化项

下面以企鹅辅导课程详情页为案例进行分析，找出潜在的优化项

（注意使用Chrome 隐身窗口并禁用插件，移除其他加载项对页面的影响）

1. Network 分析

通常进行网络分析需要禁用缓存、启用网络限速（4g/3g） 模拟移动端弱网情况下的加载情况，因为wifi网络可能会抹平性能差距。

可以看到DOMContentLoaded的时间在 6.03s ，但onload的时间却在 20.92s

先观察 DOMContentLoaded 阶段，发现最长请求路径在 vendor.js ，JS大小为170kB，花费时间为 4.32s

继续观察 DOMContentLoaded 到 onload 的这段时间

可以发现onload事件被大量媒体资源阻塞了，关于 onload 事件的影响因素，可以参考这篇文章

结论是 浏览器认为资源完全加载完成（HTML解析的资源 和 动态加载的资源）才会触发 onload

结合上图 可以发现加载了图片、视频、iFrame等资源，阻塞了 onload 事件的触发

Network 总结

1. DOM的解析受JS加载和执行的影响，尽量对JS进行压缩、拆分处理（HTTP2下），能减少 DOMContentLoaded 时间


2. 图片、视频、iFrame等资源，会阻塞 onload 事件的触发，需要优化资源的加载时机，尽快触发onload

2. Performance 分析

使用Performance模拟移动端注意手机处理器能力比PC差，所以一般将 CPU 设置为 4x slowdown 或 6x slowdown 进行模拟

观察几个核心的数据

1. Web Vitals ( FP / FCP / LCP / Layout Shift ) 核心页面指标 和 Timings 时长

可以看到 LCP、DCL和 Onload Event 时间较长，且出现了多次 Layout Shift。

要 LCP 尽量早触发，需要减少页面大块元素的渲染时间，观察 Frames 或ScreenShots 的截图，关注页面的元素渲染情况。

可以通过在 Experience 行点击Layout Shift ，在 Summary 面板找到具体的偏移内容。

2. Main Long Tasks 长任务数量和时长

可以看到页面有大量的Long Tasks需要进行优化，其中couse.js(页面代码)的解析执行时间长达800ms。

处理Long Tasks，可以在开发环境进行录制，这样在 Main Timeline 能看到具体的代码执行文件和消耗时长。

Performance 总结

1. 页面LCP触发时间较晚，且出现多次布局偏移，影响用户体验，需要尽早渲染内容和减少布局偏移


2. 页面 Long Tasks 较多，需要对 JS进行合理拆分和加载，减少 Long Tasks 数量，特别是 影响 DCL 和 Onload Event 的 Task

3. Lighthouse 分析

使用ChromeDevTool 内置 lighthouse 对页面进行跑分

分数较低，可以看到 Metrics 给出了核心的数据指标，这边显示的是 TTI SI TBT 不合格，LCP 需要提升，FCP 和 CLS 达到了良好的标准，可以查看分数计算标准

同时 lighthouse 会提供一些 优化建议，在 Oppotunities 和 Diagnostics 项，能看到具体的操作指南，如 图片大小、移除无用JS等，可以根据指南进行项目的优化。

lighthouse 的评分内容是根据项目整体加载项目进行打分的，审查出的问题同样包含Network、Performance的内容，所以也可以看作是对 Network、Performance问题的优化建议。

Lighthouse 总结

1. 根据评分，可以看出 TTI、SI、TBT、LCP这四项指标需要提高，可以参考lighthouse 文档进行优化。


2. Oppotunities 和 Diagnostics 提供了具体的优化建议，可以参考进行改善。

4. 环境准备

刚才是对线上网页就行初步的问题分析，要实际进行优化和观察，需要进行环境的模拟，让优化效果能更真实在测试环境中体现。

代理使用：whistle、charles、fiddler等

本地环境、测试环境模拟：nginx、nohost、stke等

数据上报：IMLOG、TAM、RUM等

前端代码打包分析：webpack-bundle-analyzer 、rollup-plugin-visualizer等

分析问题时使用本地代码，本地模拟线上环境验证优化效果，最后再部署到测试环境验证，提高开发效率。

三、性能优化具体实践

PART1: 加载时间优化

Network 中对页面中加载的资源进行分类

第一部分是影响 DOM解析的JS资源，可以看到这里分类为 关键JS和非关键JS，是根据是否参与首面渲染划分的

这里的非关键JS我们可以考虑延迟异步加载，关键JS进行拆分优化处理

1. 关键JS打包优化

JS 文件数量8个，总体积 460.8kB，最大文件 170KB

1.1 Splitchunks 的正确配置

vendor.js 170kB(gzipd) 是所有页面都会加载的公共文件，打包规则是 miniChunks: 3，引用超过3次的模块将被打进这个js

分析vendor.js的具体构成（上图）

以string-strip-html.umd.js 为例 大小为34.7KB，占了 vendor.js的 20%体积，但只有一个页面多次使用到了这个包，触发了miniChunks的规则，被打进了vendor.js。

同理对vendor.js的其他模块进行分析，iosSelect.js、howler.js、weixin-js-sdk等模块都只有3、4个页面/组件依赖，但也同样打进了 vendor.js。

由上面的分析，我们可以得出结论：不能简单的依靠miniChunks规则对页面依赖模块进行抽离打包，要根据具体情况拆分公共依赖。

修改后的vendor根据业务具体的需求，提取不同页面和组件都有的共同依赖（imutils/imlog/qqapi）

vendor: {

  test({ resource }) {

    return /[\\/]node_modules[\\/](@tencent\/imutils|imlog\/)|qqapi/.test(resource);

  },

  name: 'vendor',

  priority: 50,

  minChunks: 1,

  reuseExistingChunk: true,

},

而其他未指定的公共依赖，新增一个common.js，将阈值调高到20或更高（当前页面数76），让公共依赖成为大多数页面的依赖，提高依赖缓存利用率，调整完后，vendor.js 的大小减少到 30KB，common.js 大小为42KB

两个文件加起来大小为 72KB，相对于优化前体积减少了 60%（100KB）

1.2 公共组件的按需加载

course.js 101kB (gzipd) 这个文件是页面业务代码的文件

观察上图，基本都是业务代码，除了一个巨大的** component Icon，占了 25k**，页面文件1/4的体积，但在代码中使用到的 Icon 总共才8个

分析代码，可以看到这里使用require加载svg，Webpack将require文件夹内的内容一并打包，导致页面 Icon 组件冗余

如何解决这类问题实现按需加载？

按需加载的内容应该为独立的组件，我们将之前的单一入口的 ICON 组件（动态dangerouslySetInnerHTML）改成单文件组件模式直接引入使用图标。

但实际开发中这样会有些麻烦，一般需要统一的 import 路径，指定需要的图标再加载，参考 babel-plugin-import，我们可以配置 babel 的依赖加载路径调整 Icon 的引入方式，这样就实现了图标的按需加载。

按需加载后，重新编译，查看打包带来的收益，页面的 Icons 组件 stat size 由 74KB 降到了 20KB，体积减少了 70%

1.3 业务组件的代码拆分 (Code Splitting)

观察页面，可以看到”课程大纲“、”课程详情“、”购课须知“这三个模块并不在页面的首屏渲染内容里，

我们可以考虑对页面这几部分组件进行拆分再延迟加载，减少业务代码JS大小和执行时长

拆分的方式很多，可以使用react-loadable、@loadable/component 等库实现，也可以使用React 官方提供的React.lazy

拆分后的代码

代码拆分会导致组件会有渲染的延迟，所以在项目中使用应该综合用户体验和性能再做决定，通过拆分也能使部分资源延后加载优化加载时间。

1.4 Tree Shaking 优化

项目中使用了 TreeShaking的优化，用时候要注意 sideEffects 的使用场景，以免打包产物和开发不一致。

经过上述优化步骤，整体打包内容：

JS 文件数量6个，总体积 308KB，最大文件体积 109KB

关键 JS 优化数据对比：

2.非关键 JS 延迟加载

页面中包含了一些上报相关的 JS 如 sentry，beacon（灯塔 SDK）等，对于这类资源，如果在弱网情况，可能会成为影响 DOM 解析的因素

为了减少这类非关键JS的影响，可以在页面完成加载后再加载非关键JS，如sentry官方也提供了延迟加载的方案

在项目中还发现了一部分非关键JS，如验证码组件，为了在下一个页面中能利用缓存尽快加载，所以在上一个页面提前加载一次生成缓存

如果不访问下一个页面，可以认为这是一次无效加载，这类的提前缓存方案反而会影响到页面性能。

针对这里资源，我们可以使用 Resource Hints，针对资源做 Prefetch 处理

检测浏览器是否支持 prefech，支持的情况下我们可以创建 Prefetch 链接，不支持就使用旧逻辑直接加载，这样能更大程度保证页面性能，为下一个页面提供提前加载的支持。

const isPrefetchSupported = () => {

  const link = document.createElement('link');

  const { relList } = link;

 

  if (!relList || !relList.supports) {

    return false;

  }

  return relList.supports('prefetch');

};

const prefetch = () => {

    const isPrefetchSupport = isPrefetchSupported();

    if (isPrefetchSupport) {

      const link = document.createElement('link');

      link.rel = 'prefetch';

      link.as = type;

      link.href = url;

      document.head.appendChild(link);

    } else if (type === 'script') {

            // load script

    }

  };

优化效果：非关键JS不影响页面加载

3.媒体资源加载优化

3.1 加载时序优化

可以观察到onload被大量的图片资源和视频资源阻塞了，但是页面上并没有展示对应的图片或视频，这部分内容应该进行懒加载处理。

处理方式主要是要控制好图片懒加载的逻辑（如 onload 后再加载），可以借助各类 lazyload 的库去实现。 H5项目用的是位置检测（getBoundingClientRect ）图片到达页面可视区域再展示。

但要注意懒加载不能阻塞业务的正常展示，应该做好超时处理、重试等兜底措施

3.2 大小尺寸优化

课程详情页 每张详情图的宽为 1715px，以6s为基准（375px）已经是 4x图了，大图片在弱网情况下会影响页面加载和渲染速度

使用CDN 图床尺寸大小压缩功能，根据不同的设备渲染不同大小的图片调整图片格式，根据网络情况，渲染不同清晰度的图

可以看到在弱网（移动3G网络）的情况下，同一张图片不同尺寸加载速度最高和最低相差接近6倍，给用户的体验截然不同

CDN配合业务具体实现：使用 img 标签 srcset/sizes 属性和 picutre 标签实现响应式图片，具体可参考文档

使用URL动态拼接方式构造url请求，根据机型宽度和网络情况，判断当前图片宽度倍数进行调整（如iphone 1x，ipad 2x，弱网0.5x）

优化效果：移动端 正常网络情况下图片体积减小 220%、弱网情况下图片体积减小 13倍

注意实际业务中需要视觉同学参与，评估图片的清晰度是否符合视觉标准，避免反向优化！

3.3 其他类型资源优化

iframe

加载 iframe 有可能会对页面的加载产生严重的影响，在 onload 之前加载会阻塞 onload 事件触发，从而阻塞 loading，但是还存在另一个问题

如下图所示，页面在已经 onload 的情况下触发 iframe 的加载，进度条仍然在不停的转动，直到 iframe 的内容加载完成。

可以将iframe的时机放在 onload 之后，并使用setTimeout触发异步加载iframe，可避免iframe带来的loading影响

数据上报

项目中使用 image 的数据上报请求，在正常网络情况下可能感受不到对页面性能的影响

但在一些特殊情况，如其中一个图片请求的耗时特别长就会阻塞页面 onload 事件的触发，延长 loading 时间

解决上报对性能的影响问题有以下方案

1. 延迟合并上报


2. 使用 Beacon API


3. 使用 post 上报

H5项目采用了延迟合并上报的方案，业务可根据实际需要进行选择

优化效果：全部数据上报在onload后处理，避免对性能产生影响。

字体优化

项目中可能会包含很多视觉指定渲染的字体，当字体文件比较大的时候，也会影响到页面的加载和渲染，可以使用 fontmin 将字体资源进行压缩，生成精简版的字体文件、

优化前：20kB => 优化后：14kB

PART2: 页面渲染优化

1.直出页面 TTFB 时间优化

目前我们在STKE部署了直出服务，通过监控发现直出平均耗时在 300+ms

TTFB时间在 100 ～ 200 之间波动，影响了直出页面的渲染

通过日志打点、查看 Nginx Accesslog 日志、网关监控耗时，得出以下数据（如图）

• STKE直出程序耗时是 20ms左右


• 直出网关NGW -> STKE 耗时 60ms 左右


• 反向代理网关NGINX -> NGW 耗时 60ms 左右

登陆 NGW 所在机器，ping STKE机器，有以下数据

平均时延在 32ms，tcp 三次握手+返回数据（最后一次 ack 时发送数据）= 2个 rtt，约 64ms，和日志记录的数据一致

查看 NGW 机器所在区域为天津，STKE 机器所在区域为南京，可以初步判断是由机房物理距离导致的网络时延，如下图所示

切换NGW到南京机器 ping STKE南京的机器，有以下数据：

同区域机器 ping 的网络时延只有 0.x毫秒，如下图所示：

综合上述分析，直出页面TTFB时间过长的根本原因是：NGW 网关部署和 Nginx、STKE 不在同一区域，导致网络时延的产生

解决方案是让网关和直出服务机房部署在同一区域，执行了以下操作：

• NGW扩容


• 北极星开启就近访问

优化前

优化后

优化效果如上图：

2.页面渲染时间优化

模拟弱网情况（slow 3g）Performance 录制页面渲染情况，从下图Screenshot中可以发现

1. DOM 开始解析，但页面还未渲染


2. CSS 文件下载完成后页面才正常渲染

CSS不会阻塞页面解析，但会阻塞页面渲染，如果CSS文件较大或弱网情况，会影响到页面渲染时间，影响用户体验。

借助 ChromeDevTool 的 Coverage 工具（More Tools里面），录制页面渲染时CSS的使用率

发现首屏的CSS使用率才15%，可以考虑对页面首屏的关键CSS进行内联，让页面渲染不被CSS阻塞，再把完整CSS加载进来

实现Critial CSS 的优化可以考虑使用 critters

优化后效果：

CSS 资源正在下载时，页面已经能正常渲染显示了，对比优化前，渲染时间上 提升了 1～2 个 css 文件加载的时间。

3. 页面布局抖动优化

观察页面的元素变化

优化前（左图）：图标缺失、背景图缺失、字体大小改变导致页面抖动、出现非预期页面元素导致页面抖动

优化后：内容相对固定， 页面元素出现无突兀感

主要优化内容：

1. 确定直出页面元素出现位置，根据直出数据做好布局


2. 页面小图可以通过base64处理，页面解析的时候就会立即展示


3. 减少动态内容对页面布局的影响，使用脱离文档流的方式或定好宽高

四、性能优化效果展示

优化效果由以下指标量化

首次内容绘制时间FCP（First Contentful Paint）：标记浏览器渲染来自 DOM 第一位内容的时间点

视窗最大内容渲染时间LCP（Largest Contentful Paint）：代表页面可视区域接近完整渲染

加载进度条时间：浏览器 onload 事件触发时间，触发后导航栏进度条显示完成

Chrome 模拟器 4G 无缓存对比（左优化前、右优化后）

Lighthouse 跑分对比

优化前

优化后

srobot 性能检测一周数据

srobot 是团队内的性能检测工具，使用TRobot指令一键创建页面健康检测，定时自动化检测页面性能及异常

优化前

优化后

五、优化总结和未来规划

1. 以上优化手段主要是围绕首次加载页面的耗时和渲染优化，但二次加载还有很大的优化空间 如 PWA 的使用、非直出页面骨架屏处理、CSR 转 SSR等。


2. 对比竞品发现我们 CDN 的下载耗时较长，近期准备启动 CDN 上云，期待上云后 CDN 的效果提升。


3. 项目迭代一直在进行，需要思考在工程上如何持续保障页面性能


4. 上文是围绕课程详情页进行的分析和优化处理，虽然对项目整体做了优化处理，但性能优化没有银弹，不同页面的优化要根据页面具体需求进行，需要开发同学主动关注。

前言

没有无缘无故的爱，也没有无缘无故的恨，当然也没有无缘无故的 code review

为什么要 CR

给大家讲个故事，“大神 A”上班时突然恼羞成怒的骂道，这是谁写的代码，没有注释啥也没有，这么明显的 bug。当时整个小组都不敢说话，慌的要死，生怕说的就是自己。领导发话：“大神 A”查下提交记录，谁提交的谁请吃饭。过了两分钟，“大神 A”：这，这是我自己一年前提交的。所以不想自己尴尬，赶紧 code review 吧

一、角色职能

author 即需求开发者。要求：

1. 注重注释。对复杂业务写明相应注释，commit 写名具体提交背景，便于 reviewer 理解。


2. 端正心态接受他人 review。对 reviewer 给出的 comment，不要有抵触的情绪，对你觉得不合理的建议，可以委婉地进行拒绝，或者详细说明自己的看法以及原因。reviewer 持有的观点并不一定是合理的，所以 review 也是一个相互学习的过程。


3. 完成 comment 修改后及时反馈。commit 提交信息备注如"reivew: xxxx"，保证复检效率。

reviewer 作为 cr 参与者，建议由项目责任人和项目参与者组成。要求：

1. 说明 comment 等级。reviewer 对相应代码段提出评价时，需要指明对应等级，如
   
   
   
   • fix: xxxxxxx 此处需强制修改，提供修改建议
   
   
   • advise: xxxxxxx 此处主观上建议修改，不强制，可提供修改建议
   
   
   • question: xxxxxx 此处存在疑虑，需要 author 作出解释
   
   
   
   


2. 友好 comment。评价注意措辞，可以说“我们可以如何去调整修改，可能会更合适。。。”，对于比较好的代码，也应该给与足够的赞美。


3. 享受 review。避免以挑毛病的心态 review，好的 reviewer 并不是以提的问题多来衡量的。跳出自己的编码风格，主动理解 author 的思路，也是一个很好的学习过程。

二、CR 流程

1、self-review

• commit 之前要求 diff 一下，查看文件变更情况，可接着 gitk 完成。当然如果项目使用 pre-commit 关联 lint 校验，也能发现例如 debugger、console.log 之类语句。但是仍然提倡大家每次提交之前检查一下提交文件。


• 多人协作下的 commit。多人合作下的分支在合并请求时，需要关注是否带入没必要的 commit。


• commit message。建议接入 husky、commitlint/cli 以及 commitlint/config-conventional 校验 commit message。commitlint/config-conventional 所提供的类型如
  
  
  
  • feat: 新特性
  
  
  • fix: 修改 bug
  
  
  • chore: 优化，如项目结构，依赖安装更新等
  
  
  • docs: 文档变更
  
  
  • style: 样式相关修改
  
  
  • refactor：项目重构
  
  
  
  

此目的为了进一步增加 commit message 信息量，帮助 reviewer 以及自己更有效的了解 commit 内容。

2、CR

1. 提测时发起 cr，需求任务关联 reviewer。提供合并请求，借助 gitlab/sourcetree/vscode gitlens 等工具。reviewer 结束后给与反馈


2. 针对 reviewer 提出的建议修改之后，commit message 注明类似'review fix'相关信息，便于 reviewer 复检。


3. 紧急需求，特事特办，跳过 cr 环节，事后 review。

三、CR 标准

1. 不纠结编码风格。编码风格交给 eslint/tslint/stylelint


2. 代码性能。大数据处理、重复渲染等


3. 代码注释。字段注释、文档注释等


4. 代码可读性。过多嵌套、低效冗余代码、功能独立、可读性变量方法命名等


5. 代码可扩展性。功能方法设计是否合理、模块拆分等


6. 控制 review 时间成本。reviewer 尽量由项目责任人组成，关注代码逻辑，无需逐字逐句理解。

四、最后

总的来说，cr 并不是一个找 bug 挑毛病的过程，更不会降低整体开发效率。其目的是为了保证项目的规范性，使得其他开发人员在项目扩展和维护时节省更多的时间和精力。当然 cr 环节需要团队每一个成员去推动，只有每一个人都认可且参与进来，才能发挥 cr 的最大价值。

最后安利一波本人开发vscode小插件搭配gitlab进行review。因为涉及内部代码，暂时不能对外开放，这里暂时提供思路，后续开放具体代码。

Hook 是 React 16.8.0 版本增加的新特性，可以在函数组件中使用 state 以及其他的 React 特性。

✌️为什么要使用 Hook？

• 
  

  在组件之间复用状态逻辑很难

  
  

  由providers，consumers，高阶组件，render props等其他抽象层组成的组件会形成嵌套地狱，使用 Hook 可以从组件中提取状态逻辑，使得这些逻辑可以单独测试并复用。Hook 使你在无需修改组件结构的情况下复用状态逻辑。

  
  


• 
  

  复杂组件难以理解

  
  

  每个生命周期常常包含一些不相关的逻辑。例如，组件常常在 componentDidMount 和 componentDidUpdate 中获取数据。但是，同一个 componentDidMount 中可能也包含很多其它的逻辑，如设置事件监听，而之后需在 componentWillUnmount 中清除。相互关联且需要对照修改的代码被进行了拆分，而完全不相关的代码却在同一个方法中组合在一起。

  
  


• 
  

  难以理解的 class

  
  

下面介绍几个常用的Hook。

2. useState

useState让函数组件也可以有state状态，并进行状态数据的读写操作。

const [xxx, setXxx] = useState(initValue); // 解构赋值

📐useState() 方法

参数：

第一次初始化指定的值在内部作缓存。可以按照需要使用数字或字符串对其进行赋值，而不一定是对象。

如果想要在state中存储两个不同的变量，只需调用 useState() 两次即可。

返回值：

包含2个元素的数组，第1个为内部当前状态值，第2个为更新状态值的函数，一般直接采用解构赋值获取。

📐setXxx() 的写法

setXxx(newValue)：参数为非函数值，直接指定新的状态值，内部用其覆盖原来的状态值。

setXxx(value => newValue)：参数为函数，接收原本的状态值，返回新的状态值，内部用其覆盖原来的状态值。

📐 完整示例

const App = () => {

    const [count, setCount] = useState(0);



    const add = () => {

        // 第一种写法

        // setCount(count + 1);

        // 第二种写法

        setCount(count => count + 1);

    };



    return (

        <Fragment>

            <h2>当前求和为：{count}</h2>

            <button onClick={add}>点我+1</button>

        </Fragment>

    );

};

useState就是一个 Hook，唯一的参数就是初始state，在这里声明了一个叫count的 state 变量，然后把它设为0。React会在重复渲染时记住它当前的值，并且提供最新的值给我们的函数。我们可以通过调用setCount来更新当前的count。

在函数中，我们可以直接用 count：

<h2>当前求和为：{count}</h2>

更新state：

setCount(count + 1);

setCount(count => count + 1);

📐 使用多个 state 变量

可以在一个组件中多次使用State Hook：

// 声明多个 state 变量

const [age, setAge] = useState(42);

const [fruit, setFruit] = useState('banana');

const [todos, setTodos] = useState([{ text: '学习 Hook' }]);

📌不是必须要使用多个state变量，仍然可以将相关数据分为一组。但是，不像 class 中的 this.setState，useState中更新state变量是替换。不是合并。

3. useEffect

useEffect可以在函数组件中执行副作用操作（用于模拟类组件中的生命周期钩子）。

React 中的副作用操作：

• 发 ajax 请求数据获取


• 设置订阅 / 启动定时器


• 手动更改真实 DOM

📐 使用规则

useEffect(() => {

    // 在此可以执行任何带副作用操作

    // 相当于componentDidMount()

    return () => {

        // 在组件卸载前执行

        // 在此做一些收尾工作, 比如清除定时器/取消订阅等

        // 相当于componentWillUnmount()

    };

}, [stateValue]); // 监听stateValue

// 如果省略数组，则检测所有的状态，状态有更新就又调用一次回调函数

// 如果指定的是[], 回调函数只会在第一次render()后执行一次

可以把 useEffect 看做如下三个函数的组合：

• componentDidMount()


• componentDidUpdate()


• componentWillUnmount()

📐 每次更新的时候都运行 Effect

// ...

useEffect(() => {

    // ...

    ChatAPI.subscribeToFriendStatus(props.friend.id, handleStatusChange);

    return () => {

        ChatAPI.unsubscribeFromFriendStatus(props.friend.id, handleStatusChange);

    };

});

调用一个新的 effect 之前会对前一个 effect 进行清理。下面按时间列出一个可能会产生的订阅和取消订阅操作调用序列：

// Mount with { friend: { id: 100 } } props

ChatAPI.subscribeToFriendStatus(100, handleStatusChange); // 运行第一个 effect



// Update with { friend: { id: 200 } } props

ChatAPI.unsubscribeFromFriendStatus(100, handleStatusChange); // 清除上一个 effect

ChatAPI.subscribeToFriendStatus(200, handleStatusChange); // 运行下一个 effect



// Update with { friend: { id: 300 } } props

ChatAPI.unsubscribeFromFriendStatus(200, handleStatusChange); // 清除上一个 effect

ChatAPI.subscribeToFriendStatus(300, handleStatusChange); // 运行下一个 effect



// Unmount

ChatAPI.unsubscribeFromFriendStatus(300, handleStatusChange); // 清除最后一个 effect

📐 通过跳过 Effect 进行性能优化

如果某些特定值在两次重渲染之间没有发生变化，可以通知 React 跳过对 effect 的调用，只要传递数组作为 useEffect 的第二个可选参数即可：

useEffect(() => {

    document.title = `You clicked ${count} times`;

}, [count]); // 仅在 count 更改时更新

如果 count 的值是 5，而且组件重渲染的时候 count 还是等于 5，React 将对前一次渲染的 [5] 和后一次渲染的 [5] 进行比较。因为数组中的所有元素都是相等的(5 === 5)，React 会跳过这个 effect，这就实现了性能的优化。

当渲染时，如果 count 的值更新成了 6，React 将会把前一次渲染时的数组 [5] 和这次渲染的数组 [6] 中的元素进行对比。这次因为 5 !== 6，React 就会再次调用 effect。

📌 如果数组中有多个元素，即使只有一个元素发生变化，React 也会执行 effect。

对于有清除操作的 effect 同样适用：

useEffect(() => {

    function handleStatusChange(status) {

        setIsOnline(status.isOnline);

    }



    ChatAPI.subscribeToFriendStatus(props.friend.id, handleStatusChange);

    return () => {

        ChatAPI.unsubscribeFromFriendStatus(props.friend.id, handleStatusChange);

    };

}, [props.friend.id]); // 仅在 props.friend.id 发生变化时，重新订阅

📐 使用多个 Effect 实现关注点分离

使用 Hook 其中一个目的就是要解决 class 中生命周期函数经常包含不相关的逻辑，但又把相关逻辑分离到了几个不同方法中的问题。下述代码是将前述示例中的计数器和好友在线状态指示器逻辑组合在一起的组件：

function FriendStatusWithCounter(props) {

    const [count, setCount] = useState(0);

    useEffect(() => {

        document.title = `You clicked ${count} times`;

    });



    const [isOnline, setIsOnline] = useState(null);

    useEffect(() => {

        function handleStatusChange(status) {

            setIsOnline(status.isOnline);

        }



        ChatAPI.subscribeToFriendStatus(props.friend.id, handleStatusChange);

        return () => {

            ChatAPI.unsubscribeFromFriendStatus(props.friend.id, handleStatusChange);

        };

    });

    // ...

}

📐 完整示例

import React, { useState, Fragment, useEffect } from 'react';

import ReactDOM from 'react-dom';



const App = () => {

    const [count, setCount] = useState(0);



    useEffect(() => {

        let timer = setInterval(() => {

            setCount(count => count + 1);

        }, 500);

        console.log('@@@@');

        return () => {

            clearInterval(timer);

        };

    }, [count]);

    // 检测count的变化，每次变化，都会输出'@@@@'

    // 如果是[]，则只会输出一次'@@@@'



    const add = () => {

        setCount(count => count + 1);

    };



    const unmount = () => {

        ReactDOM.unmountComponentAtNode(document.getElementById('root'));

    };



    return (

        <Fragment>

            <h2>当前求和为：{count}</h2>

            <button onClick={add}>点我+1</button>

            <button onClick={unmount}>卸载组件</button>

        </Fragment>

    );

};



export default App;

4. useRef

useRef可以在函数组件中存储 / 查找组件内的标签或任意其它数据。保存标签对象，功能与 React.createRef() 一样。

const refContainer = useRef(initialValue);

useRef 返回一个可变的 ref 对象，其 .current 属性被初始化为传入的参数（initialValue）。返回的 ref 对象在组件的整个生命周期内保持不变。

📌 当 ref 对象内容发生变化时，useRef 并不会通知你。变更 .current 属性不会引发组件重新渲染。

import React, { Fragment, useRef } from 'react';



const Demo = () => {

    const myRef = useRef();



    //提示输入的回调

    function show() {

        console.log(myRef.current.value);

    }



    return (

        <Fragment>

            <input type="text" ref={myRef} />

            <button onClick={show}>点击显示值</button>

        </Fragment>

    );

};



export default Demo;

5. Hook规则

Hook 就是 JavaScript 函数，但是使用它们会有两个额外的规则：

只在最顶层使用 Hook

不要在循环，条件或嵌套函数中调用 Hook ，在 React 函数的最顶层调用 Hook。

如果想要有条件地执行一个 effect，可以将判断放到 Hook 的内部：

useEffect(function persistForm() {

    // 👍 将条件判断放置在 effect 中

    if (name !== '') {

        localStorage.setItem('formData', name);

    }

});

只在 React 函数中调用 Hook

不要在普通的 JavaScript 函数中调用 Hook。可以：

• 在 React 的函数组件中调用 Hook


• 在自定义 Hook 中调用其他 Hook

不知道大家在学习react源码的时候有没有这样的感觉：fiber对象的结构太复杂了，不仅是属性繁多，而且有些属性还是个巨复杂的对象。我在学习hooks的时候，这种感觉尤为强烈。那么，这篇文章就以fiber.memoizedState和fiber.updateQueue这两个重要属性为例，梳理一下他们的结构和作用，希望对大家阅读源码有帮助。

先来看类组件

首先来看类组件。类组件的fiber.memoizedState和fiber.updateQueue比较简单，memoizedState就是我们定义的state对象，updateQueue的结构如下：

fiber.updateQueue {

  baseState,

  firstBaseUpdate,

  lastBaseUpdate,

  shared: {

    pending,

  },

  effects

}

首先，前三个属性baseState、firstBaseUpdate和lastBaseUpdate是和可中断更新相关的。在concurrent mode下，当前的更新可能被更高优先级的更新打断，而baseState就记录了被跳过的update节点之前计算出的state，firstBaseState和lastBaseUpdate构成一条链表，记录因为优先级不足而被跳过的所有更新。shared.pending才是真正记录了所有update对象的链表，这是一条环形链表，shared.pending指向该链表的最后一个update对象，effects则是一个数组，存储了setState的回调函数。关于类组件的state计算原理，可以看我的这篇文章，这里面有更加详细的讲解，本文还是主要介绍数据结构。

看函数组件

了解hooks原理的同学应该都知道，react使用链表来存储函数组件中用到的所有hooks，而这个链表就保存在fiber.memoizedState。这个hooks链表的每一项都是hook对象，hook对象的结构如下

hook {

  memoizedState,

  baseState,

  baseQueue,

  queue,

  next

}

没错，fiber.memoizedState指向了hook链表，而每个hook对象还有一个memoizedState对象！！！

不论是哪种hook，都会使用这一种数据结构，而有些hook可能只会用到其中的几个属性。下面，就由简入繁，介绍不同的hook都用到了哪些属性。

useCallback, useMemo, useRef

这三个hook都只使用到了hook.memoizedState这一个属性。

useCallback接受一个需要缓存的函数和依赖数组，而hook.memoizedState则保存了一个数组，数组内放了缓存函数和依赖数组

function mountCallback(callback, deps) {

  var hook = mountWorkInProgressHook();

  var nextDeps = deps === undefined ? null : deps;

  hook.memoizedState = [callback, nextDeps];

  return callback;

}

useMemo和useCallback基本一致，只不过useMemo保存了函数的返回值

function mountMemo(nextCreate, deps) {

  var hook = mountWorkInProgressHook();

  var nextDeps = deps === undefined ? null : deps;

  var nextValue = nextCreate();

  hook.memoizedState = [nextValue, nextDeps];

  return nextValue;

}

至于useRef就能简单了，保存一个对象即可

function mountRef(initialValue) {

  var hook = mountWorkInProgressHook();

  var ref = {

    current: initialValue

  };



  {

    Object.seal(ref);

  }



  hook.memoizedState = ref;

  return ref;

}

这里使用Object.seal封闭了ref对象，Object.seal就是在不可扩展(Object.preventExtensions)的基础上不可配置(configurable变为false)。

useState

看完了三个简单的hook，现在加大一点难度，看看useState。

useState就比较复杂了，用到了hook对象身上的所有属性

hook {

  memoizedState: 保存的state,

  baseState：和类组件的updateQueue.baseState作用相同,

  baseQueue: 和类组件的updateQueue.firstBaseUpdate和lastBaseUpdate作用相同,

  queue: {

  	pending: 保存update对象的环状链表,

  	dispatch: dispatchAction，useState的第二个返回值,

  	lastRenderedReducer: 上次更新时用到的reducer,

  	lastRenderedState: 上次更新的state

  }

}

这里需要注意一点，useState中用到了hook.queue这个属性，而hook.queue.pending和类组件的updateQueue.shared.pending比较类似，都是用来保存update对象的。而使用useState时，fiber.updateQueue是null，也就是说和类组件不同，useState并没有用到updateQueue，这一点容易让人困惑。

useEffect

接下来看看我个人认为最复杂的hook：useEffect。说他复杂，是因为useEffect的数据结构很绕，下面一起来看一下

首先，关于hook对象身上的几个属性，useEffect只用到了一个，就是memoizedState，而在memoizedState上保存的又是一个effect对象

hook {

  memoized: {

    tag: 用于区分是useEffect还是useLayoutEffect,

    create: 就是useEffect的回调函数,

    destory: useEffect回调的返回值,

    deps: 依赖数组,

    next: 下一个effect对象，构成环装链表

  },

  baseState: null,

  baseQueue: null,

  queue: null

}

此外，useEffect还用到了fiber.updateQueue，这个updateQueue的结构还和类组件的不一样

// 类组件的updateQueue

{

  baseState,

  firstBaseUpdate,

  lastBaseUpdate,

  shared: {

    pending

  },

  effects

}



// useEffect的updateQueue

{

  lastEffect

}

useEffect不仅将effect对象放在了hook.memoized上，还放在了fiber.updateQueue上，并且都是环形链表

举个🌰

前面说了这么多，可能大家还是比较困惑，下面看个实际的例子

const App = () => {

  const [num, setNum] = useState(1)

  const handleClick1 = useCallback(() => {

    setNum((pre) => pre + 1)

  }, [])



  const [count, setCount] = useState(1)

  const handleClick2 = useCallback(() => {

    setCount((pre) => pre + 1)

  }, [])



  useEffect(() => {

    console.log('1st effect', num)

  }, [num])



  useEffect(() => {

    console.log('2nd effect', num)

  }, [num])



  useLayoutEffect(() => {

    console.log('use layout', count)

  }, [count])



  return (

    <div>

      <p>{num}</p>

      <p>{count}</p>

      <button onClick={handleClick1}>click me</button>

      <button onClick={handleClick2}>click me</button>

    </div>

  )

}

上面的例子中，我们使用了两个useState，并且每个事件处理函数都使用useCallback进行了包装，此外还有useEffect和useLayoutEffect，下面看一下

1. 首先，执行useState，因此在fiber.memoizedState上挂载了一个useState的hook对象

2. 接下来执行到useCallback，在hooks链表中再添加一项

3. 接下来又是useState和useCallback，因此和前两步一样

4. 之后来到比较复杂的useEffect了，useEffect不仅会添加hook对象到hooks链表中，还会修改updateQueue

5. 后面还是一个useEffect，这一步就比较复杂了

可以看到，使用useEffect时，不仅构成了hooks链表，effect对象也构成了一条环形链表

6. 之后执行了useLayoutEffect

最后来总结一下这个例子

前言

最近测试给我提的的 bug 终于少了很多， 在 codeReview 的时候同事们也很少指出我那个地方写的不对

反而对我整体的文件结构和组件的编写结构及状态的设计提出了更高的要求，不得不说我这代码水平还是有所提高的，表示在稳步提升的过程还有很大的进步空间

但是当我在看到同事给我说的整个组件如何分离才能提高维护性和复用性，别人在看的时候也能更清晰的知道这部分的逻辑

当时我就好奇，为啥同事能有这种见解，难道只是因为经验比我多，思考比我深入吗？我的直觉告诉我没有这么简单。

如何在看到设计图的时候就想好如何划分这块业务的逻辑，如何设计自己想要的数据结构，我在脑中思索着，忽然我想起初学 React 的时候那个被我撇过一眼就速度滑过的概念 React 哲学

我立马去官网看着概念， 果然那些我以前我以前对于一个组件不知道证明设计结构和状态，这些组件写到后面状态不通，还有我几乎还会在每个子组件都请求一遍数据，对于一些想显示的数据都定义一个 state 来简单粗暴的解决

在写一个模块的时候我几乎是马上就着手去写，往往都是没有任何思考和设计只是想到什么就写什么，只想着赶快把功能学完，以至于写出很多缝缝补补不合理的代码让我踩过很多坑，收获很多 bug ，在看到之前的组件，我的第一想法就是重构。

说了这么多我的血泪史，我们看一下 React 哲学到底是说的什么，它都是如何解决我上述的痛点的，我又因此悟到了什么？

准备阶段

首先在我们写代码之前肯定会有的是会有的一是 PM 的产品设计图，二是后端同学返回的 JSON 数据

[

  {category: "Sporting Goods", price: "$49.99", stocked: true, name: "Football"},

  {category: "Sporting Goods", price: "$9.99", stocked: true, name: "Baseball"},

  {category: "Sporting Goods", price: "$29.99", stocked: false, name: "Basketball"},

  {category: "Electronics", price: "$99.99", stocked: true, name: "iPod Touch"},

  {category: "Electronics", price: "$399.99", stocked: false, name: "iPhone 5"},

  {category: "Electronics", price: "$199.99", stocked: true, name: "Nexus 7"}

];

先理解这样一个简单的产品设计图所包含的需求都有哪些，这是一个展示商品的列表，用户可以在对商品进行关键字搜索，并且通过点击复选框选择是是否展示现货，商品列表包含商品名和价格，商品支持分类显示，其中告罄的商品名为红色显示。

当我们基本了解产品图所表达的需求之后，就可以开始代码编写的第一步了

通过产品图划分组件层级

在一开始不太熟练划分的时候可以在产品设计稿上通过画方框来确定组件和子组件，可以报组件当成一个函数或者对象来看，组件同样遵照单一功能原则，也就是说一个组件只负责一个功能

同时一个好的 JSON 数据模型也应该是和组件一一对应的，组件与数据模型中的某个部分匹配

不同的颜色划分成不同的组件，可以分成五部分：

1. FilterableProductTable (橙色): 是整个示例应用的整体


2. SearchBar (蓝色): 接受所有的用户输入


3. ProductTable (绿色): 展示数据内容并根据用户输入筛选结果


4. ProductCategoryRow (天蓝色): 为每一个产品类别展示标题


5. ProductRow (红色): 每一行展示一个产品

组件名应该能让人迅速 get 到这个组件的写的是什么（不得不说我之前的组件命名真的太糟糕了，过几天回头看都是一脸懵逼的那种

组件的层级划分：

• FilterableProductTable
  
  
  
  • SearchBar
  
  
  • ProductTable
    
    
    
    • ProductCategoryRow
    
    
    • ProductRow
    
    
    
    
  
  
  
  

用 React 构建静态页面

当我们划分好了组件层级之后可以来写代码了，先利用已有数据模型来写一个不包含交互的UI渲染，这是因为UI渲染的代码比较多，交互要考虑的细节比较多，把这两个过程分开写不容易漏掉一些细节，整个思路也比较清晰

通过复用编写的组件，使用 props 来进行数据的传递，父组件把数据进行层层的传递，这也是 React 的一个特点就是单向数据流动，在这个过程中先不使用 state ，因为 state 表示的是会随着时间变化而变化的，所以在交互的过程中使用

构建应用的时候可以使用自上而下或者自上而下的方法，自上而下表示先写层级最高的组件，如FilterableProductTable 组件，这种比较适合简单的应用； 自下而上表示先写层级最低的组件，如 ProductRow 组件，这种方法比较适合大型的应用构建

const PRODUCTS = [

  {category: 'Sporting Goods', price: '$49.99', stocked: true, name: 'Football'},

  {category: 'Sporting Goods', price: '$9.99', stocked: true, name: 'Baseball'},

  {category: 'Sporting Goods', price: '$29.99', stocked: false, name: 'Basketball'},

  {category: 'Electronics', price: '$99.99', stocked: true, name: 'iPod Touch'},

  {category: 'Electronics', price: '$399.99', stocked: false, name: 'iPhone 5'},

  {category: 'Electronics', price: '$199.99', stocked: true, name: 'Nexus 7'}

];



const FilterableProductTable = () => (

  <div>

    <SearchBar />

    <ProductTable products={PRODUCTS} />

  </div>

);



const SearchBar = () => (

  <form>

    <input type="text" placeholder="Search..." />

    <p>

      <input type="checkbox" /> Only show products in stock

    </p>

  </form>

);



const ProductTable = ({ products }) => {

  const rows = [];

  let lastCategory = null;



  products.forEach((product) => {

    if (product.category !== lastCategory) {

      rows.push(

        <ProductCategoryRow

          category={product.category}

          key={product.category}

        />

      );

      rows.push(<ProductRow product={product} key={product.name} />);

    }

    lastCategory = product.category;

  });



  return (

    <table>

      <thead>

        <tr>

          <th>Name</th>

          <th>Price</th>

        </tr>

      </thead>

      <tbody>{rows}</tbody>

    </table>

  );

};



const ProductCategoryRow = ({ category }) => (

  <tr>

    <td colSpan="2">{category}</td>

  </tr>

);



const ProductRow = ({ product }) => {

  const name = product.stocked ? (

    product.name

  ) : (

    <span style={{ color: "red" }}>{product.name}</span>

  );



  return (

    <tr>

      <td>{name}</td>

      <td>{product.price}</td>

    </tr>

  );

};

确定 state 的最小且完整的集合

当我们一些其他的数据来触发改变基础数据，让UI具有交互结果，在 React 中就可以使用 state 来表示

最小且完整的表示在于我们可以先找到一些会根据时间产生变化的全部数据，再从这些数据中选出最必要的数据作为 state ，其他数据能通过计算得到。

看一下当前应用有哪些数据：

• 商品的原始数据


• 用户的搜索数据


• 复选框是否选中的值


• 经过筛选后的数据

在确定这些数据能否成为 state 可以先问一下自己这几个问题

• 数据是否能通过 props 来传递


• 是否会通过时间而产生改变


• 是否可以通过其他 state 和 props 计算得到

那么最后我们就可以确认，原始数据可以通过 props 传递，用户搜索的数据和复选框的值可以作为 state ，筛选后的数据可以通过原始数据和用户搜索数据以及复选框数据计算得来。所以最后 state 可以是：

• 用户的搜索数据


• 复选框是否选中的值

确定 state 放置的位置

当确定了 state 的最小集合之后，接下来就该确定 state 应该放置在哪个组件里

在前面我们知道了 React 是单向的数据流，自上而下的流动，所以我们应把 state 写在共同所有者（也就是需要这些 state 的组件的共同父组件）

我们可以看到 ProductRow 组件需要筛选后的数据， SearchBar 组件需要搜索的数据和复选框的值， 所以就可以把 state 放在它们的共同所有者组件 FilterableProductTable 组件里，再通过 props 来进行 state 的传递

添加反向数据流

当我们要通过层级较低的组件改变层级较高的组件，就需要通过反向数据流的方式

React 中的反向数据流是通过需要高层级组件通过 props 把改变 state 的方法 (回调函数) 传递给层级较低的组件，子组件 state 的改变后的值传给这个回调函数。

在当前应用中如果想要拿到最新的 state 就需要FilterableProductTable 必须将一个能够触发 state 改变的回调函数（callback）传递给 SearchBar。我们可以使用输入框的 onChange 事件来监视用户输入的变化，并通知 FilterableProductTable 传递给 SearchBar 的回调函数。

const FilterableProductTable = () => {

  const [filterText, setFilterText] = React.useState("");

  const [inStockOnly, setInStockOnly] = React.useState(false);



  return (

    <div>

      <SearchBar

        filterText={filterText}

        setFilterText={setFilterText}

        inStockOnly={inStockOnly}

        setInStockOnly={setInStockOnly}

      />

      <ProductTable

        products={PRODUCTS}

        inStockOnly={inStockOnly}

        filterText={filterText}

      />

    </div>

  );

};



const SearchBar = ({

  filterText,

  setFilterText,

  inStockOnly,

  setInStockOnly,

}) => {

  const handleProductsSearch = (value) => {

    setFilterText(value);

  };



  const handleStockCheck = (value) => {

    setInStockOnly(value);

  };



  return (

    <form>

      <input

        type="text"

        placeholder="Search..."

        value={filterText}

        onChange={handleProductsSearch}

      />

      <p>

        <input

          type="checkbox"

          value={inStockOnly}

          onChange={handleStockCheck}

        />{" "}

        Only show products in stock

      </p>

    </form>

  );

};



const ProductTable = ({ products, inStockOnly, filterText }) => {

  const rows = [];

  let lastCategory = null;



  products.forEach((product) => {

    if (product.name.indexOf(filterText) === -1) {

      return;

    }

    if (inStockOnly && !product.stocked) {

      return;

    }

    if (product.category !== lastCategory) {

      rows.push(

        <ProductCategoryRow

          category={product.category}

          key={product.category}

        />

      );

      rows.push(<ProductRow product={product} key={product.name} />);

    }

    lastCategory = product.category;

  });



  return (

    <table>

      <thead>

        <tr>

          <th>Name</th>

          <th>Price</th>

        </tr>

      </thead>

      <tbody>{rows}</tbody>

    </table>

  );

};

总结

React 哲学并没有对深奥的道理，相反它更倡导我们把代码写得更加简洁清晰，更具有模块化，这一点在写大型的项目尤为重要，在写代码之前就把大致的结构和涉及的数据结构设计好，会减少 Bug 的产生，减少重构的时间，减少维护的成本。