CEF3开发者系列之进程和线程

　　CEF3是一个多进程架构框架，若是有了解过chromium的进程架构的，那么就很容易了解CEF3的多进程了。打开CEF3源代码中发布的cefclient实例，若是打开的页面带有flash或者其余插件。在任务管理其中能够看到四个进程，显示出命令行列。能够看到一个主进程，通常主进程是Browser进程，其余的分别是渲染进程（Render），GPU加速进程（GPU），插件进程（NPAPI或者PPAPI）。

Browser进程：被定义为主进程，负责窗口管理，界面绘制和网络交互。

Render 进程：Blink的渲染和Js的执行被放在一个独立的Render 进程中；除此以外，Render进程还负责Js Binding和对Dom节点的访问。 默认的进程模型中，会为每一个标签页建立一个新的Render进程。

NPAPI插件进程：按需建立，每种类型的插件只会有一个进程，每一个插件进程能够被多个Render进程共享；

Pepper插件进程：同NPAPI插件进程，不一样的是为Pepper插件而建立的进程；

GPU进程：按需建立，最多只有一个，当且仅当GPU硬件加速打开的时候才会被建立，主要用于对3D加速调用的实现。

　　多进程的好处不少，在浏览器中最主要的好处是当一个页面或者插件崩溃或假死，不会给其余页面带来影响。CEF3的进程之间能够经过IPC进行通讯。Browser和Render进程能够经过发送异步消息进行双向通讯。甚至在Render进程能够注册在Browser进程响应的异步JavaScript API。在CEF3中，Browser和Render进程间能够经过SendProcessMessage(CefProcessId target_process,  CefRefPtr<CefProcessMessage> message)函数实现消息传递。

　　默认状况下，主应用程序会被屡次启动运行各自独立的进程。经过传递不一样的命令行参数给CefExecuteProcess函数实现的。若是主应用程序很大，加载时间比较长，或者不能在非浏览器进程里使用，则宿主程序可以使用独立的可执行文件去运行这些进程。这能够经过配置 CefSettings.browser_subprocess_path变量作到。更

　　chromium自己支持多种进程模型，但CEF3主要是模型是两种：单进程和为每一个标签建立一个进程。后一种是缺省行为，前边一种可设置。经过设置命令行的--single-process，CEF3就能够支持用于调试目的的单进程运行模型。支持的平台为：Windows，Mac OS X 和Linux。

 

　　一图解千语，下图给出了缺省的chromium浏览器的进程模型。方框表明进程，链接线表明IPC进程间通讯。

 

 

　　因为关于cef3进程架构的讲解不多，我的猜想CEF3的进程架构和chromium应该差很少，毕竟CEF3是基于chromium的框架。更多和进程相关的内容能够网上搜索“chromium多进程架构”。

 

　　在CEF3中，每一个进程都会运行多个线程。完整的线程类型表请参照cef_thread_id_t

typedef enum {
// BROWSER PROCESS THREADS -- Only available in the browser process.

  ///
  // The main thread in the browser. This will be the same as the main
  // application thread if CefInitialize() is called with a
  // CefSettings.multi_threaded_message_loop value of false.
  ///
  TID_UI,

 

  // Used to interact with the database.
  TID_DB,

  ///
  // Used to interact with the file system.
  ///
  TID_FILE,

  // Used for file system operations that block user interactions.
  // Responsiveness of this thread affects users.
  TID_FILE_USER_BLOCKING,

  ///
  // Used to launch and terminate browser processes.
  ///
  TID_PROCESS_LAUNCHER,

  // Used to handle slow HTTP cache operations.
  TID_CACHE,

  // Used to process IPC and network messages.
  TID_IO,

// RENDER PROCESS THREADS -- Only available in the render process.

  ///
  // The main thread in the renderer. Used for all WebKit and V8 interaction.
  ///
  TID_RENDERER,
} cef_thread_id_t;

 

在Browser进程中包含以下主要的线程：

• TID_UI 线程是浏览器的主线程。若是应用程序在调用调用CefInitialize()时，传递CefSettings.multi_threaded_message_loop=false，这个线程也是应用程序的主线程。
• TID_IO 线程主要负责处理IPC消息以及网络通讯。
• TID_FILE 线程负责与文件系统交互。

因为CEF采用多线程架构，有必要使用锁和闭包来保证数据的线程安全语义。IMPLEMENT_LOCKING定义提供了Lock()和 Unlock()方法以及AutoLock对象来保证不一样代码块同步访问数据。CefPostTask函数组支持简易的线程间异步消息传递。更多信息，请参考Posting Tasks章节。

能够经过CefCurrentlyOn()方法判断当前所在的线程环境，cefclient工程使用下面的定义来确保方法在指望的线程中被执行。

#define REQUIRE_UI_THREAD()   ASSERT(CefCurrentlyOn(TID_UI)); #define REQUIRE_IO_THREAD()   ASSERT(CefCurrentlyOn(TID_IO)); #define REQUIRE_FILE_THREAD() ASSERT(CefCurrentlyOn(TID_FILE));