LruCache的实现原理(图片三级缓存)

官方建议使用lrucache进行内存缓存。Lrucache底层实际是维护的一个linkedHashMap集合(他是hashmap的一个子类,可以保证存入和取出顺序的集合,与hashmap不同的是他是一个双向链表从Android2.3以后,系统GC操作更加频繁,所以软引用和弱引用的资源很容易被回收。Android的结构,内部会定义两个属性分别为before和after,用于记录元素的位置;而haspmap是一个单向的链表结构),他有一个关键的方法就是在我们向lrucache中存储元素的时候,会先去将该元素所占空间大小与lrucache中所有元素的所占空间求和,然后和我们设置的最大可用存储内存进行比较,如果超过我们设置的最大值,就会将最近最少使用的元素删除以腾挪空间,每当我们获取元素时,会将原位置的元素进行删除,然后重新在表头将获取的元素进行插入。

注意:DiskLruCache不是Google官方的,需要从github上下载放入工程中,在获取DiskLruCache实例的时候,方法中有个参数是应用的版本号,这里注意当应用版本号改变时,DiskLruCache中的所有数据都会被清除。因为DiskLruCache认为,当应用版本号更新后,数据都应该重新从服务器获取。DiskLruCache能否正常工作,主要依赖journal这个文件,所以我们要注意调用diskLrucache的flush方法,将内存中的操作同步到journal文件,但是注意,不要频繁去同步操作,这样会消耗大量的同步时间,所以我们一般在activity的onPause生命周期中去执行disklrucache的flush方法即可。

对于journal文件,其内部有一些信息我们是可以看懂的

DIRTY 每当我们调用edit方法的时候,回向journal写入一条DIRTY记录,因为我们不知道该操作是否能成功

CLEAN 当我们调用commit方法时,会像journal写入一条CLEAN记录,表示操作成功,并在该数据后面记录该文件的大小。

REMOVE 但我们调用abort方法时,会向journal写入一条REMOVE记录,变化操作失败

也就是说每一条DIRTY后面都有一条对应的CLEAN或者REMOVE记录,要不就表示这条是脏数据,会被自动删除。

READ 当我们调用get方法时,会向journal写入一条READ记录

 

 

HashMap的实现原理

(面试过程中也经常会被问到):数组和链表组合成的链表散列结构,通过hash算法,尽量将数组中的数据分布均匀,如果hashcode相同再比较equals方法,如果equals方法返回false,那么就将数据以链表的形式存储在数组的对应位置,并将之前在该位置的数据往链表的后面移动,并记录一个next属性,来指示后移的那个数据。注意数组中保存的是entry(其中保存的是键值

你可能感兴趣的:(android)