App運行過程中會產生很多隨機、零碎、無固定結構的數據，這些數據重要性、數據量多變，是數據管理的一個難點。這裡分享一下筆者這幾年常用到的一些多級Cache策略。

面前上面提到的這些問題，梳理一下我們要達到的目標：隨機存取，數據非結構化，數據按重要性分級。

1、為實現隨機存取，需要建立二級Cache。先定義固定大小的LRU策略的內存Cache，讀取數據先從內存Cache讀，如果沒有命中，再從 Flash上讀。存儲數據時，先寫到內存Cache，再進一步在後台把數據刷新到Flash。至於內存Cache的實現，Android上面的 LruCache，IOS上面的NSCache都是很好的方案。

避免數據沖突，版本兼容性問題，需要為每次存取設定唯一不變的Key。 根據Cache數據量大小，Flash上面的存儲策略有兩種選擇。如果需要Cache的數據少而大，可以為Cache中的每個Item建立一個文件，在 Key和文件Path之間建立起映射。如果需要Cache的數據多而小，可以把所有數據存儲在一個文件中，以數據在文件中的位置建立起索引。可以視具體情 況看使用哪種策略。 2、由於作為操作目標的數據結構多變，我通常選擇以二進制為存取目標。 3、數據按重要性分為可丟失的和永久性的，分別建立不同的Flash存儲策略。針對可丟失的數據，控制緩存數據總量，避免緩存文件過多過大。 這裡說幾個可能會出現瓶頸的地方： 1、讀取數據，如果沒有命中內存Cache，會從Flash上面直接讀取。這裡存在UI線程操作IO的風險，如果管理不善，可能出現莫名其妙卡頓的現象。 每次出現這種情況時，筆者都會記錄IO時間，並設置安全阈值，如果超過阈值會做數據上報。從數據觀察來看，這裡不構成實現問題，這與日趨完善的Flash 技術是分不開的，畢竟手機ROM的質量是幾年前市場上到處飛的幾十塊錢SDCard沒法比的。 2、把數據從內存Cache刷新到Flash的頻率控制上。筆者在使用過程中，沒有碰到過短時間Cache大量更新的情況，也就沒有集中爆發的Flush任務，使用後台單任務執行隊列足夠了，這樣既避免了內存波動，也規避了Flush時的文件操作同步問題。 3、如果在比較特殊的業務場景中碰到一些緩存的數據量特別大，建議直接使用普通的文件存取邏輯，老老實實的顯示Loading，然後開後台線程執行任務。 4、數據同步是一個常見但重要的問題，需要做好預防。