android - 应不应该对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

Of course we need to encapsulate a layer to hide the implementation. What if there are new needs that lead to the need to extend the implementation?!

Suppose the developer is currently using a framework that does not support loading video thumbnails, and the new requirement requires loading online video thumbnails, then we will consider replacing the original framework with a framework that supports extensions such as Glide (mainstream Several image asynchronous loading frameworks can load images and local video thumbnails, but for remote videos, it is usually left to the developer to extend the implementation). If there is no encapsulation before, then you have to make all the calls to asynchronous loading of all images. Replaced it again.

Or if the original framework needs to be replaced due to performance & ease of use, etc., the above problems will also occur.

Under normal circumstances, an App does not require the simultaneous use or support of configurable multiple frameworks. Therefore, there is no need to over-design it, just encapsulate it into a tool class to hide the implementation.

Answer 2

Use strategy pattern to design an image loading tool class that can be switched at any time
Encapsulate and implement a unified image loading architecture

Similarly, network loading can also be done in this way

Answer 3

Adhering to the principle of flexibility, it is reasonable to re-encapsulate tool libraries such as image loading libraries to avoid the need to replace third-party libraries due to changes in requirements. See the previous answer for the specific packaging method.