图片引自Mariko Kosaka的《Inside look at modern web browser》
6. 服务化 - 节省更多内存
浏览器程序中相同的功能方法，正在将浏览器的每个部分作为一项服务运行，可以轻松拆分为不同进程或聚合成一个进程。
当Chrome在强大的硬件上运行时，它可能会将每个服务拆分为不同的流程，从而提供更高的稳定性，但如果它位于资源约束设备上，Chrome会将服务整合到一个流程中，从而节省内存占用。
Android的平台上已经使用了类似的方法来整合流程以减少内存使用。
图片引自Mariko Kosaka的《Inside look at modern web browser》
7. 给Iframe分配单独渲染进程 - 站点隔离
站点隔离:因不同站点之间共享内存空间会存在同源策略绕过(Meltdown and Spectre)安全问题：https://blog.csdn.net/wlmnzf/article/details/79319509" /t "_blank 。因此为每个跨网站iframe运行单独的渲染器进程。
站点隔离难点：从根本上改变iframe的通信方式，包括ctrl F查找、打开devtools等需在不同渲染器进程访问。【重大版本】。
图片引自Mariko Kosaka的《Inside look at modern web browser》
三、页面导航过程1. 浏览器进程运行
多进程架构启动多个进程处理不同的任务。选项卡外部的所有内容都由浏览器进程处理（包含UI线程、网络线程、存储线程）。在地址栏输入url时，由浏览器进程的UI线程处理。
图片引自Mariko Kosaka的《Inside look at modern web browser》
2. 处理输入
当用户开始输入地址栏时，UI线程需判断是搜索查询还是URL。
- 查询：发送到搜索引擎
- URL：请求URL的网站
3. 开始导航
用户点击进入时：
- 有注册设置Service Worker从缓存加载页面，渲染进程中运行JavaScript代码，从缓存加载页面，无需请求网络
- 未设置Service Worker时：
1) UI线程启动网络调用以获取站点内容，选项卡加载转圈
2) 网络线程通过DNS查找域名对应IP及建立http连接
3) 网络线程接收处理301重定向头。网络线程与请求重定向的UI线程通信，启动另一个URL请求
Service Worker
Service Worker注册后，保留其范围为参考。当导航时，网络线程根据注册的范围检查域名，若url已注册Service Worker，UI线程找到渲染进程执行ServiceWorker代码，从缓存加载数据或从网络加载新资源。生命周期见：https://developers.google.com/web/fundamentals/primers/service-workers/lifecycle
导航预加载
如果ServiceWorker最终决定从网络请求数据，浏览器进程与渲染进程间的往返可能导致延时，通过与ServiceWorker启动并行加载资源加速来减少延时，允许标记这些请求，允许服务器决定为这些请求发送不同的内容。
