整合营销服务商

电脑端+手机端+微信端=数据同步管理

免费咨询热线:

JavaScript中本地存储的方式有哪些?

、方式

javaScript本地缓存的方法我们主要讲述以下四种:

  • cookie
  • sessionStorage
  • localStorage
  • indexedDB

随着Service Worker(以下简称SW)的普及和规范,我们可以使用SW提供的缓存接口替代HTTP缓存。当然SW的功能是强大的,除了缓存功能,还能够使用它来实现离线、数据同步、后台编译等等。

应用

一个标配版的sw缓存工代代码应该有以下的片段:

const version = '2';
self.addEventListener('install', event => {
 event.waitUntil(
 caches.open(`static-${version}`)
 .then(cache => cache.addAll([
 '/styles.css',
 '/script.js'
 ]))
 );
});
self.addEventListener('fetch', event => {
 event.respondWith(
 caches.match(event.request)
 .then(response => response || fetch(event.request))
 );
});

首先你要明白的前提是,网络请求首先到达的是SW脚本中,如果未命中再转发给HTTP缓存。

这段代码的意思是,在SW的install阶段我们将script.js和styles.css放入缓存中;而在请求发起的fetch阶段,通过资源的URL去缓存内查找匹配,成功后立刻返回,否则走正常的网络请求流程。

但你有没有考虑过,在install阶段的资源内容是哪里来的?仍然是从HTTP缓存中。这样SW缓存机制又有可能随着HTTP缓存陷入了之前所说的版本不一致的困境中。

既然我们借助SW重写了缓存机制,所以也不想再受牵制于旧的HTTP缓存。解决办法是让SW中的请求必须向服务端验证:

self.addEventListener('install', event => {
 event.waitUntil(
 caches.open(`static-${version}`)
 .then(cache => cache.addAll([
 new Request('/styles.css', { cache: 'no-cache' }),
 new Request('/script.js', { cache: 'no-cache' })
 ]))
 );
});

目前并非所有的浏览器都支持cache选项的配置。但这个不是太大问题,我们可以通过添加随机数来保证每次请求的URL都不相同,间接的使得缓存失效:

self.addEventListener('install', event => {
 event.waitUntil(
 caches.open(`static-${version}`)
 .then(cache => Promise.all(
 [
 '/styles.css',
 '/script.js'
 ].map(url => {
 // cache-bust using a random query string
 return fetch(`${url}?${Math.random()}`).then(response => {
 // fail on 404, 500 etc
 if (!response.ok) throw Error('Not ok');
 return cache.put(url, response);
 })
 })
 ))
 );
});

上面的代码使用的是随机数作为文件版本,你当然可以使用更精确的方式,例如根据文件内容生成md5值来作为版本信息,而这个思维模式就是模块sw-precache模块的背后哲学。

sw-precache

想象一下现在我们需要实施上述绕过http缓存的解决方案。首先我们需要知道究竟站点中有多少静态资源,然后设定版本号的生成规则,接着根据静态资源再具体的编写我们的SW脚本。

不难看出,上面描述的过程可以是机械化自动化的,包括识别静态资源,生成SW脚本等。而类库sw-precache则可以帮我们完成这些工作。尤其是在构建阶段配合Gulp或者Grunt使用,具体用法我们可以摘录它官网的一段DEMO:

gulp.task('generate-service-worker', function(callback) {
 var swPrecache = require('sw-precache');
 var rootDir = 'app';
 swPrecache.write(`${rootDir}/service-worker.js`, {
 staticFileGlobs: [rootDir + '/**/*.{js,html,css,png,jpg,gif,svg,eot,ttf,woff}'],
 stripPrefix: rootDir
 }, callback);
});

这段脚本注册了一个名为generate-service-worker的任务,用于在根目录生成一个名为service-worker.js的sw脚本,而这个脚本缓存的资源呢,则是目录下的所有脚本、样式、图片、字体等几乎所有的静态文件。

浏览器的整体缓存机制

除了HTTP标准缓存以外,浏览器还有可能存在标准以外的缓存机制。对于Chrome浏览器而言还存在Memory Cache、Push “Cache”。一个请求在查找资源的过程中经过的缓存顺序是Memory Cache、Service Worker、HTTP Cache、Push “Cache”。HTTP Cache和Service Worker已经介绍过了,接下来简单介绍Memory Cache和Push Cache

Memory Cache

“内存缓存”中主要包含的是当前文档中页面中已经抓取到的资源。例如页面上已经下载的样式、脚本、图片等。我们不排除页面可能会对这些资源再次发出请求,所以这些资源都暂存在内存中,当用户结束浏览网页并且关闭网页时,内存缓存的资源会被释放掉。

