Glide原理

• Glide在加载绑定了Activity的生命周期。
• 在Activity内新建一个无UI的Fragment，这个特殊的Fragment持有一个Lifecycle。通过Lifecycle在Fragment关键生命周期通知RequestManger进行相关的操作。
• 在生命周期onStart时继续加载，onStop时暂停加载，onDestory是停止加载任务和清除操作。

优势

• 多种图片格式的缓存，适用于更多的内容表现形式（如Gif、WebP、缩略图、Video）
• 生命周期集成（根据Activity或者Fragment的生命周期管理图片加载请求）
• 高效处理Bitmap（bitmap的复用和主动回收，减少系统回收压力）
• 高效的缓存策略，灵活（Picasso只会缓存原始尺寸的图片，Glide缓存的是多种规格），加载速度快且内存开销小（默认Bitmap格式的不同，使得内存开销是Picasso的一半）

生命周期绑定

Glide通过在当前Activity/Fragment里添加一个Fragment，在Fragment的生命周期里回调LifecycleListener的相应方法，而RequestManager实现了该接口，所以就可以在相应的生命周期执行请求的开始和暂停等操作。

图片加载策略

image.png

• 首先从ActivateResource获取，是个值为弱引用的Map
• MemoryCache和DiskCache是LruCache

缓存

三级缓存：内存缓存、硬盘缓存、网络

内存缓存 LruCache

LruCache 采用最近最少使用算法，设定一个缓存大小，当缓存达到这个大小之后，会将最老的数据移除，避免图片占用内存过大导致OOM。

• LinkHashMap 继承HashMap，在 HashMap的基础上，新增了双向链表结构，每次访问数据的时候，会更新被访问的数据的链表指针，具体就是先在链表中删除该节点，然后添加到链表头header之前，这样就保证了链表头header节点之前的数据都是最近访问的（从链表中删除并不是真的删除数据，只是移动链表指针，数据本身在map中的位置是不变的）。
• LruCache 内部用LinkHashMap存取数据，在双向链表保证数据新旧顺序的前提下，设置一个最大内存，往里面put数据的时候，当数据达到最大内存的时候，将最老的数据移除掉，保证内存不超过设定的最大值。

主要线程池

public Glide build(@NonNull Context context) {
    if (sourceExecutor == null) {
        sourceExecutor = GlideExecutor.newSourceExecutor();//创建网络加载线程池对象
    }

    if (diskCacheExecutor == null) {
        diskCacheExecutor = GlideExecutor.newDiskCacheExecutor();//创建磁盘加载线程池对象
    }

    if (animationExecutor == null) {
        animationExecutor = GlideExecutor.newAnimationExecutor();//创建动画加载线程池对象
    }
    
}

自定义图片加载框架思路

• 异步加载：线程池
• 切换线程：Handler
• 缓存：LruCache、DiskLruCache
• 防止OOM：软引用、LruCache、图片压缩、Bitmap像素存储位置
• 内存泄露：注意ImageView的正确引用，生命周期管理
• 列表滑动加载的问题：加载错乱、队满任务过多问题

高清加载大图

加载图片一般为了尽可能避免OOM都会按照如下做法：

1. 对于图片显示：根据需要显示图片控件的大小对图片进行压缩显示。
2. 如果图片数量非常多：则会使用LruCache等缓存机制，将所有图片占据的内容维持在一个范围内。

但是对于单个图片非常巨大，并且还不允许压缩。比如：世界地图、清明上河图、微博长图等 ，以上2种方案就不适用了。

解决方案：局部加载（BitmapRegionDecoder）