在 Android 中进行图片压缩是非常常见的开发场景，主要的压缩方法有两种：其一是质量压缩，其二是下采样压缩。

前者是在不改变图片尺寸的情况下，改变图片的存储体积，而后者则是降低图像尺寸，达到相同目的。

质量压缩逻辑

在Android中，对图片进行质量压缩，通常我们的实现方式如下所示：

ByteArrayOutputStream outputStream = new ByteArrayOutputStream();
//quality 为0～100，0表示最小体积，100表示最高质量，对应体积也是最大
bitmap.compress(Bitmap.CompressFormat.JPEG, 100, outputStream);

在上述代码中，我们选择的压缩格式是CompressFormat.JPEG，除此之外还有两个选择：

• CompressFormat.PNG：PNG 格式是无损的，它无法再进行质量压缩，quality 这个参数就没有作用了，会被忽略，所以最后图片保存成的文件大小不会有变化；
• CompressFormat.WEBP：这个格式是 google 推出的图片格式，它会比 JPEG 更加省空间，经过实测大概可以优化 30% 左右

将 PNG 图片转成 JPEG 格式之后不会降低这个图片的尺寸，但是会降低视觉质量，从而降低存储体积。同时，由于尺寸不变，所以将这个图片解码成相同色彩模式的 bitmap 之后，占用的内存大小和压缩前是一样的。

函数 compress 经过一连串的 java 层调用之后，最后来到了一个 native 函数，如下：

//Bitmap.cpp
static jboolean Bitmap_compress(JNIEnv* env, jobject clazz, jlong bitmapHandle,jint format, jint quality,jobject jstream, jbyteArray jstorage) {LocalScopedBitmap bitmap(bitmapHandle);SkImageEncoder::Type fm;switch (format) {case kJPEG_JavaEncodeFormat:fm = SkImageEncoder::kJPEG_Type;break;case kPNG_JavaEncodeFormat:fm = SkImageEncoder::kPNG_Type;break;case kWEBP_JavaEncodeFormat:fm = SkImageEncoder::kWEBP_Type;break;default:return JNI_FALSE;}if (!bitmap.valid()) {return JNI_FALSE;}bool success = false;std::unique_ptr<SkWStream> strm(CreateJavaOutputStreamAdaptor(env, jstream, jstorage));if (!strm.get()) {return JNI_FALSE;}std::unique_ptr<SkImageEncoder> encoder(SkImageEncoder::Create(fm));if (encoder.get()) {SkBitmap skbitmap;bitmap->getSkBitmap(&skbitmap);success = encoder->encodeStream(strm.get(), skbitmap, quality);}return success ? JNI_TRUE : JNI_FALSE;
}

可以看到最后调用了函数 encoder->encodeStream(…) 编码保存本地，该函数是调用 skia 引擎来对图片进行编码压缩。

一段完整的示例代码如下：

// R.drawable.thumb 为 png 图片
Bitmap bitmap = BitmapFactory.decodeResource(getResources(), R.drawable.thumb);
try {//保存压缩图片到本地File file = new File(Environment.getExternalStorageDirectory(), "aaa.jpg");if (!file.exists()) {file.createNewFile();}FileOutputStream fs = new FileOutputStream(file);bitmap.compress(Bitmap.CompressFormat.JPEG, 50, fs);Log.i(TAG, "onCreate: file.length " + file.length());fs.flush();fs.close();
} catch (FileNotFoundException e) {e.printStackTrace();
} catch (IOException e) {e.printStackTrace();
}
//查看压缩之后的 Bitmap 大小
ByteArrayOutputStream outputStream = new ByteArrayOutputStream();
bitmap.compress(Bitmap.CompressFormat.JPEG, 50, outputStream);
byte[] bytes = outputStream.toByteArray();
Bitmap compress = BitmapFactory.decodeByteArray(bytes, 0, bytes.length);
Log.i(TAG, "onCreate: bitmap.size = " + bitmap.getByteCount() + "   compress.size = " + compress.getByteCount());

