移動應用開發（IOS/android等一下）在通常圖像緩存方案評述(附流程圖)

在移動應用開發。咱們常常從網絡請求到該設備顯示遇到的場景圖片。

假設屢次發動每一個請求，廢物流、浪費電。；

將圖片持久化到磁盤也不失爲一種策略；但每次從文件讀取圖片也存在必定的io開銷，就算採用此策略，咱們也需要控制磁盤緩存的容量。以避免佔用過多系統資源。

事實上沒有一個方案可以說是完美的方案，僅僅有最適合本身業務需求的方案。才幹夠說是一個好方案。

咱們如下所解說的方案具有很是強的通用性，設計思路簡單而清晰：

1.若是每個網絡圖片的url具備惟一性。若是網絡上的圖片變化了，會引發輸入源的url變化；

2.基於1，咱們將url做爲圖片緩存的惟一標識（可以作hash,作md5,也可以用urlstring做爲key，都是可以的）

3.訪問優先級：內存緩存>磁盤緩存>網絡資源

以上3點就是咱們這個方法的基本策略。下面是技術細節：

1.對於緩存的管理，咱們可以設置閥值（包含緩存存在時間和緩存容量），達到條件觸發清理；還可以結合LRU(Least Recently Used 最近最少使用算法)算法來提高緩存訪問效率,這需要在寫緩存時對緩存的使用次數進行對應標記，此處對此算法不展開，有興趣的自行google.

2.對於網絡資源的載入咱們必須採用異步的方案，如此作纔不會堵塞ui的展現；可以將請求加到隊列中支持併發請求，需要注意的是咱們可以依據某個地址可以支持同一時候鏈接的url數量來設置最大併發請求數目。來提升效率。

3.在訪問磁盤緩存/網絡資源成功時。需要填充高優先級的緩存。當磁盤緩存訪問成功時。填充內存緩存；當網絡資源訪問成功時，填充內存緩存＋磁盤緩存。

對於詳細的使用場合咱們可以依據業務需要來決定是否採納或部分採納此方案，也可以對此方案中的一些策略依據項目需要進行改動（比方什麼時候不訪問磁盤緩存、什麼時候清空緩存、什麼時候強制刷新緩存等）。來知足業務需求。