移動應用開發（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.在通路磁盤緩存/網絡資源成功時，需要填充高優先級的緩存，當磁盤緩存通路成功時，填充記憶體緩存；當網絡資源通路成功時，填充記憶體緩存＋磁盤緩存。

對于具體的使用場合我們可以根據業務需要來決定是否采納或部分采納此方案，也可以對此方案中的一些政策根據項目需要進行修改（比如何時不通路磁盤緩存、何時清空緩存、何時強制重新整理緩存等），來滿足業務需求。