关于html的一切(updating...)

参考https://zhuanlan.zhihu.com/p/34453198
参考https://juejin.cn/post/6844903761949753352

1.html5新特性

语义标签。给标签添加语义，让合适的标签做合适的事。<‘header’>,<‘footer’>,<‘nav’>。
有利于SEO(搜索引擎优化)，有利于开发和维护。
canvas,svg
Web Storage
本地存储解决方案，就是localStorage和sessionStorage
Web Worker
Web Worker可以通过加载一个脚本文件，进而创建一个独立工作的线程，在主线程之外运行。
WebSocket协议
建立在tcp基础之上，和http协议同属于应用层，没有同源限制

2.html解析页面过程

1. 解析html，构建DOM树

构建描述的节点的层级关系的树，包括可见和不可见节点。例如

2. 解析css，生成css规则树CSSOM

构建节点样式的层级关系树，但只包括可见节点。例如

3. 合并DOM树和CSS规则，生成render树

将节点的样式和其属性结合。注意是可见节点

4. 布局render树(layout/reflow)，负责个元素尺寸、位置的计算
5. 绘制render树(paint)，绘制页面像素信息

布局和绘制，主要发生过程就是计算样式，位置，尺寸等信息，最后绘制。
reflow，即回流。某个元素发生了结构、位置、内容的变化，就需要重新计算样式和渲染树
repaint，即重绘，某个元素只是发生了样式的变化，只需要重新绘制该元素的外观即可。
reflow必然要引起repaint。

6. 浏览器会将各层的信息发送个GPU，GPU会将各层合成，显示在屏幕上

如何优化性能：

减少逐项更改样式，最好一次性更改，要么就定义class样式
将复杂的元素绝对定位或固定定位，使其脱离文档流。否则发生改变，回流代价很高。
避免循环操作dom，创建一个容器使其涵盖所有dom的操作，最后添加到window.document。

解析过程遇到的资源的处理： 主要分为3块

css样式资源。
1. 不阻塞html解析(下载是异步的)
2. 阻塞render渲染，也就是在构建render时，会等到css资源全部下载完毕才进行。主要是防止CSSOM不断变化，导致render树的不断重构。
3. 有例外，media query(媒体查询)声明的css是不会阻塞渲染的。
js脚本资源
1. 阻塞html解析，遇到js脚本，需等待下载完毕后才继续执行
2. defer和async。加上这两个，可以使js脚本下载为并行，也就是不阻塞html解析。
  但defer和async的区别在于js脚本的执行时机。
  使用defer，js脚本的执行将会在html解析完成后。
  使用async，js脚本将会在下载完后立刻执行，且阻塞html解析。
  所以如果你的js脚本依赖dom元素，用defer。反之，用async。
img图片资源（异步下载，不阻塞。且下载完直接替换原src）

3.事件捕获、事件目标、事件冒泡、事件委托/代理

1.事件捕获

当某个元素触发某个事件（例如onclick），顶层对象document就会发出一个事件流，随着DOM树的节点向目标元素节点流去，直到到达事件真正发生的目标元素。在这个过程中，事件对应的监听的函数是不会被触发的。

2.事件目标

当到达目标元素之后，执行目标元素该事件对应的处理函数。如果没有绑定监听函数，就不执行

3.事件冒泡

从目标元素开始，往顶层元素传播。途中如果有节点绑定了相应的事件处理函数，这些函数都会被触发一次。如果想阻止，可以用e.stopPropagation（）来阻止事件的冒泡传播

4.事件委托/事件代理

就是将一个响应事件委托到另一个元素
当子节点被点击时，click事件向上冒泡，父节点捕获到事件后，我们判断是否为所需的节点，然后进行处理。其优点在于减少内存消耗和动态绑定。

currentTarget和target

currentTarget是事件的监听者，也就是绑定事件的节点
target是事件真正出发者。
假设A是B的父元素，在A上绑定click事件。当我点击B时，此时target就是B，而currentTarget是A。

可以在addEventLister的第三个参数增加true，表示事件在事件捕获时发生；
为false（默认），则表示事件在事件冒泡时发生。

4.node事件循环

当node.js启动后，它会初始化事件循环，处理已提供的输入脚本，他可能会调用一些异步的API，调度定时器，或者调用process.nextTick(),然后开始处理事件循环。

注意：每一个框都被称为事件循环的一个阶段。
每个阶段都有一个FIFO队列来执行回调，当进入给定的阶段时，它将执行特定于该阶段的任何操作，然后执行该阶段队列中的回调，直到队列用尽或最大回调树已执行。当该队列已用尽或达到回调限制，事件循环将移动到下一个阶段，等等。
阶段概述：

timers(定时器)：本阶段执行已经被setTimeout()和setInterval()的调度回调函数。
pending callbacks(待定回调)：执行延迟到下一个循环迭代的I/O回调。
idle，prepare：仅系统内部使用。
poll(轮询):检查新的I/O事件；执行与I/O相关的回调。
check(检测)：setImmedidate（）回调函数在这里执行
close callbacks(关闭的回调函数),一些关闭的回调函数。

timer阶段：

timer阶段会执行setTimeout和setInterval回调，并且是由poll阶段控制的。同样，在node中定时器指定的时间也不是准确时间。

poll阶段：

会执行两件事，1.回到timer阶段执行回调，2.执行I/O回调
假设没有timer的话
如果poll队列不为空，会遍历回调队列并同步执行，直到为空
如果poll队列为空，
如果有setImmediate回调需要执行，则poll阶段会停止进入check阶段执行回调。
如果没有setImmediate回调需要执行，则会等到回调被加入队列中并立即执行，但同样设置一个超时时间以防一直等待下去。
假设有timer，则会等待timer超时，然后回到timer阶段进行回调。

setTimeout 和 setImmediate的区别：
二者非常相似，区别主要在于调用时间不同。

setImmediate 设计在poll阶段完成时执行，即check阶段。
setTimeout 设计在poll阶段为空闲时间时，且设定时间到达后执行，但他在timer阶段执行。

setTimeout(function timeout () {console.log('timeout');
},0);
setImmediate(function immediate () {console.log('immediate');
});
对于上述代码，两者执行的顺序是随机的。
而在I/O的callBack中，setImmediate永远先于setTimeout。
const fs = require('fs')
fs.readFile(__filename, () => {setTimeout(() => {console.log('timeout');}, 0)setImmediate(() => {console.log('immediate')})
})
// immediate
// timeout

process.nextTick：

独立于事件循环之外，可以认为它拥有自己的一个nextTick队列，当每个阶段完成后，如果存在nextTick队列，就会清空nextTick队列中的所有回调函数，并且优先于其他微任务。
简单来说，nextTick就是一个拥有最高优先级的微任务。

nodejs 和浏览器关于eventLoop的主要区别：

浏览器端，微任务是在每一个响应的宏任务中执行
node端，微任务是在不同剪短之间执行的。

node11和node < 11的版本区别

setTimeout(()=>{console.log('timer1')Promise.resolve().then(function() {console.log('promise1')})
}, 0)
setTimeout(()=>{console.log('timer2')Promise.resolve().then(function() {console.log('promise2')})
}, 0)
node < 11:timer1 ，timer2，promise1，promise2
node === 11：timer1 ，promise1，timer2，promise2
可以发现node11的行为和浏览器端相同了，
这是因为在node < 11 ：若第一个定时器任务出列并执行完，当它发现队首的任务仍然是一个定时器时，
那么就将微任务暂时保存，直接去执行新的定时器任务，当新的定时器执行完后，再一一执行中途产生的微任务。