import com.zhy.utils.ImageLoader;
public class MyAdapter extends BaseAdapter
{
private Context mContext;
private List mData;
private String mDirPath;
private LayoutInflater mInflater;
private ImageLoader mImageLoader;
public MyAdapter(Context context, List mData, String dirPath)
{
this.mContext = context;
this.mData = mData;
this.mDirPath = dirPath;
mInflater = LayoutInflater.from(mContext);
mImageLoader = ImageLoader.getInstance();
}
@Override
public int getCount()
{
return mData.size();
}
@Override
public Object getItem(int position)
{
return mData.get(position);
}
@Override
public long getItemId(int position)
{
return position;
}
@Override
public View getView(int position, View convertView, final ViewGroup parent)
{
ViewHolder holder = null;
if (convertView == null)
{
holder = new ViewHolder();
convertView = mInflater.inflate(R.layout.grid_item, parent,
false);
holder.mImageView = (ImageView) convertView
.findViewById(R.id.id_item_image);
convertView.setTag(holder);
} else
{
holder = (ViewHolder) convertView.getTag();
}
holder.mImageView
.setImageResource(R.drawable.friends_sends_pictures_no);
//使用Imageloader去加载图片
mImageLoader.loadImage(mDirPath + “/” + mData.get(position),
holder.mImageView);
return convertView;
}
private final class ViewHolder
{
ImageView mImageView;
}
}

可以看到与传统的适配器的写法基本没有什么不同之处,甚至在getView里面都没有出现常见的回调(findViewByTag~用于防止图片的错位);仅仅多了一行代码:

mImageLoader.loadImage(mDirPath + “/” + mData.get(position),holder.mImageView);是不是用起来还是相当爽的,所有需要处理的细节都被封装了。

4、ImageLoader

现在才到了关键的时刻,我们封装的ImageLoader类,当然我们的异步消息处理机制也出现在其中。

首先是一个懒加载的单例

/**
• 单例获得该实例对象
• 
• @return
*/
public static ImageLoader getInstance()
{
if (mInstance == null)
{
synchronized (ImageLoader.class)
{
if (mInstance == null)
{
mInstance = new ImageLoader(1, Type.LIFO);
}
}
}
return mInstance;
}
没啥说的,直接调用私有的构造方法,可以看到,默认传入了1(线程池中线程的数量),和LIFO(队列的工作方式)
private ImageLoader(int threadCount, Type type)
{
init(threadCount, type);
}
private void init(int threadCount, Type type)
{
// loop thread
mPoolThread = new Thread()
{
@Override
public void run()
{
try
{
// 请求一个信号量
mSemaphore.acquire();
} catch (InterruptedException e)
{
}
Looper.prepare();
mPoolThreadHander = new Handler()
{
@Override
public void handleMessage(Message msg)
{
mThreadPool.execute(getTask());
try
{
mPoolSemaphore.acquire();
} catch (InterruptedException e)
{
}
}
};
// 释放一个信号量
mSemaphore.release();
Looper.loop();
}
};
mPoolThread.start();
// 获取应用程序最大可用内存
int maxMemory = (int) Runtime.getRuntime().maxMemory();
int cacheSize = maxMemory / 8;
mLruCache = new LruCache<String, Bitmap>(cacheSize)
{
@Override
protected int sizeOf(String key, Bitmap value)
{
return value.getRowBytes() * value.getHeight();
};
};
mThreadPool = Executors.newFixedThreadPool(threadCount);
mPoolSemaphore = new Semaphore(threadCount);
mTasks = new LinkedList();
mType = type == null ? Type.LIFO : type;
}

