前端離線化探索

時間 2019-11-05

標籤前端離線探索简体版

原文原文鏈接

原文：前端離線化探索
做者：flyfu wangjavascript

飛機上的梗

某天，小明同窗忽然反饋：「昨晚發現根本沒法使用大家的應用... ....怎麼回事呢」。我和個人小夥伴們立馬驚呆了，心想：「老司機多年的經驗有一種預感，那就是同窗你使用姿式不正確...（此處省略300字）」。而後默默排查了許久，答案居然是： html

「小明昨晚在飛機上」。前端

爲了之後可以在飛機上愉快的玩耍，這裏的離線體驗咱們有必要再着重優化下。自此，一個不分晝夜的需求快馬飛鞭地提上了日程。java

離線化帶來的價值

在這個流量日益白菜價，不斷說起雲端計算、5g網絡的時代，有人以爲，離線已經徹底沒有必要。談及離線，彷彿想到的是深海老林，荒無人煙之處。事實上，離線離咱們的生活很近，也很是頻繁。高速公路、地鐵隧道、樓道角落，以及諸多平常信號不穩定區域，這些場景天天都有大量用戶通過，天天有成千萬用戶頻繁由於網絡問題，心底裏吐槽抱怨過咱們的應用，斷網離線並不是咱們的錯，但咱們是否可以從用戶體驗的角度，嘗試改善他們在進入弱網或無網絡狀態時的焦慮情緒呢，從而給產品帶來更正向的體驗收益，提高用戶留存與口碑。ios

樂觀UI

談及改善用戶焦慮情緒，頗有必要介紹下樂觀 UI[Optimistic User Interfaces]。樂觀 UI 是一種界面的響應模式，它推薦前端在服務端接收響應以前，先更新 UI，一旦服務器返回，再變動爲實際結果。git

好比，用戶點擊按鈕，前端更新數據狀態爲成功，請求到達後臺，服務器響應，更新前端數據。由於99%的響應都是成功的，因此只有少部分用戶須要退回到失敗狀態。web

樂觀 UI 不是一種先進的技術和新東西，而是一種「離線優先」思惟模式下，改善用戶體驗情緒的設計。sql

前端離線化幾種經常使用的方案

Application Cache

HTML5 最先提供一種了一種緩存機制，可使web的應用程序離線運行。咱們使用 Application Cache 接口設置瀏覽器應該緩存的資源，即配置manifest文件，在用戶處於離線狀態時，點擊刷新按鈕，應用也能正常加載與工做。數據庫

不過該接口很快被標準廢棄了，緣由之一是這是個設計很不合理的接口，好比更新不及時，沒法作到用 javascript 精細化控制，可用性不好，若是你不嚴格的遵循其規則，會遇到不少坑。取而代之的是更強大的service-worker。redux

service-worker

正由於Application Cache一直沒法有效的解決離線資源精細化控制，service-worker （如下簡稱sw）接口被設計出來了，比起Application Cache，它提供獨立的後臺JS線程，是一種特殊的worker上下文訪問環境。在漸進式web應用PWA中，sw爲Network independent特性提供了最核心的支持。

藉助CacheStorage，咱們能夠在 sw 安裝激活的生命週期中，按需填充緩存資源，而後在fetch 事件中，攔截 http 請求，將緩存資源或者自定義消息返回給頁面。

service-worker 實現了真正的可用性及安全性。首先，相對於原有web 應用邏輯是不可見，它相似於一箇中間攔截服務，中間發生任何錯誤，都會退回到請求線上邏輯。其次，它只能在 https 下運行保證了安全性。

sw對於咱們的離線化方案而言，有一個致命的問題，就是ios webview 兼容性問題。ios 11.3以上自帶的Safari是支持 ws，然而，蘋果一向的特性，默認UIWebView 不支持service-worker。

離線數據

事實上，咱們的大部分離線場景將是會在本地獨立 app 之中，藉助客戶端能力，咱們能夠把 web 代碼包提早內置到客戶端之中，而後使用一套代碼更新機制，前端代碼緩存問題能夠獲得解決。離線代碼加載和更新邏輯自己不復雜，下面是一個簡化圖，具體特定業務場景下還須要考慮好比是否灰度用戶，代碼版本和數據是否同步等問題。

離線化方案的複雜度之一在於離線數據的處理，及如何對設計之初就沒有考慮過「Offline First」的舊代碼進行最小改造處理，既優先考慮在離線狀態的基本功能，在線時再進一步加強。基於離線和在線邏輯解耦的考慮，咱們應該本着最大限度減小對原有在線邏輯侵入的原則去思考離線化方案。咱們看下常見的離線數據前端方案。

PouchDB

PouchDB 是一個跨平臺javascript 數據庫，內部封裝了IndexDB、WebSql兼容前端處理.

通常而言前端pouchDB進行離線處理，搭配後臺CouchDB，能夠更方便雙向數據同步。

Sync 接口專門用不一樣步先後的數據：

在中小型項目，特別是那種後臺能夠由前端接手的全棧式開發，pouchDB是一種不錯的離線數據處理方案。此方案問題是壓縮後任然有130多kb，而且依賴於特定後臺方案，不夠通用。

Redux-Offline

