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

Bien sûr, une couche d'encapsulation est nécessaire pour masquer l'implémentation. Et si de nouveaux besoins conduisaient à la nécessité d'étendre l'implémentation ?!

Supposons que le développeur utilise actuellement un framework qui ne prend pas en charge le chargement des miniatures vidéo et que la nouvelle exigence nécessite le chargement des miniatures vidéo en ligne, nous envisagerons alors de remplacer le framework d'origine par un framework prenant en charge des extensions telles que Glide (plusieurs images grand public les frameworks de chargement asynchrone peuvent charger des images et des miniatures de vidéos locales, mais pour les vidéos distantes, il appartient généralement aux développeurs d'étendre l'implémentation). S'il n'y a pas d'encapsulation auparavant, alors toutes les images doivent être chargées de manière asynchrone. Remplacez tous les appels

Ou si le framework d'origine doit être remplacé en raison de performances et de facilité d'utilisation, etc., les problèmes ci-dessus se produiront également.

Dans des circonstances normales, une application ne nécessite pas l'utilisation ou la prise en charge simultanée de plusieurs frameworks configurables. Par conséquent, il n'est pas nécessaire de la sur-concevoir, il suffit de l'encapsuler dans une classe d'outils pour masquer l'implémentation.

Answer 2

Utilisez un modèle de stratégie pour concevoir une classe d'outils de chargement d'images qui peut être commutée à tout moment
Encapsulez et implémentez une architecture de chargement d'images unifiée

De même, le chargement du réseau peut également être effectué de cette manière

Answer 3

Adhérant au principe de flexibilité, il est raisonnable de réencapsuler les bibliothèques d'outils telles que les bibliothèques de chargement d'images pour éviter d'avoir à remplacer des bibliothèques tierces en raison de changements dans les exigences. Voir la réponse précédente pour la méthode d'emballage spécifique.