Glide小结
整体加载流程
Glide加载主要分为三个阶段，分别是在调用with、load、into方法的时候
-
在with方法中，Glide会初始化各种资源，比如请求管理器、缓存、生命周期监听等
-
在load方法中，会创建请求加载任务，然后封装各种请求参数
-
在into方法中，开始真正加载图片，加载图片会先从当前活动内存中查找，没找到再从LRU内存缓存中找，最后再通过网络等原始路径去获取图片，获取到图片之后会对它进行解码转换等处理，然后会缓存到本地以及内存当中，最终显示出来
生命周期管理
生命周期管理主要分两种情况，如果传入的是activity或者fragment，则会创建一个空的Fragment添加到当前Activity中用于监听生命周期的变化，当界面正在显示时则会去加载，界面不显示就暂停，退出则取消任务；
如果传入的是Application则图片加载任务开始后就会一直在后台进行，一直到任务结束或者进程结束
缓存管理
缓存有两种，一种内存缓存，一种磁盘缓存，内存缓存又分为“当前活动缓存”和“LRU缓存”；活动缓存是用于保存当前正在显示的图片，LRU缓存是用来保存当前未显示的图片，当加载图片时会优先从活动缓存中查找，如果没有就从LRU缓存中找，找到的话就会从LRU缓存移动到活动缓存中，都没找到才从磁盘缓存中取；
之所以有个LRU缓存还要活动缓存，一方面这个活动缓存是弱引用的，当内存不够时会自动回收这部分内存，而LRU缓存是强引用的；如果只有LRU缓存，当容量不够时有可能会导致正在显示的图片被回收掉
内存管理
-
在加载图片的时候，会根据显示控件的大小来裁剪图片并缓存到本地，减少图片在内存中的占用
-
通过监听生命周期，在图片不再需要显示时进行回收
-
在onLowMemory/onTrimMemory方法中判断如果系统内存紧张，则回收部分内存
扫描二维码关注公众号，回复： 14703896 查看本文章
-
建立Bitmap回收池，在图片回收时会将Bitmap回收到池子中避免重新创建，在设置Bitmap属性时设置inBitmap属性可以复用bitmap内存
-
inBitmap:复用Bitmap内存，在Android4.4之前必须要宽高一致才能复用，之后版本只要大于等于就可以
-
inSampleSize=4：宽高变成原来的1/4
-
inJustDecodeBunds：不讲bitmap加载进内存，只返回图片高宽等基本信息
-
bitmap内存占用计算：图片长x宽x每个像素占用字节大小(编码格式)
-
ARGB_8888：每个通道占8位，一个字节是8位，每个像素占用4个字节，支持透明度
-
ARGB_4444：每个通道占4位，一个字节是8位，每个像素占用2个字节，支持透明度，图片比较失真
-
ARGB_565：红绿蓝通道分别占5、6、5位，一个字节是8位，每个像素占用2个字节，但不支持透明度
-
ALPHA_8:只有透明通道，占用8位，1个字节，每个像素占用1个字节
-
-
-
使用弱引用管理，在一次GC后会自动回收内存
-
滑动时卡顿可能是由于频繁发起图片加载请求导致内存抖动引起的，改成滑动停止时才加载
Gif图片如何加载
在图片加载时检测到是git图片，会将gif图里一张张图片解析成Bitmap，然后通过Handler循环去加载一张张图
线程池
Glide在GlideExecutor类中定义了4个线程池，一个是用于本地缓存图片用的，一个用于解析Gif图片的，另外两个用于网络请求
图片变绿问题
早期Glide默认编码格式是ARGB_565，这种编码格式RGB通道分别占用5\6\5位，也就是绿色通道比其他通道要多1位，当图片被压缩比较厉害的时候，绿色通道颜色占比就更多，看起来就更绿一些；
现在默认都是ARGB_8888作为编码格式就没有这个问题了；ARGB_8888这种编码格式，每个通道都占用8位，不会出现某个通道色值更多导致偏色问题