目录
优秀的图片加载框架有很多,本篇文章只谈开发经验,如何去选择和应用。
一、工具选择
对比项 | Coil | Glide | Picasso | Fresco | ImageLoader |
是否维护 | true | true | true | true | false |
是否支持gif | true | true | false | true | false |
圆角、圆形 | true | true | false | true | true |
相对耦合度 | 低 | 低 | 低 | 高 | 低 |
开发语言 | koltin | java | java | java | java |
图片加载框架有很多,这里只对比了我开发以来用到的几款图片加载框架(其他的加载框架没用过没有发言权)。其他博主文章中列举了很多对比项,我只列举出几个重要的项。我目前仍在用的是Glide,原因很简单:该工具仍在维护、配置灵活、功能完整,耦合度相对较低方便进行封装。
不过后续的开发中,我可能会将Coil纳入备选,Coil是一个新的开发图片加载库,也是google力推的工具之一。它完全使用的是kotlin编写,使用的kotlin协程,网络请求默认为Okhttp,相对于其他框架有以下几个特点:
- 足够快速,它在内存、图片存储、图片的采样、Bitmap重用、暂停\取消下载等细节方面都有很大的优化
- 足够轻量,只有大概1500个核心方法;
- 足够新,也足够现代!使用了最新的Koltin协程所编写,充分发挥了CPU的性能,同时也使用了OKHttp、Okio、LifeCycle等比较新式的Android库
二、开发技巧
- 加载架构封装
在封装图片加载架构时,要做到提供统一的图片加载入口,支持底层图片加载架构的切换,并对上层业务无感。例如:
/**
* 加载图片资源
* @receiver T
* @param context Context
* @param imgUrl String? 图片地址
* @param failPic Int? 加载失败图片
*/
fun <T : ImageView> T.loadImage(
context: Context,
imgUrl: String?,
@DrawableRes failPic: Int? = R.mipmap.pic_fail_holder
) {
Glide.with(context).load(imgUrl).placeholder(R.drawable.pic_loadding_holder).error(failPic)
.into(this)
}
/******************使用方法**************************/
ivLogo.loadImage(context, url)
利用了kotlin的扩展方法,对图片加载框架进行封装。对加载错误图片做成可配置项。这样如果将来要替换图片加载框架时只需要在此扩展方法中修改一处即可。
- 图片url处理
开发中往往服务器返回给我们的图片url只是一个相对地址。比如:/temp/demo.jpg。好多同学往往都是在具体加载的地方这么写
ivLogo.loadImage(Constant.BASE_URL+url)
虽然可以加载出来,但是如果开发完了,服务器要求拼接方式改变一下(比如:url后面拼接一个token),这时是不是就是天大的灾难。如果你用kotlin开发的话可以使用扩展方法,对url进行一个简单的处理:
/**
* 获取图片URL真实地址
* @receiver CharSequence? 相对地址
* @param holder String 默认图片地址
* @return String 真实地址
*/
fun CharSequence?.getRealUrl(holder: String = "无"): String {
return if (this.isNullOrEmpty()) {
""
} else {
Constants.BASE_URL + this
}
}
/*************使用方法******************/
ivLogo.loadImage(context, url.getRealUrl())
问:为什么不把拼接放到loadImage的扩展方法中呢?
答:loadImage方法不仅可以加载网络图片,还可以用来加载本地图片。这样做可以做到职责分开。
三、总结
- 加载框架多种多样,属于自己的才是最好的,每一种框架都值得深耕。
- 框架固然好,一定要做好封装和隔离,万一要变呢。
- 根据自己的业务去封装一些东西,一定要具有前瞻性。
- 注意缓存文件的生命周期,配置好缓存路径,对将来缓存管理(垃圾清理)有帮助。
文章很简单,希望能对你有帮助。