浏览器的架构发展
- 单进程时代：
- 单进程浏览器是指浏览器的所有功能模块都是运行在同一个进程里。
- 只能借助插件来实现视频、web游戏等功能
- 复杂的js代码（计算量大）,很容易造成进程崩溃即浏览器瘫痪
- 恶意的插件可以在获取权限后写入恶意代码，获取用户信息或者恶意操作用户登录的网站
-
多浏览器开始：
image.png
多进程解决了稳定性问题和安全问题；
-
目前成熟的浏览器架构
image.png
- 浏览器进程。主要负责界面显示、用户交互、子进程管理，同时提供存储等功能。
- 渲染进程。核心任务是将 HTML、CSS 和 JavaScript 转换为用户可以与之交互的网页，排版引擎 Blink 和 JavaScript 引擎 V8 都是运行在该进程中，默认情况下，Chrome 会为每个 Tab 标签创建一个渲染进程。出于安全考虑，渲染进程都是运行在沙箱模式下。
- GPU 进程。其实，Chrome 刚开始发布的时候是没有 GPU 进程的。而 GPU 的使用初衷是为了实现 3D CSS 的效果，只是随后网页、Chrome 的 UI 界面都选择采用 GPU 来绘制，这使得 GPU 成为浏览器普遍的需求。最后，Chrome 在其多进程架构上也引入了 GPU 进程。
- 网络进程。主要负责页面的网络资源加载，之前是作为一个模块运行在浏览器进程里面的，直至最近才独立出来，成为一个单独的进程。
- 插件进程。主要是负责插件的运行，因插件易崩溃，所以需要通过插件进程来隔离，以保证插件进程崩溃不会对浏览器和页面造成影响
多进程解决的单进程 内存泄漏、权限安全、性能不稳定等问题
TCP协议如何保证页面文件能完成传给浏览器
- IP协议(网络层)：计算机在网络上的地址 + ip版本协议 + 生成时间等信息;
- UDP(传输层): 将指定的数据传输给指定的用户程序， 由源端口号+目标端口号等信息组成；
UDP的传输速度快，但是没有重发机制，多应用于在线视频、游戏等场景色； -
TCP(传输层)：在UDP的基础上加了重排机制、数据包校验机制和重传机制。
image.png
从URL输入到页面展示发生了什么
image.png
- 浏览器进程获取URL输入，如果不是请求URL，会用浏览器默认搜索引擎合成新的搜索URL;
- 将之前页面的数据状态、请求操作清除;
- IPC通知网络进程，构建网络请求；
- 查找缓存，缓存是否命中；
- controll-cache: max-age=xxxx;
- if-none-match与etag; 304
- 查找DNS缓存，存在对应域名ip，则直接使用IP, 没有则DNS服务查找；
- TCP三次握手，如果应用层是https，还需要ssl连接；
- 当前URL是否需要永久重定向301；
- 发起http请求：
- 请求行 ： 请求方法+协议版本
- 请求头：编码方式+语言格式+缓存控制+来源...........
- 请求体
- 网络资源获取后通知渲染进程；
- 渲染进程中的html\css等线程对各类资源进行解析；
- HTML解析：有限状态机+标记生成实现， 生成dom树
- 遇到css标签/内嵌样式，生成布局css树；
- 生成布局树renderTree;
- 布局树栅格化，生成图层树LayerTree
图层的形成- 开始绘制默认图层
- position：fixed、absolute；opacity;/transform,都会单独构成图层
- 滚动条/内容溢出也会构成单独的图层
- 最后绘制列表(由图层转成的绘制指令按顺序组成)，根据绘制列表生成位图;
- 渲染进程通知主进程，主进程告知GPU进程根据位图和绘制列表进行（栅格化）具体渲染
- 浏览器进程将GPU进程的渲染页面显示在客户端界面
重排和重绘
image.png
重排：重新走了渲染的完成的流水线，开销是非常大的；
image.png
而重绘：跳过了布局阶段（renderTree和布局树LayTree的重新生成）
js是如何被执行的
image.png
1.编译型语言在程序执行之前，需要经过编译器的编译过程，并且编译之后会直接保留机器能读懂的二进制文件，这样每次运行程序时，都可以直接运行该二进制文件，而不需要再次重新编译了。比如 C/C++、GO 等都是编译型语言。
2.而由解释型语言编写的程序，在每次运行时都需要通过解释器对程序进行动态解释和执行。比如 Python、JavaScript 等都属于解释型语言
V8 是如何执行一段 JavaScript 代码的#
image.png
不同于编译型语言，AST解析之后会先通过解释器转换成字节码，字节码再逐行解析转换成机器码，多次执行的代码（热代码）会被标记，后续会直接调用存储的多次执行的机器码。
