Android 进阶学习(十五) Glide源码学习(四) 通过

关于Glide的文章已经写完三篇了,虽然不能说已经了解了他所有的优点,但是大部分优点已经了然于胸了,下面就从源码的角度来分析一下他的优点,

相对于其他图片加载框架的优点

1.Google 官方出品，后期稳定性肯定没有问题

在Glide 问世之前,绝大部分App使用应该是都是ImageLoader这个框架,但是由于出现了很多优秀的框架,作者就放弃继续对它维护了,一个优秀的框架,虽然在实际开发过程中肯定是通过封装Utils来加载图片,如果需要更换新的jar包的话其实需要修改的代码并不多,但是总还是需要学习成本的,再说突然引入一种新的框架,不说使用起来有多坑,但是部分问题还是存在风险的,

2.感知生命中周期

在利用Glide.with 时获取到了DLC单例模式创建RequestManagerRetriever，在执行RequestManagerRetriever 的get（）方法时得到了一个RequestManager, RequestManager 实现了LifecycleListener, 利用与宿主绑定的Fragment 来感知宿主生命周期,从而释放资源

3.可以加载本地mp4文件，

这个有点是从网上看到的,但是亲自试验了一下确实是可以,虽然只能获取到一帧图片,但是相较于其他框架,还是有很大的提升的

4.根据尺寸缓存图片

在DecodeJob中的磁盘缓存分为了2种,一种是ResourceCacheGenerator 按照既定的宽高去缓存图片,还有一种就是DataCacheGenerator 缓存的原图,内团缓存也同样的原理,这样做的好处是不用每次加载本地文件都需要根据尺寸重新渲染，响应速度快，但是不同的尺寸会占据跟多的内存，各有优略吧，

5.优化了内存缓存

在Engine 一中添加了一个ActiveResources,他当中的维护的数据是活跃的RequestManager所请求的指定宽高的图片,如果当前RequestManager被回收,则将数据维护到LruCache,这样大大的减少了由于布局刷新导致的图片重载在内存中中的查找速度,

6.内存消耗小

默认的bitmap格式是RGB_565 ，相比ARGB_8888 4个字节节省了1半

7.线程池区分

在分析DecodeJob的过程中我们发现,在读取磁盘缓存和从网上下载时,使用的线程池是有所不同的,为什么要用不同的线程池,我说一下我自己的考虑的,从网络上获取这个肯定是存在一定的风险的,timeout 的时间,线程池的主要线程数,线程池的最大线程数,对于磁盘来说他的执行速度肯定是快于网络请求的,在没有异常的情况下也不需要timeout的时间, Glide 在这个方面都区分的如此的细致,可见在各个方面上都下足了功夫,

8 优秀的设计

其实任何一个框架的产生肯定都有他独到的想法,但是能做的想Glide这么好的,确实是比较少了,一个网络框架各个模块我们都可以自己去定义,修改配置,应用到全局,