2019就在眼前了，明天会更好，么？...
上次啊咱读了memoryCache，十分无趣，今天来看点更无趣的，没错啦就是人贱人爱的bitmapPool...
说是让你能够重复使用的bitmap...好吧，看看实现...
前两个都是废物，直接看LruBitmapPool...
这十分陌生啊，一脸懵逼...好吧，世上无难事只要肯放弃，咱弄简单点，装逼的方式简单点，看这个名字貌似是用LRU算法管理bitmap，保证这个bitmap的池子不超过最大限制，而这里用的LRU算法主要是LruPoolStrategy这个类提供，所以咱先去瞧瞧...
这...还是看实现吧...
哟呵，还分版本，大于4.4用SizeConfigStrategy小于用AttributeStrategy，看来SizeConfigStrategy要高级一点嘛，既然它要高级一点，那么我们就先看看AttributeStrategy，毕竟人也是由低级到高级进化而来的嘛（不一定哟）
可以看到这个属性策略类，主要是通过keyPool获取key，然后通过这个key从GroupedLinkedMap里取或者存bitmap，而这个keyPool里面是一个Queue，这个Queue里存储的key通过Bitmap的width, height,config保持唯一性。而这个GroupedLinkedMap内部维护了LRU算法，但是它不是单纯的LRU算法，对一点不单纯...
它说它维护的是最近最少使用的bitmap大小而不是最近最少使用的bitmap对象，当内存吃不消的时候这哥们会干掉最近最少使用的bitmap大小的那个bitmap，不错吧，LRU活学活用呀。
接下来看看SizeConfigStrategy:
可以看到SizeConfigStrategy在KeyPool和GroupedLinkedMap的基础上多了一个sortedSizes的HashMap，这个sortedSizes主要是通过Bitmap的config维护一个排序的size。另外这里的KeyPool不像AttributeStrategy的KeyPool那样通过Bitmap的width, height,config控制key,这里的keyPool是通过bitmap的size和config控制的
好，熟悉这些陌生的对象之后我们回到LruBitmapPool，我们看看它的核心方法put和get：
可以看到，先校验，不合法抛异常，超过限制大小就回收，然后就put到strategy里，计数器和大小该加的加，然后有一行莫名其妙的代码tracker.add(bitmap);这tracker是什么玩意儿？
好吧，这是个废物玩意儿，跟glide没几毛钱关系。
另外put里还有两个方法dump()和evict()：
dump也是个废物
evict就是调整大小
然后来看get方法：
先从getDirtyOrNull这个方法取，不为空就擦一下颜色直接返回，为空就创建返回。接着看看这个getDirtyOrNull
先从缓存策略里取，为空就记录丢失状态，不为空就更新命中状态和大小然后返回结果。
好了看到这里我们知道了LruBitmapPool就是一个通过LRU算法保证内存中的bitmap不超过限制大小的管理类。
到此LruBitmapPool又读完了，没有学到任何东西，没关系，我们已经迈出了一小步，正所谓万丈高楼平地起，接下来我要下班接2019去了，下期再见。
