关于前端:Chrome浏览器是如何工作的一

theme: mk-cute

“我报名加入金石打算 1 期挑战——瓜分 10 万奖池，这是我的第 n 篇文章，点击查看流动详情”

Chrome 浏览器是如何工作的？（一）

前言:

观看视频有感，顺手记录一下。并且对于本人身为一个前端工程师，连一个浏览器的页面渲染的大抵过程都无奈正确表达出来，深深感到惭愧。

tips: 本文是纯老手向，只会以本人初学的了解解说大抵过程，给和我有同样疑难的老手提供一个大抵的思路，并且会同步解说其它额定相干常识。本文并不会牵扯源码级别的实现，请各位深知其中细节大佬键⌨️下留情。

<hr/>

一. 当你刚关上浏览器时

1. 双击浏览器图标
2. 紧接着零碎调配给浏览器一块内存
3. 随后浏览器创立一个过程筹备工作（progress）

以 Mac 为例子，在 聚焦 内搜寻流动监视器，就会呈现相似于 Windows 工作管理器很类似的窗口，能够看到这台机器上运行着曾经开启的 Chrome 利用过程。

二. 浏览器启动后

祝贺你 取得了一个空白的 Chrome 首页，然而没想到吧～它此时曾经同步开启了多个过程来帮助它实现后续工作。

1. 找到 Chrome 右上角头像旁边的三个点点，找到更多工具，点击工作管理器，就能够看到此时 Chrome 浏览器运行时，同步开启了哪些过程。

2. 你自定义的拓展工具也会各自开启一个过程。

3. 回过头看一下这些过程别离代表着什么

浏览器过程（主过程，但不负责 Tab）次要管制 -> 地址栏、书签、后退、后退，并负责进行浏览器和其它过程之间的调度协调。主过程又细分为：1. GPU 过程（负责整个浏览器页面的渲染，蕴含顶部的搜寻栏，和 Tab 标签页的内容）2. Network：网络过程（看名字就不言而喻，负责网络申请的解决）3. Storage: 缓存过程（顾名思义，治理缓存之类）4. Audio: 音频过程（顾名思义）5. Data Decoder : 数字解码过程
  6. Plugin : 在这里没有明确写出 Plugin 这几个字，其实它就是咱们浏览器
  

4. 能够很清晰的看到，每个 Tab 页都有属于本人的一个过程，这也就保障了某一个页面卡死，然而并会不影响其它页面的失常工作。

然而这样一种一个 Tab 一个过程分配原则是肯定的吗？并不一定，这取决于你浏览器设置的 过程模型 是什么。这里贴一下 Chromium文档。

其中 Chrome 默认应用的的就是第一个 Process-per-site-instance 模型，能够简略的了解为每个 Tab 都会调配一个过程去解决。另外三个模型能够自行理解，这里我临时还未搞懂，就不误导大家了。

三. 当你在 url 地址栏输出网站敲下回车后

1. 此时浏览器线程会开启一个 UI 线程去捕获你输出的到底是关键字还是域名。这里假如你输出的是 www.baidu.com（输出的是域名，并不是关键字。）
2. UI 线程判断你输出的是域名，而后它会把用户输出的信息告诉给Network 过程。（这里就须要理解一下过程之间的通信是通过 IPC inter process communication）
3. Network 过程收到告诉后，会去申请 DNS（domain name system）域名解析零碎，解析域名绝对应的 IP 地址。
4. 如果你输出的是关键词，那么 Network 过程会应用默认的搜索引擎去查找绝对应的输出内容。
5. 当网络过程拿到站点服务器返回的数据后，（留神，此时你曾经拿到绝对应的页面信息，然而还没渲染到页面上）首先 Chrome 自带的 SafeBrowsing 会查看站点是否⚠️危险站点。（通常是查看站点 ip 是否在谷歌的黑名单里)
6. ok，假如你拜访的并不是危险网站。那么 Network 过程会告诉 UI 过程我这边解决好了，该你上场了。

7. UI 线程拿到网站数据后，会创立一个渲染过程（Renderer Process）来渲染页面。（通过 IPC 传递）

四. 页面渲染流程

1. 渲染过程拿到数据后，也就是 .html 文件后，将会解析该文件。构建对应的 Dom 节点。（拿到的其实就是这个样子）

2. 紧接着进行 Render 过程进行 Tokeniser 词法解析。这个过程有些形象，这里我简略举个栗子🌰。（比方: 我明天吃了一个冰激凌🍦，其中【我】是主语，【吃】是动词，【冰激凌】是名词，这些都是咱们人类主观定义好的词性，如何让机器去了解这写词语的词性，就是词法解析。）映射到这里，就好比咱们写的<div>、<img> 等标签，都是咱们人主观定义好的，通知机器如何去了解对应的数据，这个过程就是词法解析。
3. 当解析好当前，紧接着会进行 DOM Tree 结构。

4. ⚠️留神此时实在 DOM 还未结构进去。
5. 这时候会创立 Document 对象，body对象，节点对象等等。（这里不要感觉很浅近。没错，这里创立的 Document 对象并不是什么稀奇玩意，就是咱们罕用的 document.getElementById 办法中的那个 document。Body 同理。）
6. 文档解析是从上向下解析的，当遇到像 <img> 等行内替换元素是不会阻塞 Dom Tree的结构的。然而当遇到 <script> 标签的时候，就会进行解析 .html 文件，晓得 .js 文件解析结束。为什么呢？这也就是为什么 JS 为什么要设计成单线程的起因，如果解析 dom 和 JS 并行，那么就会造成某一时刻 dom 要将一个 div 渲染成一个 蓝色 背景，然而 JS 同时批改了这个 div 的背景色彩为 红色，那我到底该听谁的呢？通常就会造成页面无奈失常工作。

7. 也对应了最开始学习 html 标签时的常识，<script> 标签要放到适合的地位。
8. 假如当初最初一行代码曾经解析结束，那么咱们就会失去一个残缺的 DOM Tree

五. 款式渲染

这个过程就是解析.css 文件的过程，查找每个节点是否有设置类名，而后增加绝对应的款式即可。

六. 元素渲染地位

1. 只拿到了每个元素该渲染成什么样子是不够的，这时候还须要晓得各个元素所须要出现在页面哪个地位。也就是元素所占页面的大小和节点的坐标。这个过程称为 Layout布局。
2. Render 主线程通过遍历 DOM Tree 和先前计算好的款式生成与之对应的 Layout Tree。Layout Tree 记录了每个节点在页面上对应的（x,y）坐标和尺寸。

3. 这里须要留神的是，DOM Tree 和 Layout Tree 并不是一一对应的关系。DOM Tree 某个元素如果设置了display:none，则该元素不会呈现在 Layout Tree 上。
4. 而如果在款式中设置了 伪类 （如：div::before）并且设置了 content 属性，那么该元素就会呈现在 Layout Tree 上，然而并不会呈现在 Dom Tree 上。造成这个的根本原因就是 DOM Tree 齐全就是依据 html 生成的，它并不关怀款式。而 Layout Tree 是依据计算 DOM Tree 和 款式 计算生成的。

<hr/>

篇幅有些长，有点晚了，我要睡觉啦～未完待续 …