KJFrameForAndroid框架学习----高效设置网络图片

转自：http://blog.csdn.net/kymjs/article/details/38128531

KJFrameForAndroid框架项目地址：https://github.com/kymjs/KJFrameForAndroid

或备用地址http://git.oschina.net/kymjs/KJFrameForAndroid

KJFrameForAndroid开发群：257053751

我们都知道，计算机读取数据时：内存的读取速度是最快的，然后是文件的读取速度，最后是网络资源的读取。

如果每次加载同一张图片都要从网络获取，那代价实在太大了。所以同一张图片只要从网络获取一次就够了，然后在本地缓存起来，之后加载同一张图片时就 从缓存中加载就可以了。从内存缓存读取图片是最快的，但是因为Android对每个应用所能使用的内存容量都有限制，所以最好再加上文件缓存。文件缓存空间也不是无限大的，容量越大读取效率越低，这个很好理解，从沙漠中找出丢失的一根针和从盘子中找到一根针，哪个容易一想即知。因此我们常设置一个限定大小比如10M。

所以，加载图片的流程应该是：

1、先从内存缓存中获取，取到则返回，取不到则进行下一步；

2、从文件缓存中获取，取到则返回并更新到内存缓存，取不到则进行下一步；

3、从网络下载图片，并更新到内存缓存和文件缓存。

如果您只想了解文件缓存与内存缓存公用，请查看下一篇博文。

在过去，我们经常会使用一种非常流行的内存缓存技术的实现，即软引用或弱引用 (SoftReference or WeakReference)。但是根据Google的描述：现在已经不再推荐使用这种方式了，因为从 Android 2.3 (API Level 9)开始，垃圾回收器会更倾向于回收持有软引用或弱引用的对象，这让软引用和弱引用变得不再可靠。另外，Android 3.0 (API Level 11)中，图片的数据会存储在本地的内存当中，因而无法用一种可预见的方式将其释放，这就有潜在的风险造成应用程序的内存溢出并崩溃。

因此，我们更多的是去使用lru算法（Least Recently Used 近期最少使用算法）最初这种算法是用在操作系统调度上的。他的原理是通过个线性表存储数据，并记录数据每次调用次数，越常用到的排名就越靠前，越少用到的排名就越靠后，如果是一个新加入的数据，就会把它放在第一位，然后移除掉排名最后一位的数据。这里是KJFrameForAndroid框架中关于内存lru算法的实现方式 LruMemoryCache

既然是加载网络图片，那么当然需要加载的控件和网络图片地址作为参数，示例如下所示

[java] view
plaincopyprint?





private void loadImage(ImageView imageView, String imageUrl) {

// 首先访问内存缓存，判断图片是否已经存在

Bitmap bitmap = mMemoryCache.get(StringUtils.md5(imageUrl));

if (bitmap != null) {

imageView.setImageBitmap(bitmap);

}else{

//否则就去网络下载

BitmapWorkerTask task = new BitmapWorkerTask(imageView);

task.execute(imageUrl);

}

}

至于实际下载的方法，我就不详细讲解了，相信大家都能想到，就是一个网络请求，然后下载图片，再转成bitmap，最后设置为控件图片。然而这里有一个需要注意的重要地方，就是当我们把图片下载成功后要记得在mMemoryCache中缓存起来。

这里是KJFraemForAndroid应用开发框架中的一段网络图片加载的代码：

[java] view
plaincopyprint?





/********************* 异步获取Bitmap并设置image的任务类 *********************/

private class BitmapWorkerTask extends AsyncTask<String, Void, Bitmap> {

private View imageView;

public BitmapWorkerTask(View imageview) {

this.imageView = imageview;

}

@Override

protected Bitmap doInBackground(String... params) {

Bitmap bitmap = null;

//有关这个方法，下面的文章将会讲解

byte[] res = downloader.loadImage(params[0]);

if (res != null) {

bitmap = BitmapCreate.bitmapFromByteArray(res, 0, res.length,

config.width, config.height);

}

if (bitmap != null && config.openMemoryCache) {

// 图片载入完成后缓存到LrcCache中

putBitmapToMemory(params[0], bitmap);

if (config.isDEBUG)

KJLoger.debugLog(getClass().getName(),

"put to memory cache\n" + params[0]);

}

return bitmap;

}

@Override

protected void onPostExecute(Bitmap bitmap) {

super.onPostExecute(bitmap);

if (imageView instanceof ImageView) {

if (bitmap != null) {

((ImageView) imageView).setImageBitmap(bitmap);

}

} else {

imageView.setBackgroundDrawable(new BitmapDrawable(bitmap));

}

if (config.callBack != null)

config.callBack.imgLoadSuccess(imageView);

taskCollection.remove(this);

}

}

深入理解图片加载在实际项目中的应用：

以上只是网络图片加载并缓存的基本操作，那么我们如果在实际项目中使用必须考虑到代码的完备性与可扩展性。

①比如我们想指定图片的大小，虽然我们可以通过设置view的固定宽高来强制图片的显示大小，但如果是一张几兆的图片，而我们只需要15*15分辨率大小的显示区域，这显然是浪费的；

②又比如，我们希望控件在网络正在下载图片时先显示一个默认的图片（比如一个灰色的头像）又或者是图片下载的时候显示一个环形的进度条，那么上面的代码是没有办法的；

③再比如，我们希望图片的下载方式有多种，对于不同网站来源有不同的下载方式。。。。

这些种种特殊的需求告诉我们，上面的代码完全没有办法做到。那么为了控件的完备性与可扩展性，我们就需要一个配置器、一个显示器、一个下载器。。等等根据特殊需要而添加的插件式开发。

因此，我们可以看到在KJFrameForAndroid框架的org.kymjs.aframe.bitmap包下有着KJBitmapConfig、I_ImageLoder、I_Display等等用final修饰的类或者协议接口。

比如KJBitmapConfig类，是一个用final修饰的配置器类，通过这个配置器，我们就可以动态的对每一张下载的图片设置宽高、以及内存大小等。而I_ImageLoder、I_Display则是两个协议接口，分别定义了下载器和显示器的方法，这里实际上是GoF设计模式中工厂方法模式的应用，只是这里的工厂实际上并不是用来创建对象，而是用来定义显示方法或下载方法的，不论是哪个实现了I_ImageLoder抽象工厂的实际工厂，都必须有一个加载图片的方法。那么在项目的实际应用中，就可以不管这个下载器的实际工厂是什么，只需要调用工厂的加载图片的方法就行了。

[java] view
plaincopyprint?





/**

* 图片载入接口协议，可自定义实现此协议的下载器

*

* @explain 采用工厂方法模式设计的下载器，本类也是一个抽象工厂类，用于生产byte[]产品

* @author kymjs(kymjs123@gmail.com)

* @version 1.0

* @created 2014-7-11

*/

public interface I_ImageLoder {

public byte[] loadImage(String imageUrl);

}

这里我们应该就可以知道上面的代码段中有这么一段代码原因了

byte[] res = downloader.loadImage(params[0]);

downloader实际上就是下载器的抽象工厂。

至于显示器的逻辑和下载器是一样的，这里我就不详细介绍了，大家可以自己查看KJFrameForAndroid的源代码或示例项目。

这里是I_ImageLoader下载器协议的一个实现类 Downloader.java，大家当然也可以根据自己的需要去实现自己的下载器，这完全没有任何作为扩展试开发，这对于图片设置代码本身没有任何影响。