特别提醒:本文出自B站的卢克。
为什么我们要去了解浏览器的工作原理呢?很简单,让你写出更好的代码和提供更好的用户体验。浏览器对于前端工程师,就像赛车对于一个赛车手一样,你需要对自己的战车足够的了解,才能跑的更快,弯道拐的更优雅。伟大的作家鲁迅曾说过,不懂浏览器的前端工程师不是好码农。
1.浏览器发展史
1991年:Berners-Lee建立了第一代网络浏览器:WorldWideWeb。对了,上一期讲的互联网,他也是发明者之一,真大神,牛批!当时的WorldWideWeb的功能十分简单,只支持显示文本,图片等。
1993年: Mosaic问世,这是一种可以同时显示文本和图像的浏览器,一经推出就受到全球用户的欢迎
1994年:网景浏览器发布,它是由曾经参与开发Mosaic的人共同创建,虽然网景的功能也十分有限,只能显示简单的静态html,没有js,css,但依然大受欢迎,获得世界范围内的成功,并占领了绝大多数市场份额。同年也出现了Opera,这个大家可能用的比较少
然后1995年微软发布了万恶的IE1.0,IE2.0,自此第一次浏览器大战正式打响。接着1996年发布的IE3.0和windows操作系统集成在了一起,而此时网景的市场份额已经达到了86%。IE发行后的4年内,在windows操作系统的帮助下,逐渐取代了网景浏览器的领导地位,达到了市场份额的75%,到1999年,它已经占据了浏览器市场的99%,简直恐怖,前端工程师的噩梦来临了。
然而网景公司并没有一蹶不振,网景在1998年成立了Mozilla基金会,在该基金会的推动下,网景公司开发了著名的开源项目火狐浏览器Firefox来迎击IE,并在2004年发布了1.0版本,拉开了第二次浏览器大战的序幕
在Firefox发布的前一年2003年,苹果发布了Safari浏览器,而且该浏览器被包含在所有苹果操作系统中,更重要的是,在2005年苹果开源了Safari浏览器的内核webkit。
2008年,谷歌以苹果开源项目WebKit作为内核,创建了一个新的项目Chromium,在该项目的基础上苹果发布了自己的浏览器产品Chrome,Chrome发展十分迅速,现在已经成为全球最受欢迎的浏览器。
由于IE的性能和体验问题,IE逐渐掉队。2015微软也放弃了IE,推出了基于webkit内核的Edge浏览器作为IE的替代品,但为时已晚。
咱们再看看国内的浏览器。
我记得小时候身边的人的浏览器都是被360或者qq浏览器统治了,后来才知道,长大后才知道你们都是披着马甲的IE!!不过近几年国内浏览器的都是IE和chromium双内核。那我们就没有自己研发的浏览器内核么?至今是没有的,08年曾闹过一个笑话,红芯科技为了融资宣称自主研发的红芯浏览器使用的是公司自己开发的内核。结果被技术圈内网友打脸,最后证实是使用的是blink内核。研发内核是十分耗时耗力的,就拿chromium来说,据传Google最多时候召集过1000个硅谷的程序员集中力量去开发 Chromium内核,花了至少10年。所以自研国产浏览器内核任重而道远啊。
虽然浏览器品类众多,但他们的提供的功能都基本类似,框架结构也都大同小异。
2.浏览器结构
渲染引擎下面还有很多小的功能模块,比如负责网络请求的网络模块,用于解析和执行js的js解释器。还有数据存储持久层,帮助浏览器保存各种数据,比如cookie等等
渲染引擎可以说是一个浏览器的核心与灵魂,也是本期视频内容的重点。我们往往会把渲染引擎称为浏览器内核。不同浏览器使用的内核也不大一样,其中IE使用的Trident,Firefox是Gecko,Sarafi使用的webkit, 并将其开源,Chrome是使用的基于webkit改造优化的Blink渲染引擎,也将其开源,Opera和Edge也是使用的Blink。可以看到webkit项目的开源对浏览器的发展做了多大的贡献。
我们这期视频主要以Chrome为例,那下面如果不做特殊说明都是以chrome为例来讲解浏览器是如何工作的。
现在,我们换一个角度来拆解一下浏览器的组成结构。
浏览器是运行在操作系统上的一个应用程序,那我们在小学二年级就学过,每个应用程序必须至少启动一个进程来执行其功能。那一个程序往往需要运行很多任务,那进程就会创建一些线程来帮助它去执行这些细小的任务。这里我们就引入了两个概念,进程和线程。给你3秒钟时间想想进程和线程的联系和区别。三、二、一。没想起来的同学自行拿出小学课本《计算机操作系统教程》复习一下。
来,我给大家补补课~
😂
1. 进程是操作系统进行资源分配和调度的基本单元,可以申请和拥有计算机资源,进程是程序的基本执行实体。
2. 线程是操作系统能够进行运算调度的最小单位,一个进程中可以并发多个线程,每条线程并行执行不同的任务。
哎,看不懂,还是我来给大家讲吧
当我们启动某个程序时,就会创建一个进程来执行任务代码,同时会为该进程分配内存空间,该应用程序的状态都保存在该内存空间里。当应用关闭时,该内存空间就会被回收。进程可以启动更多的进程来执行任务,由于每个进程分配的内存空间是独立的,如果两个进程间需要传递某些数据,则需要通过进程间通信管道IPC来传递。很多应用程序都是多进程的结构,这样是为了避免某一个进程卡死,由于进程间相互独立,这样不会影响到整个应用程序。举个例子,你可以把笔记本电脑想象成一个应用程序,外接鼠标是该应用程序的一个进程,如果外接鼠标出了问题,并不会影响你继续使用笔记本电脑。进程可以将任务分成多个更细小的任务,然后通过创建多个线程,并行执行不同的任务。同一进程下的线程之间是可以直接通信共享数据的。
不知道你有没有听懂进程和线程的联系和区别。没听懂没关系,继续往下听,也许你会慢慢理解。
那今天的主角-浏览器也是一个多进程结构。
但早期的浏览器并不是多进程的结构,而是个单进程结构。
一个进程中大概有页面线程负责页面渲染和展示等,JavaScript线程执行js代码,还有其他各种线程。单进程的结构引发了很多的问题。一是不稳定,其中一个线程的卡死可能会导致整个进程出问题,比如你打开多个标签页,有一个标签页卡死,可能会导致整个浏览器无法正常运行,二是不安全,线程之间是可以共享数据,那js线程岂不是可以随意访问进程内的数据,三是不流畅,一个进程需要负责太多事情,会导致运行效率的问题。
所以为了去解决以上这些问题,现在采用了多进程浏览器结构。根据进程功能不同来拆解浏览器,我们可以将它们分解为这样的结构。
其中,浏览器进程负责与浏览器的其他进程协调工作。你可以把他想成一个工厂里的主管,用来协调各个进程部门。
网络进程负责发起接受网络请求,GPU进程负责图形渲染,插件进程负责控制网站使用的所有插件,例如Flash。这里插件并不是指的是Chrome市场里安装的扩展。Extension 进程
渲染器进程用来控制显示tab标签内的所有内容,浏览器在默认情况下会为每个标签页都创建一个进程,为什么这里会说有可能呢?这和你启动chrome时选择的进程模型有关。
在Chromium的官方文档(文档地址:https://www.chromium.org/developers/design-documents/process-models )上,说明了Chrome一共有四种进程模型,分别是默认的Process-per-site-instance,
来,我给大家翻译下,默认情况下,Chromium为用户访问的网站的每个实例创建一个渲染器进程。这样可以确保来自不同站点的页面是独立呈现的,并且对同一站点的单独访问也是彼此隔离的。简单来说就是访问不同站点和同一站点的不同页面都会创建新进程。
Process-per-site同一站点使用同一进程。
Process-per-tab一个tab里的所有站点使用一个进程。
Single process则会让浏览器引擎和渲染器引擎共用一个进程。
该文档还说明了各个进程模型的好处和坏处。大家有兴趣的可以自己去阅读一下。网址我会放在视频的末尾处。
显而易见,Process-per-site-instance模型会创建更多的进程占用更多的内存空间,但确实最安全,每个tab,以及tab内的每个站点都是相互隔离互不影响的。当其中一个标签页里渲染器进程卡死,并不会影响其他标签。
浏览器当前的所有进程我们都可以通过点击右上角的菜单按钮,然后点击选择更多工具的任务管理器,从任务管理器我们看到当前浏览器启动了哪些进程,并且每个进程的ID号,从里面我们还可以发现,我们安装的每个扩展程序,Chrome都为他们启动了一个单独的进程来运行。奢侈啊!然而还有更奢侈的,如果网页中嵌入了iframe,chrome会为每个iframe都创建了一个进程!那为什么为iframe也要创建单独的进程,主要还是出于安全考虑,通过多进程让当前的主站点和iframe里的站点之间隔离,这里我就不展开讲了。
现在我们在浏览器上输入网址www.bilibili.com
, 再你三秒钟想想浏览器是如何通过互联网获取到网页数据的?如果想不起来就去看上一期的视频补补课。但上一期的内容中,我没有讲当你在浏览器地址栏里输入内容时,浏览器内部发生了什么?
3.浏览器渲染原理
当你在地址栏输入地址时,浏览器进程的UI线程会捕捉你的输入内容,如果访问的是网址,则UI线程会启动一个网络线程来请求DNS进行域名解析接着开始连接服务器获取数据。如果你的输入不是网址而是一串关键词,浏览器就会知道你是要搜索,于是就会使用你默认配置的搜索引擎来查询。
我们主要来看看网络线程获取到数据后会做什么事。这里是整个视频内容的重点也比较复杂,这一部分我会全程用动画给你展示,我希望你可以放下你手中的零食,专心的看,看完你会收获很多。好,走起!
当网络线程获取到数据后,会通过SafeBrowsing来检查该站点的是否是恶意站点。如果是则会展示个警告页面,告诉你这个站点有安全问题,浏览器会阻止你的访问。当然你也可以强行继续访问。SafeBrowsing是谷歌内部的一套站点安全系统,通过检测该站点的数据来判断是否安全。比如通过查看该站点的ip是否在他们的黑名单内。
当返回数据准备完毕并且安全校验通过,网络线程会通知UI线程,我这准备好了,该你拉。然后UI线程会创建一个渲染器进程来渲染页面。浏览器进程通过IPC管道将数据传递给渲染器进程,正式进入渲染流程。
此时地址栏的状态更新,比如histroy更新,现在可以点击导航栏的后退。渲染器进程收到的数据,也就是html。渲染器进程的核心任务就是把html、js、css、img等资源渲染成用户可交互的web页面。
渲染器进程的主线程将html进行解析,构造DOM数据结构。DOM文档对象模型是浏览器对页面在其内部表示形式,是Web程序员可以通过JavaScript与之交互的数据结构和API。HTML首先经过Tokeniser标记化,通过词法分析,将输入html内容解析成多个标记,根据识别后的标记进行DOM树构造, 在 DOM树构造过程中会创建Document对象,然后以Document为根节点的DOM树不断进行修改,向其中添加各种元素。
HTML代码中往往会引入一些额外的资源,比如图片,css和js脚本等。图片和css这些资源需要通过网络下载或者从缓存中直接加载。这些资源不会阻塞html的解析,因为他们不会影响DOM的生成,但当html解析过程中遇到script标签,将停止html解析流程,转而去加载解析并且执行js。你可能就会问了?为什么不直接跳过js的加载和执行这一过程,等html解析完后再加载运行js呢?这是因为,浏览器不知道js的执行是否会改变当前页面的html的结构,如果js代码了调用document.write方法来修改html,那之前的html的解析就没有任何意义了。这也就是为什么我们一直说要把script标签要放在合适的位置,或者使用async 或defer属性来异步加载执行js。
在html解析完成后,我们就获得一个dom tree,但我们还不知道dom tree上每个节点应该长什么样。主线程需要解析css并确定每个DOM节点的
即使你没有提供自定义的css样式,浏览器也有自己的默认的样式表,比如h2的字体要比h3的大,具体默认的样式表可以在这里查看。比如这里设定了h2的默认字体大小是要大于h3的。我这展示的是chromium的源码,是不是很激动。
在知道dom结构和每个节点的样式后,我们接下来需要知道每个节点需要放在页面上的哪个位置,也就是节点的坐标,以及该节点需要占用多大的区域。
这个阶段被称为layout布局,主线程通过遍历DOM和计算好的样式来生成layout tree,layout tree上的每个节点都记录x,y坐标和边框尺寸。这里需要注意的一点是DOM Tree和layout tree并不是一一对应的,设置了display:none的节点不会出现在layout tree上,而在before伪类中添加了content值的元素,content的内容会出现在layout tree,不会出现在DOM树里。这是因为DOM 是通过html解析获得,并不关心样式。而layout tree是根据dom tree和计算好的样式来生成,layout tree是和最后展示在屏幕上的的节点是对应的。
好了,现在我们已经知道元素的大小,形状和位置,这还不够,我们还需要做什么了呢。对了,还需要知道以什么样的顺序绘制各个节点。举例来说,z-index这个属性会影响节点绘制的层级关系。如果我们按照dom的层级结构来绘制页面,则会导致错误的渲染。
比如像这样一段代码,神烦狗是不应该盖住我的头的,啊喂,为什么毫无违和感啊。不重要啦,那正确的层级顺序应该是我压在狗头上,我去,这独眼狗有点吓人,赶紧切走。
所以为了保证在屏幕上展示正确的层级,在绘制阶段,主线程遍历layout tree创建一个绘制记录表,该表记录了绘制的顺序。
现在知道了文档的绘制顺序,终于到了该把这些信息转化成像素点显示在屏幕的时候了。那这种行为,被称为rasterizing,栅格化。Chrome最早使用了一种很简单的方式,只栅格化用户可视区域的内容,当用户滚动页面时,再栅格化更多的内容来填充缺失的部分。这种方式带来的问题显而易见,会导致展示延迟。随着不断的优化升级,现在的Chrome使用了一种更复杂的栅格化流程,叫做compositing组合。Compositing是一种将页面的各个部分分成多个图层,分别对其进行栅格化并在合成器线程compositor thread的单独线程中进行合成页面的技术。简单来说就是,页面所有的元素按照某种规则进行分图层,并把图层都栅格化好了,然后只需要把可视区的内容组合成一帧展示给用户即可。
主线程遍历layout tree生成layer tree。
栅格线程栅格化每个图块并将它们存储在GPU内存中。对图块进行栅格化后。合成器线程可以给不同的栅格线程分别优先级,比如栅格化可视区域图块的栅格线程优先处理。
当图块栅格化完成后,合成器线程将收集称为“draw quads”的图块信息,这些信息里记录了包含诸如图块在内存中的位置和在页面的哪个位置绘制图块的信息。根据这些数据合成器线程生成了一个合成器Frame。然后这个合成器frame通过IPC传送给浏览器进程,
接着浏览器进程将compositor frame传到GPU,然后GPU渲染展示到屏幕上。恭喜你,你终于看到了页面内容。当你的页面然后变化,比如你滚动了当前页面,则会生成一个新的compositor frame,新的frame再传给GPU。再次渲染到屏幕上。
是不是一下接受到太多知识一下接受不了,那我给大家整理下刚才所讲到的知识点。
浏览器进程的网络线程请求获取到html数据和通过IPC将数据传给渲染器进程的主线程,主线程讲html解析构造DOM树,然后计算样式,根据DOM树和样式生成layout Tree,通过遍历layout tree生成绘制顺序表,然后主线程将layout Tree和绘制顺序信息一起传给合成器线程,合成器线程按规则进程分图层,并把图层分为更小的图块传给栅格线程进行栅格化,栅格化完成后,合成器线程会获得栅格线程传过来的"draw quads"图块信息,根据这些信息,合成器线程合成了一个frame,然后将该合成frame通过IPC传回给浏览器进程,浏览器进程在传到GPU进行渲染,最后就展示到你的屏幕上了。
当我们改变一个尺寸位置属性时,会重新进行样式计算,布局,绘制,以及后面的所有流程。这种行为我们称为重排。当我们改变某个元素的颜色属性时,不会重新触发布局,但还是触发会样式计算和绘制,这个就是重绘。我们可以发现重排和重绘会占用主线程,还有一个东西的运行也是在主线程。对,js。既然他们都是在主线程就会出现抢占执行时间的问题。
如果你们写了个不断导致重绘重排的动画,浏览器则需要在每一帧都会运行样式计算、布局和绘制的操作,我们知道当页面以每秒大于60帧的刷新率,才不会让用户感觉到页面卡顿。
那有什么优化的手段吗?
有,第一种就是可以通过requestAnimationFrame这个api来帮助我们解决这个问题。requestAnimationFrame这个方法会在每一帧被调用,通过这个api的回调参数,我们可以知道每一帧当前还剩余的,我们可以把js运行任务分成一些小块,在时间用完前,归还主线程,
react最新的渲染引擎react fiber就是用到了这个api来做了很多优化,后面我也会出一期视频专门来讲React的最新渲染引擎React Fiber。
还有第二个优化方法。刚才我们知道栅格化整个流程是不占用主线程的,只在合成器和栅格线程中运行,这就意味着它无需和js抢夺的主线程。刚才提到,如果我们反复重绘和重排,可能会导致掉帧,因为有可能会有js的执行阻塞了主线程。css中有个动画属性叫transform,通过该属性实现的动画,不会经过布局和绘制,而是直接运行在Compositor和rasterizing线程中,所以不会受到主线程中js执行的影响。更重要的是transform的动画,由于不需要经过布局绘制样式计算,所以节省了很多运算时间。可以让复杂的动画更加流畅。我们常常会哪些属性来实现动画效果呢,位置变化,宽高变化,那这些都可以使用transform来代替。
所以说一个页面的动画好坏,可以说是十分影响用户的体验。
我想,如果面试的时候面试官问了你为什么要避免大量的重绘和重排,你能把刚才我讲的这些说个七七八八,那这个道题回答的基本满分。
今天的内容就到这里,知识点比较多,不太容易消化,大家可以反复多看几遍。建议看看下面提供的参考资料帮助你理解。