简介
从用户角度上看对上手机流量的关心,一张图片1 - 4M,如果每次都请求网络加载,一张重复的图片却要加载多次很容易消耗特别多的流量。从android平台机制上,android 移动端本身内存就小,首先如果加载一张大的bitmap很有可能出现OOM,这时就需要对bitmap进行优化处理,加上图片的加载速度的要求,从内存读取一张图片的速度是相当快的,速度上 内存>磁盘>网络情求,所以在android开发中图片的缓存技术是非常必要的。
Bitmap优化处理
BitmapFactory.Opetions 里有个属性isSampleSize默认为1,代表以原图加载,当设isSampleSize=2,则图片的宽高都缩小两倍,则图片的大小缩小为原来的1/4,同理当isSampleSize=4,则图片的宽高都缩小4倍,则图片的大小缩小为原来的1/16,所以具体要缩小多少倍要根据imageview的宽高确定,太小图片就会太模糊。
下面是代码示例:
public Bitmap resizeBitmap(InputStream in,int reqWidth,int reqHeigth)
{
BitmapFactory.Opetions option = new BitmapFactory.Opetions();
//设为true后不会加载图片,只会解析图片的基本信息
option.inJustDecodeBounds = true;
//解析
BitmapFactory.decodeStream(in,null,option);
//得出图片的宽
int width = option.outWidth;
//得出图片的高
int heigth = option.outHeigth;
int isSampleSize = 1;
while(width > reqWidth || heigth > reqHeigth)
{
width/=2;
heigth/=2;
isSampleSize*=2;
}
//可缩小图片,这步是关键
option.isSampleSize = isSampleSize;
option.inJustDecodeBound = false;
return BitmapFatory.decodeStream(in,null,option);
}
框架介绍
- 图片压缩器
- LruCache 缓存
- DiskLruCache缓存
- 异步加载器
- 图片加载器
框架设计图如下:
基本流程:
值得注意的是异步加载最好使用线程池,图片加载会很频繁,多次的线程创建跟销毁很消耗资源,在android中对线程的优化也是尽量使用线程池。在框架中的异步加载器,可以setExcutor(Excutor) 可以复用开发者本身设的线程池,否则不用这方法默认自动建一个线程池。