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

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

watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvb3BlbmdsbmV3YmVl/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/SouthEast" alt="">

版权声明：本文博主原创文章。如需转载，请发送电子邮件至openglnewbee@163.com。