8102年就要过去了，好嗨哦，我7102年的计划都还没写呢，TMD挣钱如捉鬼，为什么，为什么...
上期读了engine，上期为什么没有读context，为什么，为什么...，现在先去看看这个context...
这TM就是applicationContext，没什么好看的，难怪上期没去读它，原来机智的我早已看穿了一切...不过源码里有一个glide全局的GlideContext，后面再看吧，按计划走吧，今天应该看memoryCache。
这是一个在内存中管理资源添加和移除的接口，下面去看它的实现...
先看第一个...
嗯，继承经典的LruCache，点进去瞧瞧...
嗯，LinkedHashMap,大家都十分的熟悉了是吧...
接着看这个LruCache的三个重要方法...
get没什么说的，通过key从LinkedHashMap里取就是了，remove也没什么说的，通过key从LinkedHashMap删，然后当前map的大小currentSize-1就是了。来看看这个put,第一句代码：final int itemSize = getSize(item);所以itemSize=1；真是愚蠢的代码（没有领悟为啥这样写，先骂再说）。
看第二行代码：
如果1>=maxSize就移除刚才准备put的那个resource，
这个maxSize与用户自定义LinkedHashMap的初始容量和扩容因子有关，所以第二行代码也只是确保LinkedHashMap的边界正确。
再看put方法的第三行代码：当前LinkedHashMap的size加一，理所当然，没什么好说的。
接着往下看：
这是直接把要put的item放到LinkedHashMap里，然后看put的结果，如果不为null，说明当前要put的key已经put过了，当前size要减一，如果put的结果不等于item，说明当前的key要put的这个item是一个新值，所以要把这个key原来的值old删掉。如果不明白，作个实验
put完之后调用了evict()方法，我们来看看它
这就是传说中的LRU了，可以看到，如果调用put方法之后，当前size大于了map的最大size，这个时候需要删除资源，删哪一个呢？根据LRU的思想需要删除最近最少使用的元素，那么在这个LinkedHashMap中哪些是最近最少使用的呢，从上面的trimToSize方法中可以看到它是从这个LinkedHashMap的第一个元素开始删的(虽然作者故作聪明命名为last)，这个就涉及到LinkedHashMap内部维护LRU算法的逻辑了，作个实验：
可以看到当把LinkedHashMap的accessOrder置为true时，它就是按LRU算法维护元素顺序的，当我们使用一次map中的a元素后，a元素被放到了LinkedHashMap逻辑顺序的最后，所以LinkedHashMap里最近最少使用的元素是从头到尾依次排列的，这也就是为什么上面trimToSize方法要按从头到尾的顺序删。
OK，了解这个LRUCache后，LruResourceCache就好理解了，它就是实现了MemoryCache接口的方法，加了一个删除资源的监听ResourceRemovedListener，然后MemoryCacheAdapter也是如此...至于LinkedHashMap内部LRU实现细节以后有时间了单独写一篇，敬请期待（不期待也无所谓...）。
到此memoryCache又读完了，没有学到任何东西，没关系，我们已经迈出了一小步，正所谓万丈高楼平地起，接下来我先去吃饭，下期再见。
网友评论