android图片压缩的完整的解决方案

     对与andorid图片的压缩,小伙伴们的可能都是用的bitmap.compress()方法,一般也没啥问题.开始我也是用的这个方法,这2天客户反映,压缩以后图片不够清楚,仔细去看,还真是,同一张图andorid和ios压出来的效果差距好大,这是为什么呢,经过不断的百度谷歌,发现原来是谷歌挖了一个坑,这个坑是什么呢,下面就开始我们的蛋疼之路.

     首先简单介绍一下一般的安卓图片压缩,第一步计算图片的压缩比

/**
	 * 计算图片的缩放值
	 * 
	 * @param options
	 * @param reqWidth
	 * @param reqHeight
	 * @return
	 */
	public static int calculateInSampleSize(BitmapFactory.Options options,
			int reqWidth, int reqHeight) {
		// Raw height and width of image
		final int height = options.outHeight;
		final int width = options.outWidth;
		int inSampleSize = 1;

		if (height > reqHeight || width > reqWidth) {

			// Calculate ratios of height and width to requested height and
			// width
			final int heightRatio = Math.round((float) height
					/ (float) reqHeight);
			final int widthRatio = Math.round((float) width / (float) reqWidth);

			// Choose the smallest ratio as inSampleSize value, this will
			// guarantee
			// a final image with both dimensions larger than or equal to the
			// requested height and width.
			inSampleSize = heightRatio < widthRatio ? heightRatio : widthRatio;
		}

		return inSampleSize;
	}

2,第2步获取到压缩的bitmap

/**
	 * 根据路径获的图片并压缩返回bitmap用于显示
	 * 
	 * @param imagesrc
	 * @return
	 */
	public static Bitmap getSmallBitmap(String filePath) {
		final BitmapFactory.Options options = new BitmapFactory.Options();
		options.inJustDecodeBounds = true;
		BitmapFactory.decodeFile(filePath, options);

		// Calculate inSampleSize
		options.inSampleSize = calculateInSampleSize(options, 640, 960);

		// Decode bitmap with inSampleSize set
		options.inJustDecodeBounds = false;
		Bitmap localBitmap1 = BitmapFactory.decodeFile(filePath, options);
		int j = readPictureDegree(filePath);
		Bitmap localBitmap2 = null;
		// 旋转图片
		if ((localBitmap1 != null) && (j != 0)) {
			localBitmap2 = rotaingImageView(j, localBitmap1);
			localBitmap1.recycle();
			localBitmap1 = null;
			return localBitmap2;
		}

		return localBitmap1;
	}

    上面的640,和960  可以自己定义合适的大小到这一步你已经取到了等比例缩小的图片了,接下来主要把图片的质量压到100,200k就ok了

bm.compress(Bitmap.CompressFormat.JPEG, 60, baos);

    经过compress方法  其实我们已经完成了对图片的压缩.那么那个坑到底在哪里呢? 答案是libjpeg.那么libjpeg是什么?请看下面这段(ps纯引用)
libjpeg是广泛使用的开源JPEG图像库（参考 http://en.wikipedia.org/wiki/Libjpeg ），安卓也依赖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。
    这段解释乍看起来没有任何问题，libjpeg的代码也经受了十多年的考验，健壮而高效。但很多人忽略了这一点，那就是，这段解释是十多年前写的，对于当 时的计算设备来说，空间和时间的消耗可能是显著的，但到今天，这似乎不应再是问题，相反，我们应该更多的考虑图片的品质（越来越好的显示技术）和图片的大 小（越来越依赖于云服务）。
    谷歌的Skia项目工程师们最终没有设置这个参数，optimize_coding在Skia中默认的等于了FALSE，这就意味着更差的图片质量和更大的图片文件，而压缩图片过程中所耗费的时间和空间其实反而是可以忽略不计的。那么，这个参数的影响究竟会有多大呢？
    经我们实测，使用相同的原始图片，分别设置optimize_coding=TRUE和FALSE进行压缩，想达到接近的图片质量（用Photoshop 放大到像素级逐块对比），FALSE时的图片大小大约是TRUE时的5-10倍。换句话说，如果我们想在FALSE和TRUE时压缩成相同大小的JPEG 图片，FALSE的品质将大大逊色于TRUE的（虽然品质很难量化，但我们不妨说成是差5-10倍）。
    我们又对Android和iOS进行了对比（均使用标准的JPEG压缩方法），两个系统都没有提供设置optimize_coding的接口（通过阅读源 码，我们已经知道Android是FALSE，iOS不详），当压缩相同的原始图片时，结果也是一样，iOS完胜。想要品质接近，文件大小就会差出 5-10倍，而如果要压缩出相同大小的文件，Android的压缩品质简直就是惨不忍睹。
    结果说明，苹果很清楚optimize_coding参数和哈弗曼表的意义，这里需要特别指出，苹果使用的哈弗曼表算法与libjpeg（及我们后来自行 采用的libjpeg-turbo）不同，像素级可以看出区别，苹果似乎基于libjpeg又进行了进一步的优化，压缩出来的图片细节上更柔和、更平滑。

    看了上面的一大段,小伙伴们应该已经明白了为什么压缩的质量不行,那要这么解决呢,
我们直接替换libjpeg库!库文件请见附件(ps:这个c库其实是从github大神那边下载的https://github.com/bither/bither-android-lib),用法就是把2个库文件放到libs文件的下armeabi文件夹下,没有就新建一下 配合一个工具类NativeUtil.

    最后祝小伙伴们少跳坑,多运动 !