//压缩之后图片占用的存储体积
compress.length = 7814
//在内存中压缩前后图片占用的大小
bitmap.size = 350000   compress.size = 350000

对比二者，保存前的图片存储体积是 106k，质量设为 50 并且保存为 JPEG 格式之后，图片存储大小就只有 8k 了，并且质量设的越低，保存成文件之后，文件的体积也就越小。

Skia 图像引擎

Skia 是一个 Google 自己维护的 c++ 实现的图像引擎，实现了各种图像处理功能，并且广泛地应用于谷歌自己和其它公司的产品中（如：Chrome、Firefox、 Android等），基于它可以很方便为操作系统、浏览器等开发图像处理功能。

Skia 在 Android 中提供了基本的画图和简单的编解码功能，可以挂接其他的第三方编码解码库或者硬件编解码库，例如 libpng 和 libjpeg，libgif 等等。因此，这个函数调用bitmap.compress(Bitmap.CompressFormat.JPEG…)，实际会调用 libjpeg.so 动态库进行编码压缩。

最终 Android 编码保存图片的逻辑是 Java 层函数→Native 函数→Skia函数→对应第三库函数（例如 libjpeg）。所以 skia 就像一个胶水层，用来链接各种第三方编解码库，不过 Android 也会对这些库做一些修改，比如修改内存管理的方式等等。

Android 在之前从某种程度来说使用的算是 libjpeg 的功能阉割版，压缩图片默认使用的是 standard huffman，而不是 optimized huffman，也就是说使用的是默认的哈夫曼表，并没有根据实际图片去计算相对应的哈夫曼表，Google 在初期考虑到手机的性能瓶颈，计算图片权重这个阶段非常占用 CPU 资源的同时也非常耗时，因为此时需要计算图片所有像素 argb 的权重，这也是 Android 的图片压缩率对比 iOS 来说差了一些的原因之一。

图像压缩与 Huffman 算法

哈夫曼算法是在多媒体处理里常用的算法之一。

比如一个文件中可能会出现五个值 a,b,c,d,e，它们用二进制表达是：

a. 1010
b. 1011
c. 1100
d. 1101
e. 1110

我们可以看到，最前面的一位数字是 1，其实是浪费掉了，在定长算法下最优的表达式为：

a. 010
b. 011
c. 100
d. 101
e. 110

这样我们就能做到节省一位的损耗，那哈夫曼算法比起定长算法改进的地方在哪里呢？

在哈夫曼算法中我们可以给信息赋予权重，即为信息加权，假设 a 占据了 60%，b 占据了 20%， c 占据了 20%，d,e 都是 0%：

a:010  (60%)
b:011  (20%)
c:100  (20%)
d:101  (0%)
e:110  (0%)

在这种情况下，我们可以使用哈夫曼树算法再次优化为：

a:1
b:01
c:00

所以思路当然就是出现频率高的字母使用短码，对出现频率低的使用长码，不出现的直接就去掉，最后 abcde 的哈夫曼编码就对应：1 01 00。

通过权重对应生成的的哈夫曼表为：

所以这个算法一个很重要的思路是必须知道每一个元素出现的权重，如果我们能够知道每一个元素的权重，那么就能够根据权重动态生成一个最优的哈夫曼表。

但是怎么去获取每一个元素，对于图片就是每一个像素中 argb 的权重呢，只能去循环整个图片的像素信息，这无疑是非常消耗性能的，所以早期 android 就使用了默认的哈夫曼表进行图片压缩。

libjpeg 与 optimize_coding

libjpeg 在压缩图像时，有一个参数叫 optimize_coding。如果设置 optimize_coding 为 TRUE，将会使得压缩图像过程中，会先基于图像数据计算哈弗曼表。由于这个计算会显著消耗空间和时间，默认值被设置为 FALSE。

