浏览器架构
目前是面向服务的多进程架构
多进程分工：
- 浏览器（主进程）
- GPU进程
- 渲染进程（标签页，这里注意一个标签为一个进程）
- 插件进程
- 网络进程
我们重点关注渲染进程
渲染进程
渲染进程 的内部是多线程的
比如：
- js引擎线程
- GUI渲染线程
- 定时器线程
- 事件线程
- 网络线程
js引擎和渲染引擎的区别
js引擎，只解析js，过程如下
渲染引擎主要解析HTML、CSS，过程如下
看到这两棵树，DOM树和CSSOM树，我想起了重绘和重排，这边顺便说一下重绘重排
重排负责元素的几何属性更新，重绘负责元素的样式更新
相当于，重排是在DOM这边更新的，而重绘主要是在CSSOM这边负责
当重绘重排完成后，重新合成一个render树
对于重绘重排的性能优化问题，另外再出一篇文章吧，这边可以参考一下这篇文章的介绍，挺不戳的
渲染进程中具体的工作机制
- 首先网络线程负责加载网页资源
- JS引擎解析JS脚本并且执行
- JS解析引擎空闲时，渲染线程立即工作
- 用户交互、定时器操作等产生回调函数放入任务队列中
- 事件线程进行事件循环，将队列里的任务取出交给JS引擎执行
而在 事件循环 中，同步任务放在浏览器渲染主线程中，形成一个执行栈，而异步任务放在消息队列中，不同的异步任务（比如微任务、宏任务等）是放在不同的任务队列中的
经典面试题： 浏览器地址输入URL后发生了什么？
从 浏览器主进程 来看： 输入处理->开始导航->读取响应->寻找渲染进程
- 解析域名，加载资源，执行脚本
- 构建DOM、CSSOM树，合成render tree
- 渲染布局
- 绘制图层
- 展示完成
输入处理
- 用户url框输入内容后，UI线程会判断输入的是一个url地址还是query查询
- 如果是url，直接请求站点资源
- 如果是query，将输入发送给搜索引擎
开始导航
- 当用户按下回车，UI线程通知网络线程发起一个网络请求
- 请求过程中，tab处于loading状态
读取响应（重点）
- 网络线程接收到HTTP响应后，先检查响应头的媒体类型（MIME TYPE 资源的媒体类型）
- 如果响应主体是一个HTML文件，浏览器将内容交给渲染进程处理
- 如果拿到的是其他类型的文件，比如Zip、exe等，则交给下载管理器处理
媒体类型通常是通过 HTTP 协议，由 Web 服务器告知浏览器的，更准确地说，是通过 Content-Type 来表示的，例如: Content-Type: text/HTML
寻找渲染进程
- 网络线程做完所有检查后，会告知主进程数据已准备完毕，主进程确认后为这个站点寻找一个渲染进程
- 主进程通过IPC（网络摄像机）消息告知渲染进程去处理本次导航
- 渲染进程开始接收数据并告知主进程自己已开始处理，导航结束，进入文档加载阶段
资源加载
- 收到主进程的消息后，先开始加载HTML文档
- 除此之外，还需要加载子资源，比如一些图片，CSS图片样式文件以及JavaScript脚本
构建渲染树
- 构建DOM树，将HTML文本转化成浏览器能够理解的结构
- 构建CSSOM树，浏览器同样不认识CSS，需要将CSS代码转化为可理解的CSSOM
- 构建渲染树，渲染树是DOM树和CSSOM树的结合
剩下的就是页面布局和页面绘制了，在页面布局中，会根据渲染树计算每个节点的位置和大小
前端性能
从以下几个方面切入：
- 首屏优化
- 压缩、分包、删除无用代码
- 静态资源分离
- JS脚本非阻塞加载
- 缓存策略
- SSR
- 预置loading、骨架屏
- 渲染优化
- GPU加速
- 减少回流、重绘
- 离屏渲染
- 懒加载
- JS优化
- 防止内存泄漏
- 循环尽早break
- 合理使用闭包
- 减少DOM访问
- 防抖、节流
- web workers