然后在私有构造里面调用了我们的init方法,在这个方法的开始就创建了mPoolThread这个子线程,在这个子线程中我们执行了Looper.prepare,初始化mPoolThreadHander,Looper.loop;如果看过上篇博客,一定知道,此时在这个子线程中维护了一个消息队列,且这个子线程会进入一个无限读取消息的循环中,而mPoolThreadHander这个handler发送的消息会直接发送至此线程中的消息队列。然后看mPoolThreadHander中handleMessage的方法,直接调用了getTask方法取出一个任务,然后放入线程池去执行。如果你比较细心,可能会发现里面还有一些信号量的操作的代码,如果你不了解什么是信号量,可以参考: Java 并发专题 : Semaphore 实现 互斥 与 连接池 。 简单说一下mSemaphore(信号数为1)的作用,由于mPoolThreadHander实在子线程初始化的,所以我在初始化前调用了mSemaphore.acquire去请求一个信号量,然后在初始化完成后释放了此信号量,我为什么这么做呢?因为在主线程可能会立即使用到mPoolThreadHander,但是mPoolThreadHander是在子线程初始化的,虽然速度很快,但是我也不能百分百的保证,主线程使用时已经初始化结束,为了避免空指针异常,所以我在主线程需要使用的时候,是这么调用的:

/**
• 添加一个任务
• 
• @param runnable
*/
private synchronized void addTask(Runnable runnable)
{
try
{
// 请求信号量,防止mPoolThreadHander为null
if (mPoolThreadHander == null)
mSemaphore.acquire();
} catch (InterruptedException e)
{
}
mTasks.add(runnable);
mPoolThreadHander.sendEmptyMessage(0x110);
}

如果mPoolThreadHander没有初始化完成,则会去acquire一个信号量,其实就是去等待mPoolThreadHander初始化完成。如果对此感兴趣的,可以将关于mSemaphore的代码注释,然后在初始化mPoolThreadHander使用Thread.sleep去暂停1秒,就会发现这样的错误。

初始化结束,就会在getView中调用mImageLoader.loadImage(mDirPath + “/” + mData.get(position),holder.mImageView);方法了,所以我们去看loadImage方法吧

/**
• 加载图片
• 
• @param path
• @param imageView
*/
public void loadImage(final String path, final ImageView imageView)
{
// set tag
imageView.setTag(path);
// UI线程
if (mHandler == null)
{
mHandler = new Handler()
{
@Override
public void handleMessage(Message msg)
{
ImgBeanHolder holder = (ImgBeanHolder) msg.obj;
ImageView imageView = holder.imageView;
Bitmap bm = holder.bitmap;
String path = holder.path;
if (imageView.getTag().toString().equals(path))
{
imageView.setImageBitmap(bm);
}
}
};
}
Bitmap bm = getBitmapFromLruCache(path);
if (bm != null)
{
ImgBeanHolder holder = new ImgBeanHolder();
holder.bitmap = bm;
holder.imageView = imageView;
holder.path = path;
Message message = Message.obtain();
message.obj = holder;
mHandler.sendMessage(message);
} else
{
addTask(new Runnable()
{
@Override
public void run()
{
ImageSize imageSize = getImageViewWidth(imageView);
int reqWidth = imageSize.width;
int reqHeight = imageSize.height;
Bitmap bm = decodeSampledBitmapFromResource(path, reqWidth,
reqHeight);
addBitmapToLruCache(path, bm);
ImgBeanHolder holder = new ImgBeanHolder();
holder.bitmap = getBitmapFromLruCache(path);
holder.imageView = imageView;
holder.path = path;
Message message = Message.obtain();
message.obj = holder;
// Log.e(“TAG”, “mHandler.sendMessage(message);”);
mHandler.sendMessage(message);
mPoolSemaphore.release();
}
});
}
}

这段代码比较长,当然也是比较核心的代码了

10-29行:首先将传入imageView设置了path,然在初始化了一个mHandler用于设置imageView的bitmap,注意此时在UI线程,也就是这个mHandler发出的消息,会在UI线程中调用。可以看到在handleMessage中,我们从消息中取出ImageView,bitmap,path;然后将path与imageView的tag进行比较,防止图片的错位,最后设置bitmap;

31行:我们首先去从LruCache中去查找是否已经缓存了此图片

32-40:如果找到了,则直接使用mHandler去发送消息,这里使用了一个ImgBeanHolder去封装了ImageView,Bitmap,Path这三个对象。然后更新执行handleMessage代码去更新UI