这其中最重要的缓存资源其实是preloader相关指令(例如<link rel="prefetch">)下载的资源。总所周知preloader的相关指令已经是页面优化的常见手段之一,而通过这些指令下载的资源也都会暂存到内存中。根据一些材料,如果资源已经存在于缓存中,则可能不会再进行preload。

需要注意的事情是,内存缓存在缓存资源时并不关心返回资源的HTTP缓存头Cache-Control是什么值,同时资源的匹配也并非仅仅是对URL做匹配,还可能会对Content-Type,CORS等其他特征做校验

Push “Cache”

“推送缓存”是针对HTTP/2标准下的推送资源设定的。推送缓存是session级别的,如果用户的session结束则资源被释放;即使URL相同但处于不同的session中也不会发生匹配。推送缓存的存储时间较短,在Chromium浏览器中只有5分钟左右,同时它也并非严格执行HTTP头中的缓存指令

Push “Cache”的优缺点

关于推送缓存,主要有以下几大特点:

  • 几乎所有的资源都能被推送,并且能够被缓存。测试过程是作者在推送资源之后尝试用fetch()、XMLHttpRequest、<link rel="stylesheet" href="…">、<script src="…">、<iframe src="…">获取推送的资源。Edge和Safari浏览器支持相对比较差
  • no-cache和no-store资源也能被推送
  • Push Cache是最后一道缓存机制(之前会经过Memory Cache、HTTP Cache、Service Worker)
  • 如果连接被关闭则Push Cache被释放
  • 多个页面可以使用同一个HTTP/2的连接,也就可以使用同一个Push Cache。这主要还是依赖浏览器的实现而定,出于对性能的考虑有的浏览器会对相同域名但不同的tab标签使用同一个HTTP连接。
  • 一旦Push Cache中的资源被使用即被移除如果Push Cache或者HTTP Cache已经存在被推送的资源,则有可能浏览器拒绝推送
  • 你可以为其他域名推送资源

开发 web 应用程序时,性能都是必不可少的话题。对于webpack打包的单页面应用程序而言,我们可以采用很多方式来对性能进行优化,比方说 tree-shaking、模块懒加载、利用 extrens 网络cdn 加速这些常规的优化。

甚至在vue-cli 项目中我们可以使用 --modern 指令生成新旧两份浏览器代码来对程序进行优化。

而事实上,缓存一定是提升web应用程序有效方法之一,尤其是用户受限于网速的情况下。提升系统的响应能力,降低网络的消耗。

当然,内容越接近于用户,则缓存的速度就会越快,缓存的有效性则会越高。

以客户端而言,我们有很多缓存数据与资源的方法,例如 标准的浏览器缓存 以及 目前火热的 Service worker。

但是,他们更适合静态内容的缓存。例如 html,js,css以及图片等文件。而缓存系统数据,我采用另外的方案。

那我现在就对我应用到项目中的各种 api 请求方案,从简单到复杂依次介绍一下。

方案一、 数据缓存

简单的 数据 缓存,第一次请求时候获取数据,之后便使用数据,不再请求后端api。
代码如下:

const dataCache = new Map()
async getWares() {   
  let key = 'wares'    // 从data 缓存中获取 数据    
  let data = dataCache.get(key)   
  if (!data) {        // 没有数据请求服务器    
    const res = await request.get('/getWares')
        // 其他操作        ...     
    data = ...
        // 设置数据缓存     
    dataCache.set(key, data)
    }    
  return data
} 

第一行代码 使用了 es6以上的 Map,如果对map不是很理解的情况下,你可以参考
ECMAScript 6 入门 Set 和 Map 或者 Exploring ES6 关于 map 和 set的介绍,此处可以理解为一个键值对存储结构。

之后 代码 使用 了 async 函数,可以将异步操作变得更为方便。你可以参考ECMAScript 6 入门 async函数来进行学习或者巩固知识。

代码本身很容易理解,是利用 Map 对象对数据进行缓存,之后调用从 Map 对象来取数据。对于极其简单的业务场景,直接利用此代码即可。

调用方式:

getWares().then( ... )
// 第二次调用 取得先前的data
getWares().then( ... )

方案二、 promise缓存

方案一本身是不足的。因为如果考虑同时两个以上的调用此 api,会因为请求未返回而进行第二次请求api。

当然,如果你在系统中添加类似于 vuex、redux这样的单一数据源框架,这样的问题不太会遇到,但是有时候我们想在各个复杂组件分别调用api,而不想对组件进行组件通信数据时候,便会遇到此场景。

