#5:0:b:4:5:f:0:8:6:5:3:e:1:4:2:4:1:6:e:e:9:f:6:4:f:a:5:f:5:b:a:a#
可能每一个后端工程师都想要理解浏览器的工作原理。
我们希望晓得从在浏览器地址栏中输入 url 到页面诠释的短短几秒内浏览器到底做了哪些；
我们希望了解平常时常据说的各类代码优化方案是到底为何能起到优化的作用；
我们希望更细致地了解浏览器的渲染流程。
浏览器的多进程构架
一个好的程序经常被界定为几个互相独立又彼此配合的模块，浏览器也是这么，以 Chrome 为例，它由多个进程组成，每个进程都有自己核心的职责，它们互相配合完成浏览器的整体功能，每个进程中又包含多个线程，一个进程内的多个线程也会协同工作，配合完成所在进程的职责。
对一些后端开发朋友来说，进程和线程的概念可能会有些模糊，为了更好的理解浏览器的多进程构架，这里我们简单讨论一下进程和线程。
进程（process）和线程（thread）
#2:6:2:c:b:b:9:e:b:9:d:1:f:1:d:f:d:2:b:c:3:0:c:a:1:b:c:c:c:6:6:e#
进程如同是一个有边界的生产厂间，而线程如同是厂间内的一个个职工，可以自己做自己的事情，也可以互相配合做同一件事情。
当我们启动一个应用，计算机会创建一个进程，操作系统会为进程分配一部分显存，应用的所有状态就会保存在这块显存中，应用其实都会创建多个线程来辅助工作，这些线程可以共享这部份显存中的数据。
如果应用关掉，进程会被终结，操作系统会释放相关显存。
更生动的示意图如下：
一个进程还可以要求操作系统生成另一个进程来执行不同的任务，系统会为新的进程分配独立的显存，两个进程之间可以使用 IPC （Inter Process Communication）进行通讯。
很多应用就会采用这样的设计，如果一个工作进程反应迟缓，重启这个进程不会影响应用其它进程的工作。
如果对进程及线程的理解还存在疑问，可以参考下列文章：
浏览器的构架
有了前面的知识做铺垫，我们可以更合理的讨论浏览器的构架了，其实假如要开发一个浏览器，它可以是单进程多线程的应用，也可以是使用 IPC 通信的多进程应用。
#1:a:6:9:d:8:9:8:e:0:b:f:9:f:0:2:c:8:8:3:3:9:8:6:8:5:6:1:a:0:d:3#
不同浏览器的构架模型
不同浏览器采用了不同的构架模式，这里并不存在标准，本文以 Chrome 为例进行说明 ：
Chrome 采用多进程构架，其顶楼存在一个 Browser process 用以协调浏览器的其它进程。
#5:8:9:e:2:5:e:8:f:8:7:5:f:f:8:9:7:5:a:3:9:f:1:6:a:e:d:6:2:3:7:8#
Chrome 的不同进程
具体说来，Chrome 的主要进程及其职责如下：
Browser Process：
Renderer Process：
Plugin Process：
#7:a:b:5:7:a:d:9:4:3:a:7:c:f:7:3:d:e:5:9:6:d:6:c:d:3:0:3:8:f:c:5#
不同进程负责的浏览器区域示意图
Chrome 还为我们提供了「任务管理器」，供我们便捷的查看当前浏览器中运行的所有进程及每位进程占用的系统资源，右键单击还可以查看更多类别信息。
通过「页面右上角的三个点点点 --- 更多工具 --- 任务管理器」即可打开相关面板。
Chrome 多进程构架的优缺点
优点
某一渲染进程出问题不会影响其他进程更为安全，在系统层面上限定了不同进程的权限
缺点
由于不同进程间的显存不共享，不同进程的显存往往须要包含相同的内容。
为了节约显存，Chrome 限制了最多的进程数，最大进程数目由设备的显存和 CPU 能力决定，当达到这一限制时，新打开的 Tab 会共用之前同一个站点的渲染进程。
测试了一下在 Chrome 中打开不断打开知乎首页，在 Mac i5 8g 上可以启动四十多个渲染进程，之后新打开 tab 会合并到已有的渲染进程中。
Chrome 把浏览器不同程序的功能看做服务，这些服务可以便捷的分割为不同的进程或则合并为一个进程。
以 Broswer Process 为例，如果 Chrome 运行在强悍的硬件上，它会分割不同的服务到不同的进程，这样 Chrome 整体的运行会愈加稳定，但是假如 Chrome 运行在资源贫瘠的设备上，这些服务又会合并到同一个进程中运行，这样可以节约显存。
iframe 的渲染 -- Site Isolation
在前面的进程图中我们还可以见到一些进程下还存在着 Subframe，这就是 Site Isolation 机制作用的结果。
Site Isolation 机制从 Chrome 67 开始默认启用。
这种机制准许在同一个 Tab 下的跨站 iframe 使用单独的进程来渲染，这样会更为安全。
#f:b:a:1:c:3:9:6:2:d:b:7:d:e:9:a:7:7:7:6:b:4:1:d:0:1:a:d:9:4:a:9#
iframe 会采用不同的渲染进程
Site Isolation 被你们看做里程碑式的功能， 其成功实现是多年工程努力的结果。
Site Isolation 不是简单的叠加多个进程。
这种机制在底层改变了 iframe 之间通讯的方式，Chrome 的其它功能都须要做对应的调整，比如说 devtools 需要相应的支持，甚至 Ctrl + F 也须要支持。
关于 Site Isolation 的更多内容可参考下列链接：
介绍完了浏览器的基本构架模式，接下来我们瞧瞧一个常见的导航过程对浏览器来说到底发生了哪些。
导航过程发生了哪些
也许大多数人使用 Chrome 最多的场景就是在地址栏输入关键字进行搜索或则输入地址导航到某个网站，我们来瞧瞧浏览器是如何看待这个过程的。
我们晓得浏览器 Tab 外的工作主要由 Browser Process 掌控，Browser Process 又对这种工作进一步界定，使用不同线程进行处理：
#7:d:2:9:a:6:1:3:f:5:5:1:4:1:f:b:f:b:a:9:b:d:3:a:b:b:a:4:0:f:0:c#
浏览器主进程中的不同线程
回到我们的问题，当我们在浏览器地址栏中输入文字，并点击回车获得页面内容的过程在浏览器看来可以分为以下几步：
处理输入
UI thread 需要判定用户输入的是 URL 还是 query；
开始导航
当用户点击回车键，UI thread 通知 network thread 获取网页内容，并控制 tab 上的 spinner 展现，表示正在加载中。
network thread 会执行 DNS 查询，随后为恳求构建 TLS 连接。
#e:0:9:8:8:5:e:9:4:5:9:6:5:9:3:5:7:a:2:a:c:e:d:a:c:f:1:7:f:a:7:2#
UI thread 通知 Network thread 加载相关信息
如果 network thread 接收到了重定向恳求头如 301，network thread 会通知 UI thread 服务器要求重定向，之后，另外一个 URL 请求会被触发。
读取响应
当恳求响应返回的时侯，network thread 会根据 Content-Type 及 MIME Type sniffing 判断响应内容的格式。
#0:9:b:3:7:3:e:1:0:9:d:d:7:7:9:2:9:1:3:e:a:8:8:6:8:f:e:0:0:5:c:5#
判断响应内容的格式
如果响应内容的格式是 HTML ，下一步将会把这种数据传递给 renderer process，如果是 zip 文件或则其它文件，会把相关数据传输给下载管理器。
Safe Browsing 检查也会在此时触发，如果域名或则恳求内容匹配到已知的恶意站点，network thread 会展示一个警告页。
此外 CORB 检测也会触发确保敏感数据不会被传递给渲染进程。
#c:d:9:c:6:7:2:d:2:f:3:b:c:c:9:e:5:2:2:4:b:6:5:5:5:6:b:b:e:f:0:9#
查找渲染进程
当上述所有检测完成，network thread 确信浏览器可以导航到恳求网页，network thread 会通知 UI thread 数据早已打算好，UI thread 会查找到一个 renderer process 进行网页的渲染。
#7:0:c:6:0:d:9:4:8:e:7:2:e:5:b:f:9:0:e:0:a:9:5:f:9:7:3:b:8:9:f:c#
收到 Network thread 返回的数据后，UI thread 查找相关的渲染进程因为网路恳求获取响应须要时间，这里虽然还存在着一个加速方案。
当 UI thread 发送 URL 请求给 network thread 时，浏览器虽然早已晓得了即将导航到哪个站点。
UI thread 会并行的预先查找和启动一个渲染进程，如果一切正常，当 network thread 接收到数据时，渲染进程早已准备就绪了，但是假如遇见重定向，准备好的渲染进程似乎就不可用了，这时候就须要重启一个新的渲染进程。
确认导航
进过了上述过程，数据以及渲染进程都可用了， Browser Process 会给 renderer process 发送 IPC 消息来确认导航，一旦 Browser Process 收到 renderer process 的渲染确认消息，导航过程结束，页面加载过程开始。
此时，地址栏会更新，展示出新页面的网页信息。
history tab 会更新，可通过返回键返回导航来的页面，为了让关掉 tab 或者窗口后以便恢复，这些信息会储存在硬碟中。
#f:7:f:9:e:e:3:3:5:8:9:2:4:a:6:a:4:c:d:3:0:9:b:3:2:1:0:6:1:4:0:0#
额外的步骤
一旦导航被确认，renderer process 会使用相关的资源渲染页面，下文中我们将重点介绍渲染流程。
当 renderer process 渲染结束（渲染结束意味着该页面内的所有的页面，包括所有 iframe 都触发了 onload 时），会发送 IPC 信号到 Browser process， UI thread 会停止展示 tab 中的 spinner。
#d:2:6:6:8:b:3:d:0:7:a:2:e:5:b:6:9:7:9:2:c:d:8:f:5:9:b:5:6:3:c:c#
Renderer Process 发送 IPC 消息通知 browser process 页面早已加载完成
当然里面的流程只是网页首帧渲染完成，在此以后，客户端仍然可下载额外的资源渲染出新的视图。
在这儿我们可以明晰一点，所有的 JS 代码虽然都由 renderer Process 控制的，所以在你浏览网页内容的过程大部分时侯不会涉及到其它的进程。不过或许你也以前窃听过 beforeunload 事件，这个风波再度涉及到 Browser Process 和 renderer Process 的交互，当当前页面关掉时（关闭 Tab ，刷新等等），Browser Process 需要通知 renderer Process 进行相关的检测，对相关风波进行处理。
#2:5:1:d:d:1:5:9:0:2:3:2:b:e:9:5:a:6:1:e:8:b:1:b:2:0:a:b:6:7:a:f#
浏览器进程发送 IPC 消息给渲染进程，通知要离开当前网站了假如导航由 renderer process 触发（比如在用户点击某链接，或者 JS 执行 window.location = "http://newsite.com" ） renderer process 会首先检测是否有 beforeunload 事件处理器，导航恳求由 renderer process 传递给 Browser process。
如果导航到新的网站，会启用一个新的 render process 来处理新页面的渲染，老的进程会留下来处理类似 unload 等风波。
关于页面的生命周期，更多内容可参考 Page Lifecycle API 。
#5:a:d:9:1:c:9:b:f:9:f:e:5:e:0:1:7:1:c:6:c:8:8:f:2:0:b:2:a:f:d:f#
浏览器进程发送 IPC 消息到新的渲染进程通知渲染新的页面，同时通知旧的渲染进程卸载
除了上述流程，有些页面还拥有 Service Worker （服务工作线程），Service Worker 让开发者对本地缓存及判定何时从网路上获取信息有了更多的控制权，如果 Service Worker 被设置为从本地 cache 中加载数据，那么就没有必要从网上获取更多数据了。
值得注意的是 service worker 也是运行在渲染进程中的 JS 代码，因此对于拥有 Service Worker 的页面，上述流程有些许的不同。
当有 Service Worker 被注册时，其作用域会被保存，当有导航时，network thread 会在注册过的 Service Worker 的作用域中检测相关域名，如果存在对应的 Service worker，UI thread 会找到一个 renderer process 来处理相关代码，Service Worker 可能会从 cache 中加载数据，从而中止对网路的恳求，也可能从网上恳求新的数据。
#d:8:e:d:f:4:9:6:5:0:9:a:d:d:2:2:f:4:3:8:c:2:c:1:2:3:c:c:0:5:6:2#
Service Worker 依据具体情形做处理
关于 Service Worker 的更多内容可参考：
如果 Service Worker 最终决定通过网上获取数据，Browser 进程 和 renderer 进程的交互似乎会提早数据的恳求时间。
Navigation Preload 是一种与 Service Worker 并行的加速加载资源的机制，服务端通过恳求头可以辨识这类恳求，而作出相应的处理。
