插件和扩展的区别

有时候，即便在互联网这个圈子中，大家也经常遇到把插件说成扩展、把扩展说成插件的用户。虽然在沟通的过程中一个称谓或许没那么重要，但如果有兴趣了解一下插件和扩展之间的区别，那就接着往下看。

Chrome 的插件与扩展有什么区别

"扩展"和"插件"，其实都是软件组件的一种形式，Chrome 只不过是把两种类型的组件分别给与了专有名称，一个叫"扩展"，另一个叫"插件"。

扩展(Extension)，指的是通过调用 Chrome 提供的 Chrome API 来扩展浏览器功能的一种组件，工作在浏览器层面，使用 HTML + Javascript 语言开发[]。比如著名的 Adblock plus。

插件(Plug-in)，指的是通过调用 Webkit 内核 NPAPI

来扩展内核功能的一种组件，工作在内核层面，理论上可以用任何一种生成本地二进制程序的语言开发，比如 C/C++、Delphi 等。比如Flashplayer 插件，就属于这种类型。一般在网页中用 <object> 或者 <embed>

标签声明的部分，就要靠插件来渲染。

至于哪种功能多的问题，这个不能比较，各有侧重。如果你想实现一个自动统计你上过的网站以及各自时间的功能，就要用扩展技术;如果你要实现一个让你的浏览器可以渲染 AutoCAD 文件的功能，就要用插件技术。

注：

Chrome 扩展本身也支持包含 Plug-in 模块，这部分可以使用 C/C++ 等语言开发。比如 web QQ 的截图扩展，就是用了这项功能。

补充一点，最直观的，可以从chrome的管理上看到：

Chrome插件和扩展有什么区别

在功能层面差异： 插件并不会增加浏览器自身的功能，可调用 *** 作系统的API，并且不同 *** 作系统的插件一般不能混用。我们经常遇到的插件有：Flash插件、PDF插件、Java插件等等。 相比较之下，扩展则可以增加浏览器本身的功能，也可以调用浏览器的API，并且同一个浏览器的扩展一般也都是可以跨 *** 作系统使用的。比如，你在Windows 使用的那些Chrome扩展，换到Mac平台上也一样能用。 安全性方面的差异 由于插件一般实现的都是比较底层的功能，所以一旦出现问题，往往就会牵涉到整个 *** 作系统，像Flash插件就属于经常被扒出高危漏洞的那一类。

相比较之下，扩展出现问题，其危害性类往往似于浏览器漏洞。不过Chrome Extension在为用户带来便利的同时，也的确带来了不少安全问题，Google Chrome的稳定版甚至还禁掉了Windows用户安装Chrome Web Store外扩展的权限。即便是在Chrome Web Store中的应用也不能保证绝对安全，因为Google自己也下架过一些有安全隐患的扩展。 好了，看完这些差异后，有没有感觉插件和扩展之间的区别还是蛮大的，下次再遇到有人混淆这两个概念时不妨纠正一下。

chrome 应用和扩展程序的区别

都知道 Chrome 支持扩展(也有些人叫插件)以及 Web Apps，但有一些刚刚接触 Chrome 的人始终搞不清这俩到底有什么区别，这里就简单的给大家介绍一下，高手请无视。

首先 Chrome 扩展是存放在 Google Chrome 扩展库中的，而 Web Apps 是放在 Chrome Web Store 中的也可以访问到这枚扩展，只是它的托管位置就变成在 Chrome web store 中了。也正是这个原因，导致很多人分不清扩展和Web Apps，也不知道 Google 是不是故意迷惑大众的。

第二点是这两者的工作方式不一样，Web Apps 通常具备独立的用户界面，并且具备典型且丰富的用户互动，更大程度上是一个具备互动性的东东。Google 的目的也是希望 Web Apps 能够像安装在你电脑中的软件一样具备互动性。

而扩展的作用主要是丰富浏览器或网站的功能，而不是像 Web Apps 一样属于某个网站的专用产品或者说不具备独立性。相对于 Web Apps 来说，扩展程序适用于网站以及 Web Apps ，一般来说适用于所有网站，但 Apps 不具备该特性，它们是独立的，就像一个传统的网站或者应用程序。

另外还有一个区别就是安装 Web Apps 需要 Google 帐号登陆，而安装扩展就无所谓。当然，有些 Apps 是需要银子的，而扩展则全都是免费的，至少目前如此。