const promiseCache = new Map()
getWares() {    
  const key = 'wares'   
  let promise = promiseCache.get(key);  
  // 当前promise缓存中没有 该promise    
  if (!promise) {        
    promise = request.get('/getWares').then(res => {        
      // 对res 进行操作         
      ...    
    }).catch(error => {       
      // 在请求回来后,如果出现问题,把promise从cache中删除 以避免第二次请求继续出错S 
      promiseCache.delete(key)     
      return Promise.reject(error)     
    })   
    }    
    // 返回promise 
                                            
  return promise
 }
      
      

该代码避免了方案一的同一时间多次请求的问题。同时也在后端出错的情况下对promise进行了删除,不会出现缓存了错误的promise就一直出错的问题。

调用方式:

getWares().then( ... )/
                / 第二次调用 取得先前的promise
                getWares().then( ... )

方案三、 多promise 缓存

该方案是同时需要 一个以上 的api请求的情况下,对数据同时返回,如果某一个api发生错误的情况下。

均不返回正确数据。

const querys ={    
  wares: 'getWares', 
  skus: 'getSku'
}
const promiseCache = new Map()
async queryAll(queryApiName) {   
  // 判断传入的数据是否是数组    
  const queryIsArray = Array.isArray(queryApiName)   
  // 统一化处理数据,无论是字符串还是数组均视为数组   
  const apis = queryIsArray ? queryApiName : [queryApiName]
    // 获取所有的 请求服务   
  const promiseApi = []
    apis.forEach(api => {    
      // 利用promise        
      let promise = promiseCache.get(api)
        if (promise) {         
          // 如果 缓存中有,直接push        
          promise.push(promise)       
        } else {          
          promise = request.get(querys[api]).then(res => {       
            // 对res 进行操作               
            ...              
          }).catch(error => {      
            // 在请求回来后,如果出现问题,把promise从cache中删除       
            promiseCache.delete(api)         
            return Promise.reject(error)      
          })          
            promiseCache.set(api, promise)     
            promiseCache.push(promise)    
          } 
        })  
      return Promise.all(promiseApi).then(res => {      
        // 根据传入的 是字符串还是数组来返回数据,因为本身都是数组操作     
        // 如果传入的是字符串,则需要取出操作       
        return queryIsArray ? res : res[0]    
      })
   }

该方案是同时获取多个服务器数据的方式。可以同时获得多个数据进行操作,不会因为单个数据出现问题而发生错误。

调用方式:

queryAll('wares').then( ... )
// 第二次调用 不会去取 wares,只会去skus
queryAll(['wares', 'skus']).then( ... )

方案四 、添加时间有关的缓存

往往缓存是有危害的,如果我们在知道修改了数据的情况下,直接把 cache 删除即可,此时我们调用方法就可以向服务器进行请求。

这样我们规避了前端显示旧的的数据。但是我们可能一段时间没有对数据进行操作,那么此时旧的数据就一直存在,那么我们最好规定个时间来去除数据。

该方案是采用了 类 持久化数据来做数据缓存,同时添加了过期时长数据以及参数化。

代码如下:

首先定义持久化类,该类可以存储 promise 或者 data

class ItemCache() {    
  construct(data, timeout) {      
    this.data = data       
    // 设定超时时间,设定为多少秒      
    this.timeout = timeout       
    // 创建对象时候的时间,大约设定为数据获得的时间   
    this.cacheTime = (new Date()).getTime    }
}

然后我们定义该数据缓存。我们采用Map 基本相同的api


class ExpriesCache {
    // 定义静态数据map来作为缓存池
    static cacheMap =  new Map()

    // 数据是否超时
    static isOverTime(name) {
        const data = ExpriesCache.cacheMap.get(name)

        // 没有数据 一定超时
        if (!data) return true

        // 获取系统当前时间戳
        const currentTime = (new Date()).getTime()        

        // 获取当前时间与存储时间的过去的秒数
        const overTime = (currentTime - data.cacheTime) / 1000

        // 如果过去的秒数大于当前的超时时间,也返回null让其去服务端取数据
        if (Math.abs(overTime) > data.timeout) {
            // 此代码可以没有,不会出现问题,但是如果有此代码,再次进入该方法就可以减少判断。
            ExpriesCache.cacheMap.delete(name)
            return true
        }

        // 不超时
        return false
    }

    // 当前data在 cache 中是否超时
    static has(name) {
        return !ExpriesCache.isOverTime(name)
    }

    // 删除 cache 中的 data
    static delete(name) {
        return ExpriesCache.cacheMap.delete(name) 
    }

    // 获取
    static get(name) {
        const isDataOverTiem = ExpriesCache.isOverTime(name)
        //如果 数据超时,返回null,但是没有超时,返回数据,而不是 ItemCache 对象
        return isDataOverTiem ? null : ExpriesCache.cacheMap.get(name).data
    }

