浏览器架构
主要架构模式介绍:
- 单进程架构:所有模块运行在同一个进程里,包含网络、插件、JavaScript运行环境等
- 多进程架构:主进程、网络进程、渲染进程、GPU进程、插件进程
- 面向服务架构:算是多进程架构的升级版。将原来的UI、数据库、文件、设备、网络等,作为一个独立的基础网络服务
浏览器架构对比
浏览器架构--任务管理器
浏览器架构--多进程分工
-
为什么会有单进程架构?
1.简单性
单进程架构更易于实现和维护,因为它不需要处理多进程间的通信和资源分配问题。对于早期的浏览器开发者来说,单进程架构提供了一种快速实现浏览器功能的方法。
2.资源消耗
相较于多进程架构,单进程架构在内存和CPU资源消耗方面较低。因为多进程架构中,每个进程都需要占用一定的系统资源,而单进程架构只需要维护一个进程。在计算机硬件资源有限的早期,这一点是非常重要的。
3.兼容性
早期的Web技术和标准相对较为简单,单进程架构在兼容性方面表现优秀。因为不需要处理多进程间的兼容性问题,单进程浏览器更容易支持不同的操作系统和硬件平台。 -
面向服务架构是否会替代多进程架构?
- 面向服务架构在某种程度上可以看作是多进程架构的一种演进和优化。这种架构将浏览器的各个功能模块化,作为独立的服务来运行和维护。这样可以进一步提高浏览器的稳定性、安全性和性能,同时优化资源利用率。
- 尽管面向服务架构具有一定的优势,但是它不一定会完全替代多进程架构。这是因为两种架构各自有不同的应用场景和优缺点:
- 面向服务架构在某种程度上可以看作是多进程架构的一种演进和优化。这种架构将浏览器的各个功能模块化,作为独立的服务来运行和维护。这样可以进一步提高浏览器的稳定性、安全性和性能,同时优化资源利用率。
-
面向服务架构更适用于复杂的浏览器系统,它可以更好地管理和维护浏览器的各个功能模块。然而,在一些轻量级或特定用途的浏览器中,多进程架构可能仍然是一个合适的选择,因为它相对简单且易于实现。
-
面向服务架构的优势在于模块化和灵活性,它可以根据需求自动扩展或缩减资源。但是,这种架构可能需要更多的系统资源和开发维护成本。多进程架构在资源消耗和开发成本方面可能更具优势。
-
不同浏览器厂商可能会根据自己的产品定位和技术栈选择不同的架构。例如,谷歌Chrome浏览器采用了多进程架构,并在此基础上引入了一些面向服务架构的设计理念。而其他浏览器厂商可能会选择完全基于面向服务架构的实现。
渲染进程
常见浏览器内核
渲染进程 - 多线程架构
内部是多线程实现,主要负责页面渲染,脚本执行,事件处理,网络请求等。
JS引擎 vs 渲染引擎
- 解释执行JS
- XML解析生成渲染树,显示在屏幕
- 桥接方式通信
多线程工作流程
- 网络线程负责加载网页资源
- JS引擎解析JS脚本并执行
- JS解析引擎空闲时,渲染进程立即工作
- 用户交互、定时器操作等产生回调函数放入任务队列中
- 事件线程进行事件循环,将队列里的任务 取出交给JS引擎执行
Chrome运行原理
浏览器地址输入URL后发生了什么?
-
输入处理:
- 用户URL框输入内容后,UI 线程会判断输入的时一个URL地址呢还是一个query查询条件;
- 如果是URL,直接请求站点资源;
- 如果是query,将输入发送给搜索引擎。
-
开始导航:
- 当用户按下回车,UI线程通知网络线程发起一个网络请求,来获取站点内容;
- 请求过程中,tab页处于loading状态。
-
读取响应:
- 网络线程接受到HTTP响应后,先检查响应头的媒体类型(MIME type);
- 如果响应主体是一个HTML文件,浏览器将内容交给渲染进程处理;
- 如果拿到的是其他类型文件,比如zip、exe等,则交给下载管理器处理。
-
寻找渲染进程:
- 网络线程做完所有检查后,会告知主进程数据已经准备完毕,主进程确认后为这个站点寻找一个渲染进程;
- 主进程通过IPC消息告知渲染进程去处理本次导航;
- 渲染进程开始接受数据并告知主进程自己已开始处理,导航结束,进入文档加载阶段。
-
渲染进程-资源加载:
- 收到主进程的消息后,开始加载HTML文档;
- 除此之外,还需要加载子资源,比如一些图片,CSS样式文件以及JavaScript脚本。
-
渲染进程-构建渲染:
- 构建DOM树,将HTML文本转化成浏览器能够理解的结构;
- 构建CSSOM树,浏览器同样不认识CSS,需要将CSS代码转化为可理解的CSSOM;
- 构建渲染树,渲染树是DOM树和CSSOM树的结合。
-
渲染进程-页面布局:
- 根据渲染树计算每个节点的位置和大小
- 在浏览器页面区域绘制元素边框
- 遍历渲染树,将元素以盒模型的形式写入文档流
-
渲染进程-页面绘制:
- 构建图层:为特定的节点生成专用图层
- 绘制图层:一个图层分成很多绘制指令,然后将这些指令按顺序组成一个绘制列表,交给合成线程
- 合成线程接收指令生成图块
- 栅格线程将图块进行栅格化
- 展示在屏幕上
首屏优化
- 压缩、分包、删除无用代码
- 静态资源分离
- JS脚本非阻塞加载
- 缓存策略
- SSR
- 预置loading、骨架屏
渲染优化
- GPU加速:一般是利用css3
- 减少回流、重绘
- 离屏渲染
- 懒加载
JS优化
- 防止内存泄漏
- 循环尽早break
- 合理使用闭包
- 减少DOM访问
- 防抖、节流
- Web Worker
跨端容器
为什么需要跨端
- 开发成本、效率
- 一致性体验
- 前端开发生态
有哪些跨端方案
- webview
- 小程序
- RN 、Weex
- Lynx
- Flutter
webview
Webview,即网页视图,用于加载网页Url,并展示其内容的控件。
可以内嵌在移动端App内,实现前端混合开发,大多数混合框架都是基于Webview的二次开发:比如lonic、Cordova、uniapp。
优点:
- 一次开发,处处使用,学习成本低
- 随时发布,即时更新,不用下载安装包
- 移动设备性能不断提升,性能有保障
- 通过JSBridge和原生系统交互,实现复杂功能
Javascript调用Native:
- API注入: Native获取Javascript环境上下文,对其挂载的对象或者方法进行拦截
- 使用Webview URL Scheme跳转拦截
- IOS上window.webkit.messageHandler直接通信
Native调用Javascript:
- 直接通过webview暴露的API执行JS代码
- IOS方法:webview.stringByEvaluatingJavaScriptFromString
- Android方法:webview.evaluateJavascript
Webview 和 Native通信:
- JS环境中提供通信的JSBridge
- Native端提供SDK响应JSBridge发出的调用
- 前端和客户端分别实现对应功能模块
小程序
常见小程序:微信小程序、支付宝小程序、百度小程序、小米直达号
小程序架构:
- 渲染层-webview
- 双线程,多webview架构
- 数据通信,Native转发
React Native / Weex
- 原生组件渲染
- React / Vue 框架
- virtual dom
- JSBridge
在安卓和IOS中展示是不一样的,因为底层还是调用的安卓或IOS的底层组件。
Lynx
字节自研的一款跨端框架。(暂未开源,字节旗下使用较多)
- Vue
- JS Core / V8
- JSBinding
- Native UI / Skia
Flutter
- wideget
- dart vm
- skia图形库
通用原理
- UI组件
- 渲染引擎
- 逻辑控制引擎
- 通信桥梁
- 底层API抹平表现差异
跨端方案对比
同样是基于webview渲染,为什么小程序体验比webview流畅?
小程序会先把需要的资源下载下来,在使用的时候直接使用;限制了相关DOM操作。