Picasso.with(这里只能传入上下文) .
Glide.with,后面可以传入上下文,Application实例,Activity实例,FragmentActivity实例,Fragement实例,View实例。传入的对象要比前者多。Context会自动的从它们获取。同时将Activity/Fragment作为with()参数的好处是:
图片加载会和Activity/Fragment的生命周期保持一致
,比如Pause状态会自动暂停加载,Resume的时候又自动重新加载。所以建议传递Activity 和 Fragment给Glide,而不是Context。
2.加载后图片质量不同
Picasso采用的ARGB-8888,Glide采用的是RGB-565,比ARGB_8888格式的内存开销要小一半。当然Glide也可以通过GlideModule设置格式。
相对而言,Picasso加载的是全图,图片质量和清晰度要比Glide的要高,但是,因为加载的采样率过高,导致出现OOM异常的概率要比Glide要大很多.
3.加载Gif图片(备注:Gif图片消耗太多内存,尽量谨慎使用):
Picasso不能加载Gif图片
Glide可以加载Gif图片
4.缓存策略和加载速度.
Picasso缓存的是全尺寸,而 Glide的缓存的跟ImageView的尺寸相同.
将ImageView调整为不同的大小,不管大小如何设置,Picasso只缓存一个全尺寸的图片,Glide会为每个大小的ImageView都缓存一张图片.
Glide的这个特点,让加载显得特别的快,而Picasso则因为需要
在显示之前重新调整大小
而导致一些延迟,(即便是添加了 noFade)
5.Picasso (v2.5.1)大小约为118KB,然而Glide (v3.5.2)的大小约为430KB。Picasso的方法数大约480,然而Glide的方法数约2678。
6.总结:
总的来说二者极为相似,有着近乎相同的 API 风格,但
Glide 在缓存策略和加载 gif 方面略胜一筹
。
Glide比Picasso加载速度要快,其实它是在Picasso的基础上进行了第二次封装,但是Glide比Picasso需要更多的空间来缓存;Glide加载图像以及磁盘缓存的方式,都优于Picasso,且Glide更有利于减少OutOfMemoryError的发生;
Glide中的大部分设置项都可以
通过 RequestOptions 类和 apply() 方法来应用到程序中
。
RequestOptions options = new RequestOptions()
.placeholder(R.mipmap.ic_launcher) //加载成功之前占位图
.error(R.mipmap.ic_launcher) //加载错误之后的错误图
.override(400,400) //指定图片的尺寸
//指定图片的缩放类型为fitCenter (
等比例缩放图片
,宽或者高等于ImageView的宽或高。)
.fitCenter()
//指定图片的缩放类型为centerCrop (
等比例缩放图片
,直到图片的宽高都大于等于ImageView的宽度,然后截取中间的显示。)
.centerCrop()
.circleCrop()//指定图片的缩放类型为centerCrop (圆形)
.skipMemoryCache(true) //跳过内存缓存
.diskCacheStrategy(DiskCacheStrategy.ALL) //缓存所有版本的图像
.diskCacheStrategy(DiskCacheStrategy.NONE) //跳过磁盘缓存
.diskCacheStrategy(DiskCacheStrategy.DATA) //只缓存原来分辨率的图片
.diskCacheStrategy(DiskCacheStrategy.RESOURCE) //只缓存最终的图片
;
Glide.with(this)
.load(url)
.apply(options)
.into(imageView);
Glide.get(this).clearDiskCache();//
IO操作,
不能在UI线程里跑,得另开一个线程。
Glide.get(this).clearMemory();//
只能在主线程里跑
得到bitmap
private SimpleTarget target =
new SimpleTarget<Bitmap>() {
@Override
public
void
onResourceReady
(Bitmap bitmap, Transition<?
super Bitmap> transition) {
imageView1.setImageBitmap( bitmap );
private
void
loadImageSimpleTarget
() {
Glide.with( context )
Glide高级用法: https://www.jianshu.com/p/cfb3d467687d
https://www.cnblogs.com/whoislcj/p/5558168.html
https://www.jianshu.com/p/c3a5518b58b2
集以上二者之长的Fresco
Fresco 中设计有一个叫做
Image Pipeline
的模块。它
负责从网络,从本地文件系统,本地资源加载图片
。为了最大限度节省空间和CPU时间,它含有3级缓存设计(2级内存,1级磁盘)。
Fresco中设计有一个叫做
Drawees模块
,它会在
图片加载完成前显示占位图
,加载成功后自动替换为目标图片。当
图片不再显示在屏幕上时,它会及时地释放内存和空间占用
。
·内存管理
解压后的图片,即Android中的Bitmap,占用大量的内存。大的内存占用势必引发更加频繁的GC。在5.0以下,GC将会显著地引发界面卡顿。
在5.0以下系统,Fresco将图片放到一个特别的内存区域。当然,在图片不显示的时候,占用的内存会自动被释放。这会使得APP更加流畅,减少因图片内存占用而引发的OOM。
Fresco 在低端机器上表现一样出色,你再也不用因图片内存占用而思前想后。
·图片绘制
Fresco 的 Drawees 设计,带来一些有用的特性:
1.自定义居中焦点
2.
圆角图
,当然圆圈也行
3.
下载失败之后,点击重现下载
4.
自定义占位图,自定义overlay, 或者进度条
5.
指定用户按压时的overlay
·图片加载
Fresco的
Image Pipeline
允许你用很多种方式来自定义图片加载过程,比如:
1.
为同一个图片指定不同的远程路径,或者使用已经存在本地缓存中的图片
2.
先显示一个低清晰度的图片,等高清图下载完之后再显示高清图(渐进式呈现)
3.加载完成回调通知
4.对于本地图,如有EXIF缩略图,在大图加载完成之前,可
先显示缩略图
5.缩放或者旋转图片
6.对已下载的图片
再次处理
7.
支持WebP解码
,即使在早先对WebP支持不完善的Android系统上也能正常使用!
·动图加载
加载Gif图和WebP动图在任何一个Android开发者眼里看来都是一件非常头疼的事情。每一帧都是一张很大的Bitmap,每一个动画都有很多帧。Fresco让你没有这些烦恼,它处理好每一帧并管理好你的内存。
·图片的渐进式呈现
渐进式的JPEG图片格式已经流行数年了,渐进式图片格式先呈现大致的图片轮廓,然后随着图片下载的继续,呈现逐渐清晰的图片,这对于移动设备,尤其是慢网络有极大的利好,可带来更好的用户体验。
说了那么多总之Fresco就是吊!
最后,进行总结一下
Picasso 所能实现的功能 Glide 都能做到,只是所需设置不同。两者的区别是 Picasso 比 Glide 体积小很多且图像质量比 Glide 高,但Glide 的速度比 Picasso 更快,Glide 的长处是处理大型的图片流,如 gif、video,如果要制作视频类应用,Glide 当为首选。
Fresco 可以说是综合了之前图片加载库的优点,其在5.0以下的内存优化非常好,但它的不足是体积太大,按
体积进行比较:Fresco>Glide>Picasso
,所以 Fresco 在图片较多的应用中更能凸显其价值,如果应用没有太多图片需求,还是不推荐使用 Fresco。
内存缓存和硬盘缓存分别的作用
一个完善的图片加载框架一般都包含内存缓存和硬盘缓存两种缓存策略。他们的作用各不相同,内存缓存主要是
防止应用重复的把数据读到内存中
,而硬盘缓存主要是
防止应用重复的去网络上下载图片
。这样才能让框架
加载图片的速度更快
,也能
更省流量
。
Glide的内存缓存机制:LruCache算法 + WeakReference弱引用
代码示例使用讲解:
Picasso,Glide,Fresco以及UIL使用经验的整理: https://www.jianshu.com/p/93198a80bda7
Glide缓存机制代码解析(了解):https://blog.csdn.net/mingyunxiaohai/article/details/80174923
Glide的缓存策略的配置使用(掌握):https://blog.csdn.net/shangming150/article/details/77839016
Picasso的使用
示例: https://www.cnblogs.com/kim-liu/p/7457033.html
Picasso加载图片的内存优化实践:https://blog.csdn.net/ashqal/article/details/48005833