Android开发之Glide分析

本文主要从以下三条主线去分析Glide

1、了解请求怎么发送的，有没有队列，怎么维护的

2、生命周期怎么回事，Glide怎么去做的？

3、Glide是如何处理我们的请求的

首先先说一下Glide跟其他框架相比优势在哪里？

1：生命周期的管理
2：支持gif picasso也支持gif
3：三级缓存，内存缓存中还分为活动缓存和内存缓存；活动缓存指得是讲正在使用得图片用弱引用缓存，使用完成后到内存缓存；再到磁盘缓存；
4：占用内存小，它默认得编码格式是rgb565； picasso用得argb8888 ImageLoader不支持gif图片加载 而且也很老了

     rgb565 没有a的像素通道，r只占5位，g要占6位， b要占5位， 一个要占16位， 2个字节；而argb8888中，a要占8个位，r要占8个位，一个像素点要占32位，四个字节；

Glide缺点：

加载GIF的时候，第一次是 从第一帧 一直播到最后一帧。应用杀掉或者第二次再进到这个页面的时候，可能是从第五帧开始播，最好用NDK去加载

第一条线 ：load.into()方法 这个请求发送到哪里去了

发送到RequestTracker 两个队列中 ：requests和pendingRequests 请求过来之后，都是存入这两个队列；从Glide具有生命周期的特性开始推算，RequestManager 进行维护队列

第二条线：为什么RequestManager能够管理生命周期？谁在处理？

通过RequestManagerRetriever创建一个无UI的Fragment，并将这个Fragment的生命周期绑定到RequestManager上；

Glide队列请求如何处理的？

     当我们在load.into();方法时，所有的请求都会被添加到一个叫RequestTracker的队列中，这个队列有两个，一个是运行时队列，一个是等待队列；
     如果当前页面停止，onStop方法被调用，所有的运行中的请求都会被停止，并且全部添加到等待队列中；
     当开始运行时，又会把所有等待队列中的请求放到运行队列中去！

队列是如何维护的?

RequestManager with = Glide.with(this);
     通过这句代码，创建了一个RequestManager，并在Glide.with方法中，为传入的this(Activity) 创建一个无UI的Fragment，并将Fragment的生命周期绑定到ReuqestManager上。
      当Activity触发了onStop等方法时，则会隐式的调用fragment的onStop方法，再通过fragment 的onStop 调用RequestManager的onStop方法，以此来管理两个请求队列中的请求；

第三条主线

1：当RequestManager类里调用requestTracker.runRequest的时候，所有请求都会构成一个SingleRequest，并开始调用begin方法运行
2： begin方法最终会调用engine.load方法
3： 根据request构建EngineKey
4： 根据EngineKey去活动缓存中获取数据
5： 如果获取不到，去内存缓存中获取数据
6： 如果获取不到，通过硬盘缓存的线程池去获取本地硬盘的数据
7： 如果获取不到本地的，通过网络的线程池去获取网络的数据

最后说一下，如果让我自己写一个 图片加载框架，我可能会这个设计：

1：要有生命周期
2：活动缓存设计
3：内存缓存设计
4：磁盘缓存设计