App架構設計經驗談:介面的設計
App架構設計經驗談:技術選型
App架構設計經驗談:資料層的設計
App架構設計經驗談:業務層的設計
App架構設計經驗談:展示層的設計
一個App，從根本上來說，就是對資料的處理，包括資料從哪裡來、資料如何組織、資料怎麼展示，從職責上劃分就是：資料管理、資料加工、資料展示。相對應的也就有了三層架構：資料層、業務層、展示層。本文就先講講資料層的設計。
資料層，是三層架構中的最底層，負責資料的管理。它主要的任務就是：
- 呼叫網路API，獲取資料；
- 將資料快取到本地；
- 將資料交付給上一層。
根據這三個任務，資料層可以再拆分為三層：網路層、本地資料層、交付層。
網路層
網路層主要就是對網路API的封裝。關於API的設計，該系列的第一篇文章介面的設計已經講過一些。關於如何封裝，可以參考Android專案重構之路系列的架構篇和實現篇，其中介面層和本文的網路層是一樣的。
還有一些在前面的文章中沒有提及到的，在此做一些補充。
首先是不同網路狀態的處理。當網路不可用時，則不應該再去呼叫API；當網路可用，但不是WIFI時，有些比較耗流量的操作也應該禁止，比如上傳和下載大檔案；當網路狀態不同時，還可以採用不同的網路策略，比如，當網路為WIFI時，當前API可以返回更多更全面的資料，還可以預先載入相關聯的其他API。
其次，為了節省流量，介面的設計上可以對資料進行簡化。例如，對於一些列表類的介面，可以這麼設計：只返回更新的部分，比如，上一次請求返回了10條按時間排序的資料，第一條資料為最新的，id為101，當發起下一次請求時，將101的id作為引數呼叫API，API查到該id，發現該id之後又新增了兩條資料，API則只返回新增的這兩條資料。
另外，為了保證程式的健壯性，呼叫API時，對入參的合法性檢查也是很有必要的。而且，也應該定義好本地的錯誤碼和錯誤資訊，保證每個錯誤都能正常解析。
本地資料層
本地資料層主要就是做快取處理，這需要設計好一套快取策略。設計快取策略時，有幾個問題需要考慮清楚：
- 哪些需要快取？哪些不需要快取？
- 快取在哪裡？資料庫？檔案？還是記憶體？
- 快取時間多長？
哪些需要快取？
將所有資料都快取是不明智的，不同的資料應該有不同的快取策略，比如一個電商App，首頁的商品列表資料應該快取，而且快取時間應該比較長，而每個商品的詳情資料就沒必要快取或快取時間很短。對於一份資料需不需要快取，判斷標準可以是：使用者檢視該資料的頻率高不高？首頁商品列表是使用者每次啟動都會看到的，而每個商品的詳情使用者最多隻看幾次。
快取在哪裡？
從記憶體讀取資料是最快的，但記憶體非常有限。因此，記憶體一般只用來快取使用頻率非常高的資料。
檔案快取主要就是圖片、音訊、視訊了。
資料庫可以儲存大量資料，主要就是用於儲存商品列表、聊天記錄之類的關係型資料。
然而，不管快取在哪裡，都需要限定好快取的容量，要定期清理，不然會越積越多。
快取時間多長？
首先，每份快取資料都應該設定一個快取的有效時間，有效期的起始時間以最後一次被呼叫的時間為準，當該資料長時間沒有再被呼叫到時，就應該從快取中清理掉。
快取的有效時間應該設多長呢？可以短至一分鐘，長至一星期甚至一個月，具體因資料而異。一般記憶體的快取時間不宜太長，程式退出基本就要全部清理了。檔案快取可以設定保留一天或一個星期，可以每隔一天清理一次。資料庫快取再久一些也無所謂，但最好還是不要超過一個月。
交付層
交付層其實就是一個向上層開放的互動介面層，是上層向資料層獲取資料的入口。上層向資料層請求資料，它是不關心資料層的資料是從快取獲取還是從網路獲取的，它只關心結果，資料層能給到它想要的資料結果就OK了。因此，交付層主要就是定義一堆開放的介面或協議。
如果介面或協議非常多，那麼，將介面或協議按照模組劃分也是有必要的。比如微信，按模組劃分有：IM、公眾號、朋友圈、錢包、購物、遊戲等等。模組之間應該儘量相對獨立、鬆耦合。
寫在最後
資料層如果再擴充套件，還可以再加入日誌管理，這裡就不再展開講了。上面內容講得也比較亂，有哪裡講得不好的地方歡迎吐槽。