浏览器架构
主要架构模式介绍：
- 单进程架构：所有模块运行在同一个进程里，包含网络、插件、JavaScript运行环境等
- 多进程架构：主进程、网络进程、渲染进程、GPU进程、插件进程
- 面向服务架构：算是多进程架构的升级版。将原来的UI、数据库、文件、设备、网络等，作为一个独立的基础网络服务
浏览器架构对比
优缺点如图：
- 为什么会有单进程架构？
单进程架构各方面都不够好，但它的存在是由于早期硬件的限制。
- 面向服务架构是否会替代多进程架构？
未来面向服务架构可能代替多进程架构
渲染进程
主要包含以下线程：
- 主线程（Main thread）(下载资源、执行js、计算样式、进行布局、绘制合成)
- 光栅线程（Raster thread）
- 合成线程（Compositor thread）
- 工作线程（Worker thread）
渲染进程-多线程架构
内部是多线程实现,主要负责页面渲染,脚本执行,事件处理,网络请求等
渲染进程-多线程工作流程
-
- 网络线程负责加载网页资源
-
- JS引擎解析JS脚本并且执行
-
- JS解析引擎空闲时,渲染线程立即工作
-
- 用户交互、定时器操作等产生回调函数放入任务队列中
-
- 事件线程进行事件循环,将队列里的任 务取出交给JS引擎执行
Chrome运行原理
输入处理：
- 用户URL框输入内容后，UI 线程会判断输入的时一个URL地址呢还是一个query查询条件；
开始导航：
- 当用户按下回车，UI线程通知网络线程发起一个网络请求，来获取站点内容；
读取响应：
- 网络线程接受到HTTP响应后，先检查响应头的媒体类型（MIME type）；
- 如果响应主体是一个HTML文件，浏览器将内容交给渲染进程处理；
- 如果拿到的是其他类型文件，比如zip、exe等，则交给下载管理器处理。
寻找渲染进程：
- 网络线程做完所有检查后，会告知主进程数据已经准备完毕，主进程确认后为这个站点寻找一个渲染进程；
- 主进程通过IPC消息告知渲染进程去处理本次导航；
- 渲染进程开始接受数据并告知主进程自己已开始处理，导航结束，进入文档加载阶段。
渲染进程-资源加载：
- 收到主进程的消息后，开始加载HTML文档；
- 除此之外，还需要加载子资源，比如一些图片，CSS样式文件以及JavaScript脚本。
渲染进程-构建渲染树：
- 构建DOM树，将HTML文本转化成浏览器能够理解的结构；
- 构建CSSOM树，浏览器同样不认识CSS，需要将CSS代码转化为可理解的CSSOM；
- 构建渲染树，渲染树是DOM树和CSSOM树的结合。
渲染进程-页面布局：
- 根据渲染树计算每个节点的位置和大小
- 在浏览器页面区域绘制元素边框
- 遍历渲染树，将元素以盒模型的形式写入文档流
渲染进程-页面绘制：
- 构建图层：为特定的节点生成专用图层
- 绘制图层：一个图层分成很多绘制指令，然后将这些指令按顺序组成一个绘制列表，交给合成线程
- 合成线程接收指令生成图块
- 栅格线程将图块进行栅格化
- 展示在屏幕上
可以做的优化如下：
首屏优化
- 压缩、分包、删除无用代码
其中分包利用浏览器并行的特点达到优化。
- 静态资源分离
将页面中的静态资源（如CSS、JavaScript和图像等）与HTML文档分离，可以使得浏览器可以并行加载这些资源，从而提高页面的加载速度 类似于分包
- JS脚本非阻塞加载
js加载和渲染是互斥的所以采用非阻塞加载或将其放在包的底部，让渲染进程先执行渲染再解析js
- 缓存策略
- SSR
- 预置loading、骨架屏
渲染优化
- GPU加速：一般是利用css3
- 减少回流、重绘
- 离屏渲染
- 懒加载: 将需要的资源加载到本地
JS优化
-
防止内存泄漏
-
循环尽早break
-
合理使用闭包
-
减少DOM访问
-
防抖、节流
-
Web Worker
跨段容器
为什么需要跨端
- 开发成本、效率
- 一致性体验
- 前端开发生态
跨端方案
- webview
- 小程序
- RN 、Weex
- Lynx
- Flutter
具体省略...
通用原理
- UI组件
- 渲染引擎
- 逻辑控制引擎
- 通信桥梁
- 底层API抹平表现差异
写在最后
想和大家一起看烟花
