浏览器相关知识梳理

浏览器运行机制梳理

前言

已经毕业一年了，说来惭愧，这还是我的第一篇博客，在这方面已经比很多大牛们落后很多了吧，所以现在来恶补一下博客，把这一年的所学所想都写下来，巩固的同时也能给大家带来一些小前辈的经验吧~
这是我的第一篇博客，相当于一个Hello World吧~~思考了一下应该以什么样的内容作为我的博客开端，果然还是应该从浏览器说起吧，毕竟现如今是在做HTML5的手游开发工作，虽然还是和游戏引擎打的交道比较多，但基本功还是不能忘哈，浏览器才是这一切发展的基础~

浏览器的选择

浏览器说白了就是一个EXE程序（Windows系统下），作为一个开发，就用Chrome！没有第二选择！作为一个普通用户，还是用Chrome！所以无脑用Chrome就完事了。至于为什么的话，本来想找个浏览器发展史贴过来的，但本人不太喜欢历史，只需要知道当下最好用的就是chrome，网页渲染速度、V8的执行效率，包括安全、交互体验、界面简洁明了、第三方插件支持、开发工具功能完整等等优点，使他成为开发人员使用的浏览器的不二之选。当然，这是在windows下，听说linux下的浏览器大部分人用的是firefox，这一块没去了解过，windows版的firefox唯一好处可能就是开发者工具对中文的支持吧，但程序员当多了，看中文有时候还真一下反应不过来是啥意思，就比如console…

浏览器的组成

用户界面

以上红框以外的部分都属于用户界面，包括地址栏，页签，前进后退刷新书签目录等。
这一部分相当于浏览器的“前端”部分，负责接收用户的操作，并传递给浏览器引擎进行处理。

浏览器引擎

整个浏览器只有一个浏览器引擎，主要负责浏览器的页面管理、书签、前进后退、资源下载管理等等。同时负责用户界面与渲染引擎的数据通信和本地缓存读写数据，还有一些底层操作比如网络请求和文件访问，所以浏览器引擎是各个部分之间通信的核心。
浏览器引擎中主要的三个线程：network线程，storage线程，UI线程。
network线程负责执行网络方面的操作，比如用户在地址栏输入网址后，用户界面子系统将数据传递给浏览器引擎，浏览器引擎使用network子线程来进行http的请求。
storage线程负责数据的存储，控制文件的访问等。
UI线程则负责控制浏览器的组件显示，包括按钮，地址栏等。

渲染引擎

渲染引擎也称为浏览器内核，它是决定一个浏览器是否能让用户舒服地“浏览”的关键部分。
它负责一个tab内关于网页呈现的所有事情。
一个浏览器有多个渲染进程，每一个页签便对应一个渲染进程。
一个渲染进程包括多个线程：
1.GUI线程
2.JS引擎线程
3.事件线程
4.定时器线程
5.异步请求线程

1.GUI线程负责将网络层提供的数据文件（html，css）构建DOM树和渲染树，进行布局以及绘制。同时，当页面需要重绘或回流时，也由该线程负责执行。Dom树的解析实在太难啃了。。附上链接：
https://www.html5rocks.com/zh/tutorials/internals/howbrowserswork/#The_browsers_we_will_talk_about
2.JS引擎也称JS内核，负责处理Javascript脚本，chrome的JS引擎就是V8引擎，JS线程是单线程，一个页面永远只有一个JS线程。
3.事件线程是属于浏览器的，用于帮助JS线程控制事件的循环。
4.定时器线程类似于事件线程，用于帮助JS线程控制定时器事件。
5.当有类似AJAX异步操作时，浏览器会开一个异步请求线程，当检测到状态改变时，将回调函数放入事件队列中。

JS解释器

只有当渲染线程遇到< script >标签的时候，才会唤醒JS解释器开始工作。
JS解释器负责解释编译JS代码，并在渲染引擎中的JS引擎线程中运行。
编译过程这里也不详讲了，就是将字符串编译为可执行的代码。

浏览器的执行流程

当我们在浏览器地址栏中输入文字，并点击回车获得页面内容的过程在浏览器看来可以分为以下几步：