对于开发者来说，也可以通过 Google 官方的介绍了解一下这两者的区别，其中涉及到 API 的调用以及打包方式等等。

猜你喜欢

1 Win10系统Edge浏览器怎么加载扩展插件

2 ps扩展功能插件无法使用怎么解决

3 360极速浏览器如何安装扩展中心里没有的chrome插件

4 win10系统怎么安装edge浏览器扩展插件

5 电脑的浏览器扩展插件

6 360 安全浏览器 极速浏览器 区别

7 主板和cpu有什么区

一、什么是Chrome 的插件

插件（Plug-in），指是通过调用 Webkit 内核 NPAPI 来扩展内核功能的一种组件，工作在内核层面，理论上可以用任何一种生成本地二进制程序的语言开发，比如 C/C++、Delphi 等。

比如Flash player 插件，就属于这种类型，一般在网页中用 <object> 或者 <embed> 标签声明的部分，就要靠插件来渲染。

二、什么是Chrome 的扩展

扩展（Extension），指的是通过调用 Chrome 提供的 Chrome API 来扩展浏览器功能的一种组件，工作在浏览器层面，使用 HTML + Javascript 语言开发[]。

比如著名的 Adblock plus。

二、Chrome 的扩展和插件的不同

1、工作层面不同：插件工作在内核层面；扩展工作在浏览器层面

2、开发语言不同：

插件看通过任何一种生成本地二进制程序的语言开发；扩展则使用的是 HTML + Javascript 语言开发

3、功能层面不同：

插件不会增加浏览器自身的功能，可调用 *** 作系统的API，并且不同 *** 作系统的插件一般不能混用；

扩展则可以增加浏览器本身的功能，也可以调用浏览器的API，并且同一个浏览器的扩展一般也都是可以跨 *** 作系统使用的。

4、安全性方面不同

插件一般实现的都是比较底层的功能，所以一旦出现问题，往往就会牵涉到整个 *** 作系统；

而扩展一般出现问题，其危害性类往往似于浏览器漏洞

确认您已经月度了多进程架构的设计文档。

您将特别想了解主要的组成方块图。

您同时也可能有兴趣了解多进程资源加载，以了解网页如何从网络下载。

概念上的应用层 每个方框表示一个概念层。

通过选取或者取代各层之上的层可以构建不同的浏览器应该是可能的。

因此，任何层都不应该依赖任何比它层次更高的层或者需要更高层次的相关信息。

WebKit：Safari、Chromium和任何其他基于Webkit的浏览器的渲染引擎。

Port是WebKit的一部分，它与依赖于系统服务的平台集成，如资源加载和图形。

Glue：转换Webkit类型成Chromium类型。

这是我们的Webkit嵌入层。

它是Chromium和test_shell（允许我们测试Webkit）这辆个浏览器基本的部分。

Render/Render host：这是Chromium的多进程嵌入层。

它穿透进程边界代理各种通知和命令。

您应该可以想象其他多进程浏览器正在使用这层，它应该依赖浏览器的其他服务。

Tab contents：浏览器特定的层表示标签的内容。

它与历史系统、口令管理登应用服务绑定。

它不应该，而且决不假设它嵌入在一个Chromium浏览器窗口里（它也可被其他浏览器组件像HTML对话框使用）。

Broeser：表示浏览器窗口，它嵌入了多个标签内容(TabContentses)。

WebKit我们使用WebKit开源工程布局网页。

这些代码来自苹果而且存在/third_party/WebKit目录。

WebKit主要由表示内核布局功能的 WebCore、执行JavaScript的JavaScriptCore组成。

我们仅运行JavaScriptCore进行测试，通常我们以我们更高性能的V8引擎取代它。

我们并没有实际使用苹果称为WebKit的那一层，这一层是嵌入WebCore和OSX应用Safari之间的API。

为了方便，我们把参考苹果这一层的代码称为WebKit。

WebKitPort 在最底层我们有我们的WebKit Port。

这是平台无关的WebCore的代码的接口在特定平台的我们的实现。

这些文件位于/webkit/port，且与WebCore的目录层次相似。

我们的port大部分都是与实际OS无关：您可以认为是Chromium port的WebCore。

少数部分像字体渲染的处理在每个平台不同。

通过多进程资源加载系统处理网络资源和响应。

