专栏首页梦里茶室【Chromium中文文档】插件架构

【Chromium中文文档】插件架构

背景

在阅读这个文档前,你应当熟悉Chromium的多进程架构。

概述

插件是浏览器不稳定的主要来源。插件也会在渲染器没有实际运行时,让进程沙箱化。因为进程是第三方编写的,我们无法控制他们对操作系统的访问。解决方案是,让插件在各自独立的进程中运行。

设计细节

进程内插件

Chromium有着在进程内运行插件的能力(对测试来讲非常方便),也可以在进程外运行插件。它们都始于我们的非多进程WebKit嵌入层,期待嵌入层实现WebKit::WebPlugin接口。这实际由WebPluginImpl实现。WebPluginImpl在图中的虚线以上,与WebPluginDelegate接口交流,对进程内插件而言,这个接口由WebPluginDelegateImpl实现,它会接着与我们的NPAPI包装层通信。

历史经验:还没有WebKit嵌入层的时候,WebPluginImpl是对应的嵌入层。它会与“嵌入应用程序”通过WebPluginDelegate抽象接口交流,我们通过切换这个接口的实现,服务与进程内插件与进程外插件。在有了额外的Chromium WebKit API之后,我们增加了新的WebKit::WebPlugin抽象接口,它与旧的WebPluginDelegate接口有着相同的功能。这个接口的一个好一点的设计是,合并WebPluginImpl和WebPluginDelegateImpl,在WebKit::WebPlugin层做进程划分。由于这个问题的复杂性,现在还没有这样实现。

进程外插件

Chromium通过切换上面的图中,虚线以上几层的实现来支持跨进程插件。这干预了WebPluginImpl层和WebPluginDelegateImpl之间的IPC层,并让我们在每个模式之间共享我们所有的NPAPI代码。所有旧的WebPluginDelegateImpl代码,以及与它通信的NPAPI层,现在是在独立的插件进程中执行了。

渲染器/插件通信通道的两端分别由PluginChannel和PluginChannelHost代表。我们有许多渲染器进程,以及每个插件唯一的一个插件进程。这意味着渲染器中,对于每种它所使用的插件都持有一个PluginChannelHost对象(例如,Adobe Flash和Windows Media Player)。在每个插件进程中,每个渲染器进程会有一个PluginChannel,它们各自持有一个那种插件的实例。

接着,channel的每个端点,对应许多不同的插件实例。例如,如果网页中嵌有两个Adobe Flash视频,渲染器端就会有两个WebPluginDelegateProxies对象(以及相关的成员),插件端就会有两个WebPluginDelegateStubs(以及相关的成员)。channel用一个IPC连接管理这些对象直接复数的通信。

在这个图中,你可以看到上面的进程内图表的类(用灰色表示),以及中间彩色的新的进程外代码层。

历史经验:我们曾经考虑使用一个stub(存根)/proxy(代理)模型进行通信,每个IPC通道的端点有一个stub和一个proxy,分别接收和发送消息给对应的插件。这会导致许多类变得迷乱。因此,WebPluginStub被合并到WebPluginDelegateProxy,现在它处理渲染器端与一个插件实例的所有IPC通信。插件端还没有合并,还剩两个类WebPluginDelegateStub和WebPluginProxy,概念上他们是相同的对象,只是代表了通信的不同方向。

无窗口插件

无窗口插件设计用于在渲染器管道内直接运行。当WebKit想要在屏幕上绘制一个区域时,调用插件代码,将它作为一个绘制上下文处理。无窗口插件通常用在希望插件在网页上透明的情况 -- 这取决于插件绘制代码,以决定它如何导航给定的网页。

为了将无窗口插件抽出进程,你仍然需要在同步的WebKit渲染端合并他们的渲染。一个简单但低速的方法是切掉插件将要绘制的区域,然后同步地切到插件进程让它绘制。这可以由一些共享内存的方式来加速。

