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（其中保存的是键值