而不是直接从render进程交由OS处理。

图形上使用为Android开发的Skia图形库。

这是一个跨平台的图形库而且可以处理许多图象和除文本外的基本图形元素。

skia位于 /third_party/skia。

主要的图形 *** 作的入口是/webkit/port/platform/graphics /GraphicsContextSkiacpp。

它也被许多在同一目录的其他文件如/base/gfx使用。

Webkit胶粘层 Chromium应用使用不同的类型、代码风格和代码布局而不是第三方的WebKit代码。

WebKit胶粘层提供许多方便的嵌入的API为 WebKit使用Goole代码方便和类型转换（如，我们使用std::string取代WebCore::String，GURL取代KURL）。

胶粘层位于/webkit/glue。

胶粘对象都与Webkit对象相似，只是以"Web"作为前缀。

例如，WebCore::Frame编程 WebFrame。

WebKit胶粘层隔离了基于Chromium的代码库与WebCore数据类型，以便基于Chromium代码修改最小化对于WebCore的影响。

基于次，WebCore的数据类型决不直接在Chromium使用。

API都被加到WebKit胶粘层，以方便Chromium(when it needs to poke at some WebCoreobject)。

test_shell应用是缺少网页浏览器骨架的应用，用于测试我们的WebKit port和胶粘层代码。

它像Chromium一样使用相同的胶粘(glue)接口与webkit通讯。

它没有许多复杂的浏览器特性、线程和进程，但是提供了一个简单的方法给开发者测试新代码。

这个应用也用于自动运行WebKit测试。

Chromium的渲染进程使用glue接口嵌入了我们的webkit port。

它没有包含非常多的代码：它的主要任务是成为渲染器连接浏览器的IPC通道。

渲染器中最重要的类是RenderView，位于/chrome/renderer/render_viewcc。

这个对象表示一个网页。

它处理所有来自或者到浏览器进程的浏览相关的命令。

它由RenderWidget驱动，RenderWidget提供绘制和事件处理。

RenderView与浏览器进程通讯通过全局的（每个渲染进程一个）RenderProcess对象。

FAQ：RenderWidget与RenderView的区别是什么？RenderWidget通过实现在glue层称为 WebWidgetDelegate的抽象接口映射成WebCore::Widget对象。

基本上它可以认为是屏幕上接收输入事件和我们需要绘制的窗口。

RenderView继承了RenderWidget而且是标签或者d出窗口的内容。

它处理浏览命令另外处理绘制和widget的输入事件。

每个渲染器有2个线程（见chrome多进程架构中的图或者chroimum的线程）。

渲染器线程执行RenderView等主要对象和所有WebKit代码。

当它与浏览器通讯时，消息首先发送给主线程，主线程分发消息给浏览器进程。

另外就是这种方式允许发送从渲染器到浏览器的同步消息。

这种方式提供了浏览器等待渲染器的一组 *** 作完成后继续。

一个简单的例子是当JavaScript读取cookie时。

渲染器线程将阻塞而且主线程将投递所有接收到的消息直到收到正确的响应。

正常的处理都是一旦主线程收到消息就顺序地发送给渲染器。

浏览器进程 底层浏览器进程对象 所有与渲染器进程的通讯都有浏览器的IO线程完成。

这个线程同时处理所有网络通讯这也保持了与用户接口进行交互。

当主线程（用户接口在此执行）初始化RenderProcessHost。

RenderProcessHost创建新的渲染器进程和ChannelProxy对象（与渲染器通过有名管道通讯）。

RenderProcessHost在浏览器的IO线程中执行，同时侦听来自渲染器的有名管道数据，而且自动前向通知所有消息给UI线程中的RenderProcess。

ResourceMessageFilter安装在这个通道里，这可以查到某种需要直接在IO线程处理的消息（如网络请求）。

ResourceMessageFilter::OnMessageReceived执行消息过滤。

UI线程的RenderProcessHost负责分发视图相关的消息给合适的RenderViewHost（它处理有限的自身的非视图相关的消息）。

RenderProcessHost::OnMessageReceived进行这些消息的分发。

高层浏览器进程对象 当视图相关的消息进入RenderViewHOst::OnMessageReceived，大多数这些消息在次处理，剩下的消息交给集成 RenderWidgetHost的类处理。

渲染器中对应与这两对象的分别是RenderView和RenderWidget（关于这些对象见渲染器进程）。

