开发中避免不了要与Bitmap打交道，但随着手机的屏幕及分辨率提高图片质量也得到很大提高，这就当来一系列的BUG源。
一个就是OOM，OOM不单给程序带来问题，还对用户的使用带来不好的体验（这里就不能容忍了）。
Bitmap怎么会引起OOM的？
- 1.每个机型在编译的时候ROM都设置了一个应用对内存VM的上限，用来限制每个应用可用的最大内存，当程序的运行内存超过这个阈值就会内存溢出OOM。一般根据手机屏幕dpi大小递增。
- 2.图片分辨率越高，消耗的内存越大，当加载高分辨率图片的时候，将会非常占用内存，一旦处理不当就会OOM。
- 3.在使用ListView, GridView等这些大量加载view的组件时，如果没有合理的处理缓存，大量加载Bitmap的时候，也将容易引发OOM。
Bitmap所占内存
Bitmap所占用的内存 = 图片长度 x 图片宽度 x 一个像素点占用的字节数。
而Bitmap.Config，正是指定单位像素占用的字节数的重要参数。
ALPHA_8
表示8位Alpha位图,即A=8,一个像素点占用1个字节,它没有颜色,只有透明度 。
ARGB_4444
表示16位ARGB位图，即A=4,R=4,G=4,B=4,一个像素点占4+4+4+4=16位，2个字节 。
ARGB_8888
表示32位ARGB位图，即A=8,R=8,G=8,B=8,一个像素点占8+8+8+8=32位，4个字节 。
RGB_565
表示16位RGB位图,即R=5,G=6,B=5,它没有透明度,一个像素点占5+6+5=16位，2个字节。
注：A代表透明度；R代表红色；G代表绿色；B代表蓝色。
Bitmap加载
BitmapFactory提供的解析Bitmap的静态工厂方法有以下五种：
decodeFile(...)
decodeResource(...)
decodeByteArray(...)
decodeStream(...)
decodeFileDescriptor(...)
其中常用的三个：decodeFile、decodeResource、decodeStream。
decodeFile和decodeResource其实最终都是调用decodeStream方法来解析Bitmap。
Bitmap优化
1.BitmapConfig的配置
2.使用decodeFile、decodeResource、decodeStream进行解析Bitmap时，配置inDensity和inTargetDensity，两者应该相等,值可以等于屏幕像素密度*0.75f
3.使用inJustDecodeBounds预判断Bitmap的大小及使用inSampleSize进行压缩
4.对Density>240的设备进行Bitmap的适配（缩放Density）
5.4.4以下版本inPurgeable、inInputShareable的使用
7.Bitmap的回收
所以我们根据以上的思路，我们将Bitmap优化的策略总结为以下3种：
1.对图片质量进行压缩
2.对图片尺寸进行压缩
3.使用libjpeg.so库进行压缩
对图片质量进行压缩
ByteArrayOutputStream baos = new ByteArrayOutputStream();
//质量压缩方法，这里100表示不压缩，把压缩后的数据存放到baos中
//一般是循环判断如果压缩后图片是否大于设置的KB
bitmap.compress(Bitmap.CompressFormat.JPEG, 100, baos);
//把压缩后的数据baos存放到ByteArrayInputStream中
ByteArrayInputStream isBm = new ByteArrayInputStream(baos.toByteArray());
//把ByteArrayInputStream数据生成图片
Bitmap newBitmap = BitmapFactory.decodeStream(isBm, null, null);
对图片尺寸进行压缩
/** 根据手机屏幕的宽高设置图片的大小 */
public Bitmap getFitBitmap(InputStream inputStream ,int mWidth ,int mHeight) {
if (inputStream == null) {
return null;
}
BitmapFactory.Options options = new BitmapFactory.Options();
options.inJustDecodeBounds = true;
try {
BitmapFactory.decodeStream(inputStream ,new Rect(0 ,0 ,0 ,0) ,options);
int width = options.outWidth;
int height = options.outHeight;
int sampleSize = 1;
if (width > mWidth || height >mHeight) {
while (width/sampleSize > mWidth || height/sampleSize >mHeight) {
sampleSize *= 2;
}
}
options = new BitmapFactory.Options();
options.inJustDecodeBounds = false;
options.inSampleSize = sampleSize;
options.inPreferredConfig = Bitmap.Config.RGB_565;
return BitmapFactory.decodeStream(inputStream ,new Rect(0 ,0 ,0 ,0) ,options);
}catch (Exception e) {
Log.e("BitmapUtil" ,"=== "+ e);
}
return null;
}
使用libjpeg.so库进行压缩
除了通过设置simpleSize根据图片尺寸压缩图片和通过Bitmap.compress方法通过压缩图片质量两种方法外，我们还可以使用libjpeg.so这个库来进行压缩。
libjpeg是广泛使用的开源JPEG图像库，Android所用的是skia的压缩算法，而Skia对libjpeg进行了的封装。
libjpeg在压缩图像时，有一个参数叫optimize_coding，关于这个参数，libjpeg.doc有如下解释：
boolean optimize_coding TRUE causes the compressor to compute optimal
Huffman coding tables for the image. This requires an extra pass over the
data and therefore costs a good deal of space and time. The default is
FALSE, which tells the compressor to use the supplied or default Huffman
tables. In most cases optimal tables save only a few percent of file size
compared to the default tables. Note that when this is TRUE, you need not
supply Huffman tables at all, and any you do supply will be overwritten.
如果设置optimize_coding为TRUE，将会使得压缩图像过程中基于图像数据计算哈弗曼表，由于这个计算会显著消耗空间和时间，默认值被设置为FALSE。
谷歌的Skia项目工程师们最终没有设置这个参数，optimize_coding在Skia中默认的等于了FALSE，但是问题就随之出现了，如果我们想在FALSE和TRUE时压缩成相同大小的JPEG 图片，FALSE的品质将大大逊色于TRUE的，尽管谷歌工程师没有将该值设置为true,但是我们可以自己编译libjpeg进行图片的压缩。
libjpeg的官网下载地址：http://www.ijg.org/ 。从官网下载之后，我们必须自己对其进行编译。
