前言
幾乎所有的項目都做了緩存，但是緩存做的怎麼樣，其實隻有我們自己知道。緩存做的好，沒有網絡也能流暢的使用；再多的資料請求都不會出現卡頓延遲等待很久的情況。
程式中除了圖檔緩存（三級緩存），還有資訊緩存。當使用者無法聯網時，app會預設顯示緩存的資料。
前言緩存方式
SQLite
下載下傳完資料檔案後，把檔案的相關資訊如url，路經，下載下傳時間，過期時間等存放到資料庫，把url作為唯一的辨別。下次下載下傳的時候根據url先從資料庫中查詢，如果查詢到目前時間并未過期，就根據路徑讀取本地檔案，進而實作緩存的效果。
檔案緩存使用File.lastModified()方法得到檔案的最後修改時間，與目前時間判斷是否過期，進而實作緩存效果。資料格式為JSON。
緩存方式兩點說明
1、不同類型的檔案的緩存時間不一樣。籠統的說，不變檔案的緩存時間是永久，變化檔案的緩存時間是最大忍受不變時間。說白點，圖檔檔案内容是不變的，一般存在SD卡上直到被清理，我們是可以永遠讀取緩存的。配置檔案内容是可能更新的，需要設定一個可接受的緩存時間。
2、不同環境下的緩存時間标準不一樣。無網絡環境下，我們隻能讀取緩存檔案，為了應用有東西顯示，沒有什麼過期之說了。
WiFi
網絡環境下，緩存時間可以設定短一點，一是網速較快，而是流量不要錢。
3G
流量環境下，緩存時間可以設定長一點，節省流量，而且使用者體驗也更好。
緩存時間
app中多個頁面的緩存時間是不一樣的，對實時性要求高的頁面緩存時間較短。而http消息頭中包含有緩存時間，android端無需自己記錄/規定緩存時間，讀取即可。
http協定對緩存的支援
Expires & Cache-Control
Expires響應首部給出了響應失效的絕對時間,這樣用戶端就可以緩存一份副本,在這個時間到期之前,
不用去詢問伺服器它是否有效了。http1.0引入。 例:Expires: Thu, 03 Oct 1997 17:15:00 GMT
Cache-Control首部用于傳輸對象的緩存資訊。http1.1引入。它的值是一個緩存指令，給出了與某個對象可緩存性有關的特有指令。這個首部可以出現在請求或者響應頭中。例如:Cache-Control: no-cache
CacheControl
有兩個字段表達響應的過期時間：max-age和max-stale
前者表示：max-age秒内，網頁再有請求，你不要來我服務端，直接取你本地緩存的結果好了
後者表示：max-stale秒内的請求，你可以使用本地緩存的，但還是要來我服務端問問，到底行不行，當然，這裡要帶上Last Modified等資訊 ，如果服務端傳回了304，那說明你本地緩存繼續用吧，我不給你響應體200的話，自然就帶上了響應體。
Expires和Cache-Control作用一緻，都是指目前資源的有效期，控制是直接從緩存擷取資料還是重新發送請求到伺服器取資料。
緩存算法
1、LRU - 最近最少使用（最後通路時間）替換掉最近被請求最少的文檔。這一傳統政策在實際中應用最廣。在CPU緩存淘汰和虛拟記憶體系統中效果較好。
2、LRU-K
LRU-K
中的K代表最近使用的次數，也可以認為是LRU-1。LRU-K的主要目的是為了解決LRU算法“緩存污染”的問題，其核心思想是将“最近使用過1次”的判斷标準擴充為“最近使用過K次”。相比LRU，LRU-K需要多元護一個隊列，用于記錄所有緩存資料被通路的曆史。隻有當資料的通路次數達到K次的時候，才将資料放入緩存。當需要淘汰資料時，LRU-K會淘汰第K次通路時間距目前時間最大的資料。如下：
1. LFU - 最不經常使用（通路次數）替換掉通路次數最少的。這一政策意圖保留最常用的、最流行的對象，替換掉很少使用的那些。
LFU
的每個資料塊都有一個引用計數，所有資料塊按照引用計數排序，具有相同引用計數的資料塊則按照時間排序。如下：
1. SIZE（緩存大小）替換size最大的對象。這一政策通過淘汰一個大對象而不是多個小對象來提高命中率。不過，可能有些進入緩存的小對象永遠不會再被通路。SIZE政策沒有提供淘汰這類對象的機制，會導緻“緩存污染”（大量偶發性的資料通路讓記憶體中存放大量冷資料,也即是緩存污染）。
引申幾個問題，面試常被問到的問題：
1、http的緩存是怎麼做的 ？
2、用的什麼？（這個問題和線程會同問，一般問一個。）
答案請自行百度。我就不說了。因為我看過http的源碼，看過他的緩存和線程。是自定義的。大家做一個了解就行。
這個問題被問到的頻率不高。而高頻問的一般是這種問題：有一個網絡請求，有很多資料（比如一年，兩年，每天的資料都要請求出來），然後拿到資料後做處理，然後recycleview（或listview）展示出來。像這種請求由于資料很多， 會有一段時間的等待，導緻頁面UI資料延遲的情況的解決方案。大家心裡要做一個準備。
原文釋出時間為：2018-11-13
本文作者：小餅幹也有夢想
本文來自雲栖社群合作夥伴“
終端研發部”，了解相關資訊可以關注“
”。