Android图片压缩

一、图片的存在形式

1. 文件形式(即以二进制形式存在于硬盘上)
2. 流的形式(即以二进制形式存在于内存中)
3. Bitmap形式 （位图图像（bitmap）, 亦称为点阵图像或绘制图像，是由称作像素（图片元素）的单个点组成的。这些点可以进行不同的排列和染色以构成图样。）
     这三种形式的区别: 文件形式和流的形式对图片体积大小并没有影响,也就是说,如果你手机SD卡上的如果是100K,那么通过流的形式读到内存中,也一定是占100K的内存,注意是流的形式,不是Bitmap的形式,当图片以Bitmap的形式存在时,其占用的内存会瞬间变大, 我试过500K文件形式的图片加载到内存,以Bitmap形式存在时,占用内存将近10M,当然这个增大的倍数并不是固定的。

二、常用的压缩方法

1. 质量压缩
   质量压缩不会减少图片的像素，它是在保持像素的前提下改变图片的位深及透明度，来达到压缩图片的目的，图片的长，宽，像素都不会改变，那么bitmap所占内存大小是不会变的。
     我们可以看到有个参数：quality，可以调节你压缩的比例，但是还要注意一点就是，质量压缩对png格式这种图片没有作用，因为png是无损压缩。
2. 采样率压缩
   采样率压缩其原理是缩放bitamp的尺寸，通过调节其inSampleSize参数，比如调节为2，宽高会为原来的1/2，内存变回原来的1/4.
3. 缩放法压缩（martix）
   放缩法压缩使用的是通过矩阵对图片进行裁剪，也是通过缩放图片尺寸，来达到压缩图片的效果，和采样率的原理一样。
4. RGB_565压缩
    RGB_565压缩是通过改用内存占用更小的编码格式来达到压缩的效果。Android默认的颜色模式为ARGB_8888，这个颜色模式色彩最细腻，显示质量最高。一般不建议使用ARGB_4444，因为画质实在是辣鸡，如果对透明度没有要求，建议可以改成RGB_565，相比ARGB_8888将节省一半的内存开销。

三、压缩优化方式

Android 质量压缩逻辑

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

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

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

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

由于项目原因和兼容性选择了JPEG，因此接下来的分析也将是围绕 JPEG 展开。

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

Android Skia 图像引擎

在上文中，提到的Skia是Android 的重要组成部分。

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 来说差了一些的原因之一。

libjpeg 与 optimize_coding

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

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

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 手机性能比以前好很多，所以目前性能往往不是瓶颈，时间和压缩质量反而成为更重要的指标了。

优化思路

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

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

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

更换图片格式

提到图片格式，大家可能想到更多的是JPEG和PNG之类的格式，毕竟已经使用了很久了，兼容性很强，压缩也几乎到了该方法下所能到达的极限。然而在2013年，Google(和一些开源贡献者)创建了一种新的图片编解码算法，叫做WebP，它旨在同样的的图片质量下比JPG压缩得更小。
WebP有多屌？一张同样大小和复杂度的图片，WebP可以比JPG小24%-35%。真令人震惊，因为JPG已经把文件压缩得差不多极致了。
另外一个事实是WebP支持大部分主流的浏览器，Android原生也同样支持，IOS也提供了解析库
为了理解WebP为什么能比JPG还要省空间，我们必须了解一下它的编解码原理。

有损压缩

WebP 的压缩是使用与 VP8 相同的方式来预测帧。VP8 基于块预测与任何基于块的编解码器一样，VP8 将帧划分为称为宏块(MarcoBlocking)的小块。在每个宏块内，编码器可以基于先前处理的块来预测冗余运动和颜色信息。图像帧是“关键”，意思是它仅使用已经在每个宏块的直接空间邻域中解码的像素。并试图对它们的未知部分进行赋值。这就称为与预测编码。然后可以从块中减去冗余数据，进而有效压缩。

宏块(MarcoBlocking)

编码器的第一阶段是将图像分割成“宏块”。宏块包含一个 16x16 的亮度像素块，和两个 8x8 的色度像素块。这个阶段非常像 JPEG 格式里转换颜色空间，对色度通道降低采样，以及细分图片。

预测

宏块里每个4x4的子块都有一个预测模型。(又名过滤)。在PNG里过滤用得非常多，它对每一行都做同样的事，而WebP过滤的是每一块。它是这样处理的，在一个块周围定义两组像素:有一行在它上面为A，在它左边那一列为L。

利用A和L，编码器会将它们放在一个4x4的测试像素块填满，并确定哪一个生成了最接近原始块的值。这些用不同方法填满的块叫做"预测块"。

Horiz prediction(水平预测)——将块的每列使用左列（L）数据的副本进行填充。
Vertical Prediction(垂直预测)——将块的每行使用上列（A）数据的副本进行填充。
DC Prediction(DC 预测)——将块使用 A 上列的像素与 L 左列的像素的平均值进行填充。
True Motion (TrueMotion 预测)——一种超级先进的模式，我暂时不讲。

值得注意的是，4x4的亮度块还有另外6种模式，但你现在只需知道这些就好;)

基本流程是我们找到这个快最佳的预测块，并导出过滤结果(剩余误差)，然后送到下个阶段。

JPGify it

WebP编码的最后阶段看起来非常像我们的老朋友JPG:

对块里剩余的值执行DCT过滤
DCT矩阵后量化
转成量化矩阵后重新排序，然后送到一个静态压缩器里。

这有主要有两点不同：

1. 在DCT阶段输入的数据不是原始的数据块本身，而是预测后的数据
2. WebP用得静态压缩器是算术压缩器，它和JPG用的霍夫曼编码器类似。

总结

从最后的结果看WebP感觉有点像加强版的JPG。WebP的预测阶段相比JPG是最大的优势，它减少了特殊颜色，使得在以后的处理阶段能更有效的压缩图片数据。同时它也改进了编码器，拥有大约10%的提升。