浏览器的多进程架构

前言

现代浏览器普遍采用多进程的架构，本文以Chrome浏览器为例，进行分析。

目的

解耦

现代浏览器功能越做越多，浏览器发展到一定程度甚至会演变成操作系统，Chrome OS是一个典型的例子。
随着复杂度的增加，按功能划分模块也成为必然，所以多进程的出现不足为奇。

稳定性

一个进程异常不会影响其他的进程，举个典型的例子：
随便打开一个网页，通过控制台写个死循环，然后在页面中进行操作（点击、输入）会发现没有任何响应。

打开任务管理器，会发现chrome的某个进程不太正常（因为有死循环~）。

此时我们再打开一个其他的网页，比如bootstrap的主页，新的页面不受异常页面影响，可以正常工作。

例子举完了，有些同学会说了，多线程也可以做到呀。关键是我们举的是进程异常的问题，如果进程崩溃直接退出呢，所有线程可就都退了，此时多进程的架构的优势也就体现了出来。

进程

一个Browse进程

浏览器的主进程，其他进程的父进程，同时负责和操作系统底层打交道，如网络IO，磁盘读写，捕获用户的鼠标、键盘行为等。

一个GPU进程

负责和GPU设备打交道，GPU进程不是直接和GPU打交道，而是通过图形 API（OpenGl，Direct3D）。

多个Render进程

负责解析我们熟悉的Html、Css、JS的操作等，最后变成显示器上的图像展示给我们，内部包含了渲染引擎、JS引擎。
Render进程被设计在一个沙箱中，具有有限的操作系统的访问能力。

多个Plugin进程

典型的有Flash插件，运行在一个Plugin进程中，当某个页面Flash崩溃时，其他页面内的Flash也会一起崩溃。插件进程如果需要使用GPU能力，是需要和GPU进程进行交互，而不是直接调用图形API。

进程间通信

提到进程间通信，可能我们第一个想到的是Socket，但如果在浏览器的多进程中使用socket会有以下问题。
1、封包、解包的开销。
2、以一张图片的展示为例，由Browse进程先下载，再交由Render进程处理，Render进程再交由GPU进程处理。如果三个进程都持有位图数据，对内存空间是一种浪费；同时内存的频繁读写也是要消耗内存带宽的，低端设备上就不一定抗的住了。

对于这样的大数据（位图、视频等），浏览器使用了共享内存加信号量的方式。这种方式跟多线程中的锁很像。如此一来，进程之间的通信代价大为降低。

最后上两张图，来看下多进程、多进程间的通信