43-66行:如果没有存在缓存中,则创建一个Runnable对象作为任务,去执行addTask方法加入任务队列

49行:getImageViewWidth根据ImageView获取适当的图片的尺寸,用于后面的压缩图片,代码按顺序贴下下面

54行:会根据计算的需要的宽和高,对图片进行压缩。代码按顺序贴下下面

56行:将压缩后的图片放入缓存

58-64行,创建消息,使用mHandler进行发送,更新UI

/**
• 根据ImageView获得适当的压缩的宽和高
• 
• @param imageView
• @return
*/
private ImageSize getImageViewWidth(ImageView imageView)
{
ImageSize imageSize = new ImageSize();
final DisplayMetrics displayMetrics = imageView.getContext()
.getResources().getDisplayMetrics();
final LayoutParams params = imageView.getLayoutParams();
int width = params.width == LayoutParams.WRAP_CONTENT ? 0 : imageView
.getWidth(); // Get actual image width
if (width <= 0)
width = params.width; // Get layout width parameter
if (width <= 0)
width = getImageViewFieldValue(imageView, “mMaxWidth”); // Check
// maxWidth
// parameter
if (width <= 0)
width = displayMetrics.widthPixels;
int height = params.height == LayoutParams.WRAP_CONTENT ? 0 : imageView
.getHeight(); // Get actual image height
if (height <= 0)
height = params.height; // Get layout height parameter
if (height <= 0)
height = getImageViewFieldValue(imageView, “mMaxHeight”); // Check
// maxHeight
// parameter
if (height <= 0)
height = displayMetrics.heightPixels;
imageSize.width = width;
imageSize.height = height;
return imageSize;
}
/**
• 根据计算的inSampleSize,得到压缩后图片
• 
• @param pathName
• @param reqWidth
• @param reqHeight
• @return
*/
private Bitmap decodeSampledBitmapFromResource(String pathName,
int reqWidth, int reqHeight)
{
// 第一次解析将inJustDecodeBounds设置为true,来获取图片大小
final BitmapFactory.Options options = new BitmapFactory.Options();
options.inJustDecodeBounds = true;
BitmapFactory.decodeFile(pathName, options);
// 调用上面定义的方法计算inSampleSize值
options.inSampleSize = calculateInSampleSize(options, reqWidth,
reqHeight);
// 使用获取到的inSampleSize值再次解析图片
options.inJustDecodeBounds = false;
Bitmap bitmap = BitmapFactory.decodeFile(pathName, options);
return bitmap;
}
接下来看AddTask的代码:
/**
• 添加一个任务
• 
• @param runnable
*/
private synchronized void addTask(Runnable runnable)
{
try
{
// 请求信号量,防止mPoolThreadHander为null
if (mPoolThreadHander == null)
mSemaphore.acquire();
} catch (InterruptedException e)
{
}
mTasks.add(runnable);
mPoolThreadHander.sendEmptyMessage(0x110);
}

可以看到,简单把任务放入任务队列,然后使用mPoolThreadHander发送一个消息到后台的loop中,后台的loop会取出消息执行:mThreadPool.execute(getTask());

execute执行的就是上面分析的Runnable中的run方法了。

注意一下:上述代码中还会看到mPoolSemaphore这个信号量的身影,说下用处;因为调用addTask之后,会直接去从任务队列取出一个任务,放入线程池,由于线程池内部其实也维持着一个队列,那么”从任务队列取出一个任务”这个动作会瞬间完成,直接加入线程池维护的队列中;这样会造成比如用户设置了调度队列为LIFO,但是由于”从任务队列取出一个任务”这个动作会瞬间完成,队列中始终维持在空队列的状态,所以让用户感觉LIFO根本没有效果;所以我按照用户设置线程池工作线程的数量设置了一个信号量,这样在保证任务执行完后,才会从任务队列去取任务,使得LIFO有着很好的效果;有兴趣的可以注释了所有的mPoolSemaphore代码,测试下就明白了。