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的緩存機制與場景在這里也基本上介紹了，基本上能夠完成絕大多數的數據業務緩存

在線咨詢

上一篇：高顏值網頁首屏：采用黃色系，如何不刺眼
下一篇：HTML詳細介紹1

您的項目需求

*請認真填寫需求信息，我們會在24小時內與您取得聯系。

整合營銷服務商

JavaScript中本地存儲的方式有哪些？

、方式

言

應用

瀏覽器的整體緩存機制

方案一、 數據緩存

方案二、 promise緩存

方案三、 多promise 緩存

方案四 、添加時間有關的緩存

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

總結

您的項目需求

方案一、數據緩存

方案三、多promise 緩存

方案四、添加時間有關的緩存