Chromium 模型、线程介绍

多进程模型

• Browser 进程:浏览器的主进程,负责浏览器界面的显示，各个页面的管理,其他各种进程的管理;
• Render 进程:页面的渲染进程,负责页面的渲染工作,WebKit 的工作主要在这个进程中完成;
• NPAPI 插件进程:每种类型的插件只会有一个进程,每个插件进程可以被多个 Render 进程共享;
• GPU 进程:最多只有一个,当且仅当GPU硬件加速打开的时候才会被创建,主要用于对 3D 加速调用的实现;
• Pepper 插件进程:同 NPAPI 插件进程,不同的是为Pepper 插件而创建的进程

沙箱模型

在页面多进程中，页面的渲染是运行在沙箱模型中的Render进程中实现的，这些渲染引擎没有访问本地资源的能力，可以保护渲染引擎被入侵。

多线程机制

几个重要的线程：

1. chrome线程：进程的主线程，browser进程重要 主要是负责UI，当然也是管家；Render进程中则是管家兼处理WebKit渲染的，gpu进程中则负责处理绘图请求并调用OpenGL进行绘制工作。
2. Chrome_IOThread/Chrome_ChildIOThread线程:用来接收其他进程的IPC消息和派发资深消息到其他进程。
3. SignalSender线程：v8 JavaScript引擎中用于处理Linux信号的线程。

消息循环

chromium中需要处理三种类型的消息：chromium自定义任务，Socket，文件IO操作。

• MessageLoop 是主消息循环，由于有三种类型的消息，那么必然会有三种消息循环来处理这三种不同类型的消息：一种是处理自定义任务，一种是处理自定义任务和IO操作，一种是处理自定义任务和UI消息。由于只有自定义任务和平台无关，而其他两种都需要和平台相关联，就出现了一个MessagePump类。MessagePump的每个子类针对不同平台和不同的消息类型，事实上，消息处理的主循环也在MessagePump中，MessageLoop 通过实现MessagePumpDelegate接口来处理自定义任务。
• 对于所有平台，History线程所使用的类都是一样的。而UI线程和IO线程分别对应不同的MessagePump的。
• Android平台的处理不同，原因在于主循环在java层，用户界面的事件派发机制都在java层来处理，因而需要在Android的消息循环机制中加入对自定义任务的处理。

如何等待自定义任务

假设现在MessageLoop没有任务和消息需要处理，就需要等待自定义任务到来。不能盲目等待。chromium非常巧妙，他在MessagePumpLibEvent为例：在Linux上创建一个管道，等待读取这个管道的内容，当有新的自定义任务到来的时候，就写入一个字节到管道中，从而MessageLoop被唤醒，简单直接。