前端存儲調研總結

時間 2019-12-14

標籤前端存儲調研總結简体版

原文原文鏈接

前言：這幾天應老大要求，對前端存儲進行調研。以前校招的時候理解的不全面，感受還迷迷糊糊的，只知其一;不知其二，如今本身系統梳理一遍，總算明白了這些東西是怎麼一回事，但願可以幫助接下去參加校招的小盆友以及在前端路上一塊兒前行的小夥伴們。q(≧▽≦q)javascript

1、調研目的

系統梳理前端存儲，總結他們的特色、兼容性等，並進行對比，找出其各自的應用場景。html

2、控制檯展現前端存儲

Chrome：前端

搜狗瀏覽器：html5

3、本地存儲概覽

好處（一切爲了提高用戶體驗 :D）：java

方便網頁的加載，避免取回數據前頁面一片空白，若是不須要最新數據也能夠減小向服務端請求的次數，從而減小用戶等待從服務器獲取數據的時間；
網絡狀態不佳時仍能夠顯示離線數據。

1）本地數據存儲：通常存儲的都是數據

Cookie：瀏覽器均支持，容量爲4KB
IE用戶數據（UserData）：僅IE支持
Web存儲機制（Web Storage）：H5，容量爲5M
- localStorage
- sessionStorage
- globalStorage（Firefox獨有，Firefox13起就再也不支持）
數據庫存儲：
- IndexDB
- Web SQL

2）離線存儲（應用緩存）：通常存儲的是網頁

Cache Storage：定義在 Service Worker 的規範中，配合 Service Worker 進行離線緩存
Application Cache：在定稿的 HTML 5.1 中被拿到了

4、對主要前端存儲方式的詳解和比較

1.1 說明

HTTP Cookie，最初用於在客戶端存儲會話信息。該標準要求服務器對任意 HTTP 請求發送 Set-Cookie HTTP 頭做爲響應的一部分，其中包含會話信息。瀏覽器會存儲這樣的會話信息，並在這以後，經過爲每一個請求添加 Cookie HTTP 頭將信息發送回服務器。web

【舉例以下】：sql

服務器響應頭：數據庫

瀏覽器響應頭：segmentfault

1.2 使用

在 JavaScript 中能夠經過 document.cookie 設置字段和進行訪問。windows

// 設置 cookie 字段
document.cookie = 'name=Lucy';

// 更好的設置方式：
document.cookie = encodeURIComponent('age') + '=' + encodeURIComponent(25);

// 訪問 cookie
document.cookie

// 刪除 cookie（設置存儲有效時長爲過去時間）
var date = new Date();
date.setDate(date.getDate() + '設置時長');
document.cookie = 'name=Lucy;expires=' + date.toUTCString();

cookie 由瀏覽器保存的如下幾塊信息構成：名稱、值、域、路徑、失效時間、安全標誌。

【舉例說明】：

該頭信息指定了一個叫作 name 的 cookie，會在格林威治時間2007年1月22日7:10:24失效（日期過時時，會當即失效），同時對於 www.wrox.com 和 wrox.com 的任何子域都有效。

secure 標誌是 cookie 中惟一一個非名值對兒的部分，直接包含一個 secure 單詞。以下：

注意：域、路徑、失效時間和 secure 標誌都是服務器給瀏覽器的指示，以指定什麼時候應該發送 cookie。這些參數並不會做爲發送到服務器的 cookie 信息的一部分，只有名值對兒纔會被髮送。

1.4 訪問限制及存儲時長

cookie 能夠設置訪問域，在設置 cookie 的時候，設定了 cookie 的訪問域名爲一個頂級域名，則能夠達到幾個子域名共享 cookie 的效果，如騰訊網 www.qq.com 與微信網頁版 wx.qq.com 共享了 pac_uid，以及不一樣頁面的購物車共享。
若是設定了 cookie 的超時時間，則 cookie 將在到期的時候失效。
若是沒有設定超時時間，則是 session 級別的（注意上圖 Expires/Max-Age 一欄），在退出瀏覽器時，該 cookie 將消失。

cookie 的 session 不一樣於 sessionStorage 的 session，cookie 的 session 是指在未關閉瀏覽器的狀況下，全部的 tab 級別的頁面或新開，或刷新，均屬於一個 session。

