红色代表严重缺点
| 对比项 | ImageLoader | Picasso | Glide | Fresco | Coil |
| 库是否维护 | false | true | true | true | true |
| 是否支持gif | false | false | true | true | true |
| 是否支持webp | false | true | true | true | true |
| 大小 | 162kb | 116kb | 465K | 3.5M | 27kb |
| 方法数 | 878个 | 840个 | 2678个 | 4535个 | 1500个核心方法 |
| 圆角, 圆形 | true | false | true(需要自己实现) | true | true |
| 图片加载质量 | ARGB8888 | ARGB8888 | Glide4.0之前RGB565(默认情况下),Glide4.0之后ARGB8888 | ARGB8888 | ARGB8888或RGBA_F16 |
| 缓存级别 | 2级,内存和磁盘缓存 | 2级,内存和磁盘缓存 | 2级,内存和磁盘缓存 | 三级缓存,分别是 Bitmap缓存,未解码图片缓存, 文件缓存;内存缓存分为java内存堆和native内存堆两个部分 | 三级,内存和磁盘缓存和网络 |
| 缓存图像大小 | 原始大小 | 原始大小 | 原始大小和针对ImageView大小的result型 | 原始大小 | 可以内存缓存result型,磁盘缓存原始大小 |
| 加载策略 | 占位图 | 占位图 | 占位图 | 先加载小尺寸图片,再加载大尺寸的 | 可以以小尺寸作为占位图 |
| 加载进度 | true | false | false | true | false |
| 加载速度 | 中 | 中 | 快 | 快 | 快 |
| 内存占用 | 偏高 | 适中 | 低 | 高(分为java堆内存和native堆内存) | 适中 |
| 生命周期支持 | false | false | true | true | true |
| Easy of use | mediun | low | mediun | difficult | low |
- ImageLoader:universalImageLoader虽然好但是配置多,缓存机制没有和http的缓存很好的结合,是自己的一套缓存机制,而且ImageLoader已停止维护。
- Glide:glide的方法数量比universalImageLoader多了1000多个,容易遇到64k问题;由于是根据ImageView尺寸缓存图片,如果有多个ImageView可能内存占用会比Picasso还要高,当然可以设置只缓存原始图片;
- Picasso:不支持 GIF,并且它缓存的图片是未缩放的,使用ARGB_8888格式缓存图片,所以加载过多的大图片时,Picasso可能会OutOfMemoryError(Glide相反);
- Fresco:框架较大,影响Apk体积、使用较繁琐,需要使用内部提供的ImageView控件;
- Coil:基于kotlin语言开发设计的,需要更新的语言和技术做支持,在android的kotlin项目上使用较为友好;使用要求需在androidx版本和java 8及以上版本;
-
Picasso: 使用方便, 一行代码完成加载图片并显示, 框架体积小;
-
Glide:可以说是 Picasso 的升级版,并且支持 GIF 图片和本地视频图片加载, 图片缓存也会自动缩放,缓存配置丰富,可以配置全尺寸缓存图片或者根据ImageView尺寸缓存图片。
-
Fresco:
- 图片存储在安卓系统的匿名共享内存, 而不是虚拟机的堆内存中, 图片的中间缓冲数据也存放在本地堆内存,
所以, 应用程序有更多的内存使用, 不会因为图片加载而导致 oom(其实它是占用了很多内存的), 同时也减少垃圾回收器频繁调用回收 Bitmap
导致的界面卡顿, 性能更高. - 渐进式加载 JPEG 图片, 支持图片从模糊到清晰加载
- 图片可以以任意的中心点显示在 ImageView, 而不仅仅是图片的中心.
- JPEG 图片改变大小也是在 native 进行的, 不是在虚拟机的堆内存, 同样减少 OOM;
- 很好的支持 GIF 图片的显示
- 功能更加丰富,支持RGBA_F16格式图片
- 图片存储在安卓系统的匿名共享内存, 而不是虚拟机的堆内存中, 图片的中间缓冲数据也存放在本地堆内存,
- Coil:
1.更快: Coil 在性能上做了很多优化,包括内存缓存和磁盘缓存、对内存中的图片进行采样、复用 Bitmap、支持根据生命周期变化自动暂停和取消图片请求等
2.更轻量级: Coil 大约会给你的 App 增加两千个方法(前提是你的 App 已经集成了 OkHttp 和 Coroutines),Coil 的方法数和 Picasso 相当,相比 Glide 和 Fresco 要轻量级很多
3.更容易使用: Coil's API 充分利用了 Kotlin 语言的新特性,简化并减少了很多重复代码
4.更流行: Coil 首选 Kotlin 语言开发,并且使用包含 Coroutines、OkHttp、Okio 和 AndroidX Lifecycles 在内的更现代化的开源库
5.细节方面:Coil 开箱即用,与 R8 完全兼容,不需要添加任何额外规则;Coil默认实现四种图片转换:高斯模糊、将图片转换为圆形、实现将图片转换为灰色、为图片添加圆角;支持RGBA_F16图片格式;
小知识点:
RGBA_F16
从F16就可以看出。它每个像素占用8个字节,但是它是以半浮点数存储的,那前面的F就说的通了。Google的注释里还指明这个属性非常适合用于广色域宽屏和HDR(高动态范围的图片)。所以以此来看,它所占用的内存是最高的,因此显示的效果也非常好。
四.总结Picasso包比 Glide包体积小很多且图像质量比 Glide 3.x 高,但Glide 的速度比 Picasso 更快,Glide 的长处是处理大型的图片流,如 gif、video,如果要制作视频类应用,Glide 当为首选。
Fresco 可以说是综合了之前图片加载库的优点,但它的包体积太大,按体积进行比较:Fresco>Glide>Picasso,Fresco因为主要占用的是系统的匿名共享内存, 而不是虚拟机的堆内存,这在图片较多的应用中更能凸显其价值,如果应用没有太多图片需求,不推荐使用 Fresco。
Glide和Fresco可以绑定到Activity的生命周期中,在生命周期结束时会自动释放掉内存占用(Activity未被占用时),但是Picasso和ImageLoader需要自己手动去释放
五.glide与coil作对比- 实现语言
- Glide 全盘使用 Java 语言来实现,对于 Java 和 Kotlin 语言的友好程度差不多
- Coil 全盘使用 Kotlin 语言来实现,为 ImageView 声明了多个用于加载图片的扩展函数,对 Kotlin 语言的友好程度会更高很多
- 网络请求
- Glide 默认是使用 HttpURLConnection,但也提供了更换网络请求实现途径的入口
- Coil 默认是使用 OkHttp,但也提供了更换网络请求实现途径的入口
- 生命周期监听
- Glide 通过向 Activity 或者 Fragment 注入一个无 UI 界面的 Fragment 来实现监听
- Coil 直接通过 Lifecycle 来实现监听
- 内存缓存
- Glide 的内存缓存分为 ActiveResources 和 MemoryCache 两级
- Coil 的内存缓存分为 WeakMemoryCache 和 StrongMemoryCache 两级,本质上和 Glide 一样
- 磁盘缓存
- Glide 在加载到图片后通过 DiskLruCache 来进行磁盘缓存,且提供了是否缓存、是否缓存原始图片、是否缓存转换过后的图片等多个选择
- Coil 通过 OkHttp 的网络请求缓存机制来实现磁盘缓存,且磁盘缓存只对通过网络请求加载到的原始图片生效,不缓存其它来源的图片和转换过后的图片
- 网络缓存
- Glide 不存在这个概念
- Coil 相比 Glide 多出了一层网络缓存,可用于实现不进行网络加载,而是强制使用本地缓存(当然,如果本地缓存不存在的话就会报错)
- 线程框架
- Glide 使用原生的 ThreadPoolExecutor 来完成后台任务,通过 Handler 来实现线程切换
- Coil 使用 Coroutines 来完成后台任务及线程切换
glide缓存原理https://blog.csdn.net/gongjdde/article/details/106629601
Android图片框架对比https://www.jianshu.com/p/069d8400ebab
glide和fresco面试要问和深入理解https://www.jianshu.com/p/1ab5597af607
主流图片加载框架ImageLoader、Glide、Picasso、Fresco性能分析---内存占用比较https://blog.csdn.net/zivensonice/article/details/51835781
coil深入理解及源码分析https://juejin.cn/post/6897872882051842061



