浏览器架构

事实上开发一个浏览器可以是单进程多线程应用，也可以是通过IPC进行通信的多进程应用。

一般来说一个好的应用程序往往被分割为多个相互独立的模块进程，每个进程都有自己的核心职责。这些进程相互配合完成浏览器的整体功能。而每个进程又可以包含多个线程，一个进程中的多个线程相互协同工作完成所在进程的职责。

不同浏览器采用了不同的架构模式，这里并不存在标准。

补充说明进程和线程的区别如下图

下边我们以chrome浏览器为例来看看它的架构

○ Browser Process 核心职责：

1：负责地址栏、书签栏、前进后退按钮等部分工作。

2：负责浏览器不可见的一些底层操作，如网络请求、文件访问等。

○ Render Process 核心职责：

负责网页呈现渲染

○ Plugin Process 核心职责：

负责一个网页所用到的所有插件，如flash等。

○ GPU Process 核心职责：

负责GPU（Graphics Processing Unit）相关任务，即图像处理计算相关任务。

Chrome还为我们提供了任务管理器，方便我们查看当前浏览器中运行的所有进程以及每个进程占用的系统资源等更多信息。

Chrome浏览器多进程架构的优缺点

优点：

1：某一渲染进程出现问题不会影响其他进程。

2：在系统层面限定了不同的进程权限，更为安全。

缺点：

1：不同进程的内存是不能共享的，这就意味着不同进程包含相同的内容。

2：为了节省内存，chrome限定了最大进程数，当达到这一极限时，新开的Tab会共享之前打开的同一站点的渲染进程。（最大进程数由设备的内存和CPU决定）

Site Isolation

Site Isolation 被大家看做是里程碑式的功能，其成功的实现是多年工程努力的结果。

那么到底什么是Site Isolation呢？

从上边的Chrome多进程架构图中我们可以看到某些进程中还出现了SubFrame，这就是Site Isolation机制作用的结果。

Site Isolation 机制从Chrome 67开始默认启用。这种机制允许在同一个Tab下的跨站iframe使用单独的进程来渲染，这样会更为安全。

Site Isolation并不是简单的进程叠加，而是在底层改变了iframe的通信方法，Chrome的其他功能也要做对应的调整，比如devtool需要响应的支持。

更多Site Isolation参考这篇文章

输入URL后浏览器都干了些什么？

前言：

如上边说的，我们都知道chrome是多进程的，不同的进程有不同的核心职责。

Browser Process掌管着Tab外的工作，如任务栏、书签栏等

那么很明显我们在浏览器任务栏中输入了URL后，立马工作的就是Browser Process。

Browser Process 又对这些工作进行一一拆解，交给不同的线程去处理。

Browser Process下的线程：

1：UI Thread 控制浏览器上的按钮和输入框

2：Network Thread 处理网络请求

3：Storage Thread 控制文件等的访问

输入URL后Chrome浏览器具体干了些什么？

1：输入处理

UI Thread 处理输入，判断用户输入的URL还是query，通知Network Thread获取网页内容。

2：开始导航

Network Thread 负责网络请求网页内容，并控制 tab 上的 spinner 展现，表示正在加载中。执行 DNS 查询，随后为请求建立 TLS 连接。如果 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 进行网页的渲染。为什么会是查找一个Render Process，这个涉及到一个加速方案，当UI Thread通知Network Thread进行网络请求的时候，UI Thread事实上清楚将要导航到哪个站点，所以UI Thread会在此时并行预先加载一个渲染进程，等到Network Thread请求到数据时，渲染进程就已经准备好了。但是如果是重定向，那么之前预先准备的渲染进程将不可用，就要重新再启一个渲染进程。

5：确认导航

上述过程后，数据以及渲染进程都是可用了，Browser Process会给Render Process发送IPC消息来确认导航，一旦Browser Process收到Render Process的渲染确认信息，导航过程就结束了，页面加载过程开始。此时，地址栏会更新，展示出新页面的网页信息。history tab会更新，可通过返回键返回导航来的页面，为了让关闭tab窗口后便于恢复，这些信息会保存在硬盘中。

未完待续...