App架構設計經驗談:資料層的設計

發表於2016-03-09

App架構設計經驗談:介面的設計
App架構設計經驗談:技術選型
App架構設計經驗談:資料層的設計
App架構設計經驗談:業務層的設計
App架構設計經驗談:展示層的設計

一個App,從根本上來說,就是對資料的處理,包括資料從哪裡來、資料如何組織、資料怎麼展示,從職責上劃分就是:資料管理、資料加工、資料展示。相對應的也就有了三層架構:資料層、業務層、展示層。本文就先講講資料層的設計。

資料層,是三層架構中的最底層,負責資料的管理。它主要的任務就是:

  1. 呼叫網路API,獲取資料;
  2. 將資料快取到本地;
  3. 將資料交付給上一層。

根據這三個任務,資料層可以再拆分為三層:網路層、本地資料層、交付層。

網路層

網路層主要就是對網路API的封裝。關於API的設計,該系列的第一篇文章介面的設計已經講過一些。關於如何封裝,可以參考Android專案重構之路系列的架構篇實現篇,其中介面層和本文的網路層是一樣的。

還有一些在前面的文章中沒有提及到的,在此做一些補充。

首先是不同網路狀態的處理。當網路不可用時,則不應該再去呼叫API;當網路可用,但不是WIFI時,有些比較耗流量的操作也應該禁止,比如上傳和下載大檔案;當網路狀態不同時,還可以採用不同的網路策略,比如,當網路為WIFI時,當前API可以返回更多更全面的資料,還可以預先載入相關聯的其他API。

其次,為了節省流量,介面的設計上可以對資料進行簡化。例如,對於一些列表類的介面,可以這麼設計:只返回更新的部分,比如,上一次請求返回了10條按時間排序的資料,第一條資料為最新的,id為101,當發起下一次請求時,將101的id作為引數呼叫API,API查到該id,發現該id之後又新增了兩條資料,API則只返回新增的這兩條資料。

另外,為了保證程式的健壯性,呼叫API時,對入參的合法性檢查也是很有必要的。而且,也應該定義好本地的錯誤碼和錯誤資訊,保證每個錯誤都能正常解析。

本地資料層

本地資料層主要就是做快取處理,這需要設計好一套快取策略。設計快取策略時,有幾個問題需要考慮清楚:

  1. 哪些需要快取?哪些不需要快取?
  2. 快取在哪裡?資料庫?檔案?還是記憶體?
  3. 快取時間多長?

哪些需要快取?

將所有資料都快取是不明智的,不同的資料應該有不同的快取策略,比如一個電商App,首頁的商品列表資料應該快取,而且快取時間應該比較長,而每個商品的詳情資料就沒必要快取或快取時間很短。對於一份資料需不需要快取,判斷標準可以是:使用者檢視該資料的頻率高不高?首頁商品列表是使用者每次啟動都會看到的,而每個商品的詳情使用者最多隻看幾次。

快取在哪裡?

從記憶體讀取資料是最快的,但記憶體非常有限。因此,記憶體一般只用來快取使用頻率非常高的資料。

檔案快取主要就是圖片、音訊、視訊了。

資料庫可以儲存大量資料,主要就是用於儲存商品列表、聊天記錄之類的關係型資料。

然而,不管快取在哪裡,都需要限定好快取的容量,要定期清理,不然會越積越多。

快取時間多長?

首先,每份快取資料都應該設定一個快取的有效時間,有效期的起始時間以最後一次被呼叫的時間為準,當該資料長時間沒有再被呼叫到時,就應該從快取中清理掉。

快取的有效時間應該設多長呢?可以短至一分鐘,長至一星期甚至一個月,具體因資料而異。一般記憶體的快取時間不宜太長,程式退出基本就要全部清理了。檔案快取可以設定保留一天或一個星期,可以每隔一天清理一次。資料庫快取再久一些也無所謂,但最好還是不要超過一個月。

交付層

交付層其實就是一個向上層開放的互動介面層,是上層向資料層獲取資料的入口。上層向資料層請求資料,它是不關心資料層的資料是從快取獲取還是從網路獲取的,它只關心結果,資料層能給到它想要的資料結果就OK了。因此,交付層主要就是定義一堆開放的介面或協議。

如果介面或協議非常多,那麼,將介面或協議按照模組劃分也是有必要的。比如微信,按模組劃分有:IM、公眾號、朋友圈、錢包、購物、遊戲等等。模組之間應該儘量相對獨立、鬆耦合。

寫在最後

資料層如果再擴充套件,還可以再加入日誌管理,這裡就不再展開講了。上面內容講得也比較亂,有哪裡講得不好的地方歡迎吐槽。

相關文章