应不应该对Picasso进行一层包装?

Question

目前项目使用的图片加载框架是Picasso ,但是只使用到了部分功能.

现在看来很多地方显示图片都是直接使用

Picasso.with(c).load(path).into(img);

现在我在想如果以后想要换成Glide的话,那么会有很多地方都需要修改,所以我是不是应该对Picasso 进行一层包装,加载图片的时候使用包装类去进行任务,以后切换图片加载框架的时候成本也小一些?

public class Display {
    public static Picasso with(Context context) {
        return Picasso.with(context);
    }
}

如果有用的话这样可以吗? 有点菜,关爱一下本人新手....

但是这样的话,也只是因为Glide 和Picasso 加载图片的API 比较相似,如果使用了其他命令,例如占位符,错误显示图片等,这样的处理没有任何帮助,如果是其它的图片加载框架,那么还是一个灾难.

我应该把显示一张图片所需要的2个关键对象 图片来源 和控件 独立出来,然后调用图片加载框架真正的对图片进行处理,这样的话我可以在不创建多余对象的情况下,避免并发的问题吗......

Answer 1

当然要封装一层来隐藏实现呀, 万一有新需要导致需要扩展实现呢?!

假设开发者目前使用了一个不支持加载视频缩略图的框架, 而新需求又要求加载在线视频缩略图, 那么这是我们就会考虑把原有框架替换为Glide等支持扩展的框架(主流的几个图片异步加载框架都能加载图片还有本地视频的缩略图, 但是对于远程视频一般都会交给开发者自己去扩展实现). 如果之前没有封装, 那么就只好把所有图片异步加载的调用全部替换一遍了.

又或者由于性能 & 易用性等原因需要替换原有框架, 也会出现上述问题.

正常情况下, 一个App并不会要求同时使用或者支持可配置多框架, 因此, 没必要过度设计, 只需将其封装成一个用于隐藏实现的工具类就好了.

Answer 2

使用策略模式设计一个可以随时切换的图片加载工具类
封装并实现统一的图片加载架构

同理，网络加载也可以这么做

Answer 3

秉承flexible的原则，对图片加载库等工具库进行二次封装是合理的，以免出现需求改动带来的第三方库需要替换的情况。具体封装的方法见上一回答。