项目正在改版，即时通讯功能暂时删除了。
1 有哪些常用的图片加载库？
当下使用的主要有Piccaso、Fresco、Android-Universal-Image-Loader、Glide、Volley这五个图片加载框架。 关于这些图片加载框架的对比，网上可以找到很多文章。这里不做过多赘述。具体请参考5中的参考链接，肯定会对你有帮助。
2 为什么要封装？
这个段落的答案，摘抄自Stormzhang的文章 如何正确使用开源项目？
计算机史上有个万能的解决方案就是，如果原有层面解决不了问题，那么就请再加一层！
对于开源项目，我们知道有些库设计的确实很棒，使用者调用起来非常方便，一行代码直接搞定，拿图片加载库 Picasso 举个例子：
|
1 |
Picasso.with(context).load(imageUrl).into(imageView); |
使用起来是不是特简单？你也许问我，都封装的这么好了还用得着再封装一层么？那你错了，哪怕他已经很完美了，我都会这么做：
|
1 2 3 4 5 |
public class ImageLoader { public static void with(Context context, String imageUrl, ImageView imageView) { Picasso.with(context).load(imageUrl).into(imageView); } } |
这样我所有项目调用的方式直接就是 ImageLoader.with() ，这样做的好处是：
入口统一，所有图片加载都在这一个地方管理，一目了然，即使有什么改动我也只需要改这一个类就可以了。
随着你们业务的需求，发现 Picasso 这个图片加载库已经满足不了你们了，你们需要换成 Fresco ，如果你没有封装一层的话，想要替换这个库那你要崩溃了，要把所有调用 Picasso 的地方都改一遍，而如果你中间封装了一层，那真的非常轻松，三天两头的换一次也没问题。
这就是所谓的外部表现一致，内部灵活处理原则。
3 有哪些需求？
这里提供我平常开发用到的两个需求：
3.1 图片封装，提供统一入口。封装成熟的图片框架，也就解决了这些问题：（内存缓存，磁盘缓存，网络加载的结合，利用采样率对图片进行一定的压缩，高效加载bitmap，图片的加载策略，缓存策略（LRU），图片错位 ，优化列表的卡顿）
3.2 提供wifi下加载图片开关，非wifi下显示占位图片。
4 怎么实现图片封装？
4.1 整体目录
在我的mvp搭建的项目中，imageloader放在和activity，fragment同级的widget下面。当然后续也会不断的添加widget（小控件），比如这里的loading（加载），netstatus（网络状态监听），progress（Material 进度条），swipeback（滑动返回）等。
4.2 ImageUtil类
作为整个ImageLoader的公共访问入口，以后使用的方式，将会是
|
1 2 |
ImageLoader imageLoader =new ImageLoader.Builder().url("img url").imgView(mImgView).build(); ImageLoaderUtil.getInstance().loadImage(context,imageLoader); |
这种形式。可以看到ImageUtil提供的是单例模式，进行了封装(后期引入Dagger2 之后直接会修改使用ImageLoaderUtil实例的方式)。全局应该只提供一个ImageLoader的实例，因为图片加载中又有线程池，缓存系统和网络请求等，很消耗资源，所以不可能让它构造多个实例。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 |
package edu.com.base.ui.widget.imageloader; import android.content.Context; /** * Created by Anthony on 2016/3/3. * Class Note: * use this class to load image,single instance */ public class ImageLoaderUtil { public static final int PIC_LARGE = 0; public static final int PIC_MEDIUM = 1; public static final int PIC_SMALL = 2; public static final int LOAD_STRATEGY_NORMAL = 0; public static final int LOAD_STRATEGY_ONLY_WIFI = 1; private static ImageLoaderUtil mInstance; private BaseImageLoaderStrategy mStrategy; private ImageLoaderUtil(){ mStrategy =new GlideImageLoaderStrategy(); } //single instance public static ImageLoaderUtil getInstance(){ if(mInstance ==null){ synchronized (ImageLoaderUtil.class){ if(mInstance == null){ mInstance = new ImageLoaderUtil(); return mInstance; } } } return mInstance; } public void loadImage(Context context,ImageLoader img){ class="crayon-h"> void loadImage(Context context,ImageLoader img){ ݽ库？
当下使用的主要有Piccaso、Fresco、Android-Universal-Image-Loader、Glide、Volley这五个图片加载框架。 关于这些图片加载框架的对比，网上可以找到很多文章。这里不做过多赘述。具体请参考5中的参考链接，肯定会对你有帮助。 2 为什么要封装？这个段落的答案，摘抄自Stormzhang的文章 如何正确使用开源项目？ 计算机史上有个万能的解决方案就是，如果原有层面解决不了问题，那么就请再加一层！ 对于开源项目，我们知道有些库设计的确实很棒，使用者调用起来非常方便，一行代码直接搞定，拿图片加载库 Picasso 举个例子：
使用起来是不是特简单？你也许问我，都封装的这么好了还用得着再封装一层么？那你错了，哪怕他已经很完美了，我都会这么做：
这样我所有项目调用的方式直接就是 ImageLoader.with() ，这样做的好处是： 入口统一，所有图片加载都在这一个地方管理，一目了然，即使有什么改动我也只需要改这一个类就可以了。 随着你们业务的需求，发现 Picasso 这个图片加载库已经满足不了你们了，你们需要换成 Fresco ，如果你没有封装一层的话，想要替换这个库那你要崩溃了，要把所有调用 Picasso 的地方都改一遍，而如果你中间封装了一层，那真的非常轻松，三天两头的换一次也没问题。 这就是所谓的外部表现一致，内部灵活处理原则。 3 有哪些需求？这里提供我平常开发用到的两个需求： 3.1 图片封装，提供统一入口。封装成熟的图片框架，也就解决了这些问题：（内存缓存，磁盘缓存，网络加载的结合，利用采样率对图片进行一定的压缩，高效加载bitmap，图片的加载策略，缓存策略（LRU），图片错位 ，优化列表的卡顿） 3.2 提供wifi下加载图片开关，非wifi下显示占位图片。 4 怎么实现图片封装？4.1 整体目录 在我的mvp搭建的项目中，imageloader放在和activity，fragment同级的widget下面。当然后续也会不断的添加widget（小控件），比如这里的loading（加载），netstatus（网络状态监听），progress（Material 进度条），swipeback（滑动返回）等。
4.2 ImageUtil类 作为整个ImageLoader的公共访问入口，以后使用的方式，将会是
这种形式。可以看到ImageUtil提供的是单例模式，进行了封装(后期引入Dagger2 之后直接会修改使用
|
