目前项目使用的图片加载框架是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个关键对象 图片来源
和控件
独立出来,然后调用图片加载框架真正的对图片进行处理,这样的话我可以在不创建多余对象的情况下,避免并发的问题吗......
高洛峰2017-04-18 09:18:00
もちろん、実装を隠すためにカプセル化の層が必要です。新しいニーズによって実装を拡張する必要が生じた場合はどうなるでしょうか?!
開発者が現在ビデオ サムネイルのロードをサポートしていないフレームワークを使用しており、新しい要件ではオンライン ビデオ サムネイルのロードが必要であると仮定します。その場合、元のフレームワークを Glide などの拡張機能をサポートするフレームワークに置き換えることを検討します (いくつかの主流の画像非同期読み込みフレームワークは画像とローカル ビデオのサムネイルを読み込むことができますが、リモート ビデオの場合、実装の拡張は通常、開発者に任されています)。事前にカプセル化がない場合は、すべての画像を非同期的に読み込む必要があります。<🎜 を置き換えます。 >
または、パフォーマンスや使いやすさなどの理由で元のフレームワークを置き換える必要がある場合にも、上記の問題が発生します。通常の状況では、アプリは構成可能な複数のフレームワークを同時に使用したりサポートしたりする必要はありません。そのため、過剰に設計する必要はなく、実装を隠すためにツール クラスにカプセル化するだけです。
黄舟2017-04-18 09:18:00
戦略パターンを使用して、いつでも切り替え可能なイメージ読み込みツール クラスを設計します
統合されたイメージ読み込みアーキテクチャをカプセル化して実装します
同様に、ネットワークの読み込みもこの方法で行うことができます
黄舟2017-04-18 09:18:00
柔軟性の原則に従い、要件の変更によるサードパーティのライブラリの置き換えの必要性を避けるために、画像読み込みライブラリなどのツール ライブラリを再カプセル化することが合理的です。具体的な梱包方法については、前の回答を参照してください。