    // 默认存储20分钟
    static set(name, data, timeout = 1200) {
        // 设置 itemCache
        const itemCache = mew ItemCache(data, timeout)
        //缓存
        ExpriesCache.cacheMap.set(name, itemCache)
    }
}

此时数据类以及操作类 都已经定义好,我们可以在api层这样定义

// 生成key值错误
const generateKeyError = new Error("Can't generate key from name and argument")

// 生成key值
function generateKey(name, argument) {
    // 从arguments 中取得数据然后变为数组
    const params = Array.from(argument).join(',')

    try{
        // 返回 字符串,函数名 + 函数参数
        return `${name}:${params}`
    }catch(_) {
        // 返回生成key错误
        return generateKeyError
    }
}

async getWare(params1, params2) {
    // 生成key
    const key = generateKey('getWare', [params1, params2]) 
    // 获得数据
    let data = ExpriesCache.get(key)
    if (!data) {
        const res = await request('/getWares', {params1, params2})
        // 使用 10s 缓存,10s之后再次get就会 获取null 而从服务端继续请求
        ExpriesCache.set(key, res, 10)
    }
    return data
}

该方案使用了 过期时间 和 api 参数不同而进行 缓存的方式。已经可以满足绝大部分的业务场景。

调用方式:


getWares(1,2).then( ... )
// 第二次调用 取得先前的promise
getWares(1,2).then( ... )
// 不同的参数,不取先前promise
getWares(1,3).then( ... )

方案五、基于修饰器的方案四

和方案四是的解法一致的,但是是基于修饰器来做。
代码如下:

// 生成key值错误
const generateKeyError = new Error("Can't generate key from name and argument")

// 生成key值
function generateKey(name, argument) {
    // 从arguments 中取得数据然后变为数组
    const params = Array.from(argument).join(',')
    try{
        // 返回 字符串
        return `${name}:${params}`
    }catch(_) {
        return generateKeyError
    }
}

function decorate(handleDescription, entryArgs) {
    // 判断 当前 最后数据是否是descriptor,如果是descriptor,直接 使用
    // 例如 log 这样的修饰器
    if (isDescriptor(entryArgs[entryArgs.length - 1])) {
        return handleDescription(...entryArgs, [])
    } else {
        // 如果不是
        // 例如 add(1) plus(20) 这样的修饰器
        return function() {
            return handleDescription(...Array.protptype.slice.call(arguments), entryArgs)
        }
    }
}

function handleApiCache(target, name, descriptor, ...config) {
    // 拿到函数体并保存
    const fn = descriptor.value
    // 修改函数体
    descriptor.value = function () { 
        const key =  generateKey(name, arguments)
        // key无法生成,直接请求 服务端数据
        if (key === generateKeyError)  {
            // 利用刚才保存的函数体进行请求
            return fn.apply(null, arguments)
        }
        let promise = ExpriesCache.get(key)
        if (!promise) {
            // 设定promise
            promise = fn.apply(null, arguments).catch(error => {
                 // 在请求回来后,如果出现问题,把promise从cache中删除
                ExpriesCache.delete(key)
                // 返回错误
                return Promise.reject(error)
            })
            // 使用 10s 缓存,10s之后再次get就会 获取null 而从服务端继续请求
            ExpriesCache.set(key, promise, config[0])
        }
        return promise 
    }
    return descriptor;
}

// 制定 修饰器
function ApiCache(...args) {
    return decorate(handleApiCache, args)
}

此时 我们就会使用 类来对api进行缓存


class Api {
    // 缓存10s
    @ApiCache(10)
    // 此时不要使用默认值,因为当前 修饰器 取不到
    getWare(params1, params2) {
        return request.get('/getWares')
    }
}

因为函数存在函数提升,所以没有办法利用函数来做 修饰器
例如:


var counter = 0;

var add = function () {
  counter++;
};

@add
function foo() {
}

该代码意图是执行后counter等于 1,但是实际上结果是counter等于 0。因为函数提升,使得实际执行的代码是下面这样

@add
function foo() {
}

var counter;
var add;

counter = 0;

add = function () {
  counter++;
};

所以没有 办法在函数上用修饰器。具体参考ECMAScript 6 入门 Decorator
此方式写法简单且对业务层没有太多影响。但是不可以动态修改 缓存时间

调用方式


getWares(1,2).then( ... )
// 第二次调用 取得先前的promise
getWares(1,2).then( ... )
// 不同的参数,不取先前promise
getWares(1,3).then( ... )

总结

api的缓存机制与场景在这里也基本上介绍了,基本上能够完成绝大多数的数据业务缓存