说在开头
图片加载作为基本需求，迎来送往我们都经历了好几代图片加载库了，开源库是越做越好，我们也是跟着更新换代，但是时间悠悠过去了，我们的基本功呢，大家能看懂源码吗，能从中吸收优秀的设计和代码吗，我们的基本功，代码思路跟着进步了吗，带着这个疑问，我们再来回顾下我们都经历了哪些开源图片加加载库：
- 12年： imageLoader
- 13年：Picasso - Square 出品
- 14年： Glide - google 出品
- 15年： Fresco - Facebook 出品
很明显的大家可以看出来， 图片加载这块是越来越大牌的厂商参与进来，为啥，很简单，图片加载是现在继网络之后最重要的 app 基本需求了，而且图片加载需要耗费大量系统资源，CPU,memory，GPU，对 app 的影响越来越大，现在哪个 app 没有大量的动态图片呢，做的好的 app 显示和柔和，混动很平和，做的一般的呢，显示生硬，快速滑动很卡。当然现在做图片加载这个工恩那个也是要求越来越多，要加载视频截图，高清大图。图片加载功能呢是现在的基本功，好在各大公司如今进入进来，省了我们好多事，但是呢也不是我们简简单单调一下 API 就可以不管的了，后面还有优化和各种思路，策略可以玩的，这个功能做的一般是本分，做的好呢是优势，现在 app 各大基础功能都有优秀的开源库，怎么才能体现出我们的价值呢，除了拓展面，就是做好我们的本分了 app ，app 做的不卡，界面绚丽，效果出众，过度自然，平滑，架构清晰，易于扩展，修改，添加功能，模块可插拔，基础功能组件化，apk 包要小，打包，编译，测试自动化，可定制，bug 可动态修复，这就是我们目前 app 的追求，纵观市面，能都做到的真没几个，有也是小 app，因为新所以新，因为小所以快，但是像淘宝，京东的就一般了，但是人家做到规模经济了，不再以 app 为卖点了。
这里我们按照时间线来对比下最新的几个大厂的开源库，了解其理论，方能知其优势，择优取之。
Picasso 与 Glide对比
-
相似
Glide 和 Picasso在API的调用上 非常相似，且都支持图片的内存缓存，都是非常优秀的图片加载框架，可以说Glide是Picasso的升级，在性能上有所提升。
差异
1.缓存方式不同
首先Picasso是2级缓存，它支持内存缓存而不支持磁盘缓存；而Glide是3级缓存，也就是说依次按照内存 > 磁盘 >网络的优先级来加载图片。再者，二者图片缓存的策略不同。将同一张网络图片加载到相同大小的ImageView中，Glide 加载的图片质量是不如Picasso的，原因是：Glide 加载图片默认的 Bitmap 格式是 RGB-565，一个像素点占32位 ，而 Picasso默认的格式是ARGB-8888 ，一个像素点占16位，所以Glide的内存开销要小一半。当然 Glide也可以通过GlideModule 将 Bitmap 格式转换到 ARGB-8888。还有一点， Picasso 是加载了全尺寸的图片到内存，下次在任何ImageView中加载图片的时候，全尺寸的图片将从缓存中取出，重新调整大小，然后缓存。而 Glide 是按 ImageView 的大小来缓存的，它会为每种大小的ImageView缓存一次。尽管一张图片已经缓存了一次，但是假如你要在另外一个地方再次以不同尺寸显示，需要重新下载，调整成新尺寸的大小，然后将这个尺寸的也缓存起来。具体说来就是：假如在第一个页面有一个200x200的ImageView，在第二个页面有一个100x100的ImageView，这两个ImageView本来是要显示同一张图片，却需要下载两次。结论：Glide的这种方式优点是加载显示非常快，但同时也需要更大的空间来缓存。
关于加载图片是占用内存，glide几乎是Picasso的2倍，可以用网上一张图来说明，这个你可以通过AndroidStudio Monitors自行查看。
[图片上传失败...(image-5e4e2a-1517545111529)]
生命周期的问题
Glide 的 with() 方法不光接受 Context,还能接收 Activity 和 Fragment的实例,,这样做的好处是：图片加载会和 Activity/Fragment 的生命周期保持一致，比如 Paused 状态在暂停加载，在 Resumed 的时候又自动重新加载。个人建议传参的时候传递Activity 和 Fragmen的实例t给Glide，而不是Context。
GIF
Glide可以加载GIF动态图，而Picasso不能。而且Glide加载动图的时候不需要做特别的配置，正常传入动图的url即可，它会自动识别。
库的大小不同
Picasso的大小大概100k，而Glide的大小大概500k。单纯这个大小还好，更重要的是Picasso和Glide的方法个数分别是840和2678个，这个差距还是很大的，对于DEX文件65535个方法的限制来说，2678是一个相当大的数字了，建议在使用Glide的时候开启ProGuard。
Fresco
之所以在最后介绍它，是因为它和前面2者的差异较大，而且相对比较复杂，但是它可以说是综合了前面这些图片框架的有点，如果对图片要求比较高的应用，推荐使用它。
- 优点:
-
图片存储在安卓系统的匿名共享内存, 而不是虚拟机的堆内存中, 图片的中间缓冲数据也存放在本地堆内存,所以, 应用程序有更多的内存使用, 不会因为图片加载而导致 oom, 同时也减少垃圾回收器频繁调用回收 Bitmap
导致的界面卡顿, 性能更高.
渐进式加载 JPEG 图片, 支持图片从模糊到清晰加载，尤其是慢网络有极大的利好，可带来更好的用户体验。
图片可以以任意的中心点显示在 ImageView, 而不仅仅是图片的中心.
JPEG 图片改变大小也是在 native 进行的, 不是在虚拟机的堆内存, 同样减少 OOM
很好的支持 GIF 图片的显示
-
缺点
1.包较大（2~3M）
2.用法复杂
3.底层涉及c++领域，阅读源码深入学习难度大
总结
Glide能做到Picasso所能做到的一切，两者的区别是 Picasso 比 Glide 体积小很多且图像质量比 Glide 高，但Glide 的速度比 Picasso 更快，Glide 的长处是处理大型的图片流，如 gif、video，如果要制作视频类应用，Glide 当为首选。Fresco 可以说是综合了之前图片加载库的优点，但它的包很大，用法比较复杂，API不够简洁。 Fresco 在图片较多的应用中更能凸显其价值，如果应用没有太多图片需求，还是不推荐使用 Fresco，Glide基本就能满足你的需求