1. 处理输入

UI thread 需要判断用户输入的是 URL 还是 query；

2. 开始导航

当用户点击回车键，UI thread 通知 network thread 获取网页内容，并控制 tab 上的 spinner 展现，表示正在加载中。

network thread 会执行 DNS 查询，随后为请求建立 TLS 连接
UI thread 通知 Network thread 加载相关信息

如果 network thread 接收到了重定向请求头如 301，network thread 会通知 UI thread 服务器要求重定向，之后，另外一个 URL 请求会被触发。

3. 读取响应

当请求响应返回的时候，network thread 会依据 Content-Type 及 MIME Type sniffing 判断响应内容的格式。

判断响应内容的格式

如果响应内容的格式是 HTML ，下一步将会把这些数据传递给 renderer process，如果是 zip 文件或者其它文件，会把相关数据传输给下载管理器。

Safe Browsing 检查也会在此时触发，如果域名或者请求内容匹配到已知的恶意站点，network thread 会展示一个警告页。此外 CORB 检测也会触发确保敏感数据不会被传递给渲染进程。

4. 查找渲染进程

当上述所有检查完成，network thread 确信浏览器可以导航到请求网页，network thread 会通知 UI thread 数据已经准备好，UI thread 会查找到一个 renderer process 进行网页的渲染。

收到 Network thread 返回的数据后，UI thread 查找相关的渲染进程
由于网络请求获取响应需要时间，这里其实还存在着一个加速方案。当 UI thread 发送 URL 请求给 network thread 时，浏览器其实已经知道了将要导航到那个站点。UI thread 会并行的预先查找和启动一个渲染进程，如果一切正常，当 network thread 接收到数据时，渲染进程已经准备就绪了，但是如果遇到重定向，准备好的渲染进程也许就不可用了，这时候就需要重启一个新的渲染进程。

5. 确认导航

进过了上述过程，数据以及渲染进程都可用了， Browser Process 会给 renderer process 发送 IPC 消息来确认导航，一旦 Browser Process 收到 renderer process 的渲染确认消息，导航过程结束，页面加载过程开始。

此时，地址栏会更新，展示出新页面的网页信息。history tab 会更新，可通过返回键返回导航来的页面，为了让关闭 tab 或者窗口后便于恢复，这些信息会存放在硬盘中。

6. 额外的步骤

一旦导航被确认，renderer process 会使用相关的资源渲染页面。当 renderer process 渲染结束（渲染结束意味着该页面内的所有的页面，包括所有 iframe 都触发了 onload 时），会发送 IPC 信号到 Browser process， UI thread 会停止展示 tab 中的 spinner。

Renderer Process 发送 IPC 消息通知 browser process 页面已经加载完成。

当然上面的流程只是网页首帧渲染完成，在此之后，客户端依旧可下载额外的资源渲染出新的视图。

在这里我们可以明确一点，所有的 JS 代码其实都由 renderer Process 控制的，所以在你浏览网页内容的过程大部分时候不会涉及到其它的进程。不过也许你也曾经监听过 beforeunload 事件，这个事件再次涉及到 Browser Process 和 renderer Process 的交互，当当前页面关闭时（关闭 Tab ，刷新等等），Browser Process 需要通知 renderer Process 进行相关的检查，对相关事件进行处理。

浏览器进程发送 IPC 消息给渲染进程，通知要离开当前网站了
如果导航由 renderer process 触发（比如在用户点击某链接，或者 JS 执行 window.location = “http://newsite.com” ） renderer process 会首先检查是否有 beforeunload 事件处理器，导航请求由 renderer process 传递给 Browser process。

如果导航到新的网站，会启用一个新的 render process 来处理新页面的渲染，老的进程会留下来处理类似 unload 等事件。

关于页面的生命周期，更多内容可参考 Page Lifecycle API 。

浏览器进程发送 IPC 消息到新的渲染进程通知渲染新的页面，同时通知旧的渲染进程卸载。

这一部分原文链接为https://zhuanlan.zhihu.com/p/47407398