设计思路
crater 的使用场景是这样的：一个站点的内容是由多个独立的模块提供的，而每个模块都需要配置自己 需要缓存的静态资源及其缓存策略。Baidu 的搜索结果页就是一个很好的例子。在这种场景下， crater 可以帮助开发者对多个模块不同的缓存需求进行管理。
基于这样的场景设置，crater 需要满足的特性有：
- 每个模块各自独立，不能互相影响，包括路由规则和配置文件等
- 每个模块能够快速提交/修改自身的需求
- 缓存策略可扩展
- 模块较多时拥有较好的性能，否则起不到 PWA 本身的目的
- 各类浏览器和环境下比较完备的测试
- webpack
crater 的生成结果只有一个 JavaScript 文件 service-worker.js，因此势必需要经过编译，打包，混淆等步骤，因此采用时下比较流行的 webpack 进行构建处理。
- 测试相关
此外为了对 service-worker.js 进行测试，我们参考了 sw-toolbox 的测试方式，引用了 selenium-assistant, sw-testing-helpers, chromedriver 等等 npm 包，并且编写了测试用例，均放在 test/browser-tests 目录下，可以通过运行 npm run test 进行测试。
- ES6
为了保证 JavaScript 代码的简洁和高效，crater 使用了 ES6 进行编码，并额外使用了 babel 在打包时进行转换，因此生成的 service-worker.js 中并不包含 ES6 的代码。
这里将列出一些主要模块的依赖和调用关系。核心代码都位于 lib 目录下。
- sw-base
对外唯一接口，提供 add, precache 等方法对需要缓存的规则或者文件进行注册。此外还在这里调用 service worker 的 self.addEventListener 方法进行注册。
- defaults
记录配置项和缓存策略的默认值，同时也确保用户配置文件的合法性，过滤非法项并和默认值进行合并
- precache
记录预缓存文件列表
- strategy
位于 strategies 目录中，每个文件（除 index.js 和 utils.js 之外）均表示一个缓存策略。而 index.js 即为对外暴露的接口，这样成功将策略部分和上层部分解耦，保证缓存策略的可扩展性
- router
crater 的核心，提供 add 和 match 方法。add 用于添加路由规则，match 用于匹配路由规则并选择缓存规则。其中匹配部分优先匹配 referrer 再匹配路由规则，因此在模块较多时是先选定一个模块再匹配路由规则，避免匹配内容过多影响性能。
- listeners
提供 service worker 的各个阶段事件的响应函数，目前提供 install, activate 和 fetch 事件的响应。
此外，最外层还有一个 main.js ，将所有位于 product/* 下的配置文件加载并逐个调用 sw-base 的 add 和 precache 方法，完成注册。