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、公眾號、朋友圈、錢包、購物、游戲等等。模塊之間應該盡量相對獨立、松耦合。

寫在最后

數據層如果再擴展，還可以再加入日志管理，這里就不再展開講了。上面內容講得也比較亂，有哪里講得不好的地方歡迎吐槽。

掃描以下二維碼即可關注訂閱號。