對於項目使用了 redux 數據管理的項目而言，最快捷的辦法，就是使用 redux-offline，其基本思路是經過redux middleware 監聽每次 acton 數據變化，而後將須要離線的數據序列化到本地（對於 web 瀏覽而言存儲兼容順序是indexdb—websql—localstorage），等下一次刷新頁面時，優先從本地還原數據還原到 store 中。這種方案的好處是快速配置須要緩存的API接口到中間件便可，充分結合了 redux 特性，對於想要達到簡單優先展現離線數據的應用而言，是很是不錯的。

但這種思路帶來的問題是操做數據不夠靈活，本地儲存數據沒法方便的和其餘非 redux邏輯共享。在離線數據量較大的狀況，一次性讀寫，並同時序列化大量本地數據也會帶來性能問題，對於頻繁有數據變動的場景也不合適。

Redux與IndexDB結合

若是想要達到對數據精細化控制，而且同時不對原有在線邏輯有過多的侵入，咱們能夠在數據儲存上用 IndexDB 替換後臺返回數據，前端數據處理仍然複用原有redux。

業務數據的本地儲存須要注意的就是合理抽象業務使用的數據，而後按照數據庫設計的基本原則本地建表，這裏也能夠和後臺同窗聊聊，避免有遺漏的設計問題。

因爲IndexDB 原生操做api比較粗糙，咱們分裝了一套通用DB底層操做庫，同時將api接口抽象出來，以 git 子倉庫的形式在各業務放公用。這裏首先簡化了前端業務層DB本地讀寫、排序等邏輯，便於相互關聯項目的共用，其次將 DB 抽象出來也是爲了更好的方便業務自己能夠不依賴 IndexDB自己，能夠結合客戶端特性，給底層數據庫替換及進行優化提供了便捷，或者對於純web 端，爲向下兼容可使用WebSql、LocalStorage等兼容提供了拓展。

對於前端代碼架構上，如何藉助 redux將原有的在線請求後臺接口，快速優雅的轉換到對本地的讀寫呢？

比較合適的作法是，單獨抽出一層redux 中間件，經過配置文件的形式，將須要離線的 API初始化時傳進去，而後在middleware中，完成對 DB 的讀寫操做，將數據組裝好給下一個 reducer，咱們能夠叫offline中間件。爲了更進一步合理的對 api 參數分解出來，咱們也須要在offline 中間件前將接口請求層再抽象一箇中間件，咱們叫 API middleware ，這樣通過離線中間件的 api 參數已經被分解，能夠直接做爲查詢 db 使用，同時也能服務於後臺請求。

離線優先與數據同步

咱們已經能夠經過配置將須要離線的接口經過offline中間件進行離線化，那麼這裏面臨着兩種數據更新方式，第一種是在線時走正常邏輯等待後臺數據返回，異步同步到本地數據庫，再進行渲染；當判斷離線時，從本地讀取。還有一種是具有樂觀UI的思惟，配置了離線的接口，優先從本地進行數據操做，渲染UI，而後再將服務端數據與本地數據進行同步。顯然，後者離線優先的方案顯得更爲明智。

數據同步分爲本地向後臺同步，和後臺向本地同步。後者須要增長增量變動的邏輯，用於解決離線下用戶數據因爲其餘緣由發生的變動，好比當用戶登陸多臺設備數據移動、刪除等場景（前端離線增量變動涉及不少細節及業務相關考慮點，這裏暫不細述）。

如何記錄本地的數據變動而後同步到後臺呢？這裏咱們須要定義一個數據變動的抽象，好比Change

裏面功能主要是定義變動類型，字段等。每次抵達offline中間件的數據經過一個數據同步管理器對變動進行註冊，待合適的時機再去同步。數據同步管理器主要接受change，進行diff管理，判斷數據是否有變化，及去重管理，最後再觸發異步同步任務。同步可能會失敗，這裏的超時，重試，失敗退回處理都須要加以注意，保證同步的事務性。

儲存安全

儲存安全包括數據加密安全和儲存大小問題。對於對稱加密，前端查看，客戶端必需要知道密匙，密匙自己繞不開加密的問題，理論上，不和服務端通訊的離線狀態，任何可以在前端可以離線下查看的數據，無論採用什麼加密手段，數據都能被還原。純前端數據加密並沒有可靠性，可是訪問權限能夠依賴於IndexDB瀏覽器同源策略進行數據安全隔離。避免明文儲存和加大數據直接還原的難度纔是思考的方向。

有一個容易忽視的安全問題是 iframe, 它能夠訪問它所嵌入的源的 IndexedDB 庫，因此咱們須要保證頁面所有資源可信任。

採用IndexDB 的儲存方案涉及到一個儲存大小問題，瀏覽器的最大存儲空間是動態的，總共爲可用磁盤空間的50％，每一個站點爲所用空間的20%，超出限制的寫入將致使數據被刪除，而且導嚴重在的數據丟失。由於從瀏覽器自己沒法直接獲取到 IndexDB 儲存空間（以字符串方式計算性能不可靠，也極不許確），從產品統計角度，限制儲存條數是一直思路之一，固然更好的方案是採用端上儲存好比larveldb，杜絕此類數據丟失現象。對於純 web 端，採用瀏覽器插件拓展的形式也值得嘗試（好比 Google doc），更合理的保證數據安全。