那么 optimize_coding 参数的影响究竟会有多大呢？查阅一些博客资料介绍，使用相同的原始图片，分别设置 optimize_coding=TRUE 和 FALSE 进行压缩，发现 FALSE 时的图片大小大约是 TRUE 时的 5-10 倍。换言之就是相同文件体积的图片，不使用哈夫曼编码图片质量会比使用哈夫曼低 5-10 倍。

最终，官方人员修改了这个默认的实现：在 SkImageDecoder_libjpeg.cpp 文件中给 optimize_code 赋值了一个默认值 TRUE。

Android 与 optimize_coding

那么在 Android 中有没有使用哈夫曼变长编码呢？查阅了 Android 7.0 源码，如下：

/* Use Huffman coding, not arithmetic coding, by default */
cinfo->arith_code = FALSE;

可以看到注释里面很清楚，默认是哈夫曼变长编码，而不是算数编码。同时去查阅 14 年时的 Android 4.4 源码，发现依旧如此。

对于optimize_coding，早期的 Android 考虑到性能瓶颈，将其设置为 FALSE。但是，现在 Android 手机性能比以前好很多，所以目前性能往往不是瓶颈，时间和压缩质量反而成为更重要的指标了。

为此，Google 在 Android 7.0 版本左右，也做了相应修改，如 Android 7.0 和 Android 6.0 源码所示：

Android JPEG VS. iOS JPEG

经过上面的介绍大家应该了解了为什么 Android 的 JPEG 图片压缩率会比 iOS 小一些，那么还有另一个问题就是为什么同一张 PNG 图片设置成同样的压缩质量压缩成 JPEG 之后，Android 输出的图像质量会比 iOS 差一些呢，经过相关资料的查找，发现造成这个结果有两方面的因素。

第一个因素是 JPEG 编码过程中有一个步骤是颜色空间 RGB -> YUV 的转换，之前的 Android 版本同样考虑到性能问题，skia 引擎写了一个函数替代了原来 libjpeg 的转换函数，好处是提高了编码速度，坏处就是牺牲了每一个像素的精度。

第二个因素是离散余弦变换有三种方式，Skia 引擎选择了 JDCT_IFAST，JDCT_IFAST 是最快的变换方式，当然也是精度最差的一种。

上面两种因素第一个会造成色调偏差，第二个会造成色块的出现，所以如果需要提高压缩之后的图像质量，可以考虑从这两方面入手。

质量压缩小结

从 Android 7.0 版本开始，optimize_code 标示已经设置为了 TRUE，也就是默认使用图像生成哈夫曼表，而不是使用默认哈夫曼表。而至于这个标志所产生的体积差距也没有 5-10 倍那么大，大约可以在原图的基础上缩小 10%～50% 的体积，经过修改前后不同 Android 版本实测，数据吻合。

如何提高 Android 的压缩率，这里需要提到两个库，一个是 mozilla/mozjpeg，另一个是 libjpeg-turbo，前者是一个来自 Mozilla 实验室的 JPEG 图像编码器项目，目标是在不降低图像质量且兼容主流的解码器的情况下，提供产品级的 JPEG 格式编码器来提高压缩率以减小 JPEG 文件的大小，后者相当于是一个 libjpeg 的增强版，前者也是基于后者，在后者的基础上进行了一些优化。

编码方式除了哈夫曼之外，还有定长的算术编码。对比哈夫曼编码和算术编码，网上相关资料显示算术编码在压缩 jpeg 方面可以比哈夫曼编码体积小 5%～12%，所以需要提升图片压缩率的同样也可以尝试从切换成算术编码这方面入手。

尺寸压缩逻辑

针对图片尺寸的修改其实就是一个图像重新采样的过程，放大图像称为上采样（upsamping），缩小图像称为下采样（downsampling）。

在 Android 中图片重采样提供了两种方法，一种叫做邻近采样（Nearest Neighbour Resampling），另一种叫做双线性采样（Bilinear Resampling）。

