Chrome Extension扩展 – 半自动数据保存

Chrome 插件满天飞，但是为了某些精华数据，还是忍不住，开发了此数据保存插件。本文记录了 Chrome 扩展，半自动化数据保存的设计初衷，与开发过程碰到的问题，持续更新。

前言

在多数爬虫场景下，自动化抓取行为很容易触发目标应用风控，存在被封ip、封号的风险；解决这个问题最快的方式就是放弃爬虫；但是原生网站一些使用上的缺陷，还是让我对数据获取依依不舍，于是就有了这个半自动化数据获取扩展。
插件在浏览器环境中执行，降低数据获取频次，手工选取数据的保存方式（或db或截图），这种半自动化的数据获取不能用于大量数据爬取，只适用于小规模，精华类数据保存。

扩展设计

扩展的初衷是某些场景下解决数据保存的问题，而非提供爬虫类自动化获取数据再清洗，所以使用过程中需要人工筛选出要保存的数据，比如一个群组的精华帖，筛选后的非付费用户不行下载的数据表格，某个可能会被删除的文章截图，浏览的图片上传云端等。
扩展需要提供大量的模版、规则支撑各种场景，比如某个网站的正文内容保存，解析其中标签，保存时需要清洗的无使用意义的标签等。
扩展还需要支持各种数据保存的方式与配置，数据保存的位置，云端保存时数据源选择，自定义接口数据保存等。
除上述的核心功能外，周边的功能有，用户注册、注销等，个性化配置等。

入门

Chrome 扩展已经存在很多年，国内外都做好了很多免费、付费的插件，开发的文章也非常详细，可以Google参考。
如同 Chrome 自身的配置页面，扩展的代码文件也全部都是 html/js/css 三种，只是调用的 API 由浏览器本身提供。
从扩展最基础且必须的清单文件manifest.json来解释：

icons，扩展图标，各种尺寸的图标，适配不同分辨率设备。
popup.html/popup.js，左键点击扩展图标提供展现的页面，即扩展功能相关首页，比如启用切换，状态展示等。
options.html/options.js等，右键点击扩展图标 – 选项，展现的页面，即扩展本身提供的配置选项。
background.js，扩展的消息、事件处理中心，生命周期和浏览器一致。
content.js，针对目标页面的js代码植入，可以配置在某个阶段植入，比如document_start，document_end等。
web_accessible_resources，配置打包时，需要带入的额外js脚本，图标文件等。
permissions，顾名思义，为扩展运行所需要的权限，比如contextMenus（右键菜单），tabs（操作标签），webRequest（使用web请求）, storage（允许使用本地存储） “http://*”(可以通过executeScript或者insertCSS访问的网站)

Chrome开发说明文档，比较好用非官方说明文档

开发

扩展本质上是使用 javascript 功能实现，html/css整理页面展现，本身开发的难度点在于页面元素与数据处理。基础的处理流程如下：
1. 目标页面在加载的时候，注入业务处理的js脚本。
2. js脚本查找目标数据。
3. 发送目标数据到云端，或者保存到本地。

问题

一个合格的开发人员，1-2天就能上手插件开发，但是在开发过程中，有一些比较迷惑问题，比如：

1. 如何快速启用最新代码？
   • 整理好声明文件，manifest.json与必须的页面文件，popup.html/content.js/options.html后，在扩展管理中心装入扩展，开始调试代码。
   • 在扩展管理中心，点击启用开关，或者在目标页面强制刷新，可以使用最新代码。
2. console.log没有输出？
   • background环境中与目标页面环境不是同一个console，不要期待在目标页面（主页面）中看到background的console输出结果。
   • 若在background.js中使用chrome.windows.create，创建一个页面，会发现，这个窗口会被create 多次，说明background.js在被重复执行。
3. 数据上传的机制
   • 数据的上传只能在background.js中完成，在content.js或者注入的脚本页面的js文件中，存在同源策略问题，发送数据不会成功。
   • 在content.js中完成的某些请求，可能会触发目标网页的监控，比如原网页使用阿里云web页监控系统，或者目标页面作了xmlhttprequest与fetch等操作hook，就会上报数据。
   • 阿里云页面监控系统从页面响应速度，页面稳定性，接口稳定性等衡量一个页面是否稳定，也会把用户每分钟数据获取的频次，与调试目标网页的错误信息上报，即上传调试者的行为信息；在调试的时候，检查 Chrome 控制台输出，看看是否存在监控与数据上传行为。
4. 为何存在content.js了，还需要在页面注入js？
   • content-script 机制有个比较大的限制，content.js 可以操作dom，但是目标页面上的js无法调用 content.js 中的业务代码，也无法完成一些必要的hook行为，所以需要在document_start的时候，注入js。
   • 注入的js，也无法直接调用content.js提供的api，只能使用通信的方式，发送获取的数据，content.js监听通信的内容后，完成后面的操作。
5. 页面之间的通信机制
   • background/popup拥有同一套api权限与一样的通信机制，所以二者之间可以直接调用对方的js方法与访问dom结构。
   • popup/background与content script之间，content_script -> popup/background，直接sendMessage即可，当然popup需要做好onMessage监听；popup/background -> content_script，需要在popup中作 chrome.tabs.query 找到对应的tab，当然content_script也要做好onMessage 监听。
   • injected js与content script之间，二者之间共享的东西是页面的DOM元素，因此消息通信机制主要基于DOM，content -> injected js不存在通信的问题，直接执行里面的方法即可；injected js – > content_script 则需要在injected js中，使用window.postMessage或者自定义event方式，发送消息，content_script中window.addEventListener监听事件；

写在后面

扩展入门很简单，完善的产品设计与定义好的功能边界，才能产出一个合格的输出。文章将根据后续开发情况，持续更新。