chromium的RenderProcess的启动

本文详细解析了浏览器进程与渲染进程之间的通信机制,包括如何建立管道通信、子进程启动流程以及主消息循环的初始化过程。重点介绍了渲染进程的入口RendererMain及其关键初始化步骤,展示了RenderProcess和RenderThreadImpl之间的关系。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

RenderProcess与Browser进程中的RenerProcessHost对应,RenderProcess在RenderProcessHostImpl的Init函数中被创建。

Init函数主要进行以下几个工作:

1、建立与RenderProcess进行通信的管道,管道的名称为channel_id。

2、将管道名称channel_id作为子进程启动的参数,调用ChildProcessLauncher启动子进程,子进程可以通过channel_id对应的管道与RenderProcessHost进行通信

3、ChildProcessLauncher经过一系列的调用启动子进程。

  • ChildProcessLauncher实例化一个Context对象context_,调用context_的Launch函数。
  • Launch函数,Post一个Task到PROCESS_LAUNCHER线程,在该线程中执行Context::LaunchInternal
  • LaunchInternal函数,根据是否需要在SandBox中运行子进程,调用LaunchElevatedProcess或者StartSandboxedProcess函数启动子进程
  • 启动的子进程是过程和Browser进程的类似,但是这次它带了参数kProcessType,在执行ContentMainRunner::RunNamedProcessTypeMain的时候进入RenderProcess的主函数RendererMain。

Render进程的入口RendererMain在content/render/render_main.cc,它的初始化过程比较简单,主要有以下几个步骤:

1、初始化主消息循环

base::MessageLoop main_message_loop;
2、初始化RenderProcessImp。

RenderProcessImpl render_process;
3、初始化RenderThreadImpl。

new RenderThreadImpl();
4、运行主消息循环

base::MessageLoop::current()->Run();
MessageLoop、RenderProcessImpl、RenderThreadImpl它们都是便用单例模式的,通过current()接口就能拿到当前线程中的实例。

其中RenderProcessImpl和RenderThreadImpl的关系图如下:


RenderProcessImpl继承自RenderProcess,而RenderProcess继承于ChildProcess,ChildProcess会包含一个用于处理消息的实例ChildThread,ChildThread继承了Sender和Listener接口,可以用于发收和处理接收到的消息,同时ChildProcess还有一个IO线程,用于IO事件的处理,它其实就是ChildThread中管道channel_所使用的IO线程。

RenderProcess接收到的消息首先会调用ChildThread::OnMessageReceived进行处理

一些控制消息会交给RenderThreadImpl::OnControlMessageReceived函数进行处理,比如新建一个RenderView的消息ViewMsg_New,它会接着调用RenderThreadImpl::OnCreateNewView函数完成RenderView的创建。

### Chromium 多进程架构原理及实现机制 Chromium 的多进程架构是一种为了提高浏览器稳定性和安全性的设计,其核心思想是将不同的功能模块分配到独立的进程中运行。这种架构通过隔离渲染、网络、GPU 等任务来避免单一进程崩溃影响整个浏览器[^3]。 #### 进程分 Chromium 主要包含以下几进程: - **Browser 进程**:负责管理用户界面、网络请求、磁盘 I/O 等全局性操作。 - **Render 进程**:负责解析 HTML、CSS 并渲染页面内容,每个标签页通常对应一个 Render 进程。 - **GPU 进程**:处理与图形加速相关的任务,例如合成和光栅化。 - **Plugin 进程**:用于运行第三方插件(如 Flash),以确保其不稳定性不会直接影响主流程[^3]。 #### 进程间通信机制 (IPC) 各进程之间通过 Chromium 自定义的 IPC 机制进行通信。IPC 采用消息传递模型,支持同步和异步通信方式。具体实现中,每个进程都有自己的 IPC 通道,通过这些通道交换数据并协调操作。例如,Browser 进程通过 IPC 向 Render 进程发送导航指令,并接收页面加载完成的通知[^1]。 #### 渲染进程共享行为 在某些场景下,多个标签页可能需要共享同一个 Render 进程,这可以通过命令行参数 `--process-per-site` 或 `--process-per-tab` 来控制。前者按照网站域名划分进程,后者则为每个标签页创建独立的 Render 进程。此机制允许灵活地平衡资源消耗和隔离级别[^1]。 #### 安全与沙箱化 Chromium 对 Render 进程实施了沙箱保护,限制其对系统资源的访问权限。例如,Render 进程无法直接访问文件系统或执行任意代码。此外,Browser 进程会监控 Render 进程的状态,在检测到异常时自动重启受影响的进程,从而提升整体稳定性[^2]。 #### 内存回收与崩溃恢复 当某个 Render 进程崩溃时,Browser 进程能够检测到这一事件并通过重新启动新的 Render 进程来恢复页面状态。同时,Chromium 采用了高效的内存回收策略,以减少长期运行导致的内存泄漏问题。 #### 示例代码:WaitableEvent WaitableEvent 是 Chromium 中用于线程同步的一个重要,它提供了一种等待某个事件发生的机制。以下是其构造函数的简化实现: ```cpp WaitableEvent::WaitableEvent(bool manual_reset, bool initially_signaled) : kernel_(new WaitableEventKernel(manual_reset, initially_signaled)) { } ``` 该函数定义在文件 `external/chromium_org/base/synchronization/waitable_event_posix.cc` 中,用于创建一个可手动重置或自动重置的事件对象[^4]。
评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值