| Chrome浏览器初始启动时的六个进程 | 您所在的位置：网站首页 › win10多少个进程 › Chrome浏览器初始启动时的六个进程 |
Chrome浏览器初始启动时的六个进程
|
一、前置准备
在Mac上安装Chrome后，打开任务管理器和活动监视器： （1）打开任务管理器： 我们可以看到，在Chrome初始启动时有六个进程，包括：浏览器进程、存储进程、网络进程、GPU进程、渲染程序进程、备用渲染程序进程。 二、Chrome的多进程架构目前Chrome的多进程架构如下：
主要控制-> 地址栏、书签、后退、前进，并负责进行浏览器和其它进程之间的调度协调。它具有访问系统资源的权限，Windows中显示为浏览器进程，Android上通常就是App的进程。因为主进程中通常也负责和窗口系统的交互，所以有时也被称为UI进程。早期的时候主进程负责UI交互，持久化数据访问，网络资源下载。最新的Chromium中持久化数据访问，网络资源已作为独立的进程存在。 Network网络进程看名字就显而易见，负责网络请求的处理 GPU进程负责整个浏览器页面的渲染，包含顶部的搜索栏，和Tab标签页的内容。GPU 的使用初衷是为了实现 3D CSS 的效果，只是随后网页、Chrome 的 UI 界面都选择采用 GPU 来绘制，这使得 GPU 成为浏览器普遍的需求。最后，Chrome 在其多进程架构上也引入了 GPU 进程。（无论开多少个标签页，只会有一个GPU进程） 渲染（Renderer）进程浏览器渲染进程（浏览器内核）（内部是多线程的），该进程负责页面的渲染和JavaScript脚本的执行。根据配置的不同，能存在多个Renderer进程。简单来说每个Tab页面一个进程，互不影响。但打开的每个网页并不一定会创建一个renderer进程，在资源较少的情况下，浏览器有时候会优化，可以配置域相同的网页共享一个进程，甚至只有一个renderer进程，如多个空白页合并成一个进程。 如果每一个tab页面可以看作是浏览器内核的一个进程，这个进程是多线程的，它有几大类子线程： 线程名称线程介绍GUI渲染线程负责渲染浏览器界面，解析HTML，CSS，构建DOM树和RenderObject树，布局和绘制等。当界面需要重绘（Repaint）或由于某种操作引发回流(reflow)时，该线程就会执行。注意，GUI渲染线程与JS引擎线程是互斥的，当JS引擎执行时GUI线程会被挂起（相当于被冻结了），GUI更新会被保存在一个队列中等到JS引擎空闲时立即被执行。JS引擎线程也叫 JS 内核，负责解析执行 JS 脚本程序的主线程，例如 V8 引擎。JS引擎一直等待着任务队列中任务的到来，然后加以处理，一个Tab页（renderer进程）中无论什么时候都只有一个JS线程在运行JS程序。同样注意，GUI渲染线程与JS引擎线程是互斥的，所以如果JS执行的时间过长，这样就会造成页面的渲染不连贯，导致页面渲染加载阻塞。事件触发线程属于浏览器内核线程（不是JS引擎，可以理解，JS引擎自己都忙不过来，需要浏览器另开线程协助），主要用于控制事件，例如鼠标、键盘等，当事件被触发时，就会把事件的处理函数推进事件队列，等待 JS 引擎线程执行。定时器触发线程主要控制 setInterval和 setTimeout，用来计时，计时完毕后，则把定时器的处理函数推进事件队列中，等待 JS 引擎线程。注意，由于JS的单线程关系，所以这些待处理队列中的事件都得排队等待JS引擎处理（当JS引擎空闲时才会去执行）。注意，W3C在HTML标准中规定，规定要求setTimeout中低于4ms的时间间隔算为4ms异步http请求线程通过XMLHttpRequest连接后，通过浏览器新开的一个线程，监控readyState状态变更时，如果设置了该状态的回调函数，则将该状态的处理函数推进事件队列中，等待JS引擎线程执行。Renderer进程是运行在Sandbox中的，该进程没有访问系统资源的权限，所有对资源的访问需求都通过IPC委托给其他功能进程，如网络进程，GPU进程。 备用渲染进程用于配合渲染进程的使用。 三、问题记录 1.为什么GUI渲染线程与JS引擎线程是互斥的？由于JavaScript是可操纵DOM的，如果在修改这些元素属性同时渲染界面（即JS线程和UI线程同时运行），那么渲染线程前后获得的元素数据就可能不一致了。 因此为了防止渲染出现不可预期的结果，浏览器设置GUI渲染线程与JS引擎为互斥的关系，当JS引擎执行时GUI线程会被挂起，GUI更新则会被保存在一个队列中等到JS引擎线程空闲时立即被执行。 2.Mac Chrome刚启动时在任务管理器中出现的“渲染程序”是什么？Chrome刚启动时会在任务管理器中短暂的出现一个“渲染程序”： 站点隔离（site-isolation），这个功能会为网站内不同站点的iframe分配一个独立的渲染进程。Chrome会为每个tab分配一个单独的渲染进程，可是如果一个tab只有一个进程的话不同站点的iframe都会跑在这个进程里面，这也意味着它们会共享内存，这就有可能会破坏同源策略。同源策略是浏览器最核心的安全模型，它可以禁止网站在未经同意的情况下去获取另外一个站点的数据，因此绕过同源策略是很多安全攻击的主要目的。而进程隔离（proces isolation）是隔离网站最好最有效的办法了。再加上CPU存在Meltdown和Spectre的隐患，网站隔离变得势在必行。因此在Chrome 67版本之后，桌面版的Chrome会默认开启网站隔离功能，这样每一个跨站点的iframe都会拥有一个独立的渲染进程。 所有跨站点的导航都将成为跨进程的，因此来自不同站点的文档不会彼此共享一个进程，然后将外部站点独立出一个渲染进程。这样就可以避免外部网站的数据进入父站点的渲染进程读取内存数据。一般对iframe才会独立一个辅助框架进程。 3.打开多个空白Tab页会有几个进程？如果在chrome中打开多个空白Tab： 1.第一种情况：打开多个Tab访问同一个网页： 可以观察到，两种情况下到进程数量不一样。第一种情况，打开两个Tab，有两个进程；第二种情况，也是有两个Tab，但却只有一个进程。主要原因是： 第一种情况，通过URL打开的各个页面都毫无关联的，并不会因为在同一个域名下就会将渲染进程合并为一个。它们的window.opener属性都为null，说明都是独立开启，没有任何页面依赖关系，资源相互独立，自然就要给其分配独立的运行内存空间。 而第二种情况，通过window.open()打开新页面时可以获取到window.opener属性，与父页面共享渲染进程。 5.往返缓存策略页面在任务管理器里面可能会发现一个叫做往返缓存版页面的名称： |
（2）打开活动监视器： 
（3）通过进程ID(PID)对比任务管理和活动监视器： 
进程介绍：
不久会发现这个“渲染程序”又“消失不见”，此时出现了另一个名为“辅助框架”的进程，而通过观察可以发现二者其实是同一个进程（进程ID一样）： 
那么它到底是怎么出现的呢？首先看一chrome初始启动时的页面： 
由此可见：如果页面内嵌了 iframe，iframe页面会在一个单独的进程中。同时我们也可以看到，一个Tab下是可以不止一个渲染进程的。 浏览器实现了站点隔离，跨域读取阻止。网站隔离有效地使不受信任的网站更难访问或窃取您在其他网站上的帐户中的信息。
可见其始终只有一个进程，所以多个Tab可包含在同一个渲染进程。不过，当不停的打开新的标签页，会合并为一个渲染进程，但是当你在新标签页搜索或者查询之后，也会将该页面独立出来一个渲染进程。 我们已经知道并非每个Tab页都一定会有自己的一个进程，而这取决于浏览器设置的进程模型是什么。
2.第二种情况：使用window.open打开 
其作用是，当用户点击后退或前进按钮时，可以瞬时加载页面。【本文地址】