浏览器缓存、CacheStorage、Web Worker 与 Service Worker

[275957304]

浏览器缓存

传统意义上的浏览器缓存，分为强缓存和协商缓存，其共同点都是通过设置 HTTP Header 实现。关于两者的异同已经被讨论得很多，我就不赘述了，附两个参考资料。

1. 浏览器的缓存机制
2. http协商缓存VS强缓存

这种浏览器缓存（我称之为 Header 缓存）有两个共同的缺点：

1. 当没有网络的时候，应用无法访问，因为 HTML 页面总得去服务器获取。
2. 缓存不可编程，无法通过 JS 来精细地对缓存进行增删改查。

应用缓存

为了在无网络下也能访问应用，HTML5 规范中设计了应用缓存（Application Cache）这么一个新的概念。通过它，我们可以做离线应用。然而，由于这个 API 的设计有太多的缺陷，被很多人吐槽，最终被废弃。废弃的原因可以看看这些讨论：
为什么app cache没有得到大规模应用？它有哪些硬伤吗？
Application Cache is a Douchebag, By Jake Archibald

CacheStorage

为了能够精细地、可编程地控制缓存，CacheStorage 被设计出来。有了它，就可以用 JS 对缓存进行增删改查，你也可以在 Chrome 的 DevTools 里面直观地查看。对于传统的 Header 缓存，你是没法知道有哪些缓存，更加没法对缓存进行操作的。你只能被动地修改 URL 让浏览器抛弃旧的缓存，使用新的资源。

PS：CacheStorage 并非只有在 Service Worker 中才能用，它是一个全局性的 API，你在控制台中也可以访问到 caches 全局变量

Web Worker

一直以来，一个网页只会有两个线程：GUI 渲染线程和 JS 引擎线程。即便你的 JS 写得再天花乱坠，也只能在一个进程里面执行。然而，JS 引擎线程和 GUI 渲染线程是互斥的，因此在 JS 执行的时候，UI 页面会被阻塞住。为了在进行高耗时 JS 运算时，UI 页面仍可用，那么就得另外开辟一个独立的 JS 线程来运行这些高耗时的 JS 代码，这就是 Web Worker。

Web Worker 有两个特点：

1. 只能服务于新建它的页面，不同页面之间不能共享同一个 Web Worker。
2. 当页面关闭时，该页面新建的 Web Worker 也会随之关闭，不会常驻在浏览器中。
   浏览器缓存、CacheStorage、Web Worker 与 Service Worker youngwind/blog#113