关闭

WebKit之多进程模型2

190人阅读 评论(0) 收藏 举报
分类:

相信你一定有这样的经历:打开很多个页面,不幸的是其中某个页面不响应了或者崩溃了,随之而来的是更不幸的事,所有页面都不响应或者都崩溃了。最让人崩溃的是其中一些页面还有未保存或者未发送的信息!

这绝对是不堪回首的过去。但是,现在好了,现代浏览器很多都支持多进程模型,这个模型可以很好地避免上面的问题,虽然它很复杂而且也有自身的问题,例如更多的资源消耗,但是它的优势也是非常明显地。

chromium的多进程架构至少带来三点好处,其一是避免单个页面的不响应或者奔溃影响整个浏览器的稳定性;其二是当第三方插件奔溃时候不会影响页面或者浏览器的稳定性;其三是方便了安全模型的实施,也就是说沙箱模型是基于多进程架构的。其实,这很大程度上也是WebKit2产生的原因。那么,这是怎么做到的呢?

下图给出了缺省的chromium浏览器的进程模型。方框代表进程,连接线代表IPC进程间通信。


通常来讲,chromium浏览器包括以下主要进程类型:

1.   Browser进程:浏览器的主进程,负责浏览器界面的显示,各个页面的管理,其他各种进程的管理;

2.   Render进程:页面的渲染进程,负责页面的渲染工作,WebKit的工作主要在这个进程中完成;

3.   NPAPI插件进程:每种类型的插件只会有一个进程,每个插件进程可以被多个Render进程共享;

4.   GPU进程:最多只有一个,当且仅当GPU硬件加速打开的时候才会被创建,主要用于对3D加速调用的实现;

5.   Pepper插件进程:同NPAPI插件进程,不同的是为Pepper插件而创建的进程

Chromium浏览器的进程模型,包括以下特征:

1.   browser进程和页面是分开的,这保证了页面的奔溃不会导致浏览器主界面的奔溃;

2.   每个页面是独立的进程,这保证了页面之间相互不影响;

3.   插件进程也是独立的,插件的问题不会影响浏览器主界面和页面;

4.   GPU硬件加速进程也是独立的。

因为这么多的进程,开发者通常需要知道进程列表中的进程类别,这很简单,可以通过进程的命令行参数"--type"来识别。

有趣的是,就在我写下上面这段文字的时候,我的chrome浏览器的flash插件崩溃了,幸运的是其他一切都很好,感谢chrome的多进程模型!

 

##模型的类型

其实介绍了进程模型,其实Chromium支持多种进程模型,特别是对页面而言,下面简单的介绍以下模型的类型:

###Process-per-site-instance

该类型的含义是为每一个页面都创建一个独立的Render进程,不管这些页面是否来自于同一域。举个例子来讲,例如,用户访问了milado_njuCSDN博客(我的博客),然后从个人主页打开多篇文章时,每篇文章的页面都是该域的一个实例,因而它们都有各自不同的渲染进程。如果新打开CSDN博客的主页,那么就是另一个实例,会重新创建进程来渲染它。这带来的好处是每个页面互不影响,坏处自然是资源的巨大浪费。

###Process-per-site

该类型的含义是为属于同一个域的页面共享同一个进程,而不同一个域的网页则分属不同的进程。好处是对于相同的域可以共享,相对较小的内存消耗,坏处是可能会有特别大的Renderer进程。可以在命令行加入参数--process-per-site来尝试它。

###Process-per-tab

该类型的含义是为每个标签页创建一个独立的进程,这也是chrome/chromium的缺省行为

###Single process

该类型的含义是不为页面创建任何独立的进程,所有渲染工作都在browser进程中。但是这个类型只是实验性质的,不稳定,因而不推荐使用,只有在比较单进程和多进程时候比较有用,可以在命令行加入参数--single-process来尝试它。


值得提出的是,在Android系统上,不是上面的模型都支持的很好。


##沙箱模型

在页面的多进程模型中,页面的渲染是运行在沙箱模型中的Render进程中实现的,这些渲染引擎没有访问本地资源的能力(例如文件系统,窗口系统,等等),这可以保护渲染引擎被入侵。

0
0

查看评论
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
    个人资料
    • 访问:131090次
    • 积分:3858
    • 等级:
    • 排名:第8281名
    • 原创:243篇
    • 转载:159篇
    • 译文:0篇
    • 评论:2条
    文章分类
    最新评论