作者回复: 是这样的,通常情况下是一个页面使用一个进程,但是,有一种情况,叫"同一站点(same-site)",具体地讲,我们将“同一站点”定义为根域名(例如,geekbang.org)加上协议(例如,https:// 或者http://),还包含了该根域名下的所有子域名和不同的端口,比如下面这三个:
https://time.geekbang.org
https://www.geekbang.org
https://www.geekbang.org:8080
都是属于同一站点,因为它们的协议都是https,而根域名也都是geekbang.org。你也许了解同源策略,但是同一站点和同源策略还是存在一些不同地方,在这里你需要了解它们不是同一件事就行了。
Chrome的默认策略是,每个标签对应一个渲染进程。但是如果从一个页面打开了新页面,而新页面和当前页面属于同一站点时,那么新页面会复用父页面的渲染进程。官方把这个默认策略叫process-per-site-instance。
直白的讲,就是如果几个页面符合同一站点,那么他们将被分配到一个渲染进程里面去。
所以,这种情况下,一个页面崩溃了,会导致同一站点的页面同时崩溃,因为他们使用了同一个渲染进程。
为什么要让他们跑在一个进程里面呢?
因为在一个渲染进程里面,他们就会共享JS的执行环境,也就是说A页面可以直接在B页面中执行脚本。因为是同一家的站点,所以是有这个需求的。
作者回复: 这个建议很好,后续课程我考虑按照你这个思路来规划下。
作者回复: 之前回答的有点笼统,下面是我整理过后的回答:
首先这个问题提的很好,我们从IE6开始讲起,IE6时代,浏览器是单进程的,所有页面也都是运行在一个主线程中的,当时IE6就是这样设计,而且此时的IE6是单标签,也就是说一个页面一个窗口。
这时候,国内有很多国产浏览器,都是基于IE6来二次开发的,而IE6原生架构就是所有页面跑在单线程里面的,意味着,所有的页面都共享着同一套JavaScript运行环境,同样,对于存储Cookie也都是在一个线程里面操作的。
而且这些国产浏览器由于需要,都采用多标签的形式,所以其中的一个标签页面的卡顿都会影响到整个浏览器。
基于卡顿的原因,国内浏览器就开始尝试支持页面多线程,也就是让部分页面运行在单独的线程之中,运行在单独的线程之中,意味着每个线程拥有单独的JavaScript执行环境,和Cookie环境,这时候问题就来了:
比如A站点页面登陆一个网站,保存了一些Cookie数据到磁盘上,再在当前线程环境中保存部分Session数据,由于Session是不需要保存到硬盘上的,所以Session只会保存在当前的线程环境中。这时候再打开另外一个A站点的页面,假设这个页面在另外一个线程中里面,那么它首先读取硬盘上的Cookie信息,但是,由于Session信息是保存在另外一个线程里面的,无法直接读取,这样就要实现一个Session同步的问题,由于IE并没有源代码,所以实现起来非常空难,国内浏览器花了好长一点时间才解决这个问题的。
Session问题解决了,但是假死的问题依然有,因为进程内使用了一个窗口,这个窗口是依附到浏览器主窗口之上的,所以他们公用一套消息循环机制,消息循环我们后面会详细地讲,这也就意味这一个窗口如果卡死了。也会导致整个浏览器的卡死。
国产浏览器又出了一招,就是把页面做成一个单独的弹窗,如果这个页面卡死了,就把这个弹窗给隐藏掉。
这里还要提一下为什么Chrome中的一个页面假死不会影响到主窗口呢?
这是因为chrome输出的实际上图片,然后浏览器端把图片贴到自己的窗口上去,在Chrome的渲染进程内,并没有一个渲染窗口,输出的只是图片,如果卡住了,顶多图片不更新了。
国产浏览器这一套技术花了四五年时间,等这套技术差不多成熟时,Chrome发布了 :(
作者回复: 关于参考资料,我先整理下,回头完整发出来
作者回复: 你说的是UserAgent,又称为UA,UA是浏览器的身份证,通常,在发送HTTP请求时,UA会附带在HTTP的请求头中user-agent字段中,这样服务器就会知道浏览器的基础信息,然后服务器会根据不同的UA返回不同的页面内容,比如手机上返回手机的样式,PC就返回PC的样式。
你也可以在浏览器的控制台中输入:
navigator.userAgent
来查看当前浏览器的UA信息。
FireFox中的打印的信息是:
"Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Firefox/68.0"
Chrome中打印的信息是:
"Mozilla/5.0 (Linux; Android 6.0; Nexus 5 Build/MRA58N) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/76.0.3809.100 Mobile Safari/537.36"
安卓系统中的Chrome浏览器:
"Mozilla/5.0 (Linux; Android 5.0; SM-G900P Build/LRX21T) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/76.0.3809.100 Mobile Safari/537.36"
我们知道了服务器会根据不同的UA来针性的设计不同页面,所以当出了一款新浏览器时,他如果使用自己独一无二的UA,那么之前的很多服务器还需要针对他来做页面适配,这显然是不可能的,比如Chrome发布时他会在他的UA中使用“Mozilla” ,“AppleWebKit”,等关键字段,用来表示他同时支持Mozilla和AppleWebKit,然后再在最后加上他自己的标示,如Chrome/xxx。
这就解释了为什么你查看的信息中含有WebKit字样。
作者回复: 通常情况下会是五个,但是有很多其他情况:
1:如果页面里有iframe的话,iframe也会运行在单独的进程中!
2:如果页面里有插件,同样插件也需要开启一个单独的进程!
3:如果你装了扩展的话,扩展也会占用进程
4:如果2个页面属于同一站点的话,并且从a页面中打开的b页面,那么他们会公用一个渲染进程
这些进程都可以通过chrome的任务管理器来查看。
作者回复: 👍
作者回复: 总结的很好👍
作者回复: 要定位页面崩溃页面,我们先要了解下有可能造成页面崩溃的因素,根据我的实际统计数据看来,主要有以下三个方便的因素:
首先,主要因素是一些第三方插件注入浏览器或者页面进程,拦截了网页的一些正常操作而导致页面或者浏览器崩溃,如一些杀毒软件,或者卫士类软件,或者一些流量劫持软件。
第二个因素是插件,虽然容易崩溃,但是通常情况下只会影响到自身的进程,不过我们以前的统计数据来看,也会小概率地影响到页面的崩溃,不过整体数据来看还好了。另外一个方向来看,插件的使用率已经越来越低了,所以插件不是个大问题。
第三个因素是浏览器的一些bug,如渲染引擎,JavaScript引擎等,不过从统计数据来看,这类因素导致的崩溃也是越来越低的了,而且随着浏览器的更新升级,引起问题的因素也是在不断变化的。
所以要直接给出页面崩溃原因是很难的,而且直接从JS的层面来看,也是很难跟踪崩溃原因的。
提一个我之前使用的方法,那就是使用JS来统计页面是否崩溃,这类统计不是100%准备,但是可以通过数据来大致判断页面是否崩溃,然后再找一些典型的用户环境来实地排查。
作者回复: 感谢
作者回复: 我觉得就是一帮大佬没谈妥
作者回复:
Chrome支持使用JavaScript来写连接代理服务器脚本,又称为在线pac代理脚本,pac脚本具体什么样子你可以搜索“PAC代理脚本”,总之使用pac代理脚本可以实现一些那啥的事。
刚开始的时候啊,Chrome是在浏览器进程里面解析pac代理脚本的,由于是JavaScript脚本,所有需要在浏览器进程里面引入V8,不过把V8运行在浏览器进程似乎不太好,于是Chrome团队后来就把这个功能独立出来一个进程了,这个进程就叫着“Utility: V8 Proxy Resolver”。
英文好的话可以看他们提供的官方文档:https://docs.google.com/document/d/1n5hr4KJhZl2A4MicTfmyiHPdiKp7kmUoWXnRBN8SrZE/edit#
作者回复: 其实,很多标准并不是先制定的,而且先产品化,得到广泛的认可之后,再形成标准, 如spdy协议。
世上本无路,走的人多了便有了路。
作者回复: iframe没有单独标签,是潜入在其它页面里面的,比如一个页面嵌入了三个不同域名的iframe,那么这个页面就会拥有四个渲染进程
作者回复: 会讲JS的执行流水线,这点对于理解JS中一些概念很有帮助。
作者回复: 如果一个进程使用了安全沙箱之后,该进程对于操作系统的权限就会受到限制,比如不能对一些位置的文件进行读写操作,而这些权限浏览器主进程所需要的,所以安全沙箱是不能应用到浏览器主进程之上的。
作者回复: 点击鼠标选中文字的时候,这些消息会传递到渲染进程,渲染进程再合成选中文字的状态,然后更新图片!