優勢：
- 可控制過時時間，使其不會長期有效
- 可擴展、可用性比較好，可跨域共享
- 可加密減小cookie被破解的可能性
- 兼容性好
缺點：
- 數量和長度有限制
- 在請求頭上帶着數據安全性差

1.6 應用場景

通常非到不得已，不要在 cookie 裏面存東西，更不要存儲重要和敏感的數據。若是要存儲的話，建議存儲一些同步訪問頁面的時候必需要被帶到服務端的信息。

客戶端登陸，用於保存用戶信息。如「下次自動登陸」的選項，勾選以後下次就不須要重複驗證。經過 cookie 能夠保存用戶的 id。

建立購物車。能夠實現不一樣頁面之間的數據同步（同一個域名下是能夠共享cookie的），同時在提交訂單的時候又會把這些cookie傳到後臺。

跟蹤用戶行爲。例如百度聯盟會經過cookie記錄用戶的偏好信息，從而推薦個性化推廣信息，如頁面上的小廣告。這是能夠禁用的，也是cookie的缺點之一。

2. Web Storage：僅存儲於客戶端

定義了兩種用於存儲數據的對象：sessionStorage 和 localStorage，後二者是Storage的實例。

注意：Storage 類型只能存儲字符串。非字符串的數據在存儲以前會被轉換成字符串。

【瀏覽器兼容性】：

大多數瀏覽器對 webstorage 的支持狀況還算不錯，具體請參閱：http://caniuse.com/#search=webstorage

Local Storage 的兼容性方案實現：LocalStorage Compability

2.1 目的及兩個主要目標

克服由 cookie 帶來的一些限制，當數據須要被嚴格控制在客戶端上時，無須持續地將數據發回服務器。
（目標）提供一種在 cookie 以外存儲會話數據的途徑；
（目標）提供一種存儲大量能夠跨會話存在的數據的機制。

2.2 訪問方式

這兩個對象在瀏覽器中都是以 windows 對象屬性的形式存在，在 JavaScript 中能夠直接經過 sessionStorage 和 localStorage 訪問。

2.3 Storage 的實例方法

clear：刪除全部值，Firefox中沒有實現
getItem(name)：根據指定的名字 name 獲取對應的值
key(index)：得到 index 處的值的名字
removeItem(name)：刪除由 name 指定的名值對兒
setItem(name, value)：爲指定的 name 設置一個對應的值

2.4 sessionStorage 和 localStorage 介紹

短暫的 sessionStorage

1) 使用：

2) 訪問限制：
- 同源策略：不一樣於cookie，sessionStorage訪問限制更高，只有當前設定sessionStorage的域下才能訪問；
- 單標籤頁：兩個tab（相同域）之間不能互通；
- 在新開的tab下或者關閉本tab以後再打開，也不能訪問以前寫下的sessionStorage；
- 刷新本tab能夠訪問。
3) 特色及應用場景：
- 主要用於僅針對會話的小段數據的存儲。
- 建議存儲一些當前頁面刷新須要存儲，且不須要在tab關閉時候留下的信息。
- 能夠用來檢測用戶是不是刷新進入的頁面，如音樂播放器恢復播放進度條的功能。
- 很是適合單頁應用程序，能夠方便在各業務模塊進行傳值。
持久的 localStorage（隱身窗口例外）

1) 使用： 同 sessionStorage

2) 訪問限制：
- 同源策略：同 sessionStorage，要訪問同一個 localStorage，頁面必須來自同一個域名（子域名無效），使用同一種協議，在同一個端口上；
- localStorage 設定後，刷新或新開 tab 是能夠訪問到的，關閉瀏覽器從新打開原先tab也可訪問。
3) 特色及應用場景：
- 持久保存客戶端數據，數據保留到經過JavaScript刪除或者用戶清除瀏覽器緩存。
- 若是有一些數據，服務器難以承載其壓力，但又要與用戶的信息綁定，可使用 localStorage 存儲一些狀態，這樣既能緩解服務器壓力，也能夠存儲用戶的數據。
- 數據比較大的臨時保存方案。如在線編輯文章時的自動保存。
- 多頁面訪問共同數據。sessionStorage只適用於同一個標籤頁，localStorage相比而言能夠在多個標籤頁中共享數據。
localStorage 與 sessionStorage 的區別總結
- H5的兩種存儲技術的最大區別就是生命週期
  - localStorage是本地存儲，存儲期限不限；
  - sessionStorage是會話存儲，頁面關閉數據就會丟失。
