从浏览器原理分析界面性能优化00
前言
提到前端总是绕不开前端的性能优化部分,而前端性能优化的难点在于不成体系,需要我们在开发过程中去注意各种细节.
最近这段时间在学习浏览器的原理的过程中,发现了很多知识点和我们的前端优化部分紧密相关,加上之前自己在项目中的实践以及参考网络上大神们的性能优化总结,进行一个只是框架的梳理.
文章的主要目的是提供一个大致的思路框架,以期望各位在实际项目实践中能够快速的定位到自己需要的点.
浏览器原理与优化—网络篇
浏览器原理与优化—渲染篇
因为个人感觉这个话题太大了,所以打算分几章的时间来慢慢整理出来一个大致的轮廓,下面先简单来个概括:
从输入 URL 到界面显示,浏览器经历了什么
这是一道前端经典的面试题,如果要详细讲的话,可以拓展 N 多的知识点.在这里我们只需要记住重要的几步,然后顺着这个思路去看看,我们可以从哪些方面进行优化
- 浏览器将输入的 URL 进行 DNS 解析,解析成 IP 地址
- 浏览器的网络进程和服务器进行 TCP 连接
- 连接建立后,客户端发送 HTTP 请求,请求数据
- 请求有结果后,浏览器渲染进程获取数据进行内容的解析,将解析后得到的界面展示出来
上面几个核心步骤是所有界面渲染都需要经历的过程,我们可以从上面几点剖析一下浏览器的工作原理,同时整理一下我们前端的优化知识点.
按照上图中的思路,我们可以从网络请求和DOM渲染两个层面来进行我们的性能优化.
PS:因为本人看的浏览器的原理主要是基于 Chrome 的,所以我们暂时只讨论在 Chrome 浏览器下的过程
浏览器的多进程架构
宏观看浏览器的话,他是一个多进程的架构,多进程指的是当我们打开一个浏览器网页的时候,可以从浏览器的任务管理器看到开启的多个进程.
它通常包含:浏览器进程、网络进程、插件进程、GPU 进程和网页渲染进程五个进程.每个进程所负责的工作都是不同的
- 浏览器进程,负责界面显示、用户交互、子进程之间的调度和一些存储功能
- 渲染进程,渲染进程主要负责将 HTML 文件、CSS、JS 转换为用户可以访问的网页,排版引擎 Blink(前身是 Webkit)和 JavaScript 引擎 V8 都运行在该进程中,默认情况下 Chrome 会为每个标签页面创建一个渲染进程(同源站点的情况单独考虑).
- GPU 进程,GPU 主要是用来绘制界面同时实现一些特殊的效果
- 网络进程,网路进程主要负责网络请求的处理,之前都是依附在浏览器进程中.现在独立称为一个单独的进程
- 插件进程,主要负责插件的运行,因为进程间数据相互独立的特性,插件崩溃也不会影响到界面的运行
多进程架构的优势
浏览器的多进程架构是由之前的单进程架构改进而来的,我们都知道进程内的资源是共享的,但是进程与进程间是互相隔离的.
相对于之前的单进程架构,多进程架构的优势很明显
更稳定
之前所有的浏览器任务都运行在一个进程内,插件模块和渲染模块等都运行在一个进程中,当其中一个模块出现问题,就可能引起整个浏览器的崩溃
但是多进程架构很显然规避了这个问题,插件模块和渲染模块都在不同的进程中,当插件模块崩溃时,渲染进程依然能够保证界面渲染实现
更流畅
在单进程架构的情况下渲染模块和插件模块以及 JS 都运行在一个进程中,这也意味着当我们的 JS 执行一段耗时操作的时候,会造成所有界面的卡顿.
例如:
function timer(){
while(true){
console.log('something')
}
}
timer()
但是在多进程的情况下,每个界面都对应了一个渲染进程(先不考虑同源站点的情况),也就是说当同样执行一段耗时操作的时候,只有本界面会造成卡顿,其他界面依然能够流畅的运行.
更安全
单进程的情况下,通过 C/C++编写的插件可以获取到操作系统的任意资源,我们使用一个插件的时候这个插件也可以任意操作我们的电脑.另外的页面脚本也可以通过浏览器的漏洞获取我们的系统权限,这是非常不安全的.
但是多进程的浏览器架构采用了安全沙箱的策略,可以看作是操作系统对浏览器进程的一种封锁,进程内的程序能够流畅的运行,但是不能够在你的硬盘上写入数据也不能读取电脑的一些敏感信息等.
多进程架构的缺陷
多进程架构确实很强大,但是也有他的缺点
- 更高的资源占用,多进程以为着消耗更多的内存资源
- 更复杂的架构,现在的多进程架构会增大浏览器各个模块之间的耦合性造成扩展性变差,因此不得不使用更加复杂的架构来满足新的需求.