在微软的Windows上，我们将每个RenderWidgetHost与RenderWidgetHostHWND关联。

RenderWidgetHost管理事件和绘制到本地的HWND。

其他的系统我们采用相似的类管理本地输入和绘制。

在RenderView/Widget之上的是WebContents对象，大多数的消息实际上都以在这个对象上的函数调用方式结束。

每个WebContents表示显示网络数据的标签的内容。

它受一般的TabContents类（有许多其他TabContents的规范，如历史和下载。

）驱动。

WebContents是大多数浏览和顶层浏览器UI更新的切换点。

FAQ：为什么将WebContents和RenderViewHost分离？这两个对象提供了不同的功能层次。

您可以认为 RenderViewHost是Chromium的多进程嵌入层。

RenderViewHost对象能用于（实际上不是）渲染内容的其他部分。

例如，您可想象成一个带有web视图的对话框。

它能使用RenderViewHost去管理绘制且与渲染进程通讯，但是它不能有标签或者常见的浏览命令。

RenderViewHost通过抽象接口RenderViewHostDelegate前向传递许多消息给WebContents。

WebContents处理浏览状态和任何与web浏览器UI相关的 *** 作。

我们假设的对话框不必需要任何这些功能，仅需要实现它关心的 RenderViewHostDelegate的部分接口。

演示示例 其他关于浏览和启动的例子在获取Chrome源码 “设置光标”消息的处理过程 设置光标是由渲染器发送给浏览器的一个典型的消息。

在渲染器按下面过程处理： 设置光标消息由WebKit内部生成。

典型地一般是响应输入事件。

设置光标消息由RenderWidget::SetCursor（chrome/render/render_widgetcc）发出。

它将调用RenderWidget::Send去分发消息。

这个方法也被RenderView使用去发送消息给浏览器。

然后调用RenderThread::Send。

接着调用IPC::SyncChannel，这个方法实现内部代理消息给渲染器的主线程同时投递消息给发送消息给浏览器的命名管道。

接着浏览器接管该消息： RenderProcessHost的IPC::ChannelProxy接收所有浏览器IO线程的消息。

它首先发送它们给 RenderMessageFilter，RenderMessageFilter将直接在IO线程分发网络请求和相关的消息。

既然我们的消息没有被过滤掉，它将继续交由浏览器的UI线程（IPC::ChannelProxy内部如此实现）。

RenderProcessHost::OnMessageReceived（chrome/browser/render_process_hostcc）获取所有响应渲染器进程的视图的消息。

它直接处理几种类型的消息，且对于剩下的前向通知相应的RenderViewHost去响应来自RenderView的消息。

消息到达RenderViewHost::OnMessageReceived（chrome/browser /render_view_hostcc）。

许多消息在这里处理，但是设置光标的消息不在此处，因为它是一个来自RenderWidget的消息应该交给RenderWidgetHost处理。

所有RenderViewHost未处理的消息都自动地前向通知给RenderWidgetHost，包括设置光标消息。

在chrome/browser/render_widget_hostcc中的消息映射最终接收RenderWidgetHost::OnMsgSetCusor然后调用合适的UI函数去设置鼠标的光标。

鼠标单击消息处理过程 发送鼠标消息是一个从浏览器发送给渲染器的典型消息。

浏览器的UI线程通过RenderWidetHostHWND::OnMouseEvent接收到窗口消息，然后调用ForwardMouseEventToRenderer。

这个前向通知函数将输入事件包装成跨平台的WebMouseEvent且发送给与之相关的RenderWidgetHost后结束。

RenderWidgetHost::ForwardInputEvent创建一个IPC消息ViewMsg_HandleInputEvent，序列化成WebInputEv。

然后调用RenderWigetHost::Send 发送。

这将事件前向传递给RenderProcessHost::Send函数，这个函数按顺序将消息传递给IPC::ChannelProxy。

内部里，IPC::ChannnelProxy将代理此消息给浏览器的IO线程。

然后写入与之相应的渲染器的命名管道。

注意：许多由WebContents创建的其他类型的消息，特别是浏览功能的消息，这些也按照相似的过程从WebContents传递到RenderViewHost。

然后渲染器接管该消息。

渲染器的主线程的IPC::Channel读取由浏览器发送的消息，且IPC::ChannelProxy代理给渲染线程。

