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

你可能感兴趣的:(Android图片压缩加密上传 - JPEG压缩算法解析)