Glide 三级缓存的简单分析

这是一个简易的流程图，磁盘缓存如果访问到了就会复制给活动缓存，而内存缓存会剪切到活动缓存当中，那么问题来了，这个流程是如何实现的？好处在哪？

活动缓存是为了防止正在访问的过程当中被删除而创建的缓存

当 onDestory的时候会把活动缓存释放到内存缓存里面

而Http请求到的bitmap会在请求后放到内存缓存

那么，如何实现这种缓存机制？

LRU 最近最少没有使用算法 大致流程入下图所示

 Glide就是利用了LinkedHashMap来创建了这个机制

 put的时候如果大于的时候就会移除

 而移除的时候如果被移除了就会出问题，这个时候就要使用一个非LRU的活动缓存

如果进程被杀死两个缓存都会不存在

活动缓存里的数据是弱引用的

遗漏的流程关于磁盘缓存 如下图

 有可能获取到的磁盘缓存的策略，那么就不会走网络流程而是走磁盘缓存的流程

那么为什么LRU使用LinkHashmap？好处在哪？

LinkedHashMap 使用双向链表来维护插入顺序或者访问顺序，具体取决于构造函数中传入的参数。这是因为 LinkedHashMap 不仅要维护键值对的映射关系，还要维护插入顺序或者访问顺序，这些顺序需要随时更新。使用双向链表可以方便地在链表中插入或删除元素，以及在链表中移动元素的位置，这样就可以快速地更新顺序。

具体来说，每个 Entry 在 LinkedHashMap 中都是一个双向链表的节点，包含两个指针：before 和 after，分别指向前一个节点和后一个节点。当一个元素被插入到 LinkedHashMap 中时，它会被添加到双向链表的末尾；当一个元素被访问时，它会被移动到双向链表的末尾。这样，最近访问的元素就会排在链表的末尾，最早访问的元素就会排在链表的头部。当需要删除元素时，只需要将该元素在链表中的节点删除即可，这样就可以快速地更新顺序，而不需要遍历整个链表。

因此，使用双向链表可以使 LinkedHashMap 在维护插入顺序或者访问顺序时具有较高的性能。

那么handler Message为什么使用单向列表？

Handler message 是使用单向链表实现的。在 Android 系统中，每个 Handler 都有一个 MessageQueue，用于存放 Message 对象。当 post 一个 Runnable 或者发送一个 Message 到 Handler 时，该 Runnable 或者 Message 会被封装成一个 Message 对象并被插入到 MessageQueue 的末尾。当 Handler 处理消息时，它会从 MessageQueue 的头部取出一个 Message，处理完后再从头部取出下一个 Message，以此类推。由于 MessageQueue 中的 Message 对象是按照插入顺序进行管理的，因此单向链表就足够了。

glide磁盘缓存最大容积是多少，怎么实现的？

Glide 的磁盘缓存最大容量默认是 250MB，可以通过 `DiskCache.Factory` 来进行配置。具体实现是通过 `DiskLruCacheFactory` 类来实现的。

`DiskLruCacheFactory` 类继承自 `DiskCache.Factory`，实现了 `DiskCache.Factory` 中的 `build()` 方法。在 `build()` 方法中，会根据传入的文件夹路径、最大缓存容量和版本号来创建一个 `DiskLruCacheWrapper` 对象，然后将其封装成一个 `DiskCache` 对象返回。

其中，最大缓存容量是通过 `DiskLruCacheFactory` 的构造函数传入的，如果没有指定，默认是 250MB。在创建 `DiskLruCacheWrapper` 对象时，会将该值传递给 `DiskLruCache` 的构造函数，从而限制磁盘缓存的最大容量。

需要注意的是，由于 Glide 的磁盘缓存是基于 LRU 策略实现的，因此实际占用的磁盘空间可能会超过最大缓存容量。如果需要进一步控制磁盘缓存的空间占用，可以通过调用 `DiskCache.clear()` 方法来手动清理过期或不需要的缓存。

那为什么是250m？

Glide 磁盘缓存大小设计成 250MB 的原因是为了在磁盘缓存的容量和缓存效率之间取得一个平衡点，同时也考虑到了设备存储空间的限制和使用体验的需求。

具体来说，Glide 的磁盘缓存是通过将图片文件存储在设备的内部存储或外部存储中来实现的。为了避免磁盘缓存占用过多存储空间，Glide 设计了一个默认的磁盘缓存大小限制，即 250MB。这个大小限制可以通过设置 DiskCacheStrategy.ALL 的方式进行调整，但是建议在实际使用中根据应用的实际需求进行调整。

250MB 的磁盘缓存大小既可以满足一般应用的图片加载需求，又可以避免占用过多的存储空间，从而提高应用的使用体验。同时，Glide 还提供了缓存清理和自动清理机制，可以帮助开发者更好地管理磁盘缓存，避免缓存占用过多存储空间和影响应用性能。

总之，Glide 磁盘缓存大小设计成 250MB 可以在磁盘缓存容量和缓存效率之间取得一个平衡点，同时也考虑到了设备存储空间的限制和使用体验的需求。开发者在使用 Glide 进行图片加载时，可以根据应用的实际需求进行磁盘缓存大小的调整。

举例来说，一款社交应用可能需要处理大量的用户头像、动态图片等资源，这些资源通常需要频繁地加载和显示，因此需要设置较大的磁盘缓存大小来减少重新加载的频率，提高用户体验。同时，社交应用的用户量通常很大，因此需要考虑磁盘缓存占用过多存储空间的问题，建议在 200MB ~ 500MB 之间进行设置，同时可以通过定期清理或者自动清理机制来管理磁盘缓存。

另外一个例子是一款电商应用，这种应用通常需要处理大量的商品图片、广告图片等资源，这些资源通常不需要频繁地加载和显示，因此可以设置较小的磁盘缓存大小来减少磁盘占用和提高缓存效率。同时，电商应用的用户量也比较大，因此需要考虑磁盘缓存占用过多存储空间的问题，建议在 100MB ~ 300MB 之间进行设置，同时可以通过定期清理或者自动清理机制来管理磁盘缓存。

总之，不同的应用可能需要不同大小的磁盘缓存，需要根据应用的实际需求和设备的存储空间情况来进行设置。同时，需要注意磁盘缓存占用过多存储空间的问题，建议通过定期清理或者自动清理机制来管理磁盘缓存。