RenderView::OnMessageReceived获取这个消息。

许多种类型的消息都在此直接处理。

但是单击消息却不是，它将继续（和其他所有未处理消息一起）通过此传递给RenderWidget::OnMessageReceived（它按照顺序前向通知 RenderWidget::OnHandleInputEvent）。

输入事件最终交给WebWidgetImpl::HandleInputEvent。

开始

为了着手创建你的扩展程序，你只需要为你的扩展创建一个文件夹。程序所必须的文件只有manifestjson，不过也推荐准备一些用作图标，和至少一个JavaScript以提供功能。一般来说还会包含HTML文档、样式表、等等其他的资源。

Manifest文件

每个扩展都必须在其根目录下包含一个manifestjson文件。

这个文件里面声明了扩展的名称、版本、权限、设置选项和其他的一些和扩展相关的元数据。Manifestv1早在Chrome18便已被弃用，而且会根据这个时间表逐渐淘汰使用Manifestv1的扩展。如果你在参考一些旧扩展的Manifest文件的话，请确认添加"manifest_version":2

Google发布的Manifestv2中支持的域

后台页

大多数扩展都会在其manfiestjson文件内有这样的内容：

1

2

3

4

5

{

"background":{

"scripts":["indexjs","otherjs"]

}

}

这一段代码指定了两个需要被加载而且要保持在后台运行的脚本，这些脚本会在扩展的后台页运行。后台页是一个在扩展的进程中生成并运行的页面，存在时间会和扩展的生命周期等长。后台页可用来作为扩展的其他界面的控制器，用来维护某个状态或者保持某些活动。如果你需要用后台页来声明一些标记来用，可以把一个HTML文件名指定给page选项。

事件页

后台页会从扩展被加载的时候被装载，而且会一直留在内存里。这是因为如果有些状态需要被长时间维护，或者需要被扩展的其他部分访问。但是如果你没有这个需求，那么应该尽可能的使用事件页。事件页其实只是相当于一个包含了”persistent”:false条目的后台页，这一行语句告诉Chrome可以不需要把后台页保留在内存里。相对来说，事件页也会在最开始被装载，但是一旦指定的脚本运行完毕，事件页便会从内存卸载，而且会在需要的时候被再次加载（比如用来回应某些 *** 作）。

以上便是在为扩展添加功能之前所需要知道的。

交互

利用Google提供的大量API，你的扩展与浏览器交互或者为用户提供功能都变得方便。

chromeAPIs

Chrome的程序和扩展程序都非常喜欢调用chromeAPIs，这些API可以让你通过不同的方式来 *** 控浏览器，API通常会在后台脚本里面被调用，这是我找到的一些常用API：

chrometabs标签页：新建、刷新、关闭、访问和 *** 控标签页

chromehistory历史：访问用户浏览历史

chromebookmarks书签：添加、编辑、移除和搜索用户书签

chromeevents事件：监听或者管理浏览器发生的事件

chromemands命令：添加或者改变键盘命令

chrome右键：添加条目到右键下文菜单

chromeomnibox多功能框（地址栏）：添加多功能框关键字，使用户可以向扩展发送指令或者激活扩展

其他API

Chrome程序和扩展程序通常也会用到其他的API，包括如本地存储、地理位置、缓存、画布等新型的HTML5API。你也可以用普通的JavaScript或者webkitAPI来实现。

声明权限

有些ChromeAPI的功能必须要在manifestjson文件中声明相关权限才能被调用，通过在permissions域中把值设成相应权限名称，或者是通识符组成的数组。

开始

为了着手创建你的扩展程序，你只需要为你的扩展创建一个文件夹。程序所必须的文件只有manifestjson，不过也推荐准备一些用作图标，和至少一个JavaScript以提供功能。一般来说还会包含HTML文档、样式表、等等其他的资源。

Manifest文件

每个扩展都必须在其根目录下包含一个manifestjson文件。

这个文件里面声明了扩展的名称、版本、权限、设置选项和其他的一些和扩展相关的元数据。Manifest v1早在Chrome 18便已被弃用，而且会根据这个时间表逐渐淘汰使用Manifest v1的扩展。如果你在参考一些旧扩展的Manifest文件的话，请确认添加"manifest_version": 2

Google发布的Manifest v2中支持的域

后台页

大多数扩展都会在其manfiestjson文件内有这样的内容：