除了 Android 中这两种常用的重采样方法之外，还有另外比较常见的两种：双立方／双三次采样（Bicubic Resampling） 和 Lanczos Resampling。除此之外，还有一些其他个人或机构发明的算法 Hermite Resampling，Bell Resampling，Mitchell Resampling。

邻近采样（Nearest Neighbour Resampling）

我们先来看看在 Android 中使用邻近采样的示例代码：

BitmapFactory.Options options = new BitmapFactory.Options();
//或者 inDensity 搭配 inTargetDensity 使用，算法和 inSampleSize 一样
options.inSampleSize = 2;
Bitmap bitmap = BitmapFactory.decodeFile("/sdcard/test.png");
Bitmap compress = BitmapFactory.decodeFile("/sdcard/test.png", options);

来看看邻近采样的图片效果：

上图是每个像素红绿相间的图片，可以看到处理之后的图片已经完全变成了绿色。

我们来看看 inSampleSzie 的官方描述：
If set to a value > 1, requests the decoder to subsample the original image, returning a smaller image to save memory. The sample size is the number of pixels in either dimension that correspond to a single pixel in the decoded bitmap. For example, inSampleSize == 4 returns an image that is 1/4 the width/height of the original, and 1/16 the number of pixels. Any value <= 1 is treated the same as 1. Note: the decoder uses a final value based on powers of 2, any other value will be rounded down to the nearest power of 2.

从官方的解释中我们可以看到 x（x 为 2 的倍数）个像素最后对应一个像素，由于采样率设置为 1/2，所以是两个像素生成一个像素。邻近采样的方式比较粗暴，直接选择其中的一个像素作为生成像素，另一个像素直接抛弃，这样就造成了图片变成了纯绿色，也就是红色像素被抛弃。

邻近采样采用的算法叫做邻近点插值算法。

双线性采样（Bilinear Resampling）

双线性采样（Bilinear Resampling）在 Android 中的使用方式一般有两种：

Bitmap bitmap = BitmapFactory.decodeFile("/sdcard/test.png");
Bitmap compress = Bitmap.createScaledBitmap(bitmap, bitmap.getWidth()/2, bitmap.getHeight()/2, true);

或者直接使用 matrix 进行缩放：

Bitmap bitmap = BitmapFactory.decodeFile("/sdcard/test.png");
Matrix matrix = new Matrix();
matrix.setScale(0.5f, 0.5f);
bm = Bitmap.createBitmap(bitmap, 0, 0, bit.getWidth(), bit.getHeight(), matrix, true);

看源码可以知道 createScaledBitmap 函数最终也是使用第二种方式的 matrix 进行缩放，我们来看看双线性采样的表现：

可以看到处理之后的图片不是像邻近采样一样纯粹的一种颜色，而是两种颜色的混合。双线性采样使用的是双线性內插值算法，这个算法不像邻近点插值算法一样，直接粗暴的选择一个像素，而是参考了源像素相应位置周围 2x2 个点的值，根据相对位置取对应的权重，经过计算之后得到目标图像。

双线性内插值算法在图像的缩放处理中具有抗锯齿功能, 是最简单和常见的图像缩放算法，当对相邻 2x2 个像素点采用双线性內插值算法时，所得表面在邻域处是吻合的，但斜率不吻合，并且双线性内插值算法的平滑作用可能使得图像的细节产生退化，这种现象在上采样时尤其明显。

邻近采样和双线性采样对比

邻近采样的方式是最快的，因为它直接选择其中一个像素作为生成像素，但是生成的图片可能会相对比较失真，产生比较明显的锯齿，最具有代表性的就是处理文字比较多的图片在展示效果上的差别，对比：

原图：

邻近采样：

双线性采样：

邻近采样字的显示失真对比双线性采样来说要严重很多。

双立方／双三次采样（Bicubic Resampling）