然而,渲染速度取决于插件进程(想象有着30个透明插件的页面,我们需要30轮插件进程的旅行)。所以,相反地,我们异步绘制无窗口插件,更像我们已有的页面是关于screen异步那样。渲染器有一个高效的回退存储,存储插件的渲染区域的图像,并使用这个图像来绘制,这样插件就可以异步发送新的代表更改渲染区域的更新。

所有的这些在透明插件上都有点复杂。这个插件进程需要知道它想要绘制的是哪些像素。所以它也要缓存渲染器最后发给它的东西,作为插件后面的页面背景,然后让插件反复地绘制这个区域。

因此,总的来说,无窗口插件绘制的区域会调用几个buffer。

渲染器进程

  • 回退存储插件最后绘制的东西
  • 插件的共享内存,以接收更新(“透明的DIB”)
  • 复制插件背后的页面背景(在下面有描述)

插件进程

  • 复制插件背后的页面背景,作为绘制时的源材料使用
  • 渲染器共享内存以发送更新(“透明的DIB”)

渲染器为什么要保存页面背景的副本呢?因为如果页面背景改变了,我们需要同步地让插件重新绘制新的即将出现的背景。我们可以通过比较新绘制的背景和我们的插件存储的背景副本来判断背景的改变。因为插件和渲染器进程相互之间是异步的,他们需要独立的副本。

系统全貌

这个图片展示了整个系统,有浏览器和两个渲染进程,它们都与一个共享的进程外Flash进程交流。总共有三个插件实例。注意这个图表有一部分是过期的,WebPluginStub已经合并到WebPluginDelegateProxy中了。

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 不同的strcmp

    Android libc中的strcmp https://android.googlesource.com/platform/bootable/bootload...

    梦里茶
  • 【Chromium中文文档】跨进程通信 (IPC)

    概览 Chromium有一个多进程架构,这意味着我们有许多需要互相交流的进程。我们的主要跨进程交流元素是命名管道。在Linux和OS X上,我们使用socket...

    梦里茶
  • 编程策略类note

    2016-1-15 LOG LOG最重要的作用即是为程序出bug时调试提供思路, 一个自定义的log,需要有几个要素: 1. 时间,以知道哪些log是我们所需要...

    梦里茶
  • WordPress免费插件的选择指南

    无论你是喜欢码代码的开发人员,还是希望能轻易做出高质量网站的设计者,在某些时候你都会需要用到WordPress插件的帮助。

    丘壑
  • 原创插件:WordPress读者排行榜插件WP Readers Ranking

    貌似在上个月,我就和中国历史、梦轩丽人等几位博友提过,张戈博客分享的《WordPress 酷炫 CSS3 读者墙,排名按年度、本月、本周划分的小方法》,其实可以...

    张戈
  • scheduling-framework功能介绍

    scheduling framework 是Kubernetes Scheduler的一种新的可插入架构,可简化调度程序的自定义, 它向现有的调度程序中添加了一...

    有点技术
  • 萌妹子语音陪你写代码,一个神奇的 VSCode 插件

    最近在 GitHub 发现了一个有趣的 VSCode 插件:Rainbow Fart。在你写代码的时候,可根据关键字播放接近代码含义的语音。

    Enjoy233
  • 推荐个软件:uTools

    更多的内容可以去看一下差评的推文或者官方文档,我这篇文章主要放一下刚用起来就觉得挺不错的一些功能

    yichen
  • 从Elasticsearch的插件实现机制见:如何在Java中实现一个插件化系统

    此外,笔者还对Java的流行插件框架PF4J进行的简单的了解,发现其实现方式和ES比较相似:都是由ClassLoader实现,感兴趣的读者可以自行了解。

    franyang
  • 【插件开发】—— 2 插件入门

      最近由于特殊需要,开始学习插件开发。 以前接触java也算有些时日,但是一直不知道有插件开发这样一种技术路径,本想着这开发工具都给你备好了,直接用不就行了...

    用户1154259

扫码关注云+社区

领取腾讯云代金券