浏览器架构：

• 多进程架构：
  • 一个主进程
    • 主线程
    • 使用网络进程中的网络线程（进程间通信）
      • DNS查询，TCP连接，HTTP请求
  • 多个渲染进程（一个tab一个）
  • GPU进程
  • 网络进程
    • 所有请求

浏览器渲染流程

https://mp.weixin.qq.com/s/q70TMZ5jJcOCJpHOWndo8A

• 浏览器刷新频率60HZ
• JS的浏览器环境有一个主线程，它既负责页面渲染（页面布局、绘制。合并图层），也负责运行JS脚本执行DOM； 两个行为是互斥的；

浏览器虽然使用单线程执行 JavaScript 代码，但通过以下机制实现了并发效果：

浏览器有哪些进程？

• 主进程： (Browser Process)
  • 页面，前进后退标签页
  • 网络请求的发起和下载
  • 文件的存储和读取
  • 管理其他进程（渲染，gpu等等）
• 渲染进程 (Renderer Process)
  • 解析html、css和js
  • 每个tab单独一个
  • 特点：它内部的串行的
• GPU进程 (GPU Process)
  • 每个浏览器只有一个
  • 处理css动画和绘制页面图层
• 网络进程 (Network Process)
  • 专门负责处理所有的网络请求，如获取页面资源、发起 Ajax 请求等
  • 管理网络协议栈，处理 DNS 解析、建立 TCP 连接、发送和接收 HTTP/HTTPS 报文
• 插件进程 (Plugin Process)
  • 每个插件专门一个

浏览器的渲染原理和过程？

• 主要解析html构建dom树
• 解析css和其中的异步标签，构建cssom树
  • 其中如果执行到了script标签，会立刻进行暂停, 然后解析js。
    • 异步操作：请求是异步的，区别仅仅是是否暂停等它返回
      • 如果有defer标签，会把解析js放在html完成后
      • 如果是async，在返回后立刻解析
• 构建render树
  • 只包含可见的节点，不含display：none
• 回流：dom结构的绘制
• 重绘：样式的更改
• 合成层：会把这些提升到合成层
  • 然后 动画操作都会放到合成层来优化性能

渲染进程的执行顺序？

追问：

• 我们常说 CSS 的解析会阻塞渲染，这是为什么？它会阻塞 DOM 的解析吗？

  • css的解析阻塞渲染，原因是为了避免无样式内容闪烁（FOUC），渲染树（Render Tree）需要html（dom树）和css（cssom树）的解析都完成了再开始构建。所以会阻塞。
  • 渲染线程中，会有一个预解析器，扫描所以html，并且去让“网络进程”来获取网络资源。此时，html仍然可以继续解析。
  • 总之，阻塞主要是网络阻塞，css的解析本身是很快的。
    • 还有内联@import，这个也是网络层面的。
  • 但是，css解析可能会触发js执行，间接影响html解析。
    • 最佳实践是，使用defer/async标签，并且把style标签放在body前面。

• 什么是“回流 (Reflow)”和“重绘 (Repaint)”？它们之间有什么区别？哪些 CSS 属性的改变只会触发重绘而不会触发回流？

• <script> 标签的 async 和 defer 属性有什么区别？它们是如何优化关键渲染路径的？

• 浏览器是如何处理图片资源的加载和显示的？它会阻塞渲染吗？

• 什么是“合成层 (Compositing Layer)”？哪些 CSS 属性可以隐式地创建一个新的合成层？这样做有什么好处和潜在的风险？

为什么要引入Fiber架构？

在引入fibe架构之后，会采用异步策略， 将其分为Reconciliation和Commit阶段，其中Reconciliation阶段会将update分成一小块一小块，并且加上优先级来决定先更新什么（什么时候diff，什么时候渲染， 什么时候响应用户输入）。 并且它是可中断的，可以被更高优先级的东西中断； 就相当于给它加了一个操作系统，有时间片轮转这样的机制，也支持中断；