1

2

3

4

5

{

"background": {

"scripts": ["indexjs", "otherjs"]

}

}

这一段代码指定了两个需要被加载而且要保持在后台运行的脚本，这些脚本会在扩展的后台页运行。后台页是一个在扩展的进程中生成并运行的页面，存在时间会和扩展的生命周期等长。后台页可用来作为扩展的其他界面的控制器，用来维护某个状态或者保持某些活动。如果你需要用后台页来声明一些标记来用，可以把一个HTML文件名指定给page选项。

事件页

后台页会从扩展被加载的时候被装载，而且会一直留在内存里。这是因为如果有些状态需要被长时间维护，或者需要被扩展的其他部分访问。但是如果你没有这个需求，那么应该尽可能的使用事件页。事件页其实只是相当于一个包含了地persistent地: false条目的后台页，这一行语句告诉Chrome可以不需要把后台页保留在内存里。相对来说，事件页也会在最开始被装载，但是一旦指定的脚本运行完毕，事件页便会从内存卸载，而且会在需要的时候被再次加载（比如用来回应某些 *** 作）。

以上便是在为扩展添加功能之前所需要知道的。

交互

利用Google提供的大量API，你的扩展与浏览器交互或者为用户提供功能都变得方便。

chrome APIs

Chrome的程序和扩展程序都非常喜欢调用chrome APIs，这些API可以让你通过不同的方式来 *** 控浏览器，API通常会在后台脚本里面被调用，这是我找到的一些常用API：

chrometabs 标签页：新建、刷新、关闭、访问和 *** 控标签页

chromehistory 历史：访问用户浏览历史

chromebookmarks 书签：添加、编辑、移除和搜索用户书签

chromeevents 事件：监听或者管理浏览器发生的事件

chromecommands 命令：添加或者改变键盘命令

chromecontextMenus 右键：添加条目到右键下文菜单

chromeomnibox 多功能框（地址栏）：添加多功能框关键字，使用户可以向扩展发送指令或者激活扩展

其他API

Chrome程序和扩展程序通常也会用到其他的API，包括如本地存储、地理位置、缓存、画布等新型的HTML5 API。你也可以用普通的JavaScript或者webkit API来实现。

声明权限

有些Chrome API的功能必须要在manifestjson文件中声明相关权限才能被调用，通过在permissions 域中把值设成相应权限名称，或者是通识符组成的数组。

1

2

3

4

5

6

7

8

{

"permissions": [

"contextMenus",

"tabs",

"",

""

]

}

在这一段声明代码中，数组中的头两个字符串是分别用来为chromecontextMenus和chrometabs 的API授权的，最后的两个字符串则是用来匹配以 和 开头的地址。

用户界面

Chrome扩展的用户界面有着严格的限制，但是根据扩展的需要却可以有不同形式的界面。

浏览器按钮[a]

浏览器按钮允许你在右上角放置一个的16 x 16像素的图标，如果扩展应用的界面是全局的，而不是针对某个页面，那就应该使用浏览器 *** 作。如果要使用浏览器按钮，你必须在manifestjson中的browser_action域中做如下声明：

1

2

3

4

5

6

7

8

9

10

{

"browser_action": {

"default_icon": {

"19": "images/icon19png",

"38": "images/icon38png"

},

"default_title": "tooltip text here",

"default_popup": "popuphtml"

}

}

一个浏览器按钮可以有一个图标、提示、文字标记和一个d出内容，文字标记可以将极少的文字（4字符）动态的覆盖在浏览器 *** 作的图标上，你也可以通过chromebrowserActionAPI来对浏览器按钮相关的事件做出反应。

页面按钮

页面按钮允许你在多功能栏（地址栏）右边添加一个按钮，其实他和浏览器按钮很相似，区别之处在于页面按钮是专门用来处理某些指定的页面的。页面按钮必须在manfiestjson中声明， page_action域的使用和浏览器按钮一样。页面按钮可以通过chromepageAction API控制，可以在不同的标签页中灵活的显示或者隐藏。页面按钮也可以设置图标、提示和d出内容，和浏览器按钮不同的是其没有文字标记功能。

右键菜单

右键菜单是另一个提供用户界面，方便用户和扩展交互的方式。Chrome的右键菜单通过右键激活，但根据激活内容的变化，菜单内容也会做相应改变。

