資料層，是三層架構中的最底層，負責資料的管理。它主要的任務就是：
呼叫網路api，獲取資料；
將資料快取到本地；
將資料交付給上一層。
根據這三個任務，資料層可以再拆分為三層：網路層、本地資料層、交付層。
網路層主要就是對網路api的封裝。關於api的設計，該系列的第一篇文章介面的設計已經講過一些。關於如何封裝，可以參考android專案重構之路系列的架構篇和實現篇，其中介面層和本文的網路層是一樣的。
還有一些在前面的文章中沒有提及到的，在此做一些補充。
其次，為了節省流量，介面的設計上可以對資料進行簡化。例如，對於一些列表類的介面，可以這麼設計：只返回更新的部分，比如，上一次請求返回了10條按時間排序的資料，第一條資料為最新的，id為101，當發起下一次請求時，將101的id作為引數呼叫api，api查到該id，發現該id之後又新增了兩條資料，api則只返回新增的這兩條資料。
另外，為了保證程式的健壯性，呼叫api時，對入參的合法性檢查也是很有必要的。而且，也應該定義好本地的錯誤碼和錯誤資訊，保證每個錯誤都能正常解析。
本地資料層主要就是做快取處理，這需要設計好一套快取策略。設計快取策略時，有幾個問題需要考慮清楚：
哪些需要快取？哪些不需要快取？
快取在**？資料庫？檔案？還是記憶體？
快取時間多長？
哪些需要快取？
快取在**？從記憶體讀取資料是最快的，但記憶體非常有限。因此，記憶體一般只用來快取使用頻率非常高的資料。
資料庫可以儲存大量資料，主要就是用於儲存商品列表、聊天記錄之類的關係型資料。
然而，不管快取在**，都需要限定好快取的容量，要定期清理，不然會越積越多。
快取時間多長？首先，每份快取資料都應該設定乙個快取的有效時間，有效期的起始時間以最後一次被呼叫的時間為準，當該資料長時間沒有再被呼叫到時，就應該從快取中清理掉。
快取的有效時間應該設多長呢？可以短至一分鐘，長至一星期甚至乙個月，具體因資料而異。一般記憶體的快取時間不宜太長，程式退出基本就要全部清理了。檔案快取可以設定保留一天或乙個星期，可以每隔一天清理一次。資料庫快取再久一些也無所謂，但最好還是不要超過乙個月。
交付層其實就是乙個向上層開放的互動介面層，是上層向資料層獲取資料的入口。上層向資料層請求資料，它是不關心資料層的資料是從快取獲取還是從網路獲取的，它只關心結果，資料層能給到它想要的資料結果就ok了。因此，交付層主要就是定義一堆開放的介面或協議。
App架構設計經驗談 資料層的設計
寫於2016 01 07 使用者用密碼登入成功後，伺服器返回token給客戶端 客戶端將token儲存在本地，發起後續的相關請求時，將token發回給伺服器 伺服器檢查token的有效性，有效則返回資料，若無效，分兩種情況 然而，此種驗證方式存在乙個安全性問題 當登入介面被劫持時，黑客就獲取到了使用...
App架構設計經驗談 展示層的設計
三層架構中，資料層和業務層都已經做過了簡單的分享，最後，就剩下展示層了。本篇就給各位分享下我在展示層設計方面的一些經驗心得。展示層是三層架構中最複雜的一層了，需要考慮的包括但不限於介面布局 螢幕適配 文字大小 顏色 資源 提示資訊 動畫等等。展示層也是變化最頻繁的乙個層面，每天改得最多的就是介面了。...
App架構設計經驗談 展示層的設計
三層架構中，資料層和業務層都已經做過了簡單的分享，最後，就剩下展示層了。本篇就給各位分享下我在展示層設計方面的一些經驗心得。展示層是三層架構中最複雜的一層了，需要考慮的包括但不限於介面布局 螢幕適配 文字大小 顏色 資源 提示資訊 動畫等等。展示層也是變化最頻繁的乙個層面，每天改得最多的就是介面了。...