- sessionStorage 有單標籤頁限制，localStorage 則沒有。

2.5 Storage 存儲類型說明

Storage 類型只能存儲字符串。若是存儲的是對象，能夠將對象序列化爲字符串再存入。（如下以 localStorage 進行說明，sessionStorage 一樣適用）

2.6 Storage 大小限制及檢測

Web Storage 的限制因瀏覽器而異。通常來講，對存儲空間大小的限制都是以每一個來源（協議、域和端口）爲單位的，即每一個來源都有固定大小的空間用於保存本身的數據。對於 localStorage 而言，大多數桌面瀏覽器會設置每一個來源 5MB 的限制。對 sessionStorage 的限制也是因瀏覽器而異。

有關 Web Storage 的限制，參考：Web Storage Support Test

對於 Storage 的大小檢測，能夠將 localStorage 和 sessionStorage 序列化，而後查看其字節數：

2.7 storage 事件

對 Storage 對象進行任何操做，都會在文檔上觸發 storage 事件，該事件的 event 對象有如下屬性：

domain：發生變化的存儲空間的域名
key：設置或者刪除的鍵名
newValue：若是是設置值，則是新值；若是是刪除鍵，則是null
oldValue：鍵被更改以前的值

使用時須要檢測 WebKit 是否支持 storage 事件。

Web Storage 是爲了更大容量存儲設計的，而Cookie的大小是受限的。
cookie 在每次請求一個新的頁面的時候都會被髮送過去，在瀏覽器和服務器間來回傳遞，這樣無形中浪費了帶寬。
cookie 能夠設定訪問域，在同源窗口中能夠共享，而 web storage 受同源策略限制。
可是Cookie也是不能夠或缺的：Cookie的做用是與服務器進行交互，做爲HTTP規範的一部分而存在，而Web Storage僅僅是爲了在本地「存儲」數據而生。

3. 數據庫：IndexDB 與 Web SQL

3.1 二者的特色

（本小節詳細內容請參考：聊一聊前端存儲那些事兒）

websql 像關係型數據庫，使用 sql 語句進行操做。
indexdb 像 nosql，直接使用 js 方法操做數據。

訪問：indexdb 和 websql 與 web storage 一致，均是在建立數據庫的域名下才能訪問。且不能指定訪問域名。
存儲時間：這兩位的存儲時間也是永久，除非用戶清除數據，能夠用做長效的存儲。
大小限制：理論上講，這兩種存儲的方式是沒有大小限制的。然而indexeddb的數據庫超過50M的時候瀏覽器會彈出確認。基本上也至關於沒有限制了。
性能測試：indexeddb查詢少許數據花費差很少20MS左右。大量數據的狀況下，相對耗時會變長一些，可是也就在30MS左右，也是至關給力了，10W數據+，畢竟nosql。
而 websql 的效率也不錯，10w+數據，簡單查詢一下，只花費了20MS左右。

3.2 IndexDB 特色

它的數據不是保存在表中，而是保存在對象存儲空間中。
建立對象存儲空間時，須要定義一個鍵，而後就能夠添加數據。
可使用遊標在對象存儲空間中查詢特定的對象。
而索引則是爲了提升查詢速度而基於特定的屬性建立的。

說明：indexDB 目前兼容性還不是很好，Web SQL 雖然已通過時，可是其兼容性卻很是好，幾乎是移動端都可用（兼容性對比查看請移步：http://caniuse.com/#search=websql 以及 http://caniuse.com/#search=indexdb）。

所以，能用 indexdb，就用 indexdb，由於其表明了將來的發展方向，若是不能使用盡可能使用 websql 進行代替。

3.3 IndexDB 異步 API

IndexDB 設計的操做徹底是異步的。所以，大多數操做會以請求的方式進行，但這些操做會在後期執行，若是成功則返回結果，若是失敗則返回錯誤。差很少每一次 IndexDB 操做，都須要你註冊 onerror 或 onsuccess 事件處理程序，以確保適當地處理結果。

打開數據庫時，實質上返回了一個DB對象，該對象存在於 result 中。

3.4 應用場景：

當咱們是在作一個離線應用，或者webapp的時候，能夠考慮使用本地數據庫中存取數據。若是不存大量的數據的話，其實localStorage就夠用了。亦或者，你想把一張用戶的皮膚圖片之類的大量數據存入客戶端緩存起來，localStorage已經不夠用了的話，也能夠嘗試一下websql與indexeddb。