背景
参考
还记得使用IE时期,这是一个ActiveX群魔乱舞的时代:各种软件通过ActiveX一键被安装进电脑,点几个网页就多装了好多个软件,特别酸爽。这是因为那个时期,JavaScript还不是特别强大,所以IE直接利用COM(组件对象模型)赋予开发者非常大的权限,去实现一些惊艳的功能。这些强大同样导致了特别严重的安全问题,很多插件拥有了不该拥有的能力。能够想象吗?随便开个网页,把我电脑的扫雷给自动打开了?
是的,IE显然把浏览器插件的路给走歪了。Google的Chrome扩展程序(Extension)主要使用JavaScript+HTML+CSS来进行构建。一个扩展程序和一个网站差不多,只不过用户在使用时不是直接网址访问,需要有个安装过程。在程序侧,由于被装到了用户本地,所以在状态维持上多了一些能力,同时给予程序一些浏览器层级的接口权限,但像直接打开扫雷的这种权限肯定是没有的。
下面就来介绍一下这个Chrome扩展程序(Extension)与普通网站不一样的地方。
关键文件
manifest.json
参考 index.html
的<head>
中的各种引用标签,就列出这个网页需要哪些资源。但对于一个代码工程而言,这个是非常有必要的。因为工程需要打包,需要知晓将哪些资源打进包里。于是在Chrome扩展程序(Extension)中的目录,manifest.json
这个文件是必需的。
manifest.json
中有特定结构,可以参照
popup.html
每个扩展被安装了之后,在浏览器的右上角会有一个小图标,当用户去点击这个图标的时候,会弹出一个页面,这个页面就被称作是popup,如下图所示。在manifest.json
的配置中有专门一个字段用来指定该页面的路径。所以在扩展程序的目录结构中,需要有这样一个popup.html的网页文件。
background.js
这个文件是扩展程序的核心,一直处于运行状态,会接收来自popup.html等各处的消息,经过处理后进行存储,或者发回一些什么消息。这个文件在v2版本的manifest.json
中可以指定为html页面,在v3版本中就只能指定为js文件了。这样设计也算合理,可能在v2版本的时候,ES6(ECMAScript 6.0)都还无法用,所以只能用一个html来加载多个js文件。在v3版本的时候,就直接可以用es6的import和export来加载整个工程了。
background.js的使用场景非常接近后端的API服务,原本需要发给API的请求,在扩展程序场景下可以全部都发给background.js。而且由于background.js是在本地的进程,不像远程接口那样有几十到几百毫秒的延时,每次交互都是秒回,体验特别好。
content scripts
由于popup.html需要在浏览器右上角打开,和用户的交互距离略微还有点远,毕竟不会常常去浏览器右上角点击。content scripts
则能完全贴着用户执行,比如在用户的右键上增加一些东西,在用户的网页上增加一些有利交互的HTML元素,甚至是直接修改用户网页的CSS/HTML等。content scripts
是算作一个普通的js文件,没有很多的特权,所以很多事情,都要通过消息机制,发给background.js进行处理:比如跨域请求这种,只有background.js能执行,而content scripts
需要遵循普通js的跨域限制。
options.html
popup.html只是一个在右上角的小页面创建,很多复杂的配置或交互都无法展开。如果扩展程序需要有一个自己的完整页面怎么办,就是options.html,如下图所示。
options.html的功能特性全部可以参照popup.html,按照一个普通的HTML页面去理解即可。
程序结构
按照上述的文件描述,一个最简单的Chrome扩展程序(Extension)的目录如下所示:
├── background.js
├── content-script.js
├── manifest.json
├── popup.html
└── popup.js