一.簡單介紹
client快取機制不僅能夠減輕server端的壓力，同一時候也能讓使用者在網速較慢的情況下獲取良好的使用者體驗。
所以構建一個優秀的APP,快取是非常重要的一個環節。
二.處理方案
client從server獲取最新資料，假如是20條，同一時候將資料快取到本地，當載入下一頁資料時不僅將資料加入到記憶體中。還要同步到快取中。
這樣以此類推，記憶體中的資料和快取的資料保持一致。
當使用者又一次下拉重新整理介面時，會出現兩種情況：
一種是此時使用者資料更改小於一頁。另外一種是使用者資料更改大於一頁。
第一種情況比較簡單。資料變動小於一頁。說明重新整理返回的資料加上快取的資料就能夠構建出使用者的所有資料，所以此時僅僅須要合併重新整理返回的最新資料和快取的資料，將反覆的資料去掉就可以。
另外一種情況比較複雜。資料變動大於一頁，說明重新整理返回資料和快取資料之間還遺漏了部分的資料，那怎樣去同步這部分的資料呢？
簡單的方案是，假設出現這樣的情況，則重構快取。重構快取的意思就是刪除舊的快取資訊又一次加入建立快取。這個方法的長處就是實現簡單不easy出錯，當然缺點就是假設頻繁的重構快取則失去了快取的意義。
真正的解決中間資料獲取的問題。能夠通過新建暫時的陣列的方式。將當前在記憶體中的資料放入暫時的變數中，然後把重新整理返回的資料增加記憶體中，當使用者觸發載入很多其它事件時，推斷最新返回的資料是不是和暫時變數中的資料有重合，有重合說明中間的遺漏資料已經獲取完成，則將暫時變數的資料合併到記憶體中就可以。當然記憶體中的操作都須要同步到快取中。
使用者每次又一次進入該模組都會先從快取中載入資料到記憶體，然後自己主動獲取最新的資料與記憶體中的資料合併就可以。
若使用者網路不通的情況下直接展示快取資料。
三.問題
上述方案中會遇到下面幾個問題：- 載入很多其它時。傳入分頁的page和size，當使用者資料頻繁的更新時。會出現冗餘的資料，比方第一頁的最後兩條可能就是第二頁的前兩條。
- 同步問題，在有些業務中，資料大部分是不變的，可是有些資料是會變化的，比方在微博中，微博內容不會變化，可是轉發條數，評論數是在變化的。假設只展示快取中的資料會出現和server端不同步的問題
- 快取沒有一個清理功能。隨著時間的增長，總會出現記憶體溢位的情況
解決：
問題1：獲取資料時分頁中增加sinceID和maxID。用以來控制最大和最小的資料ID。這樣就能防止冗餘的反覆資料
問題2：對於頻繁的小資料塊（如閱讀數。分享數）能夠制定同步協議，更新這些小資料塊時無需更新總體的資料
問題3：記憶體的增長能夠通過限制快取的條數來控制，當快取條數超過限制後。為使用者重構快取（大資料塊的更新也能夠通過定時重構快取來實現）
異常處理：
網路異常--顯示快取資料
記憶體溢位--限制快取條數