摘要:而緩存系統數據,我采用另外的方案。調用方式第二次調用取得先前的方案二緩存方案一本身是不足的。當前緩存中沒有該對進行操作在請求回來后,如果出現問題,把從中刪除以避免第二次請求繼續出錯返回該代碼避免了方案一的同一時間多次請求的問題。
在開發 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) }) promiseCache.set(api, promise) } // 返回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的緩存機制與場景在這里也基本上介紹了,基本上能夠完成絕大多數的數據業務緩存,在這里我也想請教教大家,有沒有什么更好的解決方案,或者這篇博客中有什么不對的地方,歡迎指正,在這里感謝各位了。
同時這里也有很多沒有做完的工作,可能會在后面的博客中繼續完善。
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/103741.html
摘要:前端性能優化的涉及點從服務器到協議再到宿主環境本身都要有比較深刻的認識,業界目前主要還是以雅虎總結出來條前端性能優化的黃金軍規為參考。 歡迎大家前往騰訊云技術社區,獲取更多騰訊海量技術實踐干貨哦~ 導語 : 從事前端有6年+的時間了,從最開始的美工到重構再到偏向js邏輯開發的前端開發,一直在前端這個行業里面摸索和學習,我現在將自己這些年的一個心得體會來個系統性的梳理寫成一篇關于性能優化...
摘要:服務端渲染兩種方式根據上文介紹對服務端渲染利弊有所了解,我們可以根據利弊權衡取舍,最近在做服務端渲染的項目,找到多種服務端渲染解決方案,大致分為兩類。第一種方式傳統方式服務端渲染,解決用戶體驗和更好的,有諸多工具使用這種方式如的的等。 最近在開發一個服務端渲染工具,通過一篇小文大致介紹下服務端渲染,和服務端渲染的方式方法。在此文后面有兩中服務端渲染方式的構思,根據你對服務端渲染的利弊權...
摘要:新聞熱點國內國外,前端最新動態蘋果開源了版近日,蘋果開源了一款基于事件驅動的跨平臺網絡應用程序開發框架,它有點類似,但開發語言使用的是。蘋果稱的目標是幫助開發者快速開發出高性能且易于維護的服務器端和客戶端應用協議。 showImg(https://segmentfault.com/img/remote/1460000013677379); 前端每周清單專注大前端領域內容,以對外文資料的...
閱讀 3289·2023-04-25 14:35
閱讀 3422·2021-11-15 18:00
閱讀 2564·2021-11-12 10:34
閱讀 2496·2021-11-11 16:54
閱讀 3481·2021-10-08 10:12
閱讀 2768·2021-09-06 15:02
閱讀 3320·2021-09-04 16:48
閱讀 2804·2019-08-29 14:02