双立方／双三次采样使用的是双立方／双三次插值算法。邻近点插值算法的目标像素值由源图上单个像素决定，双线性內插值算法由源像素某点周围 2x2 个像素点按一定权重获得，而双立方／双三次插值算法更进一步参考了源像素某点周围 4x4 个像素。

这个算法在 Android 中并没有原生支持，如果需要使用，可以通过手动编写算法或者引用第三方算法库，幸运的是这个算法在 ffmpeg 中已经给到了支持，具体的实现在 libswscale/swscale.c 文件中：FFmpeg Scaler Documentation。

双立方/双三次插值算法经常用于图像或者视频的缩放，它能比双线性内插值算法保留更好的细节质量。我们看看这个算法的实际表现和与双线性内插值算法的下采样对比。

原图：

双三次采样：

双线性采样：

就下采样来说，两者表现很相近，肉眼可见的差距不大，接下来比较一下这两种算法的上采样实际表现。

原图：

双三次采样：

双线性采样：

这两种算法的上采样结果我们还是可以看见较为明显的差距，双立方/双三次采样的锯齿是要小一些。

双立方／双三次插值算法在平时的软件中是很常用的一种图片处理算法，但是这个算法有一个缺点就是计算量会相对比较大，是前三种算法中计算量最大的，软件 photoshop 中的图片缩放功能使用的就是这个算法。

Lanczos Resampling

Lanczos 采样和 Lanczos 过滤是 Lanczos 算法的两种常见应用，它可以用作低通滤波器或者用于平滑地在采样之间插入数字信号，Lanczos 采样一般用来增加数字信号的采样率，或者间隔采样来降低采样率。

Lanczos 采样使用的 Lanczos 算法也可以用来作为图片的缩放，Lanczos 算法和双三次插值算法都是使用卷积核来通过输入像素计算输出像素，只不过在算法表现上稍有不同。

Lanczos 从算法角度讲理论上会比双三次／双立方插值算法更好一点，先来看看它和双三次／双立方采样的图片下采样对比。

原图：

Lanczos 采样：

双三次采样：

基本看不出差别，然后是这两种算法的上采样对比。

原图：

Lanczos 采样：

双三次采样：

这两种算法的上下采样结果从肉眼上看差距很小，但是从理论上来说 Lanczos 算法处理出来的图片应该是更加平滑少锯齿的。

同样的，Lanczos 算法在 ffmpeg 的 libswscale/swscale.c 中也有实现。其实不光 Lanczos 和上面的三种算法，ffmpeg 还提供了其他的图像重采样方法，诸如 area averaging、Gaussian 等等。

通过编译好的 ffmpeg 库调用这些算法处理图片的命令如下：

ffmpeg -s 600x500 -i input.jpg -s 300x250 -sws_flags lanczos lanczos.jpg

-sws_flags 参数根据采样算法可以选择 bilinear/bicubic/lanczos 等等。

四种算法对二值化图片的处理表现

这四种图片重采样算法在处理二值化图片上面的表现差异较大，我们先看看下采样的对比。

原图：

邻近采样：

双线性采样：

双三次采样：

Lanczos 采样：

下采样的对比一目了然，从上到下的图像表现效果逐渐变优，Lanczos 算法处理后的图像质量属于最优，接着我们看看这四种算法的上采样对比。

原图：

邻近采样：

双线性采样：

双三次采样：

Lanczos 采样：

从图像质量上来看，和下采样结果一致，邻近采样效果较差，依次往下效果变优，Lanczos 效果最优。

尺寸压缩小结

在 Android 中，前两种采样方法根据实际情况去选择即可，如果对时间要求不高，倾向于使用双线性采样去缩放图片。如果对图片质量要求很高，双线性采样也已经无法满足要求，则可以考虑引入另外几种算法去处理图片，但是同时需要注意的是后面两种算法使用的都是卷积核去计算生成像素，计算量会相对比较大，Lanczos 的计算量则是最大，在实际开发过程中根据需求进行算法的选择即可。