chromecontextMenusAPI允许你向为不同内容激活的右键菜单添加项目，若要使用此API，则在manifestjson文件中声明相应的contextMenus权限。

目前可用的激活内容有：

all, page, frame, selection, link, editable,image, video, audio

对应：所有内容、页面、框架、选择、链接、可编辑、图像、视频、音频，以下这个例子需要contextMenus 和tabs权限，他可以使扩展为右键菜单添加一个根项目，然后添加一个子菜单，用来复制当前的页面到一个新选项卡。[b]

1

2

3

4

5

6

7

8

9

10

11

12

13

var root = chromecontextMenuscreate({

title: 'MyExtension',

contexts: ['page']

}, function () {

var subMenu = chromecontextMenuscreate({

title: 'Duplicate Tab'

contexts: ['page'],

parentId: root,

onclick: function (evt) {

chrometabscreate({ url: evtpageUrl })

}

});

});

多功能框

Chrome把地址栏/搜索栏称为多功能框，通过chromeomnibox API，他可以让扩展有另一个界面。通过API 可以设置一个特定的激活字符串，当这个字符串被键入多功能框时扩展便可以对其做出反应。在manifestjson中做如下声明：

1

2

3

4

5

{

"omnibox": {

"keyword": "ext-"

}

}

这部分代码会把ext-作为激活字符串，当用户键入ext-并按下SPACE键或者TAB键时扩展会被激活。激活字符串必须通过manifestjson文件声明，故也不能通过JavaScript来更改。用户可以通过右键单击多功能框—–修改搜索引擎来更改。激活字符串是大小写敏感的，同时想为一个扩展声明多个激活字符串也是不可以的。

chromeomnibox API可以让你添加激活字符串被键入之后的修改或者输入的事件处理器。

选项页面

选项页面是一个的常见的用户界面，在chrome://extensions里可以通过单击扩展右边的选项按钮来打开。通常这个页面会和存储API结合使用，以用来在计算机上为用户保存设置。而使用脚本通过chrometabsAPI来打开选项页面也是可以的。

页面重载

页面重载允许你完全替代一个以下指定页面（一个扩展程序只能重载一个页面）

书签管理器

通过访问chrome://bookmarks或者Chrome菜单打开的页面

历史

通过访问chrome://history或者Chrome菜单打开的页面

新选项卡

通过访问chrome://newtab或者新建选项卡出现的页面

这些被替换的页面必须在manifestjson文件中如下声明chrome_url_overrides域：

1

2

3

4

5

{

"chrome_url_overrides": {

"bookmarks": "newBookmarkManagerhtml"

}

}

内容脚本

内容脚本是和你的扩展有关，在网页中运行的脚本。这个脚本可以让你访问页面里相应的DOM元素，你可以像这样在manifestjson里通过指定content_scripts域定义一个内容脚本数组：

1

2

3

4

5

6

7

8

9

10

11

12

13

14

{

"content_scripts": [

{

"matches": [""],

"css": ["custom-google-stylescss"],

"js": ["custom-google-script-1js", "custom-google-script-2js"]

},

{

"matches": [">

可以用NPAPI（具体如何实现我没用过，一般直接用js就能完成，NPAPI可以使用dll，dll应该可以多种语言开发）：

使用HTML和JavaScript开发新扩展是十分容易的事情，不过如果你想在扩展中重用已经开发完成的代码和功能，你可以通过使用NPAPI插件到达目的。NPAPI插件使JavaScript代码能够调用本地二进制代码。

NPAPI 是重型武器，当别的方法无法到达你的目的时，才建议使用

在你的扩展中包含一个NPAPI插件是一件危险的事情。因为NPAPI插件拥有访问你本地机器的完全权限而不受控制。如果你的插件不够健壮，包含漏洞，黑客可以通过溢出攻击利用漏洞来安装恶意软件到用户的机器。 有鉴于此，请尽可能的避免在扩展中使用NPAPI插件。

如果单纯允许访问本地文件，试试在manifestjson文件中声明“permissions”:["file:///"]

以支持本地文件读取，声明后你试试用AJax能不能获取到本地文件

Java应该是不行的，因为java运行必须有Java虚拟机

以上就是关于插件和扩展的区别全部的内容，包括:插件和扩展的区别、Chrome 的插件与扩展有什么区别、Chrome如何显示网页等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！