一、简介：
在开发过程中，我们或多或少的都会接触到Bitmap这个东西，用的不好的话就会出现OOM问题，同时，也会有压缩的需求，可能有人会说，向Glide不是已经对图片压缩了么，但有时向图片上传到服务器功能，还得需要我们手动处理，去压缩图片后，再上传，否则，会造成上传很慢，尤其是用户网速不好的时候，还会浪费用户流量，甚至上传失败。
二、首先了解一下关于Bitmap的Config的理解
1、）A：透明度 R：红色 G：绿 B：蓝
public enum Config {
ALPHA_8 (1),
RGB_565 (3),
@Deprecated
ARGB_4444 (4),
ARGB_8888 (5);
}
Bitmap.Config ARGB_4444：每个像素占四位，即A=4，R=4，G=4，B=4，那么一个像素点占4+4+4+4=16位
Bitmap.Config ARGB_8888：每个像素占四位，即A=8，R=8，G=8，B=8，那么一个像素点占8+8+8+8=32位
Bitmap.Config RGB_565：每个像素占四位，即R=5，G=6，B=5，没有透明度，那么一个像素点占5+6+5=16位
Bitmap.Config ALPHA_8：每个像素占四位，只有透明度，没有颜色。
2、）内存计算
一张 1024 * 1024 像素，采用ARGB8888格式，一个像素32位，每个像素就是4字节，占有内存就是4M若采用RGB565，一个像素16位，每个像素就是2字节，占有内存就是2M。
Glide加载图片默认格式RGB565，Picasso为ARGB8888，默认情况下，Glide占用内存会比Picasso低，色彩不如Picasso鲜艳，自然清晰度就低。
通常我们优化Bitmap时，当需要做性能优化或者防止OOM（Out Of Memory），我们通常会使用Bitmap.Config.RGB_565这个配置，因为Bitmap.Config.ALPHA_8只有透明度，显示一般图片没有意义，Bitmap.Config.ARGB_4444显示图片不清楚，Bitmap.Config.ARGB_8888占用内存最多。
图片加载
如果我们想要加载一张大图到内存中，如果不进行压缩的话，那么很显然就会出现OOM的崩溃，
譬如我们加载一张5440*3000的大图到手机上面，如果不进行压缩处理的话，那么就会出现OOM。
错误日志如下
java.lang.OutOfMemoryErrorandroid.graphics.BitmapFactory.nativeDe
codeStream(Native
Method)android.graphics.BitmapFactory.decodeStreamInternal(Bitmap
Factory.java:703)android.graphics.BitmapFactory.decodeStream(Bitm
apFactory.java:679)android.graphics.BitmapFactory.decodeFile(Bitma
pFactory.java:446)android.graphics.BitmapFactory.decodeFile(Bitmap
Factory.java:480)com.example.ly.bitmapdemo.MainActivity.onCreate(M
ainActivity.java:21)
导致这种情况的发生的根据原因就是内存溢出，Android给每个APP的内存都是有限的，所以不能容忍这种情况的发生，所以我们就必须进行压缩一下。
压缩后的效果如下：
图片压缩
我们在上传一张图片到服务器时一般都会先进行压缩一下，这样不仅可以节省流量同时也可以节约上传的时间。最近碰到项目里碰到一个问题：图片上传时，有时会出现超时的问题，客户那边出现的频率非常高，而我的手机却基本没出现过，检查了一下原因，大概有两个：
客户的网速不是太好，3G速度不够，上传图片需要很长时间导致超时产生。图片很大，占了3、4M，没经过压缩直接上传，导致超时产生。
针对以上两种情况，主要对于第二种原因进行优化。总结来说就是将图片进行压缩再上传，经过一系列的操作，发现超时现象基本不会出现了，原先2M的图片，经过压缩只有50Kb不到，压缩率达到60%，效果很明显。
原理分析
如何将一张大图压缩到100kb以下并且保持不失真的特性？这就需要用到下面这个类了BitmapFactory.Options
BitmapFactory.Options缩放图片主要用到inSample采样率，
inSample = 1，采样后图片的宽高为原始宽高
inSample > 1，例如2，宽高均为原图的宽高的1/2
一个采用ARGB8888的1024 *1024 的图片
inSample = 1，占用内存就 1024 *1024 *4 = 4M
inSample = 2，占用内存就 512 *512 * 4 = 1M
BitmapFactory 给我们提供了一个解析图片大小的参数类 BitmapFactory.Options ，把这个类的对象的 inJustDecodeBounds 参数设置为 true，这样解析出来的 Bitmap 虽然是个 null，但是 options 中可以得到图片的宽和高以及图片的类型。得到了图片实际的宽和高之后我们就可以进行压缩设置了，主要是计算图片的采样率。
//第一次采样
BitmapFactory.Options options = new BitmapFactory.Options();
//该属性设置为true只会加载图片的边框进来，并不会加载图片具体的像素点,也就是说不会把图片加载到内存中
options.inJustDecodeBounds = true;
//第一次加载图片，这时只会加载图片的边框进来，并不会加载图片中的像素点
BitmapFactory.decodeFile(filePath, options);
//获得原图的宽和高
int outWidth = options.outWidth;
int outHeight = options.outHeight;
接下来就需要进行选定压缩的采样率了。目前市场上的主流手机分辨率一般最低是720-1280了所以就按照此分辨率进行压缩
//原始图片的宽度与720的比值，然后向上取整这里为8
int wRatio = (int) Math.ceil(options.outWidth / (float) 720);
//原始图片的高度与1280的比值，然后向上取整这里为3
int hRatio = (int) Math.ceil(options.outHeight / (float) 1280); //获取采样率
if (wRatio > 1 && hRatio > 1) {
if (wRatio > hRatio) {
options.inSampleSize = wRatio;
} else {
options.inSampleSize = hRatio;
}
}
经过上面这个采样率进行压缩后的宽和高肯定是小于720-1270的，我们计算的结果是：680-375
我们来实际比较一下压缩结果：
原先：54403000*如果采用ARGB_8888模式的话，那么如果不压缩直接加载到内存的话，那么它将占：
5440/1024 *3000/1024 *4 = 62.25M，不崩溃才怪呢~
那么现在：680375*见证奇迹的时候，680/1024 *375/1024 *4=0.9M
两者一比较的话，那么效果还是比较明显的，相差大约64倍，所以还是可以的。当然了经过上面的压缩方法，我们将压缩后的图片上传到服务器的话，那么将会大大的减少流量同时也会减少上传超时的几率的。
当然了，如果还嫌大的话，我们可以进一步增加压缩的比例，可以设置成480800*，那么这样的话，质量肯定是有所下降的。
这里是图片二次采样的代码
public class BitmapUtils {
/**
* @param filePath 要加载的图片路径
* @param destWidth 显示图片的控件宽度
* @param destHeight 显示图片的控件的高度
* @return
*/
public static Bitmap getBitmap(String filePath, int destWidth, int destHeight) {
//第一次采样
BitmapFactory.Options options = new BitmapFactory.Options();
//该属性设置为true只会加载图片的边框进来，并不会加载图片具体的像素点
options.inJustDecodeBounds = true;
//第一次加载图片，这时只会加载图片的边框进来，并不会加载图片中的像素点
BitmapFactory.decodeFile(filePath, options);
//获得原图的宽和高
int outWidth = options.outWidth;
int outHeight = options.outHeight;
//定义缩放比例
int sampleSize = 1;
while (outHeight / sampleSize > destHeight || outWidth / sampleSize > destWidth) {
//如果宽高的任意一方的缩放比例没有达到要求，都继续增大缩放比例
//sampleSize应该为2的n次幂，如果给sampleSize设置的数字不是2的n次幂，那么系统会就近取值
sampleSize *= 2;
}
/********************************************************************************************/
//至此，第一次采样已经结束，我们已经成功的计算出了sampleSize的大小
/********************************************************************************************/
//二次采样开始
//二次采样时我需要将图片加载出来显示，不能只加载图片的框架，因此inJustDecodeBounds属性要设置为false
options.inJustDecodeBounds = false;
//设置缩放比例
options.inSampleSize = sampleSize;
options.inPreferredConfig = Bitmap.Config.ARGB_8888;
//加载图片并返回
return BitmapFactory.decodeFile(filePath, options);
}
}
