Android图片压缩加密上传 - JPEG压缩算法解析

1. 概述

---

我们在开发的过程中，肯定很多项目都需要上传图片文件，我们往往都是直接上传，相信很多都并未对其做过压缩。当然很多哥们估计也在这方面费劲心思，往往都是采用google提供好的BitmapFactory,但是效果不太理想，如果觉得还行那请把3M的图片压缩到30K或者更小试试看看效果，这里考大家一个经常问到的面试题：一张 421x633 的 PNG 图片，我把它放到 drawable-xhdpi 目录下，在红米NOTE3上加载，占用内存是多少？

效果演示

为什么要压缩图片然后再上传这个就不用说了，十张5M的图片直接上传到服务器想想都觉得可怕，那为什么我们BitmapFactory压缩的图片效果并不理想呢？又或者说为什么Android一张5M还比不过苹果一张500K的清晰呢？这就需要从Android的发展史开始讲起，但是你若看过BitmapFactory的NDK部分的源码就会清晰的找到这么一段代码：

static jobject doDecode(JNIEnv* env, SkStreamRewindable* stream, jobject padding,
        jobject options, bool allowPurgeable, bool forcePurgeable = false) {

    // ....省略
    float scale = 1.0f;
    // 请留意一下这个C++对象
    SkBitmap outputBitmap;

    // 判断图片是否需要缩放
    const bool willScale = scale != 1.0f;
    isPurgeable &= !willScale;
   
    // 更新options
    if (options != NULL) {
        // 设置图片最终显示出来的宽高为缩放后的宽高
        env->SetIntField(options, gOptions_widthFieldID, scaledWidth);
        env->SetIntField(options, gOptions_heightFieldID, scaledHeight);
        env->SetObjectField(options, gOptions_mimeFieldID,
                getMimeTypeString(env, decoder->getFormat()));
    }

    // ....省略

    // 创建Bitmap对象
    return GraphicsJNI::createBitmap(env, outputBitmap, javaAllocator.getStorageObj(),
            bitmapCreateFlags, ninePatchChunk, layoutBounds, -1);
}

上面我们只要留意一下SkBitmap这个对象就好了，如果你能够找到doDecode这个方法并且能够看得懂里面的所有代码，那么你就可以回答出我的问题了，这里我没有详细说明对于图片压缩，我提的这个问题然并卵，但这是我面试必问的一个题目。
　　SkBitmap中的前缀SK你可以认为是Skia，这是google所采用的一套图片算法，为什么要采用这个算法呢？图片又大，3M的图片可能还不够清晰，具体请看Skia官网。

2. JPEG压缩算法解析

---

既然我们知道了原因，那么我们打算采用JPEG来压缩，后面压缩的时候你会发现内存蹭蹭的往上走，好在我们现在手机都不是用的Android第一代了，对于这点内存还是小Case。接下来我们主要分析JPEG的压缩算法，如果听JPEG的发展史请自行google或者百度。目前绝大部分图片都使用了JPEG压缩技术，通常JPEG文件相对于原始图像,能够得到1/8的压缩比，反编译BAT的一些apk你会发现也在使用。

2.1 RGB转YCbCr

图像被分割成大小为8X8的小块，这些小块在整个压缩过程中都是单独被处理的。我们常见的“RGB”模型，就是把颜色分解成红绿蓝三种分量，这样一张图片就可以分解成三张灰度图，数学表达上，每一个8X8的图案，可以表达成三个8X8的矩阵，其中的数值的范围一般在[0,255]之间。而在JPEG压缩算法中，需要把图案转换成为YCbCr模型，这里的Y表示亮度(Luminance)，Cb和Cr分别表示绿色和红色的“色差值”。最终可以得到RGB转换为YCbCr的数学公式为：

对于一张图片RGB可以得到三张灰度图，YCbCr也能够得到三张图片

　　我们能够发现有一张图片我们感觉比较好就是Y，而Cb和Cr基本没感觉，所以我们可以对Cr和Cb做一下处理，反正没感觉可以再搞得更加没感觉。这种方式就是针对数据的重要程度不同做不同的处理。这就是为什么JPEG使用这种颜色空间的原因。

2.2 离散余弦变换

离散余弦变换（Discrete cosine transform），简称DCT。离散余弦变换属于傅里叶变换的另外一种形式，没错，就是大名鼎鼎的傅里叶变换。傅里叶是法国著名的数学家和物理学家，他认为任何周期性的函数，都可以分解为为一系列的三角函数的组合，这个想法一开始并没有得到当时科学界的承认，比如当时著名的数学家拉格朗日提出质疑，三角函数无论如何组合，都无法表达带有“尖角”的函数，一直到1822年拉格朗日死后，傅里叶的想法才正式在他的著作《热的解析理论》一书中正式发表。金子总会闪光，傅里叶变换如今广泛应用于数学、物理、信号处理等等领域，变换除了它在数学上的意义外，还有其哲学上的伟大意义，那就是，世上任何复杂的事物，都可以分解为简单的事物的组合，而这个过程只需要借助数学工具就可以了。但是当年拉格朗日的质疑是正确的，三角函数的确无法表达出尖角形状的函数，不过只要三角函数足够多，可以无限逼近最终结果。比如下面这张动图，就动态描述了一个矩形方波，是如何做傅里叶分析的。

一些公式我就不贴了大家可以上网找找，我估计没个两年肯定是看不懂的，实话说就算有个两年的数据结构和算法也不一定行，不要问我我也不行，如果是做应用开发如果没有多少时间其实没必要去深究,了解就好，当然闲得不行还是可以研究一下的。

2.3 哈弗曼编码

对于哈弗曼编码我们还是有可能明白的，JPEG压缩的最后一步是对数据进行哈弗曼编码(Huffman coding)，哈弗曼几乎是所有压缩算法的基础，它的基本原理是根据数据中元素的使用频率，调整元素的编码长度，以得到更高的压缩比。
　　举个例子，比如下面这段数据
　　AABCBABBCDBBDDBAABDBBDABBBBDDEDBD
　　这段数据里面包含了33个字符，每种字符出现的次数统计如下

　　如果我们用我们常见的定长编码，每个字符都是3个bit。

　　那么这段文字共需要3 x 33 = 99个bit来保存，但如果我们根据字符出现的概率，使用如下的编码

　　这段文字共需要3 x 6 + 1 x 15 + 4 x 2 + 2 x 9 + 4 x 1 = 63个bit来保存，压缩比为63%，哈弗曼编码一般都是使用二叉树来生成的，这样得到的编码符合前缀规则，也就是较短的编码不能够是较长编码的前缀，比如上面这个编码，就是由下面的这颗二叉树生成的。

最终经过一系列的处理以及数据的量化，我们保存长度为64的数组大概10字节就可以了，当然还可以更优只要你能想到。

所有分享大纲：2017Android进阶之路与你同行

视频讲解地址：http://pan.baidu.com/s/1boUdYdL