博客
关于我
Chromium与CEF的多进程模型及相关参数
阅读量:123 次
发布时间:2019-02-26

本文共 1998 字,大约阅读时间需要 6 分钟。

CEF基于Chromium,也是多进程模型。关于进程模型,参考这里:。我还看到一篇韩国人写的renderer process的文章,也很不错,在这里:。

CEF的进程模型,这里也有一部分描述:。CEF3默认使用multiple processess,CEF1默认支持较为稳定的的单进程模型。

Chromium的进程分为好几类(content/public/common/content_switches.cc中有进程参数定义,content/app/content_main_runner.cc中对不同进程做了分支处理):

  • browser(没有type参数时默认为browser进程)
  • renderer(kRendererProcess)
  • plugin(kPluginProcess)
  • ppapi-broker(kPpapiBrokerProcess)
  • ppapi(kPpapiPluginProcess)
  • sandbox-ipc(kSandboxIPCProcess)
  • utility(kUtilityProcess)
  • zygote(kZygoteProcess,linux)
  • gpu-process(kGpuProcess)

这篇文章会提到browser、ppapi、renderer、gpu,其它的我也没研究,不知道干嘛的……

CEF支持很多命令行参数(switches)。下面这些源文件的注释里对它支持的switches做了定义:

  • tests/cefclient/common/client_switches.cc
  • base/base_switches.cc
  • cef/libcef/common/cef_switches.cc
  • chrome/common/chrome_switches.cc (not all apply)
  • content/public/common/content_switches.cc

大多数的Chromium swithes也适用于CEF,可以参考这里:。当然你也可以参考这里:。

进程模型开关参数

好啦,下面重点来说进程模型相关的几个参数中与PPAPI相关的开关(拗口死了,我大部分解释是由的英文而来)。

  • –ppapi-in-process

在进程内运行ppapi插件,加上这个参数运行CEF,ppapi插件和browser还是不在一个进程……而是和renderer process在一起了……

  • –ppapi-out-of-process

指定这个参数时,ppapi插件会在一个单独的ppapi process中运行,进程启动时的命令行参数中有“–type=ppapi”。

这是默认行为。

  • –process-per-site

为每个站点分配进程,一个站点的多个页面会在同一个renderer进程内处理。(比如同一域名下的不同页面就会被认为是同一站点)

Chrome的默认行为就是这样。

  • –process-per-tab

每个tab相关的页面分配一个renderer进程。一个tab可能会有多个页面,比如JS或页面事件导致的页面跳转。

  • –site-per-process

强制给一个site分配一个死忠的process,这个process就非这个site不嫁了,嫁了就从一而终。详情可以看看这里:。

  • –force-in-process

在多进程模式下,指定某些apps在主进程中运行,它的值可能是以逗号分隔的列表,比如:

--force-in-process=mojo:native_viewport_service,mojo:network_service
  • –single-process

单进程模式运行CEF,打开这个开关后,browser、renderer、gpu-process等进程合并在一个进程里,但ppapi会单独跑一个进程。

  • –renderer-process-limit

限制renderer进程数量。Chromium默认是根据系统配置(主要是内存)来计算renderer进程的最大值。

组合使用进程模型开关

我想使用单进程的CEF(CEF1是单进程模型),又想用Chromium的新特性,所以还是得用CEF3。可有人说CEF3的多进程模型不稳定,参见这里的讨论:。还有这里:。后来发现Chromium也是这么说的,见这里:。

不过如果你真的想用,还是可以通过switches来控制。

  • ppapi、renderer、browser三者合一

要达到三者合一,传递下面的参数给CEF:

--single-process --ppapi-in-process
  • renderer、browser合一,ppapi插件单独运行在ppapi进程

传递下面的参数:

--single-process --ppapi-out-of-process

其他参考文章:

转载地址:http://qhey.baihongyu.com/

你可能感兴趣的文章
NIFI大数据进阶_NIFI监控的强大功能介绍_处理器面板_进程组面板_summary监控_data_provenance事件源---大数据之Nifi工作笔记0025
查看>>
NIFI大数据进阶_NIFI集群知识点_认识NIFI集群以及集群的组成部分---大数据之Nifi工作笔记0014
查看>>
NIFI大数据进阶_NIFI集群知识点_集群的断开_重连_退役_卸载_总结---大数据之Nifi工作笔记0018
查看>>
NIFI大数据进阶_内嵌ZK模式集群1_搭建过程说明---大数据之Nifi工作笔记0015
查看>>
NIFI大数据进阶_外部ZK模式集群1_实际操作搭建NIFI外部ZK模式集群---大数据之Nifi工作笔记0017
查看>>
NIFI大数据进阶_离线同步MySql数据到HDFS_01_实际操作---大数据之Nifi工作笔记0029
查看>>
NIFI大数据进阶_离线同步MySql数据到HDFS_02_实际操作_splitjson处理器_puthdfs处理器_querydatabasetable处理器---大数据之Nifi工作笔记0030
查看>>
NIFI大数据进阶_连接与关系_设置数据流负载均衡_设置背压_设置展现弯曲_介绍以及实际操作---大数据之Nifi工作笔记0027
查看>>
NIFI数据库同步_多表_特定表同时同步_实际操作_MySqlToMysql_可推广到其他数据库_Postgresql_Hbase_SqlServer等----大数据之Nifi工作笔记0053
查看>>
NIFI汉化_替换logo_二次开发_Idea编译NIFI最新源码_详细过程记录_全解析_Maven编译NIFI避坑指南001---大数据之Nifi工作笔记0068
查看>>
NIFI集群_内存溢出_CPU占用100%修复_GC overhead limit exceeded_NIFI: out of memory error ---大数据之Nifi工作笔记0017
查看>>
NIFI集群_队列Queue中数据无法清空_清除队列数据报错_无法删除queue_解决_集群中机器交替重启删除---大数据之Nifi工作笔记0061
查看>>
NIH发布包含10600张CT图像数据库 为AI算法测试铺路
查看>>
Nim教程【十二】
查看>>
Nim游戏
查看>>
NIO ByteBuffer实现原理
查看>>
Nio ByteBuffer组件读写指针切换原理与常用方法
查看>>
NIO Selector实现原理
查看>>
nio 中channel和buffer的基本使用
查看>>
NIO三大组件基础知识
查看>>