移动应用开发（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.在訪问磁盘缓存/网络资源成功时。需要填充高优先级的缓存。当磁盘缓存訪问成功时。填充内存缓存；当网络资源訪问成功时，填充内存缓存＋磁盘缓存。

对于详细的使用场合咱们可以依据业务需要来决定是否採纳或部分採纳此方案，也可以对此方案中的一些策略依据项目需要进行改动（比方什么时候不訪问磁盘缓存、什么时候清空缓存、什么时候强制刷新缓存等）。来知足业务需求。