原文同时发表在作者的个人博客，欢迎访问：http://www.koulianbing.com/?p=23
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、数据同步是一个常见但重要的问题，需要做好预防。